Need a few tips to optimize my DX puzzle game.
Hey,
I am having a bit of trouble getting my puzzle game to run smoothly on slower computers as well as mine.....all I have now for my test build is a series of sprites that fall fast from the top of the screen.
Here is my loop:
[
Clear backbuffer
Blit 640x480 background image to backbuffer
Blit sprites to backbuffer
Flip it.
]
Does anyone have any tips as to how I could make this run smoother, it runs very choppy on a 266 and a bit on my 450 even though there is only a few sprites and hardly any game logic? The background bmp is 900k, so should I make a surface just for that?
Any help would really be appreciated.
Thanks
-Tim Yarosh
if your background image is as big as screen, then why clear backbuffer ?
Image will cover everything anyways.
And obviously you are using 24bit background image, try 16bit perhaps ?
hope this helps, -kertropp
Image will cover everything anyways.
And obviously you are using 24bit background image, try 16bit perhaps ?
hope this helps, -kertropp
-kertropp C:Projectsrg_clueph_opt.c(185) : error C3142: 'PushAll' :bad ideaC:Projectsrg_clueph_opt.c(207) : error C324: 'TryCnt': missing point
I''m not positive what they''re called... (UpdateRegions? HotRects? we''ll just refer to them as regions.).. but that''s the way to go if the bg image will always be the same.
anyways, the theory behind this is that since it''s a puzzle game and it is a static bg... you needn''t clear the back bg all of the time. You just change the Regions which were drawn. erm, that was a horrible explanation.
basically, don''t clear the buffer, put the bg image into memory, blt the bg image to the back once fully at the start of the stages, then you blt an upper layer object to the part of the screen as normal.
next loop, just blt the surface part of the bg from memory that was modified by the previous blt. Thus you''re sort of like applying makeup to the part of the back buffer that was messed up from the object blt. Then blt all your changed in position objects again.
Next loop, cover the last blts with the source image parts.. and repeat. you get the idea?
This way you save a lot of bltting by only doing the changed parts per frame, not the whole bg. Baulder''s gate does this.
Even if you waste some time by say, rebltting the whole puzzle field because you don''t want to keep track of the individual changes per upper layer object, you will still shave 10+ more frames per second because you don''t blt the whole bg image.
this is a great technique for these types of games as long as the whole scene doesn''t chage every frame (like a tile based game may).
anyways, the theory behind this is that since it''s a puzzle game and it is a static bg... you needn''t clear the back bg all of the time. You just change the Regions which were drawn. erm, that was a horrible explanation.
basically, don''t clear the buffer, put the bg image into memory, blt the bg image to the back once fully at the start of the stages, then you blt an upper layer object to the part of the screen as normal.
next loop, just blt the surface part of the bg from memory that was modified by the previous blt. Thus you''re sort of like applying makeup to the part of the back buffer that was messed up from the object blt. Then blt all your changed in position objects again.
Next loop, cover the last blts with the source image parts.. and repeat. you get the idea?
This way you save a lot of bltting by only doing the changed parts per frame, not the whole bg. Baulder''s gate does this.
Even if you waste some time by say, rebltting the whole puzzle field because you don''t want to keep track of the individual changes per upper layer object, you will still shave 10+ more frames per second because you don''t blt the whole bg image.
this is a great technique for these types of games as long as the whole scene doesn''t chage every frame (like a tile based game may).
___________________________Freeware development:ruinedsoft.com
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement