Jump to content
  • Advertisement
Sign in to follow this  
TroneX

Straight ahead, or well designed?

This topic is 5012 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

Hi folks, lately I thought it might be a good idea to finally not only write down ideas for games, but also code 'em. But since my girlfriend occupies my own private computer for gaming purposes herself all the time, I have to get back to a backup system which is mainly thought for internet routing, ... that is ... it's only a 200MHz, 64MB computer with a linux operating system. However, ... I put BlackBox on it and got debian upgraded to a version that allows me to run Anjuta which seemed to be the best IDE being around that works under these circumstances ;-) When developing on a windows machine with 1.8GHz, 512MB RAM and an NVidia graphics accelerator, I was used to simply rendering everything ever and ever again whether it changed its state or not. So given a level consisted of 100 tiles that have alpha masks on them and lots of NPCs, I would render everything in every frame again before "flipping". No problem. Well. Now it seems like this won't work with 200MHz ;-) My level consists of a grid of gates which tiles overlap eachother. So that they don't overdraw eachother, I put alphas on them which renders fine. All 68 of them. But if I render all 68 tiles in each frame, I have approx. 1 frame per second... ;-) This is the rendering workflow until now: 1. Clear the screen with a white color 2. Render all tiles with alphas 3. Render character with alpha 4. Flip screen Before the rendering process, I call FrameMove which changes the states of the tiles (most probably only one or two at a time). To get this working under my really slow system, it seams like I will have to create bitmaps of all overlapping tile states so that it does not depend on alphas anymore. This way I could also remove the clearing thing ... what do you guys think? By the way: I also tried to adjust the tile images to the screen surface settings for fast blitting, but it didn't really help. For your information: I am using SDL with SDL_Image. Best regards, T.

Share this post


Link to post
Share on other sites
Advertisement
How about an intermediate solution - create a 'tile cache' that contains, say, twice as many tiles as are visible on screen at any given time. Generate a hash code or whatever for each composited tile as you need to render it, and look it up in the tile cache. If it's not there, generate and cache it, otherwise bingo, it's a straight blit from cache to the screen. IIRC Quake did a similar thing to this for its light maps to avoid multiplying textures by lightmaps at rasterize time.

Share this post


Link to post
Share on other sites
Greetings!

I once coded in 2D at 386 and 486 processors.
I found out, that there is a much faster apporach to 2D that the original invisible color method. What Am i talking about?

..X..
.XXX.
XXXXX

This "image" should represent an arrow pointing "up" the screen.
for usual you would have the "." spots marked as 0 as any other transparent
color value and you would draw just non "0" values like "X" for example and you get and transparent arrow.

What I did was to represent the regular bitmap into chunk, where each chunk has its (x,y) offset and stripe length, for example:

..X.. : (x=2,y=0,size=1, data=x)
.XXX. : (x=1,y=1,size=3, data=xxx)
XXXXX : (x=0,y=2,size=5, data=xxxxx)

Then i optimised the chunks, that if data was more that 2 byte long, it uses movsw (move word), and if it was at 4 byte long it used movsd.

So if an object was 9 pixels width, i used 2x 32bit move and 1x single byte move. The speed increase was enourmous. But the reneder method had to be done in assembly, altough everything else was in C or PASCAL.

Share this post


Link to post
Share on other sites
1. Clear the screen with a white color <----- DON'T DO THIS
2. Render all tiles with alphas
3. Render character with alpha
4. Flip screen

If your tiles completely cover the background (and they should), there is NO REASON to "wipe the screen", so to speak. If the screen is going to get completely covered by what you draw, no point in wiping it out first. Not doing this in both SDL and OpenGL will save you quite a bit of rendering time. Something to think about.

From what i gather, *i assume* you have some base tiles and overlapping tiles with alpha. Your base tiles should be converted to a simple format with no alpha channel because they do not need to overlap anything; they are base tiles. The overlapping elements do need alpha, and it's darned expensive, so only do so if needed or limit the amount you use.

Always convert everything to the screen format. It saves a lot of time if your formats are different. I noticed a 4x speed increase in one of my projects by converting my "base tiles" with alpha to a no-alpha format and screen-format. You'll especially notice a jump if you have hi-res graphics in a low bit depth setting or vice-versa. If you don't, you won't notice anything. But program it anyway, and make the bitdepth the app runs in an option at startup (it's really easy)

Also consider using a lower bit depth to render the screen with (16 instead of 32), start the app fullscreen, and also try RLE encoding. RLE only works well with some things though, which you'll have to read up on. And finally, instead of alpha, you can use colorkeys. They are not as pretty, but work much faster.

Based on what i've done, those tips helped me speed things up.

Quote:

To get this working under my really slow system, it seams like I will have to create bitmaps of all overlapping tile states so that it does not depend on alphas anymore. This way I could also remove the clearing thing ... what do you guys think?


Instead of hardcoding it, you could produce these images automatically if memory is not an issue. For instance, let's say you have image "brick". Now, over the course of the game, you could have a brick with a tree over the top of it. Instead of blit(brick), blit(tree), you create a special tile called "brick with tree over it" and save it:

- create new sdl surface
- blit brick to it
- blit tree to it
- save as "brick with tree over it"

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!