Before you optimize your code, give a demo of it to a few friends or people online and let them see how the performance is ontheir computers. A 600 mhz lap top is kind of *slow*, esp w/o a 3d card. I know my comp (P4 3.2) would chew through your game easily (I HOPE[WINK]), but you should test on other comps to compate performace before you do any major code modifying. I hope this helps and I'd be glad to test it out for you and let you know how it does.

Quote:

Original post by wyrzy When you mentioned that "this game works with both SDL and OpenGL", does that mean you are using SDL to blit, or are you using OpenGL?

I have two different drawing functions. One uses SDL for blitting and the other uses OpenGL. GL in software seems to be painfully slow compared to SDL in my experience.

Quote:

2) When using SDL_SetVideoMode(int,int,int,int); make the last argument contain the flag SDL_ANYFORMAT, so SDL does not create a 'shadow surface', which can cut blitting performance in half or more on some machines

That didn't change how the laptop performed, but I suspect that's why it was slow as hell on some PCs.

Quote:

4) Instead of calling SDL_Flip(SDL_Surface*);, you can call SDL_UpdateRect(SDL_Surface*, 0, 0, 0, 0); instead. I got a small performance increase from this one.

Thanks, that seems to have increased the frame rate by 1 or 2 FPS.


I'd rather not mess with SDL itself since I'm trying to make this as OS independent as I can (all my home PCs and laptop are running Linux and most of the people I have testing it run Windows).

Quote:

Original post by Drew_Benton Before you optimize your code, give a demo of it to a few friends or people online and let them see how the performance is ontheir computers. A 600 mhz lap top is kind of *slow*, esp w/o a 3d card. I know my comp (P4 3.2) would chew through your game easily (I HOPE[WINK]), but you should test on other comps to compate performace before you do any major code modifying. I hope this helps and I'd be glad to test it out for you and let you know how it does.

It has run fine on all the other PCs I've tested it on in one video mode or another. Occasionally I'll find one that is unusually slow in either SDL or GL, but I've yet to find one that has a problem with both.

I realize that almost everyone is going to have a machine that won't have the slightest problem with this game, but I'd really like to have it run well on my laptop since that's what I spend most of my time coding on.

I'll post links to the current versions (Linux and Windows) after I compile a fresh Windows version and write a quick readme.

If anybody feels like trying this game out, here are the links:

Windows version:
http://kbranch.no-ip.com/rts/rts.zip

Linux version:
http://kbranch.no-ip.com/rts/rts.tar.gz

Make sure you read the README.txt, it contains several things you should know before trying it out.

These files are being hosted on my home PC, so you won't get any transfers over about 45 KB/s.

Edit: I forgot to mention that the mini map doesn't work in OpenGL mode right now. I haven't gotten around to making the optimizations mentioned earlier in this thread to the GL part yet.

Edit... again: I just fixed the README.txt so that it should be readable in windows now.

It runs way too slow for such a simple game. It looks as if you are performing too many blits. How many tiles etc. do you draw per frame on average?

Quote:

Original post by darookie It runs way too slow for such a simple game. It looks as if you are performing too many blits. How many tiles etc. do you draw per frame on average?

Each tile is 32x32 pixels, so if you're running it at 640x480 it should be drawing 30 tiles and the HUD type thing.

I don't think that's the problem, though. I get about the same frame rate even if I comment out all the game logic and I'm just drawing one 640x480 surface and the frame rate. You might have run into the problem I've seen before where some PCs just don't work well with SDL (or at least any SDL apps I've ever written).

be sure you are converting all your surface's to the screens format BEFORE you blit any of them. otherwise, SDL will convert them on the fly, which is _slow_. so, do this:

load an imageconvert it to the screens format(hint: do both of these in the same function)now blit your image all you want

theres a function like SDL_ConvertSurface(), or something like that.

also, in OpenGL, try using vertex arrays. stuff all your tiles into one vertex array with all the texture coordinates / positions and call glDrawArrays(). this should give a nice increase (depending on if your fill rate limited or geomoetry limited).

also, try running the game in fullscreen. this should give a nice boost in OpenGL. not only that, but try running the game in 16 bit color, in fullscreen. this should definetly show a nice boost in frame-rate. (again, depending on if its fill-rate or not, im betting it is though).

also, if you don't want to use vertex arrays, at least try to make GL function calls a minimum. that is, you might be doing something like this:

for each tile   gltextcoord()   glcolor3f()   glBegin()   draw_quad()   glEnd()

instead, do this:

gltextcoord()glcolor3f()glBegin()for each tile   draw_quad();glEnd()

good luck.

[Edited by - graveyard filla on December 13, 2004 2:49:16 AM]

I've noticed with my own projects using SDL switching to fullscreen often gave a significant performance increase, SDL is somewhat famous for reduced performance within a windowed application so the switch might be worth it if it's possible.

Quote:

Original post by Spudder I've noticed with my own projects using SDL switching to fullscreen often gave a significant performance increase, SDL is somewhat famous for reduced performance within a windowed application so the switch might be worth it if it's possible.

That would be a serious drawback then. Depending on the game I like windowed mode.

Quote:

Original post by Spudder I've noticed with my own projects using SDL switching to fullscreen often gave a significant performance increase, SDL is somewhat famous for reduced performance within a windowed application so the switch might be worth it if it's possible.

The reason is because SDL was developed for O/S's not as feature rich as windows. So it simply is not optimized for windows.

As for your windows demo here are a few things:
* The back in options does not work
* I'd suggest making an -apply- button so when the user changes the display mode, they are not looped through each display.
* I found a bug, when input grab is on and you choose software mode, the game works nice and fast, however when it is off and you choose software mode, the game runs slower than a 1 legged sloth, I think it hits fps of below 2. I dont know if this is a windows problem or game, but it happens on my comp.
* Other than that, it looks very nice! It a great start, I like the minimap, production queues, and the ai that keeps on killing me [WINK]. Keep up the good work!