Hacker News Reader

Comment by djmips | Hacker News Reader

It's interesting. I downloaded, then renamed the Windows files from CPP to C so that I could easily compare the PSX to Win98 source version. You are struck at how small the project is compared to modern games. When you compare the source it becomes both a view into mid nineties game programming and how the game was ported from the Playstation to the PC. They really used a kind of emulation layer to ease the port to PC. There is a LibGTE.h which should be an abstraction of the 'Geometry Transform Engine' of the PSX hardware. I'm just getting into the code but it's small enough to grok and fun to look at.

View on HN

It appears that the game on Windows (correction MSDOS) used raw frame buffer not Direct 3D. The entire polygon rendering appears to be in x86 assembler contained in 3DPOLY.ASM with the triangle setup in DRAWPOLY.ASM

However there is also a code path for drawing using a proprietary ATI CIF hardware accelerated 3D API in winati.c - support for RAGE cards only.

I'd never seen the proprietary ATI 3D calls before.

I dug up some more info here: https://drew1440.com/tag/ati-cif/

Back in those days, there was 3dfx and ATI was just starting. Direct3D had abysmal reputation and only for very unstable Windows 95, I don't think 3dfx worked with it very well. Plus as you wrote it was DOS game, nothing like that there, just direct programming for specific cards.

Boy some good vertigo memories come with that game.

It came out just as the changeover started to happen from DOS-based software 3D engines to Windows DirectX 3D engines.

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...

  ; 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.

So it seems they took the easy road and just made a polygon renderer that was just good enough, or as good as the PS1.

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.

Yes, I mentioned that the triangle setup appears to be in DRAWPOLY.ASM

Yeah, I did some software poly stuff too but late eighties and it didn't have texture mapping. It was used in some sports games.

The ApplyMatrix and DLSRotTransPers functions are implemented with inline x86 assembly. Must have been on the hot path. There is also some inline assembly around decimating textures to adjust their size on load.

Yes, and there it is. Libgte.c a PC implementation of the PSX libgte library. Some of these functions are quite laborious without the hardware support. See NormalColorDpq3()

Reply on news.ycombinator.com