Having background in games?
Author
hey, i just have a question, I have a fairly simple background system where I have a massive 600 x 2700 bmp scrolling in and endless loop across the screen, while this works fine, drawing it takes up like half the processing time of my whole game :(. I am using copyrects to copy the image to the back buffer, is this slow / stupid? are there better ways to do it, withought implementing a more complex background system?
Make sure you aren't processing WM_ERASEBKGND too - you don't need to blank out the background and draw on it too. You can despense with the brush in your WNDCLASS too (hbrBackground = null) - which will stop the window blacking out everything then drawing your background ontop of that. This will force a WM_ERASEBKGND message, which you can just ignore (just return 1 to say you've erased it).
Can't think of any other gotchas of the top of my head with what you've posted.
Can't think of any other gotchas of the top of my head with what you've posted.
If this is OpenGL you might get some speed increase from stretching a small texture onto a large quad. If it's SDL or equivilent, there isn't much out there there to save you other than the usual techniques for blitting. If it's SDL, you might try RLE encoding and make sure the background image is in the screen format. Don't have alpha blending on, regardless of API.
Author
hey paul, i did wut you said, it improved the fps by like 2. but when i take the background out, it improves it by like 100 or more.
also, i am wonding if this is a good idea, every bullet in my game has a set of attributes, and i dynamically allocate these bullets with new, is this a preformance killer?
[Edited by - _Phalanx_ on October 15, 2004 12:36:52 AM]
also, i am wonding if this is a good idea, every bullet in my game has a set of attributes, and i dynamically allocate these bullets with new, is this a preformance killer?
[Edited by - _Phalanx_ on October 15, 2004 12:36:52 AM]
Hmmm I didn't realise you were using DirectX - I thought you were just using copyrects from the Win32 API (GDI).
If you are using directX - well Direct 3d - you could try and take advantage of Billboarding techinques - there's tons of examples of that around. You basically need something that breaks up a picture into 4 or more textured quads - giving the graphics card easier chunks to swallow.
Graphics cards tend to like handling textures that are ^2. Eg 8x8, 16x16, 256x256, etc - that will improve performace. It might be worth your while splitting your background into smaller chunks like that and using a tile system to display them. But that's kind of not the point I suppose, you are trying to avoid making things too much more complicated.
As for the bullets thing - avoid trying to optimise things until they prove themselves a problem. You are doing things exactly the right way around at the moment... you indentified your problem well with the background thing.
If you are using Direct3d - then one thing you could do is turn off all the modes that aren't needed (Z Buffer, lighting, whatever), put your background stuff on the queue, and turn things back on again as you need those extra expensive modes.
If you are using directX - well Direct 3d - you could try and take advantage of Billboarding techinques - there's tons of examples of that around. You basically need something that breaks up a picture into 4 or more textured quads - giving the graphics card easier chunks to swallow.
Graphics cards tend to like handling textures that are ^2. Eg 8x8, 16x16, 256x256, etc - that will improve performace. It might be worth your while splitting your background into smaller chunks like that and using a tile system to display them. But that's kind of not the point I suppose, you are trying to avoid making things too much more complicated.
As for the bullets thing - avoid trying to optimise things until they prove themselves a problem. You are doing things exactly the right way around at the moment... you indentified your problem well with the background thing.
If you are using Direct3d - then one thing you could do is turn off all the modes that aren't needed (Z Buffer, lighting, whatever), put your background stuff on the queue, and turn things back on again as you need those extra expensive modes.
This is base idea (i try it on OpenGL, but may work on D3D)
Split bg on ^2 parths, and load to Texture, then create bg as simple rectangle, and animate TexCoord. (On OpenGL this work fine, even whith multi-texturing ;))
Split bg on ^2 parths, and load to Texture, then create bg as simple rectangle, and animate TexCoord. (On OpenGL this work fine, even whith multi-texturing ;))
Just to say, 'new' is quite slow but not so slow that it would cause a problem unless you call it several times per frame. As the other poster said, worry about optimisation at the end.
Mark
Ever wanted to command a starship?
http://www.lostinflatspace.com
Mark
Ever wanted to command a starship?
http://www.lostinflatspace.com
Author
how do i know if all those z buffering and lighting stuff is on?
also, i think i am calling new at least once a frame, should i just use static arrays?
also, i think i am calling new at least once a frame, should i just use static arrays?
Phalanx, I think you're a little paranoid. What are the actual FPS of your game when you use the background? I mean , of course the game will run faster if you don't draw the background. It will run a lot faster if you don't draw anything at all. You say "the frame rate improved by 2fps" or "by 100fps", but you don't actually say the fps the game is running on. When the fps are high(say 300fps), those numbers aren't that significant.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
