Mail Archives: djgpp/1998/05/27/00:31:19
From going to the Intel site and downloading and reading a lot on MMX
information. So far (probably, or SHOULD change in the future), to make MMX
backwards compatible, MMX uses the FPU registers, so MMX that will store
data, will use FPU registers, which means to process MMX, you would have to
switch from FPU to MMX mode, and when you wanted to do a FPU operation, you
would have to store the MMX registers, switch back to FPU mode, and restore
the original data back to the FPU, and then vise versa whenever you wanted
to do a certain function.
My opinion :
Don't use MMX for a 3D engine. I have 3 programs that are designed for
MMX. Frogger, The Human Body, and "POD", the last two I got with my
computer. Frogger has an option of using MMX, and Non-MMX instructions, the
MMX at any resolution (including 320x200) is so slow it's impossible to
play.. the Non-MMX play is MUCH faster, and gives me a very well frame rate,
up to 640x480... The Ultimate Human Body uses MMX, has no option to not use
MMX, and when it does the 3D rendering jobs, it takes about 2 seconds to
load the next frame.. POD does ok, so their engine is better than the
others, but it's still rather slow. I would suggest doing is do the best
you can with a normal 3D-engine, and design support for 3D accelerated
cards.
BTW, I'm doing this on a P166MMX, with a non-accelerated graphics card. POD
and Human Body were running in 16-bit mode, Frogger was in 8-bit.
Another reason to not use MMX is you will have to learn MMX opcodes, and
program them yourselves either doing Binary Programming (seeing what the
bytes would be, and putting in a DB statement), or using NASM and
incorporating those into your program.
Wai Teng wrote in message <356A673C DOT FEB310D2 AT mailexcite DOT com>...
>Is it worth the effort to use MMX instructions in the 3D engine I'm
>trying to write?
>
- Raw text -