Nice work vgo!...Are you still experimenting with project miniverse?

Quote Originally Posted by vgo
This could be easily fixed by checking/resetting the fpu registers, but this would also nullify the speed increase, making it just as slow as it was before... It's fast because the code expects to find the fpu always in a certain state...The best approach would be to code the whole noise routine in MMX assembly,...
Because the MMX registers overlay the FPU registers, you cannot mix FPU and MMX instructions in the same computation sequence. You can begin executing an MMX instruction sequence at any time; however, once you execute an MMX instruction you cannot execute another FPU instruction until you execute a special MMX instruction, EMMS (Exit MMX Machine State). This instruction resets the FPU so you may begin a new sequence of FPU calculations. The CPU does not save the FPU state across the execution of the MMX instructions; executing EMMS clears all the FPU registers. Because saving FPU state is very expensive, and the EMMS instruction is quite slow, it's not a good idea to frequently switch between MMX and FPU calculations. Instead, you should attempt to execute the MMX and FPU instructions at different times during your program's execution. http://webster.cs.ucr.edu/AoA/Window...uctionSet.html
Can speed be increased by buffering (flushing) and caching? I think more data can be transferred with less procedural calls, which in turn reduces system call overhead...and items in a cache are not limited to a specific type, form, or size...

Rick (Chavez_US)