Hello, I know there has been discussions before about fast rendering, but I really am stuck with this problem. My isometric engine doesn''t have many features: * 640x480@16b resolution * 32x16, 64x32, 128x64 sized tiles * animated/non-animated sprites (any size) * 4 tile and sprite layers * 6 map layers My puter is AMD Duron 600 with 128mb RAM, "powered" by Matrox G400. Well, I''m drawing a simple map with only one layer. There are trees and people. Well, the average framerate runs somewhere between 38-42. That just sucks!!! What am I doing wrong here? I need light effects and other fun stuff, but I can''t even imagine adding those when a simple map like this gives me bad vibes. The engine is very simple. It just runs through y and x loop and blits the tiles and sprites accordingly. Only the tiles which can be seen on screen are drawn. But why so low framerate? I''m developing using SDL. This can''t be the problem now can it? Well anyway, it would be really awesome if someone would write an article about optimizing isometric engines. I have no idea how to do this. Is there a way to update just the parts of the map that need updating? Please, give looser a helping hand here. Thank you! saeZ

Give it a try on a different machine. Something could be bogging down processing, or maybe a driver issue, or a host of other system related problems. Or the problem could be in the code itself (try it outside debug mode), check calls to trig functions, and especially things that relate to the hard disk, those really show things down. From you said it "should" run faster, something is slowing it down, or your system as a whole. Exploritory research should be done, once for code, and once for unseen junk that might have slipped into the system startup code.

Thanks for the tips. I have done some testing on three different machines. The engine runs slow on all of them. I''m getting really tired of this speed issue. I can''t do any further development (ie adding more features) due to the low fps.. blah. I can''t figure out what I''m doing wrong. Everything should be just perfect with the code... I''ve checked other engines and my engine doesn''t have any major differences when comparing to them (if not counting the lack of features in my engine). Tee hee..

I do NOT want to go into OGL/D3D rendering because I want to stay in pure software rendering method. There''s gotta be a way to make things run faster..

saeZ

quote:Original post by saeZ

I do NOT want to go into OGL/D3D rendering because I want to stay in pure software rendering method. There''s gotta be a way to make things run faster..

saeZ

This may be the problem right here. Transferring data from system memory to video card memory (screen) is often slow. If you are blitting each sprite from the system memory to the video memory individually, then you hav e alot of slow calls.

Try making a screen surface explicitly in system memory. Blit the individual tiles from system memory to system memory (this is reasonably fast), then blit the whole thing to video memory (primary or secondary surface) at once.

HTH

I would agree with the anonymous poster.

Insure that you are explicitly creating all of your surfaces in system memory. I was working on a project a number of years ago that ran very fast on my home system but when I went to a system with more video ram the game slowed down! The reason was that one of my surfaces wasn''t declared as a system surface, and slipped into the video ram on the faster system. Due to the slow read and write from system to video ram, my game was a dog!

Look at your surface creation declerations first, and then try to establish where the slowdown is in the code using a profiling scheme. If you have Visual C++ professional, the profiler is excellent for this work; it will tell you how long functions took and what percentage of the program''s execution was taken up by their invocation. If you don''t have a true profiler, you can write your own, wrapping up calls between checks to GetTickCount() or timeGetTime() and seeing how long functions take. Once you isolate where the time is being spent, finding the actual problem becomes easier.

Good luck.

Sphet

Just to add slightly to the above (sorry) you can
use QueryPerformanceCounter and QueryPerformanceFrequency
to get a better figure for your profiling as it has a higher
resolution.

Hope it helps

Mark