That game was supposed to be 2D, but was switched to the characters being 3D, so I brought my whole DOS software 3D engine and ported it to DirectX over the course of 2 weeks.
I'm going to dig into that drawpoly.asm! There was a lot of competition in the early->mid 90s for poly blitting. I would say I had one of the very top ones. I was doing demo coding before I became a commercial video game developer.
LOL.. reading DRAWPOLY now...
; Draw flat shaded poly
; IN: EDI->polygon data
; OUT: Polygon appears as if by magic in buffer
The real blit code is in 3DPOLY.ASM. Doesn't look like it does perspective-correction on the texture-mapping, which isn't unusual for the time. I don't remember the PS1 well enough, did it do correction in hardware?
No, it didn't. It also didn't do any subpixel correction. Instead, there was a lot of tesselation happening to try and mask the texture warping somewhat but it was never really all that successful.
Yes, this would have had the additional benefit that it was going to be pretty performant since having to do z-buffered perspective correct texture mapping wasn't cheap on PC's at the time and the game was already set up to not require any of that.
I worked on this game at exactly the same time:
https://en.wikipedia.org/wiki/Abomination:_The_Nemesis_Proje...
That game was supposed to be 2D, but was switched to the characters being 3D, so I brought my whole DOS software 3D engine and ported it to DirectX over the course of 2 weeks.
I'm going to dig into that drawpoly.asm! There was a lot of competition in the early->mid 90s for poly blitting. I would say I had one of the very top ones. I was doing demo coding before I became a commercial video game developer.
LOL.. reading DRAWPOLY now...
The real blit code is in 3DPOLY.ASM. Doesn't look like it does perspective-correction on the texture-mapping, which isn't unusual for the time. I don't remember the PS1 well enough, did it do correction in hardware?