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.
I think Pentium 3 sockets were through-hole, so to use one they would have had to fit two different footprints on the bottom side of the interposer without any overlap. It might not have been physically possible.
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.
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.
I could be wrong, I didn’t work on it, but I believe these jankyness you describe was because DX was originally going to be like a Fallout style game but pivoted to an FPS. Old code left over from Troubleshooter and flawed game design choices that didn’t translate to a full 3D world.
But I could just be remembering it wrong.
Are you sure that the jankiness you describe is not related to you not being close enough to the enemy for it to count as a point blank hit? The engine does a simple distance check which is rather unforgiving, and if you utilize the range your melee weapon affords you, you will fail this point black attack check. This is just a guess on my part, but it's the #1 reason I've seen people be perplexed at seemingly inconsistent melee stealth takedown behavior.
If you first push yourself as close as you can get to the enemy model and attack the general area of their torso, it works every single time. But again, this is just me taking a guess as to what the problem you're referring to is!
Well that's the problem. In the first mission you have to figure out to stun the enemies in the center of their back rather than directly in their head. Its super counterintuitive and probably leads to many players not getting past the first mission.
The minicrossbow is even harder than the prod, especially at lower skill levels and with no weapon mods. The prod at least stuns enemies momentarily. With the darts they still stand around shooting at you and set off alarms, and that's if you manage to hit them at all. You can run up to a guy and get a guaranteed stun in the time it takes him to spin around like a dumbass to look at the source of the footsteps.
My first playthrough, when I was 12, I opted for the GEP gun, but had to go to the minicrossbow after running out of ammo, thereby leaving me with no pistol skill. The worst of both worlds on the very first mission. Ended up climing up the back of the statue of liberty and throwing gas grenades. Good times.
The GEP gun is ironically the pro choice to make if you know what you’re doing. All of the other weapons on offer can be found in the first level, and the GEP works as a fantastic “lockpick” even if you never fire it in anger.
This is true, but the upside of the crossbow is that for most soldiers it only takes a single shot to take them out, even if it takes a while, and you can do it from a safe spot, this can be beneficial if your JC sucks at combat or is low on ammo.
Also if you have to stun them in a pinch, they just stand there being spastic, you can knock them out by prodding a second time, but if you do it right away the hit won't register, you have to wait half a second and move around a bit or something. This is very annoying since it wastes precious prod charges.
This may be because the 'headshot' multiplier is lower than the regular multiplier (1x vs 2x) for the prod and baton. For most weapons the headshot multiplier is 8x (or something).
The game also features bullet drop, but this is completely broken. Iirc it does a hitscan against the cylinder and then depending on the length of the ray the hit point is moved further down the length of the cylinder, but this means you cannot for instance aim above the character to compensate for bullet drop.
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.
If anybody here wants to learn more about console graphics specifically, I think the original PlayStation is a good starting point since it's basically the earliest and simplest 3D-capable (though it would be more correct to say triangle capable, as it does not take Z coordinates at all!) GPU that still bears a vague resemblance to modern shader-based graphics pipelines. A few years ago I wrote a handful of bare metal C examples demonstrating its usage at the register level [1]; if it weren't for my lack of spare time over the last year I would have added more examples covering other parts of the console's hardware as well.
I'm using Firefox 139.0.4 canonical-002 Snap on Xubuntu, and the videos don't play for me. Even when not using private browsing, even when I disable uBlock Origin, even when I disable Privacy Badger (and, of course, I've set NoScript to enable JS for the tab.)
It not necessarily physical RAM. If you memmap large files, like maybe a large file from RAID or network share, you could still need that much virtual address space.
No, but 5-level paging is opt-in anyway, so its presence isn't problematic if assuming a 48-bit address space. Linux won't allocate space outside the 48-bits unless you give an address hint to mmap outside the 48-bit range.
My favorite trick with <marquee> was to nest them, with different, alternating directions. You could make the contents alternate between scrolling and stopping by setting the inner marquee to travel in the opposite direction at the same speed as the outer marquee. Or do more levels with alternating speeds to make it zip around randomly. I think you had to set a max width for the inner marquees for this to work?
Shenmue is one of my favorite games. I did a bunch of Ghidra reversing on the Dreamcast version last year, since I wanted to add improvements to it. Like adding bilinear filtering on the sky background, making time run a bit (faster so you can see time specific events like Christmas/New Year more easily,) getting the game to run without disc swapping on an ODE, and adding antialiasing (which would require mipmaps to improve rendering performance, which would require higher texture compression levels to get them to fit, which would require a different texture format that supports that...) I never got around to actually implementing any of that, outside of doing some experiments, like forcing bilinear on all 2D elements.
I don't think I found the sun/moon code (or more likely I did, but didn't realize what exactly it was doing, Ghidra SH4 has serious problems with floating point instructions making following anything that uses them almost impossible) but I did find most of the other time related code for updating the clock/calendar.
One weird thing I found while doing that is about the in-game watch. You always have a watch in your inventory, so you'd think it would be hard coded in, but it's treated like any other item. The game also has code to check if the watch is missing and add it back in anyways. But the code that draws the on-screen clock also checks if you don't have the watch, and won't draw the clock if you don't have it (or at least part of the UI clock logic is disabled, I haven't actually tried seeing what happens if you don't have a watch to verify if my interpretation is correct).
On the PAL version, the code that checks for a missing watch is at 0x0c180dc6 (that's where the code is loaded into memory, subtract 0xc010000 to get the address in 1ST_READ.BIN), and I think the code for drawing the clock (or at maybe it was just updating the hands of the clock?) is at 0x0c18290a.
Dreamcast Shenmue has code to support other video modes, like alternate resolutions (320x240p!), antialiasing, and 24/32 bit color. They're a bit bugged, like when using antialiasing, the 2D elements being squashed into the left half of the screen, and some strange issue with the screen position for the RAMDAC being setting incorrectly, causing the screen to vibrate left/right by a pixel or two, but the 3D models were drawn correctly.
24-bit color worked surprisingly well (even if the flag intended to enable it didn't seem to work, and I had to force it elsewhere.) I would have thought that having less video RAM free would have caused serious problems, but the game just loaded fewer NPCs. It was strange playing without dithering.
It seems like it should be possible to do the X async method without tearing.
When updating the cursor position, check if line being output overlaps with the cursor. If it isn't, it's safe to update the hardware cursor immediately, without tearing. Otherwise, defer updating the cursor until later (vblank would work) to avoid tearing.
Of course, this assumes it's possible to read what row of the frame buffer is being displayed. I think most hardware would support it, but I could see driver support being poorly tested, or possibly even missing entirely from Linux's video APIs.
This would have to be done by the kernel driver for you GPU. I kind of doubt that it's possible (you're not really scanning out lines anymore with things like Display Stream Compression, partial panel self refresh and weird buffer formats), and doubt even more that kernel devs would consider it worth the maintenance burden...
I mean at some point it's a fundamental choice though, right? You can either have sync problems or lag problems and there's a threshold past which improving one makes the other worse. (This is true in audio, at least, and while I don't know video that well I can't see why it would be different.)
https://www.vogons.org/viewtopic.php?t=95704