Matrox M3D: your opinions?

From what I've heard, SEGA is developing a HD casual system to compete with the successor to the Wii.

They might use the SGX543MP16 or they may just base it off the RINGWIDE or RINGEDGE.

Really? :LOL:
 
Arghh! Hit the key combo for exit 90% the way through a long reply so here comes a shortened version...

Surely there would be no harm in revealing the name of the company/game after so many years... Don't be coy with us please, nobody will mind/care. :)
I'm sure they would but, to be honest, apart from it being a racing game that also had a 3dfx port (as we were using that as the starting point) I can't remember the details. The source code was a mixture of C and ASM with, IIRC, the 3dfx calls done with assembler. Also, the draw calls were distributed throughout the code.

Btw, I loved my PCX1/2 boards. Unfortunately I fried the PCX2 by trying to overclock it, but it did go (somewhat) faster with a slightly higher frequency oscillator
IIRC the NEC ASIC libraries turned out to be fairly conservative so I think over clocking possibly not that difficult. I think I also replaced the crystal on mine (but I had a socket for the crystal).


Funny that you say the code was so well-written. I never considered the software renderer itself very fast, and it also was rather unstable iirc... wobbly polygons etc, didn't seem to have any subpixel correction.
Well, the TR code was all in C, and IIRC the polygon draw calls were restricted to only one or two functions making that aspect fairly simple to replace. Of course, there was a lot of other things that had to be done such as adding texture format conversion (palette to 16bpp + MIP mapping), identifying opaque/translucent sub-textures in each atlas, dynamic texture management (as it wouldn't all fit into the texture memory), translucency sorting (as we replaced punch-through with alpha blending), and adding the water effects.

As for the wobbly polygons in the software renderer the original code had an integer transform pipeline which we replaced with a floating point one which gave sub-pixel precision and, on the new-fangled Pentium, was faster. :) We also noticed that the original code, curiously enough, was waiting for 2 vsyncs per frame which we promptly reduced to one. :D Perhaps it was a hangover from Console+TV days <shrug>
 
... integer transform pipeline which we replaced with a floating point one which gave sub-pixel precision and, on the new-fangled Pentium, was faster. :)
The other thing we did was throw out the XY clipping as we, virtually, had an unbounded guardband on PCX.
 
Ah, the good old Apocalypse 3dx. I can quite honestly say it was directly responsible for me having the job I have today.
I was downloading updated drivers and spotted the vacancies link. :)

I would like to see the Cyberk screensaver revived.

CC
 
As for the wobbly polygons in the software renderer the original code had an integer transform pipeline which we replaced with a floating point one which gave sub-pixel precision and, on the new-fangled Pentium, was faster. :)

Yea, I recall some demos with early 3d acceleration which stuck to an integer pipeline, so you had wobble even with 3d acceleration :)
But as I say, there were also software engines that DID have subpixel correction. In fact, the first subpixel-corrected renderer I wrote was aimed at 486 and didn't even use floating point for it (was too slow on anything pre-Pentium :)).

We also noticed that the original code, curiously enough, was waiting for 2 vsyncs per frame which we promptly reduced to one. :D Perhaps it was a hangover from Console+TV days <shrug>

Hah, that's interesting... Perhaps the software renderer itself wasn't as slow as it appeared then... Perhaps one day when I'm bored, I'll try if I can locate the vbl loops and patch them out, see what happens :)
 
Yea, I recall some demos with early 3d acceleration which stuck to an integer pipeline, so you had wobble even with 3d acceleration :)
But as I say, there were also software engines that DID have subpixel correction. In fact, the first subpixel-corrected renderer I wrote was aimed at 486 and didn't even use floating point for it (was too slow on anything pre-Pentium :)).
Oh, it probably did use fixed-point but I think the final projection rounded/truncated the fractional values back to integer.

Hah, that's interesting... Perhaps the software renderer itself wasn't as slow as it appeared then... Perhaps one day when I'm bored, I'll try if I can locate the vbl loops and patch them out, see what happens :)
Good luck.
 
I think I had this card ... or the Mystique 220, not sure (probably the cheaper of the two). It was quickly left behind after release but remained one of the best 2D cards for a long time. i remember that there was a special patch for Descent, putting in bump mapping, first time I'd seen the effect in a game.
 
Matrox M3D is a 3D-only card based on PowerVR PCX2.

Mystique does have 3D acceleration, but it has few features, even lacking bilinear filtering. So it looks similar to CPU software mode. They began to push bump mapping with G400 because it has EMBM capability. There were a few special patches for that.
 
Ahhh ... G400 Max, does that exist? That may well be the one I had.
 
Back
Top