Tips for fast pixel manipulation in directdraw

1. DONT sync to refresh. it will utterly destroy your framerate when you can draw fast enough to keep up.

2. all pixel manipulated buffers that you read from MUST be in system memory. the only exception to this rule is for a screenshot function. if you feel reading from vram for any other reason is worth it for a game, you might as well quite graphics programming now.

3. only use 16bit or 32bit color depths. 24bit is slow. also only access the buffer using a DWORD or USHORT never read in one byte at a time.

4. most cards cant do much hardware acceleration on sysmem surfaces. this goes for fills. on the other hand most ago cards can accelerate blits from sysmem to vram.

5. anything in sysmem should be completly drawn and copied (lock() or blt() ) all at once from a single buffer. this will reduce bandwidth.

6. dirty rects are your friend and reduce bandwidth.

7. there is ussually no reason to clear the screen or an back buffers. if your copy pixels to the buffer, this means they dont need to be cleared.

8. DONT split your sysmem to vram copies to small sections unless you are doing dirty rects. multiple locks()/blts() can cause slowness to occer.

9. it dont matter what video card you have when dealing with copying data from sysmem to vram. only thing that matter is if its agp, and how much it can transfer (ie agpx1 agox2, agp4x). an 4mb ati rage pro is just as good as a 32mb geforce2 when dealing with this.

10. 640x480x32 uses 4x as much bandwidth as 320x240x32. this means that at best you should see a decrease of only 25% when moving up the res. its obvious your doing something wierd, turn off vsync.

Anarchi, your system CANT do 400 frame per second no matter how optimized you make your blit routine when moving that data from sysmem to vram. seems like you dont know what your talking about. 400fps seems more like a everything is in vram, and you only blt vram to vram.

just for comparison purposes. i do a fullscreen fade, fullscreen blur, draw 512 particles, running in 640x480x32. I get an avg of 47 frames per second without vsync and about 36 with vsync (refresh of 100hz). this is on a p4 1500mhz. so its definatly your code. also this test had winamp running in the background. i get slightly better speed when its not running. btw, when blitting to the backbuffer, i use a single lock() and move the entire buffer from sysmem. also i dont allocate my sysmem buffer using dx, its allocated using malloc(). it should not make a difference though.

so in the end i am moving an entire screen over 2 times (since the blur does 9 reads per write, so its pretty high quality. MMX helps greatly with this). THEN i am moving the entire buffer to vram, and doing the flip() (flips are basically free when not using vsync).

yep, same type of blur. i read all 8 surrounding pixels plus the current pixel. i do this by read the first pixel, then each subsecent pixel i read i add to the current pixel. so after read them all, i have already added them all up. i also unpack the values so that it is in a 16bit format (ie each color component gets a full 16bits for calculations while in the mmx register). this prevents overflows, and allows better accuracy. i then MULTIPLY by a constant value which is in fixed point and represents 1/9. i take the top 16bits of the calculation. thanfully this also takes care of the shift. then i repack the values (an mmx thing) to the normal 8bit per color componnet. this allows me to work on all the color components simultanously instead of spliting them and doing the calculations seperatly.

without mmx, you can still use some clever tricks, first off instead of seperating color components to r, g, b. try

rb = color&0x00FF00FF;
g = (color&0x0000FF00)>>8;

this allows you to add all the rb pairs using a single add. you dont need to worry about iverflow since that will never fill a 16bit value.

then you multiply by constant in fixed point. with mmx this was easy since i could use 65535/9 and take the top 16bits and skip the shift (since the different muls in mmx allow you to decide which half to take of the 32bit answer). in your case you have to use 0x1C. its less accuarcy but should be sufficent. if you sepearte all the color components completely you can use 0x1C72 for much better accuracy.

rb*=0x1C;
g *=0x1C;

finish fixeed point mul up
rb=(rb>>8)&0x00FF00FF;
g&=0x0000FF00;

combine
color = rb|g;
if you dont understand this, read up on fixed point math, its very helpfully.

when doing bumpmapping and other effects you actually create workloads that arenot linear with resolution. also the z buffer probably is slowing you down as well. consider rendering at half res and interpolate values. this may be faster. also on anything that gets converted to int for array access on a per pixel basis should be done in fixed point. conversion from float to int is slow.

also, side note. the mmx register looks like this.
aarrggbb since mmx registers are 64bits long and have special instructions to group bytes (in 8bit 16bit 32bit or 64bit) blocks and work on them. you can also dictate how over/underflow is handled. either the value is capped to the highest/lowest or natural wrap around occers. you can do adds, subs, muls, and shifts in this manner. i dont think mmx has a div instruction. though you have to use a few instructions to convert from the packed 32bit argb format. then at the end some more work to reconvert back to 32bit packed format. i am no mmx expert, but know it well enough to optmixe some things even if i am not using mmx to its full potenial. take a look at the 16bit mmx alphablend article on this site. its quite imformative and should get you started if you decide to go the mmx route if you can get mmx working on your compiler through inline asm.