Jump to content
  • Advertisement

Archived

This topic is now archived and is closed to further replies.

leiavoia

800x600 on a 19" - blechhh!

This topic is 5241 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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)

Share this post


Link to post
Share on other sites
Advertisement
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!