OpenGL for 2D-games. Worth it?
Author
I am concidering opengl for pure 2D games. No models or anything like that to begin with. Perhaps extend with this after a while, but for now nothing at all. So what I am wondering is if it worth using OpenGL for making this? The main concern is direct access to the framebuffer being used so I can just put pixels where I want them.
What I need is the possibility to direct put pixels into the framebuffer preferably with double buffering. This way I can write my own methods for displaying shapes as fast as possible. Also it should being able to integrate with GTK components. Any thoughts on this?
Author
Ok I guess I wont use OpenGL then. Then I guess my next question will be a bit offtopic in this forum but:
Is there any more GTK-native way of pushing pixels to the screen besides SDL? SDL is good and all, but I never seen it integrated good with gnome-applications.
TY for the reply btw :)
[Edited by - invictus on April 25, 2006 5:32:19 AM]
Is there any more GTK-native way of pushing pixels to the screen besides SDL? SDL is good and all, but I never seen it integrated good with gnome-applications.
TY for the reply btw :)
[Edited by - invictus on April 25, 2006 5:32:19 AM]
Quote:Original post by Boder
No, go with SDL. OpenGL will make your code more complicated and it was not made for pixel pushing.
Bullshit.
OpenGL works great for 2d games. You can get much higher performance, greater flexibility and much higher quality rendering than old-style bliting.
Author
Quote:Original post by OrangyTang
OpenGL works great for 2d games. You can get much higher performance, greater flexibility and much higher quality rendering than old-style bliting.
Does that include games with no models at all, just regular images drawn to the screen?
Of course. You just stick it on a quad and display it however you want (straight, warped, scaled, rotated, etc.).
<self_promotion>Theres a few pictures in my Journal which use exactly this method</self_promotion>
<self_promotion>Theres a few pictures in my Journal which use exactly this method</self_promotion>
I agree 100% with OrangyTang. I'm making a 2D game right now in OpenGL, and it really is helping a ton! I can have 'real' physics now that its is a sinch to rotate objects without hitting the performance. And I can use alpha channels without hassle or signifigant performance loss.
However, I'm not really sure if OpenGL would be great at 'putting pixels directly on the buffer'. What makes you think that your own functions will be faster at drawing than your graphics card? OpenGL is very fast, I doubt that you'll be able to get any performance gains at all by drawing directly to the buffer.
However, I'm not really sure if OpenGL would be great at 'putting pixels directly on the buffer'. What makes you think that your own functions will be faster at drawing than your graphics card? OpenGL is very fast, I doubt that you'll be able to get any performance gains at all by drawing directly to the buffer.
Quote:Original post by Boder
No, go with SDL. OpenGL will make your code more complicated and it was not made for pixel pushing.
^^ I think he was being sarcastic.
OpenGL is definetly made for pixel pushing and is significantly faster then SDL.
OpenGL also gives you spiffy effects like blending, rotation, zooming, and particle effects! Try doing those in real time with SDL :P
To do it you just make a quad and bind a texture to it.
OpenGL will greatly simplify the work you'll have to do as a 2D programmer.
You won't have to keep track of the depth that your objects are in (z-buffer) and you can use alpha blending, testing, etc...
I wouldn't use a textured quad as one big buffer, but I'd rather translate, rotate, etc... individual objects as if they were 3d-models. This will simplify your collision, physics routines etc...
You won't have to keep track of the depth that your objects are in (z-buffer) and you can use alpha blending, testing, etc...
I wouldn't use a textured quad as one big buffer, but I'd rather translate, rotate, etc... individual objects as if they were 3d-models. This will simplify your collision, physics routines etc...
Did you read exactly what he wanted? I agree that OpenGL is great for 2D games with sprites and pictures, but what the OP demanded was quite different from this.
How would you suggest to efficiently and simply push random pixels anywhere on the framebuffer?
I've never done anything like this with OpenGL, would you create a huge pixel array and call glDrawPixels() once per frame?
Quote:The main concern is direct access to the framebuffer . . . put pixels where I want
Quote:I need to direct[ly] put pixels into the framebuffer
Quote:I can write my own methods for displaying shapes
How would you suggest to efficiently and simply push random pixels anywhere on the framebuffer?
I've never done anything like this with OpenGL, would you create a huge pixel array and call glDrawPixels() once per frame?
If you're looking to write your own functions just to learn how to do it, then it doesn't matter what you use because performance doesn't matter.
Any other time, you are almost universally better off using OpenGL polygons and texture maps. They're hardware accelerated, easier to use, and can do pretty much anything you can imagine (especially with clever shader tricks).
Any other time, you are almost universally better off using OpenGL polygons and texture maps. They're hardware accelerated, easier to use, and can do pretty much anything you can imagine (especially with clever shader tricks).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
