800x600 on a 19" - blechhh!
Author
So i''m designing my 2D game engine... As i add more features and graphical eye candy (16-frame alpha blended explosions, particles, parallax scrolling background layers, etc), the framerate goes down and down and down, and *my* hardware is quite capable. So, i''m left with the decision: cut my resolution down from 1024x768 to 800x600, or cut out some of the graphical goodness (which is like the whole point, man!) ???
I have a 19" monitor. I think more and more people do since the prices are comming down on these big ticket items compared to 10 years ago. It''s also the one piece of PC hardware that will outlast the PC itself and more people are getting to realize that, thus allowing themselves to spend more money on a good monitor. bla bla bla, anyway:
800x600 @ fullscreen on 19" looks pretty chunkified and in a window @ ~1200x1000 it looks rather smallish. Is there any way to compromise? (it''s an SDL game, if that''s any help)
Are you using OpenGL to take advantage of 3D card acceleration? If not, this could really speed things up. SDL doesn''t use it automatically (future releases might, but not yet).
Author
i know that is does not currently use it (i checked the video output and it all reports false). I was just about to ask: how do i get SDL to use OpenGL (on a linux system)? I have a halfway decent card, and i also pass SDL_HWSURFACE|SDL_DUBBLEBUF when i create the program, but it doesn''t seem to have any effect.
What I''m suggesting will likely involve actually using OpenGL, rather than usign SDL for your drawing functions. All SDL will do is help you initialise GL. The reason for your slowdown is the fact that it is all being done in software. To use hardware you''ll need to use GL, and not the SDL drawing functions.
SDLDoc has some info on creating a GL context via SDL.
SDLDoc has some info on creating a GL context via SDL.
Unfortunately, to get OpenGL to work you need to get rid of all your SDL rendering code and replace it with OpenGL's textured quads. If you had the foresight to make an excellent layer of abstraction between your graphics routines and SDL, it shouldn't be too difficult to write an adapter. If not, I'm afraid you're out of luck. 
If you have a decent video card, the performance gains ought to be remarkable. But if you have to rip your game apart, it may be a good idea just to lower your resolution instead of watsing lots of time.
[edited by - twix on April 13, 2004 11:01:35 PM]
If you have a decent video card, the performance gains ought to be remarkable. But if you have to rip your game apart, it may be a good idea just to lower your resolution instead of watsing lots of time.
[edited by - twix on April 13, 2004 11:01:35 PM]
Author
my game is not so far along development wise. Most of the work has gone into framework building (polling, collisions, particles, object hierachies). So, taking it apart is not unreasonable. Learning OpenGL would take some effort though :-)
I am familiar with the fact that you can use SDL as a base for OGL apps. I've slogged through a few of the NeHe tutorials, but wasn't sure if i really wanted to go ahead with it for this particular project. But eye-candy is the name of the game here, and i do want those high FPS numbers as well.
quick question: in the event that i'd still want pixel-perfect collisions, can i do that with textured quads or am i stuck with bounding geometry checks? I know OpenGL isn't meant for pixel-perfect scenarios.
[edited by - leiavoia on April 13, 2004 11:09:47 PM]
I am familiar with the fact that you can use SDL as a base for OGL apps. I've slogged through a few of the NeHe tutorials, but wasn't sure if i really wanted to go ahead with it for this particular project. But eye-candy is the name of the game here, and i do want those high FPS numbers as well.
quick question: in the event that i'd still want pixel-perfect collisions, can i do that with textured quads or am i stuck with bounding geometry checks? I know OpenGL isn't meant for pixel-perfect scenarios.
[edited by - leiavoia on April 13, 2004 11:09:47 PM]
I don't know a lot of OpenGL so I don't know how to efficiently implement pixel perfect collisions, but I have the feeling that they would be pretty damn expensive and not really necessary. Just draw some nice form-fitting polygons over your sprites and you should be good to go (besides the part where you actually implement polygon-polygon collisions 
)
Oh, and I have done some work with simple textured quads. It's very basic stuff; you shouldn't have trouble.
[edited by - twix on April 13, 2004 11:13:39 PM]
)Oh, and I have done some work with simple textured quads. It's very basic stuff; you shouldn't have trouble.
[edited by - twix on April 13, 2004 11:13:39 PM]
You could do pixel perfect collisions, but it''s likely that you''d need to store a separate bitmap than the texture you give to GL to do it. The overhead of using GL to inspect the textures is likely to be significant, so handing GL a texture and keeping a collision bitmap for yourself would likely be the best solution.
quote:Original post by Doc
You could do pixel perfect collisions, but it''s likely that you''d need to store a separate bitmap than the texture you give to GL to do it. The overhead of using GL to inspect the textures is likely to be significant, so handing GL a texture and keeping a collision bitmap for yourself would likely be the best solution.
A good idea if he never uses OpenGL''s rotation features, but I''m somewhat tempted to think that doing a lot of pixel-perfect collisions on the CPU may be a big factor behind the currently crappy performance.
Author
i'm not currently doing pixel-collisions (and hope not too if i can help it) and my performance isn't what i'd call crappy either. In fact, there is a good chance i'll stick with SDL for the project, but i'll have to make further investigations into OpenGL before making that decision. I can get quite a bit out of SDL, but that's on *my* hardware (for software rendering, an Athlon 2500 works pretty nice, but not everybody will run it that fast, you know?)
@ 800x600 i'm getting 60-180 FPS blitting a fullscreen image, some rectangles, and a handfull of alpha-blended images. I'm also blitting pixel particles, doing collisions, and polling everybody for actions: But if i add a second or third parallax scrolling background layer, more objects with more collisions, possible lighting effects, transparent foreground objects, and whatever else i think of, it all adds up. And on a lesser CPU, i'm sure the FPS would drop substantially more.
Here's my framework in motion.
[edited by - leiavoia on April 13, 2004 12:40:46 AM]
@ 800x600 i'm getting 60-180 FPS blitting a fullscreen image, some rectangles, and a handfull of alpha-blended images. I'm also blitting pixel particles, doing collisions, and polling everybody for actions: But if i add a second or third parallax scrolling background layer, more objects with more collisions, possible lighting effects, transparent foreground objects, and whatever else i think of, it all adds up. And on a lesser CPU, i'm sure the FPS would drop substantially more.
Here's my framework in motion.
[edited by - leiavoia on April 13, 2004 12:40:46 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
