I noticed you are using straight Windows API's to do this. I would consider looking into DirectX. If nothing else, do not use SetPixel. Create a memory DC and blt from it to your real one. This way you can use straight memory operations instead of calling SetPixel. That should help a bit.

I wrote a DirectX version of the fire simulation on the flipcode page at: http://www.flipcode.com/demomaking/issue05.shtml

One thing to notice about his filter is that it sums up the numbers of 8 pixels and does a shift right 3 to divide by 8. Accessing only 5 pixels and dividing by 5 is probably still quicker.

I implemented his source code, and decided to use inline assembly for the actual part that does the filter. I let the compiler compile the normal C++ code, then I looked at the disassembly. I was able to notice a lot of optimizations that could be made to that assembly. It kept putting the same values into one of the registers and things like that.

There are bigger issues though...
I would worry about using this effect, since it is framerate dependent. In other words, you can't calculate the time between frames and tween it somehow. Your fire can only move once per frame. In my example, I could get my fire moving at 75 fps in 320x240 (due to V-Sync), but when I went to 640x480, I can only get 42 fps. It took me quite a bit of work to get to 42 fps...

Good luck with whatever you're working on...it sounds fun!

------------------

-Kentamanos

[This message has been edited by Kentamanos (edited November 08, 1999).]

void Burn(unsigned long ulBufStart, unsigned long ulBufEnd)
{
unsigned int nC, nC2;

for (nC = ulBufStart; nC < ulBufEnd; nC+=2)
{
nC2 = (double_buffer[nC + 320] + double_buffer[nC + 639] + double_buffer[nC + 640] + double_buffer[nC + 641]) / 4;
if (nC2)
nC2--;
double_buffer[nC] = (unsigned char)nC2;

nC2 = (double_buffer[nC + 321] + double_buffer[nC + 640] + double_buffer[nC + 641] + double_buffer[nC + 642]) / 4;
if (nC2)
nC2--;
double_buffer[nC + 1] = (unsigned char)nC2;
}
}

well its not that optimized but i wanna post summit

Ok, thanks for your help )
Perhaps I didn't write enough or I didn't give you enough source )
The function SetPixel is my own function of my class ByteMemory. This class allocates a number of bytes. So, SetPixel is not a call to GDI which is way too slow. SetPixel just copies the byte into the position of the bytememory. So, I don't think that SetPixel could be made faster.

I never learned assembler. Some people say it's useless today (with modern compilers) and if you can speed things up the little increase in speed is not worth the effort.

My procedural textures (Unreal uses the same technology for it's water fx and flames and so on) are quite fast now, but I don't think fast enough.

You can download a demo of my 3DEngine at www.voodoospotlight.com/devknowledge/downloads/demos/3dengineinstall.exe !! There you can see my procedural textures.

So, my question: Do you think is it worth to learn assembler and do that stuff in asm or isn't it worth the effort to learn assembler.

Phillip

1) Never make function calls in tight loops - If you need to re-use the code, use a macro (or possibly an in-line function). Functions have a rediculous overhead.

2) Whenever people tell you that optimizing C++ compilers produce better asm: Ignore them! C++ is VERY hard to optimize because of the extreme freedom built into the language. You don't have to be an ASM wiz to get a x2 speed increase from tight inner loops like the one you have - simply take the compiled (non optimized) code, disassemble it and remove the most obvious blunders.

/Niels