The only real bottleneck I can see here is the Blt function. Writing your own will probably improve performance depending on your needs. I am assuming that you have done the standard memory optimizations and are either keeping all of your surfaces in video memory, or all of them in system memory. If they are all in video memory then your speed is limited by the graphics card''s bandwidth, not too much you can do about that. On the other hand if your surfaces are in system memory it will be faster to write your own Blt function that is hand-optimized for the routine you are using it for. In your case the blt function does a whole bunch of extra work because it cannot assume anything about the tiles, while you know beforehand that you have 32x32 tiles and the vast majority of tiles aren''t clipped. That leads to another optimization, call blt without the clipping rectangle for all the non-clipped tiles and special case the edges of the screen. Hope this helps.
Premandrake
Here's the Deal - 2D tile based blit w/ scroll.
I''m not sure what kind of issue you have with using the nested for loops to loop through the tiles on a scan-line. I did a generic 2d engine that used alpha transparency and two layers per tile. It could do any sized tiles and it could handle any sized screen. At 640x480 with 64x64 tile sizes it was running fine at about 80 fps (no game code attached... with the game code... including a very cool pixel-based collision detection and a script-based AI - read the script from a textfile and interpret it - it dropped to about 48 fps). Just told the loops to go from 0 to (screendim/tilesize)+1 at tilesize steps with an offset on each tile to handle the scrolling (so each tile would be rendered at X+XOffset, Y+YOffset).
This was done in Visual Basic 6 with DX8... so, you''re bound to get more speed out of C++. I tried doing it with four layers (two for the architecture and then two in the background for parllax) and that also worked fine, but we dropped the parallax layers at the end.
''Doing the impossible is kind of fun'' - Walt Disney
This was done in Visual Basic 6 with DX8... so, you''re bound to get more speed out of C++. I tried doing it with four layers (two for the architecture and then two in the background for parllax) and that also worked fine, but we dropped the parallax layers at the end.
''Doing the impossible is kind of fun'' - Walt Disney
Hey everyone. Thanks for the additional help. For the person that mentioned skipping blank tiles, that will be there for more layers. Right now the focus was the render loop. For the guy sending me to the obsessive compulsive website, =-). Truth be known though, production code does require this much attention to detail so deal with it! For the person with the asm suggestion: that''s definitely a valid idea. I was checking into it too.
Someone comenting on my loops, i''m not quite sure what your point is. But if you are complaining about my for(; then you should take a look at the asm you end up with from different kinds of loops. A compiler will produce slower assembly for a while(1) than a for(;. Besides you never know your loop size on this type of thing if you have different possible display modes and different size tile maps. Precalculation will just eat up cpu cycles.
I hope some people see the importance of this extra work. As an example Starcraft can run happily on a p166. Now that''s optimized code!
Someone comenting on my loops, i''m not quite sure what your point is. But if you are complaining about my for(; then you should take a look at the asm you end up with from different kinds of loops. A compiler will produce slower assembly for a while(1) than a for(;. Besides you never know your loop size on this type of thing if you have different possible display modes and different size tile maps. Precalculation will just eat up cpu cycles.
I hope some people see the importance of this extra work. As an example Starcraft can run happily on a p166. Now that''s optimized code!
I don''t think that "for(;" will compile.
Seriously though, do you want to try to optimize a finished game, or do you want to try to finish an optimized game? A lot of obsessive coders (myself included) don''t know when to say "when", so they end up making an unfinished game with perfect code.
You may be right that optimization techniques can give you an edge over the other job applicants. However, if those other guys have already created three slow games before you could finish one fast one, then guess who the company is going to hire? Not "the obsessive one."
Trying to fix a problem before it actually becomes a problem (ie. optimizing code that hasn''t been proven to be a bottleneck in the finished game) is a hallmark of unhealthy obsession. Take it from someone who knows; I sent you to the OC Foundation for a reason.
Seriously though, do you want to try to optimize a finished game, or do you want to try to finish an optimized game? A lot of obsessive coders (myself included) don''t know when to say "when", so they end up making an unfinished game with perfect code.
You may be right that optimization techniques can give you an edge over the other job applicants. However, if those other guys have already created three slow games before you could finish one fast one, then guess who the company is going to hire? Not "the obsessive one."
Trying to fix a problem before it actually becomes a problem (ie. optimizing code that hasn''t been proven to be a bottleneck in the finished game) is a hallmark of unhealthy obsession. Take it from someone who knows; I sent you to the OC Foundation for a reason.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement