No, I just don't see what that has to do with the software renderer for the PC version.
Matrox M3D: your opinions?
- Thread starter Simon82
- Start date
No, I just don't see what that has to do with the software renderer for the PC version.
Arghh! Hit the key combo for exit 90% the way through a long reply so here comes a shortened version...
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. Perhaps it was a hangover from Console+TV days <shrug>
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.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.
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).
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. Perhaps it was a hangover from Console+TV days <shrug>
Definitely not. I remember that at least.
Actually, I think I've now found what it was but it would be inappropriate for me to comment further.
The other thing we did was throw out the XY clipping as we, virtually, had an unbounded guardband on PCX.... integer transform pipeline which we replaced with a floating point one which gave sub-pixel precision and, on the new-fangled Pentium, was faster.
Captain Chickenpants
Regular
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
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.
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
Oh, it probably did use fixed-point but I think the final projection rounded/truncated the fractional values back to integer.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
Good luck.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
Oh come off it it was 14 years ago
It wouldn't be of interest to you as I'm positive it had no firework simulations.
WhiteMagicRaven
Newcomer
did you have hexen2 continent of blackmarsh?
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.
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.
OpenGL guy
Veteran
Looks like a bot bumped a 3 year old thread.
WhiteMagicRaven
Newcomer
I am not bot, i am human, just seekeng for game.
Rootax
Veteran
But if you were a bot, how would you know it ?
WhiteMagicRaven
Newcomer
