   DirectDraw in system memory
  I am programming a game in DirectDraw 7 tat runs at 800x600x16 resolution. When I put all of the surfaces that I draw into video memory, it blits at 75 frames per second when that''s what the refresh rate''s set to. But if I put all of the surfaces in system memory, it drops dramatically.My questions are:What is the best way to blit from system memory to system memory?Will this be as fast as blitting from video to video memory?What is the best way to blit one 800x600x16 surface (the back buffer) from video to system memory?How fast is this compared to video to video blitting?What I want to know is if I can get acceptable (60 fps) performance while blitting everything from system memory to a back buffer in system memory and the blitting a back buffer to video memory.The game I''m making is an RPG. It draws characters and map tiles to a back buffer.    - mallen22@concentric.net- http://mxf_entertainment.tripod.com/
  Why would you like to blit the backbuffer from video to system memmory?  ;  Agreed Z. That''s crazy talk.Blitting a 800x600x16 surface from sys to video ram isn''t really feasable. Video ram just doesn''t accept writes fast enough. That''s why high res/color games haven''t been done until hardware blitting came around. You''ll never get 60fps doing this (except maybe with the fastest software access video card in the world). Just rely on the video to video blitter as much as possible. Put the images most used in video ram, and any others that don''t fit put in sys ram. Use BltFast for everything, and depending on how much is blit from sys ram it should be OK.Rock  ;  Yes, that was crazy talk: I should have switchd the "video" and "system" in that sentence. Oh, well... It''s sad that it won''t all work in system memory, because now I''m forced to limit the number of tiles to about 5 megabytes and make an 8 mb card a requirement. Damnit.Thanks for the info, though.    - mallen22@concentric.net- http://mxf_entertainment.tripod.com/;  > But if I put all of the surfaces in system memory, it drops dramatically.Really ? What kind of operations are you doing ? If you don''t read from video memory, it shouldn''t be that slower. Video to video is faster, but not that faster. One of my applications is still running at 60 fps only by blitting the sprites from system to video memory. Basically, i have a primary surface in video, a backbuffer in system, and all the sprites in system. When i draw a frame, i blit all my sprites to the backbuffer then i copy the backbuffer to the primary surface.> What is the best way to blit one 800x600x16 surface (the back buffer) from video to system memory?No, no no. Never blit from video to system. There, it will dramatically drop your framerate (i experienced 60 fps -> 8 fps ). The trick is to use a backbuffer in system memory, where you are performing all your operations. If you need to read from the screen, you''ll read from the backbuffer and not the primary surface. By using this technic, you can have alpha-blending effects up to 25 fps ( not perfect, but you can hardly do faster with direct draw only ).Y.;  Ysaneya, actually the difference between hardware and software blits is huge.  I can get around 400 FPS on a voodoo3 3000 with a few layers of overdraw and only 60 to 75 FPS with an MMX optimized software blitter which takes the same route as the back buffer in sys ram approach you mentioned on a p2 450.  The hardware blitting mode stores everything in video ram of course.  This is at 640x480x16 @ 140hz, but vsync is off on both frame rates.  this was all in a scene without much cpu use except for drawing the scene.  now if there was a lot of complex AI or other calculations involved... that 400 FPS may stay at 400 FPS or drop some, but the 60 to 75 FPS will drop significantly unless the limit was on the bus speed.  This is usually not the case where several layers of overdraw is concerned and the only tranfer over the bus to video ram is the back buffer at the end of the frame.  If your game doesn''t use multiple levels of tiles which causes overdraw, then you may not notice the difference unless you switch off vsync.  Then you may notice the 1000 FPS with hardware blitting and 100 FPS with software.  Also, on a low end system the software blitting can drop to 20 or below FPS whereas the hardware blitting may not drop much at all.    ;  I agree Ysaneya. Don''t store your sprites in DirectDraw surface (even DDSCAP_SYSTEMMEMORY), store them in your own memory buffer allocated by malloc() or other equavalent memory allocation functions. The reason is you can save thousand of Lock() and Unlock(). Do every drawings in system offscreen buffer, Lock() the backbuffer (Video RAM), blit entire offscreen to backbuffer, then Unlock(), then flip(). This should give you range from 30fps to 85fps based on your system and how many objects drawn. I know that fps cannot compare to hardware blitting, but trust me, most commerical game run only 30fps  The reason I use software blitter because VRAM <-> VRAM is ultra fast,but that only for boring transparent and block blit,I don''t think modern 2D games without blending, lighting and particle effects are good game  To do that you need Lock the VRAM and process pixels directly. VRAM is 10 times slower access rate than System RAM. To do blending and those cool effects in hardware, u need use Direct3D. That is another story already. So if you want to do 2D game only, use software blitter. If you are working 3D game, don''t think about software blitter, utilize 3D hardware. Because those complicated 3d maths algo will drop your 400fps to 75fps. But won''t happen in 2D game if well designed  ;  In my experience:VRAM -> VRAM => insanely fastRAM -> VRAM => quite fast and perfectly useableRAM -> RAM => pretty good, although I don''t suggest doing this for every image if you''re going to have more than a couple dozen sprites of reasonable sizeVRAM -> RAM => kill yourself before doing this...I''m also going to go out on a limb and say that I doubt copying the surface data yourself will be faster than using DDraw''s BLIT, and the latter is a lot more robust (you don''t need any special code depending on where the surface is).I can produce some benchmarking numbers that I have generated in the past to back this up if anyone disagrees.  It will depend from system to system, but it shouldn''t make much of a difference.My suggestion:- Just do not specify a flag for which memory store DDraw will put the surfaces.  It will put them into VRAM as long as space is available, and then it will start dumping them into RAM.  Thus the people with lots of VRAM will get the fastest gameplay available to them, and the same with the "less fortunate" people.- The only reason you ever have to FORCE something into RAM is if you need to do pixel processing on it on a per-frame basis... ie. if you use software alpha blending, etc.  It will be far to slow if it has to read from VRAM.- Summary: don''t use memory flags unless absolutely necessary.Hope that helps! 