Archived

This topic is now archived and is closed to further replies.

xtrmntr

slow tile rendering?

Recommended Posts

im making pacman, and i store the levels in a data file that i read in when necessary. in the main loop i blit the tiles according to the map data. however since adding a few other things to the game it has slowed down drastically. the other guy working on this with me says that the speed loss is caused by the way i display the map. here is how i do it. for(NUM OF TILES WIDTH) for(NUM OF TILES HEIGHT) blit tile this happens every run through the loop. is displaying all the tiles everytime really slowing it down? would like to hear comments and ideas of speeding it up. thanks in advance yesterday is history, tomorrow is a mystery, today is a gift... -TapRoot AIM screen name: StarCraftIsEvil

Share this post


Link to post
Share on other sites
First, make sure you only draw tiles that are visible ( if the number of tiles wide/ tall is greater than the width of the screen, only draw the tiles that are visible)

Then, you can try to only redraw the tiles that have changed (the player has moved off of it, etc), so only the absolutely necessary tiles to be redrawn are drawn over.

I''m not really sure what your problem is, unless my frist suggestion applies to you. There should be no problem blitting a screen full of tiles every frame.

You may check if the graphics are the same bpp as what the program is running.

Ben

Share this post


Link to post
Share on other sites
thanks ben. btw the full map is always displayed (no scrolling) i know i should only update tiles that get "dirty" but this is just a testbed prog that displays the map and lets you move pacman around it. however over this weekend my roommate added a ghost to screw around with AI... he INSISTS its not his code thats causing the prob.

Share this post


Link to post
Share on other sites
Do a quick test, remove all of the new code (comment it out) and re-run the game, if you still have a slow game then it is your tile drawing, if not add one bit on at a time until you find the bottle neck.

My opinion is that the AI is the bottle neck, as drawing tiles and moving a sprite under kb control is as fast as your system. They probably is something silly in the AI that is eating up the CPU time...

Share this post


Link to post
Share on other sites
the AI (which is just a test for now) is a bunch of if/else statements which "shouldn''t" be slowing it down. The slow down only occurs if i run the program on my laptop which is: P3 650 128mb ram 6mb video ram. my desktop is slower: celeron 333 256mb ram 32mb video. does this make any sense? the slowdown should be a result of processor speed... is that correct or is it a combination of things?

yesterday is history, tomorrow is a mystery, today is a gift... -TapRoot

AIM screen name: StarCraftIsEvil

Share this post


Link to post
Share on other sites
Mmm...there could be some graphical related things...color depth of the tiles [256 color, 16-bit color, etc..]...size of the window or screen resolution...size of the tiles...are the tile stored in video memory and blitted to a back buffer? are you blitting them from regular memory to a video back buffer one at a time?...or is the back buffer in regular memory and blitted to video memory once all drawing is done?...

Also you sead the AI contains a bunch of IF/THENs...but what are the expressions used? are they full of function calls? math expressions involveing floating point values? are there lots of ANDs/ORs stringed together?

Share this post


Link to post
Share on other sites
Ive found that some older 3d cards do 2d blitting very poorly. If you remember alot of older cards used to be 3d only and thier DDRAW performance blew. It might be that your card on your desktop is a 3d heavy card with poor 2d performance

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Have you checked that you aren''t just running out of video RAM? 6mb isn''t that much, really. Try dropping your screen resolution to something minimal and/or stop using a backbuffer (assuming you''re using one).

Share this post


Link to post
Share on other sites