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

I''m not too experienced with all these special effects, but here''s my 2 cents...

Generally, anytime you''re transferring from system to video memory, or video memory, you''ve always got to transfer through the PCI/AGP bus. This is usually very slow. On the other hand, system->system or video->video transfers are very fast. My advice is to get all of the surfaces that are stored in system memory to get blitted to another large surface in system memory. This way, you can get by with doing just one transfer from system to video memory. I think this would give you the best transfer rate. Then anything in video memory you want to blit afterward, you can blit after you do the large transfer. Good luck!

BTW: You''re making me feel really dumb. I''m trying to write an isometric engine, and you wrote a really great one (now you''re doing special FX) in a week from nothing. Geez! Keep it up though, I think I speak for everyone on the message board when I say we''d like to see how it turns out.

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.

Yeah, I was joking. But I still have a LOT to learn. I''m not really a newbie, but maybe I''m just getting ahead of myself on some things.

ColdfireV

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