If you want to see what it's supposed to look like, copy the screenshot into GIMP, go into "Color, Levels" and in the "Input Levels" section, there should be a textbox+spinner with a "1.00". Set that to 0.45.
As a kid, I remember the Windows version from being included on the disk that came with the book, "Windows Magic Tricks," published by Sybex.
Years later, I was surprised to see the exact same cat on a "port" to the Sega Dreamcast VMU (a memory card that can function as a stand-alone device, with a 48x32 pixel screen,) where pressing a button would play one of the animations. It makes a little more sense now, finding out that the cat images were released into the public domain.
Wow, you're not kidding saying that it's cursed. I thought it would adapt a socket to the BGA pads, but it looks like the pins of the replacement CPU just sit naked on the interposer.
Weird coincidence, but I had to look through some old files backed up from the computer I was using 15+ years ago, and noticed it had C:\DeusEx sitting right there, with the SDK files in it. I found the function that handles damage in it.
It looks like I misremembered/misinterpreted some stuff. It looks like the top of the head behaves like the sides of the head, extending upward, forming a + shape.
Judging by how the arm/leg damage works, it the collision hit zones rotate with the enemy. Offset appears to be were the collision point is releative to the character's rotation, since it's also used to determine front/back and left/right collision. So for a hit to count as a headshot, it has to hit a cardinal octant of the collision cylinder.
The headshot collision code in DX is broken as well. This is from memory from looking at the DX SDK years ago (+15 at least), but...
The collision shape used for a character in DX is a single cylinder. The game looks at where on the cylinder the collision point of the shot is, and tries to figure out if it's a head, body, or leg shot. It does this by checking how high the collision point is, with the lower X% being legs, top Y% being the head, and the middle being the body.
If a shot hits the head section, it runs some additional checks, and can sometimes still count as a body hit. There was some weird code that, after you stared at it long enough, looks like it ended up splitting the head area into compass aligned 1/8ths (so north, north-east, east, etc) and hits to the N-E-S-W octants would count as a head shot, and a hit to the NE-NW-SE-SW octants would count as body shots. (I couldn't tell if the angles rotate with the character, or are absolute relative to the world.) I think there was also a check for hits on the top cap of the cylinder, so that the hit would have to be close to the center of the cylinder to count as head hit, and near the outer rim would count as a body hit.
I guess what they were trying to do was make the actual head hitbox a smaller section of the head level, so that a shot that should go over the shoulder and miss would just count as a body shot and not a true headshot. And if you made a test map, with the player and a static test enemy placed in a line, this could work reliably from a fixed position. But when you actually play DX, and approach enemies from various angles, headshots inexplicably fail.
I created a (currently not publicly released) driver for the 1998 Sega Dreamcast's video hardware from scratch. It supports additional features over the driver in the open source homebrew OS, KallistiOS (KOS), like better render-to-texture support (the KOS driver only supports rendering to framebuffer sized textures), tile multipass (which allows for accumulation buffer style effects or soft shadows), and dynamically toggling anti-aliasing on the fly (with KOS it's fixed after init). Some screenshots of my driver can do are here: https://imgur.com/a/DyaqzZD
I used publicly available documentation (like https://www.ludd.ltu.se/~jlo/dc/ and the now defunct dcdev Yahoo Group), looked at the existing open source KOS driver, and looked at the source for Dreamcast emulators to figure out how things worked.
The GPU in the Dreamcast is a bit more complicated than PSX/PS2/GC since it doesn't accept polygons and draw them directly to the framebuffer. It's a tile-based deferred renderer, like many mobile GPUs, so it instead writes the polygons to a buffer in video RAM, then later walks through the polygons and renders the scene in tiles to an on-chip 32x32 pixel buffer, which finally gets written to RAM once.
This allows the Dreamcast to have a depth-only fillrate close to the 360 and PS3 (DC is 3.2 GPix/s vs 360/PS3 4.0 GPix/s), and it basically preforms a depth-only prepass to avoid doing texture reads for obscured texels. It can also preform per-pixel transparency sorting (order-independent transparency) with effectively no limit to the number of overlapping pixels (but the sorter is O(n^2), so a lot of overlap can become very expensive).
To get a working driver for the Dreamcast, you have to set up some structures in video RAM so that the hardware knows what polygons are in what tile. Another thing the driver needs to do is coordinate the part of the hardware that takes polygon commands and writes them to video RAM, and the part that actually does rendering. You typically double buffer the polygons, so that while the hardware is rendering one frame, user code can submit polygons in parallel for the next frame to another buffer.
My driver started as just code in "int main()" to get stuff on the screen, then I gradually separated stuff out from that into a real driver.