Archived

This topic is now archived and is closed to further replies.

godel

fundamental ddraw optimization problem

Recommended Posts

I''m trying to write a program that let''s me animate 2d transforms of bitmaps. My basic strategy is to load the pixel colors of the bitmap into a lookup table and then to render each frame by locking the back surface, set the color value for each pixel, and flip the front and back surfaces. Here''s the heart of the program: void RenderFrame() { unsigned uColor; DDSURFACEDESC description; ZeroMemory(&description, sizeof(DDSURFACEDESC)); description.dwSize = sizeof(DDSURFACEDESC); g_pDDSBack->Lock(NULL, &description, DDLOCK_WAIT, NULL); unsigned char *pSurfaceBits = (unsigned char*) description.lpSurface; for (int i = 0; i < 640; i ++) { for (int j = 0; j < 480; j ++) { uColor = GetTransformValue(i, j); memcpy(pSurfaceBits + i * 4 + j * description.lPitch, &uColor, 4); } } g_pDDSBack->Unlock(NULL); DDFlip(); } Basically, my problem is that this is too slow. I''m getting about 5 fps on a pretty fast machine and I''m just using an identity transform so there''s no extra math. How can I optimize this? Blitting each pixel individually instead of a lock only slows things down. I don''t know what else to try. Thanks in advance. Kevin

Share this post


Link to post
Share on other sites
Hi

dont directly read form a locked video memory sufrace... that is too much slow on most so called "modern" video cards...

instead do all pixel colour manipulations into a system memory buffer and the use a Blt or a BltFast to paint that system surface on the video back buffer and the Flip...

That should do it

i had the same problem in the start...i did not understanded how pathetic and 3D oriented today video boards are

Bogdan

Share this post


Link to post
Share on other sites
It doesn''t matter, system memory doesn''t have the disadvantage of trying to work through a bus. Do all CPU stuff (your code) in system memory. Do all video card stuff (Blt, BltFast, et cetera) in video memory if possible.

Null and Void
It is an inexperienced programmer who speaks of the length of his works.
It is an experienced one who speaks of the briefness.
http://www.crosswinds.net/~druidgames/

Share this post


Link to post
Share on other sites
Is that so furby?

we (team doing asm rts game) tried to lock read only...oops it lets us write with no problem (first time i was wanting a blue screen or a GPF to apperar...it did not )
same goes about write only...it lets me read no problem

no speed improvements also...

in asm i mean...dont know about C...

have any expl for this strange behaveiour?

Bogdan

Share this post


Link to post
Share on other sites
Readonly and writeonly only position the memory so that it can be read or written faster than the other, it does not prevent you from reading or writing to it (if you look it up in the SDK, it will say this), and sometimes it cannot move it to a better place, and so there will be no speed increase/decrease.



Please state the nature of the debugging emergency.


sharewaregames.20m.com

Share this post


Link to post
Share on other sites