Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: OpenGL rendering in SFML2.0, questions.  (Read 1681 times)

0 Members and 1 Guest are viewing this topic.

pjuke

  • Newbie
  • *
  • Posts: 3
    • View Profile
OpenGL rendering in SFML2.0, questions.
« on: January 15, 2013, 04:53:22 pm »
Hi!
I have worked a bit with SFML lately and creating small games. However, I've noticed there is ways of rendering content using OpenGL.

My question is; is it preferable to render my images with OpenGL, instead of just calling window.draw(myDrawable) on the screen? My game is just a simple 2D game and doesn't require 3D rendered graphics.

I was thinking of developing a small particle system for my game. I have looked at some exampels on the internet, and found that they render the particles (the sf::Image using getPixelsPtr()) using OpenGL. As I've read, doesn't SFML render the images with OpenGL by default? Using the sf::Rendertarget::draw() function?

I'm a beginner at games, please go easy on me.
But I'm trying to figure out if I should render my sprites using the sf::Image together with OpenGL, or just stick to the sf::Sprite and the default draw()-method. Since it both uses OpenGL I guess.

Thanks in advance.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 11027
    • View Profile
    • development blog
    • Email
Re: OpenGL rendering in SFML2.0, questions.
« Reply #1 on: January 15, 2013, 05:32:13 pm »
My question is; is it preferable to render my images with OpenGL, instead of just calling window.draw(myDrawable) on the screen? My game is just a simple 2D game and doesn't require 3D rendered graphics.
Not really, since you'd only have to recreate what SFML already does. SFML uses OpenGL underneath to render anything, thus if you write your own rendering parts for 2D just to not use SFML, you'll basically end up rewriting code in probably a different way as SFML already has.
On the other hand you wouldn't be limited to SFML and could potentially write code with a better performance, but since you're rather new I doubt it would be any better than SFML.

I was thinking of developing a small particle system for my game. I have looked at some exampels on the internet, and found that they render the particles (the sf::Image using getPixelsPtr()) using OpenGL.
You've probably looked at SFML 1.6 code, where only sf::Image existed.
You need to keep in mind that an extensive use of sf::Image in SFML 2 can lead to quite a performance kill. SFML 2 introduces sf::Texture which lives directly on the GPU, but you can't manipulate the pixels itself directly with normal C++ code. You can call texture.update() with a array of pixel to change all or part of the texture - this is faster than calling texture.loadFromImage() - or you could use a shader to manipulate the pixels on the GPU itself. All in all, particle systems can be quite complicated and probably should be your first project with SFML. But you don't have to miss nice particles, instead just use already written and tested code, like Thor provides.

As I've read, doesn't SFML render the images with OpenGL by default? Using the sf::Rendertarget::draw() function?
Yes absolutely!

But I'm trying to figure out if I should render my sprites using the sf::Image together with OpenGL, or just stick to the sf::Sprite and the default draw()-method. Since it both uses OpenGL I guess.
I'd suggest to use sf::Sprite, sf::Texture and a sf::RenderWindow with the usual draw()-call.
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

pjuke

  • Newbie
  • *
  • Posts: 3
    • View Profile
Re: OpenGL rendering in SFML2.0, questions.
« Reply #2 on: January 15, 2013, 06:07:11 pm »
Thank you for your kind reply, eXpl0it3r.
I've already looked at Thor, hehe. I just wanted to try stretch my own fingers and try make something on my own you see. I'll definately keep Thor as a reference tho, thank you very much!

I'll stick to the "regular" methods as you pointed out and see where the path will lead me.
I'm already using Box2D for my physics, so that will come in handy for create some collission-based particle engine. Smile!

Take care!