Ok, so I''m quite pleased with the speed of my iso engine thus far (thanks BTW to everyone who took it for a spin), but now I''m facing a problem... Currently I use video memory for everything, which is fast. However I am now working on some special effects that require direct access to the buffer (eg: light maps, semi-transparent sprite blits, etc) The routines are significantly faster when operating on system memory rather than video memory. It seems to me that I can either do everything in video RAM and go really light on the routines that require direct access, or I can place all my sprites and the back buffer in system RAM and simply BltFast() the backbuffer when flipping. This would allow me to add all sorts of special effects that would be too slow otherwise. Is the way it''s normally done? When I do this my frame rate drops a bit (as low as 55 from 85) and the bottleneck is now BltFast itself. I''m thinking that DirectX''s blitters are not optimized for working with system memory and that I may have to write my own in assembly. Is that true? Fortunately I already have a set of blitter routines coded in pure assembly that I wrote about 8 years ago... I guess I''ll just have to incorporate them and see what happens. //TOOM

This what I am doing. I have a surface allocated in system memory that is about the same size as the area where the map will be displayed on the screen. I have my UI elements, cursors, Fonts, and sprites that only require a straight blt with no effects in video memory along with my backbuffer. My tilesets and sprites that require special effects are in system memory. I compose the map and the elements that require special effects on the surface I allocated, and then bltfast the surface to the backbuffer. Since the surface is not the full size of the backbuffer it saves me some bandwidth. After the surface has been blitted to the backbuffer, I then blt the other elements that don't require special effects to the backbuffer followed by the UI elements that need updating and then my cursors, and text. It seems to work good so far, but we will see how it holds up as I add more functionality.

As far as blitters go. I am using a set of blitters that I wrote in assembly using MMX. (MMX realy helps out on the effects) But I only use them in system memory.

I hope this helps you out.

Edited by - bstach on 1/28/00 2:36:03 PM

ColdFireV has the right idea.

Use a system memory ''compositing surface'' to do your multiple blts to from system memory, then blast it to the back buffer to finish it up before flipping.

I knew there was something about your engine that made it fast.. now I know - all video memory. I sincerely hope you can keep the frame rate up once in system memory.

quote: Original post by Sphet
Use a system memory ''compositing surface'' to do your multiple blts to from system memory, then blast it to the back buffer to finish it up before flipping.

Makes a lot of sense - thanks for the replies guys.

quote:
I knew there was something about your engine that made it fast.. now I know - all video memory. I sincerely hope you can keep the frame rate up once in system memory.

I''ve converted it to do everything in system memory and BltFast() the entire backbuffer. The only assembly I''m using at this point is a routine to clear the backbuffer. I was getting 83-85 FPS with all video memory, now I get 65-70 FPS. Still not too shabby, especially since I will eventually be syncing it to 30 FPS in the final game. Of course I haven''t tested it on any other machines yet...

Hopefully replacing all my blits with assembly routines will make it even faster (I suspect it will since I can avoid some of the overhead DirectX undoubtably has).

//TOOM

PS: I hope ColdFireV is just joking about me making him feel dumb :-) I may be a newbie to Windows and DirectX, but I''m not a newbie to game programming. I wrote a mode 13h game library in assembly about 8 years ago that got published in at least one programming journal at the time. And I was writing games for the Vic-20 and C64 in assembly many years before that. I''m far from being an expert, but it''s not like I''m starting from scratch either.

Toom,

Im curious, what were the dimensions of your map for your isometric engine? I''m still deciding on the size of my maps and this would help put it in perspective without having to start coding with DX and graphics.

Thanks

The demo I posted uses a 128x128 array of map cells. Within each cell (tile) I allow for 32x32 "steps", so the coordinates for the map range from 0 to 4095 in both directions.

However I can change the dimensions of the map to any value without affecting the speed of rendering. In fact at the moment I''m using a 256x256 map.

//TOOM