ndepoel

The jumpy polygons are because the PSX's GPU only accepts vertex positions in screen coordinates, meaning that vertices always snap to hard integer values. There is no sub-pixel accuracy. That's not a limitation caused by the PSX's lack of an FPU though. A large part of the render pipeline and standard libraries are built around the use of fixed point math, i.e. using integers to simulate decimal values. The GTE co-processor which handles 3D math makes use of standardized fixed-point types. So the PSX would have been capable of calculating sub-pixel coordinate values, it's just that the communication between CPU and GPU was designed to use only integer screen coordinate values.

Which is complete nonsense anyway. Robert Smith from The Cure famously went against TicketMaster before their last world tour several years ago, pointing out the ridiculous prices and demanding that they be lowered to make their shows more accessible. He managed to get TicketMaster to budge and even got them to refund some of the marked up resale prices, costing them millions but generating a lot of goodwill among fans in the process. It's not that artists do not have control, but they do need to put in a good amount of effort to make change happen.

That's usually not a problem with Mega Drive/Genesis games, as they typically don't draw beyond the 224 lines that are visible on a (correctly calibrated) CRT TV. I've played this game on a B&O MX4000 CRT using an original Mega Drive and I didn't notice any issues.

Here's another: code was open sourced with every intention of becoming a thriving community-driven project, but in practice users only take from the code what they want for their own needs and never contribute back, or expect the maintainer to solve all of their integration issues for them. Eventually, the maintainer decides that they have better things to do than fixing other people's problems, and that there is more value to be had from bespoke contract work. Some updates still get pushed but over time the project gradually gets abandoned and the open source dream slowly passes away.

A lot of the things you mention there have been in development for the better part of 10 years already, and still haven't reach a stable, mature and production-ready state yet. Unity have also kept deprecated stuff around for much longer than they should have, which sounds great on paper for backward compatibility, but it just means they're lugging years of technical debt with them and it's slowed them down immensely.

Looking at the past year of Unity updates, since 6.1 or so, it seems that most of the focus is now going to refactoring major parts of the engine to facilitate backporting HDRP's feature set to URP. It's all good work and high time they did some cleanup and committed to a single standardized render pipeline, but it's not exactly moving the needle forward very much yet.

Unity 2022.3 is a great LTS version to park an older game in maintenance mode on. It's where everything kind of congealed into a solid, reliable engine again, after the hot messes that were 2020.x and 2021.x. It's also still receiving updates for Enterprise users through Unity's xLTS program, which admittedly isn't within reach of most people, but it's a good option for already released, successful games that require continued support.

It does make quite a big difference. The network packets received from the server in Quake will tell you exactly what state the game is in at any point in time. They contain information about the position and state of every entity and their motion, compressed via delta encoding. That means there's very little room for misinterpretation on the client side that would lead to de-sync issues. In fact clients have quite a lot of freedom in how they want to represent said game state, and can for example add animation interpolation to smoothen things out.

The example you mention of demo playback de-syncing when the circumstances slightly change, that is exactly what you get when you only record inputs from the player. Doom actually did this too for its networking model and demo playback system. That relies much more on the engine being deterministic and the runtime environment behaving consistently, because each client that replays those inputs has to run the exact same game simulation, in order for the resulting game states to match.

It wasn't really that much to do with determinism. Quake uses a client-server network model all the time, even when you're only playing a local single-player game. What the demo recording system does is capture all of the network packets that are being sent from the server to the client. When playing back a demo, all the game has to do is run a client and replay the packets that it originally received from the server. It's a very elegant system that naturally flows out of the rather forward-looking decision to build the entire engine around a robust networking model.

It kinda does resemble a natural resource though. The machines and technology in use at TSMC are so insanely complex, that there isn't a single person on earth who knows everything about how it works. TSMC functions only because of all of the pieces of the puzzle being together in the right place and arranged in just the right way. It's a very fragile balance that keeps it all running, and a major disruption could mean we get thrown back by a decade in chip-making technology.

The PS1 version uses a custom engine based on technology built for the game Shadow Master, the previous title by Hammerhead Studios. It was a technical tour de force for the original PlayStation.

Yes but also no. The problem with fixed point arithmetic is a lack of dynamic range compared to floating point. Floats are great at representing both large numbers with limited precision and small numbers with high precision, but with fixed point you have to make a choice based on which kind of number you're trying to represent. Meaning you need to use a mixture of 8.24, 16.16 and 24.8 fixed point types (and appropriate conversions) depending on the context of the calculations that you're doing.

It's possible to write a game engine with that limitation, but there's no easy natural conversion from Quake's judicious use of floats to a fully fixed-point codebase. You'd have to redesign and rewrite the entire engine from scratch, basically.

Windows is not exactly free of this sort of nonsense either. Just recently I built a new PC for a friend, and we wanted to keep using his old SSD and Windows installation. After messing about with Bitlocker recovery keys which was already cumbersome enough, we ran into a catch-22 issue where we needed internet access to be able to log in and verify his Microsoft account, but we needed to install a driver for the new motherboard's networking chipset first, for which you need to be able to log in to an account first. Eventually we found that you can use USB tethering from a phone to gain internet access, for which no special driver is needed, which got around the issue but it was not exactly an obvious solution.

That 20% is mostly covered by competitive online multiplayer games that use kernel-level anti-cheat systems which will only work on Windows. There's not a whole lot Valve can do about that, other than continuing to push Linux for gaming and hope that it gets popular enough to create an incentive for anti-cheat providers to start targeting Linux as well.

The real "a-ha" demystifying moment for me was not so much learning about the elementary rotation, translation or even perspective projection operations. It was understanding how all of those operations can be composed together into a single transformation and that all that 3D graphics really is, is transforming coordinates from one relative space to another.

One important revelation in that regard for instance, was that moving a camera within a world is mathematically exactly the same as moving the world in the opposite direction relative to the camera. Once you get a feel for how transformations and coordinate spaces work, you can start playing around with them and a whole new world of possibilities opens up to you.

Id Software very much skirted the edge of legality by making Commander Keen outside of office hours while still employed by SoftDisk and using SoftDisk computers, and SoftDisk could have easily sued them if they wanted to. They managed to avoid that by striking a deal where the Id guys would continue to make games for SoftDisk while working on Keen and later Wolfenstein 3D.

There was a lot of code reuse between games. John Carmack is on record somewhere that the enemy navigation code from Doom and Quake still has its origins in some of the earliest 8-bit games he wrote in the 1980's.