> The PSX devkits came with a library called LIBGPU, which handled the rendering. Since the PSX GPU didn't have a z-buffer, all primitives you wanted to draw (triangles, quads and sprites) needed to be submitted into an “ordering table” or OT for short. This table had (typically) 8192 slots allowing for 8192 different z-levels. The GPU would then rasterize the list back to front. The result would not be perfect (in some situations neither of two polygons will have all pixels in front of the other one), but close enough.
This is actually implemented in a slightly funky way on the PS1. The DMA unit responsible for sending commands to the GPU allows for a display list to be built in memory as a linked list of variable-length packets, each of which can hold zero or more commands. What Sony's libraries do is essentially generating the ordering table as an array of 8192 empty packets linked to each other, then allowing actual command packets to be allocated elsewhere (typically using a simple bump allocator) and "spliced" into the link from one empty packet to the next one. The PS1's vertex transformation coprocessor, the GTE, also keeps track of the Z coordinates of the last 4 vertices processed and has an instruction to quickly average them out so that the resulting value can be used as an index into the ordering table.
I wrote a few SDK-less bare metal C examples showing how to build an ordering table [1] and leverage it for 3D polygon sorting [2], should anybody want to check those out.
So when you're drawing triangles on the PSX, do you basically get the GTE hardware to figure out your coordinates, before putting those into the appropriately indexed packet?
I'm guessing this explains the PSX-specific artefacts you would see when rotated triangles would "clip" into each other at the seams of models. The ordering would just come from the average Z coord of the plane.
You are right: unlike modern platforms with vertex shading capabilities, the geometry pipeline runs entirely on the CPU and GTE. The GPU is a "black box" that operates exclusively in screen space and only gets access to transformed X/Y coordinates, which is also why it cannot calculate the depth of each pixel and use it to apply perspective correction to projected textures [1].
I wonder how perspective corrected texture mapping works on emulators.
Maybe the coordinate values passed from GTE to GPU are "shadowed" with extra data about the transformation, that is then retrieved further down the pipeline
Huh. I never thought about this. One of the advantage of some of these emulators is being able to fix the perspective issue on the texture-mapping, but of course most 90s games were doing the texture-mapping in 2D and the 3D points had already been projected into screen space.
This isn't an easy problem to solve. I can't think of a way you could back figure the Z from the rendered data. The only other solution I can think of is to somehow break the models up into smaller polys as they are loaded into memory. If you break them up the individual triangles will be smaller and the lack of perspective won't show.
There actually is a relatively simple, if hacky, way to accomplish this: the emulated GTE can push the Z coordinate (and optionally the full-precision X/Y coordinates) of each processed vertex into a private key-value store, using the rounded X/Y result returned to the game as a key. The emulated GPU can then look up the coordinates provided by the game - assuming they were passed as-is from the GTE, which is the case for the vast majority of games - in the same store to obtain the Z values.
This does not seem to be a new approach, as PC ports of PS1 games used similar tricks all the way back in 2000 [1].
> Each new release was decidedly worse than the previous one. Compare the original PSX version (video) to the DOS release (video): The vertex lighting on the track is gone, everything looks flat, there is no transparency and the speedometer was redrawn by a programmer. The ATI Rage Edition (video) carried this mess forward, introduced visible seams in the geometry everywhere, somehow corrupted the software z-sorting and then screwed up the text rendering with ghastly letter spacing.
I played a lot of Wipeout XL on the Playstation in my late teens/early 20s. I mean a LOT. The only thing I really wished for (other than less frustrating maps and smarter AI) was a higher resolution and farther draw distance. At some point, I found the Windows version in a bargain bin at some store and snatched it up. 640x480 Wipeout XL would be glorious!
Unfortunately whoever ported it was brand-new to programming or something because they pinned the game speed to the CPU speed, or screen refresh rate or similar. Net result was that it ran way too fast even on a modest computer at the time. It's like nobody even bothered to test it. There was a patch floating around to fix the speed at one point, but there are so many other problems with it that's just far easier to run the PSX version in an emulator and call it a day.
I played the WASM version and the controls/physics feel about right!
For the other Wipeout aficionados out there, note that there IS a modern game on Steam called BallisticNG. Supposedly created by (some of?) the original Wipeout developers. It was one of the first things I bought for my Steam Deck when it arrived. Unfortunately, I can't make heads or tails of it. It doesn't seem to be the kind of traditional Wipeout game where you start off with slow ships on slow maps and unlock more as you work your way up. In Ballistic NG, it seems like you just sorta pick your ship and and your map and then go racing against the AI. Or something like that. Maybe I just can't figure out the menus, I'm not sure.
All of this is a long-winded way of saying I support this rewrite and hope to see it evolve to adopt Wipeout XL/2097 features and maps eventually. (But not Wipeout 3, that was a disaster.)
> It doesn't seem to be the kind of traditional Wipeout game where you start off with slow ships on slow maps and unlock more as you work your way up.
IIRC there isn't a lot to unlock. There's one or two locked ships and a bunch of paint jobs. It does have a Wipeout-style campaign (left-most menu option). Each set of races in the campaign mostly resolves around a different set of three maps with various modes and variations, getting faster and faster.
I would love love to see XL/2097 added. That was my favourite. Wipeout 3 was a close second. It was certainly quite different in tone though. In what ways did you find it a disaster?
2nd'd, 3rd'd and 4th'd. 2097 was my favourite by far. Something about the controls was just right. None of the others has felt quite the same. I love seeing WipEout in there. But I long for 2097.
> Unfortunately whoever ported it was brand-new to programming or something because they pinned the game speed to the CPU speed, or screen refresh rate or similar.
Just a reminder that BallisticNG is an equally addictive Wipeout clone and available on all Steam platforms. A Nintendo Switch port was also announced.
WOW! Just a `git clone`, download and unpack the .zip with the assets (end of the blog post), type `make` and it compiles on Linux without warnings into `wipegame`, run it and it works first time!
You need a joypad/joystick, I was surprised that I could plug it in after the game had started and it picked it up, insted of having to restart the game as I remember being the case with other games on Linux years ago.
It is the Apollo Joypad (re-release of the SpeedLink Xeox Pro, http://www.apollo-computer.com/peripherals.php#Joypads) that I bought because it is compatible with the Vampire Amiga V4+ which means it has a very standard protocol, and it is set to DirectInput mode: it has a physical switch between Xinput and DirectInput mode.
I guess any proper DirectInput joypad would work just the same.
I've lately been playing Redout (Redout: Enhanced Edition) on the Steam Deck, and it is a quite fun game in the spirit of the old Wipeout game. Consider giving it a go if you are into that sort of speed-over-everything-else racing games!
I've been also enjoying GRIP racing, which while it's a bit more conventional and has wheels, (follow up to Rollcage) gives me similar pleasure. It's very fast, simple, and the gravity is often just a suggestion.
100%. WipeOut was my first clear memory of "experiencing" design. The branding was so different and futuristic, the ships, the music, even the console itself.
This is so cool! My first entry in this series was WipEout Pure on PSP; such a great experience and remastered twice with HD and Omega Collection. Impressive how the PS1 original can run at 60 fps in a browser.
As a sign of what you're getting yourself into, though (you knew this was coming though, didn't you?): "The leaked source has a few hundred global variables scattered all over. Many of these are brought in to different source files (using `extern int something;`) and there was little logic to where they were defined."
This part is great:
> If anyone at Sony is reading this, please consider that you have (in my opinion) two equally good options: either let it be, or shut this thing down and get a real remaster going.
Its always so fascinating to see source code from console games of the 5th generation when most started using C vs assembly. The ratio of lines of code to "game" for something like this or Mario 64 just seems so incredibly high.
programmers who don't understand seasoned game developers' views on manual memory management (and aversion to garbage collection) might want to take a look at the "Rewriting the memory management" section—look at how simple that is, both to implement and maintain!
Looks really cool and props for fixing a huge amount of spaghetti code.
Now, I wonder if I can make a 3d rasterizer on a FPGA and run the CPU side on a RISC-V...
If anyone else is intrigued by this let me know.
Brings back happy memories of playing this on the demo unit in the shop across the road from my house every day after school because I couldn’t afford to buy the console.
It’s strange how some HN submissions fail to get noticed, and a duplicate submission after a few hours (or even next day) gets upvoted and is more visible.
The dupe detector only gets strict if a previous post has already had significant attention. It's more important to give good articles multiple cracks at the bat, than it is to prevent repeat URLs.
When we see cases where an earlier submission "loses", we sometimes look through that submitter's previous posts and see if there's another good article that we could invite a repost of. Those go into in the second-chance pool (https://news.ycombinator.com/pool, explained at https://news.ycombinator.com/item?id=26998308), so they get a random placement on HN's front page.
This is actually implemented in a slightly funky way on the PS1. The DMA unit responsible for sending commands to the GPU allows for a display list to be built in memory as a linked list of variable-length packets, each of which can hold zero or more commands. What Sony's libraries do is essentially generating the ordering table as an array of 8192 empty packets linked to each other, then allowing actual command packets to be allocated elsewhere (typically using a simple bump allocator) and "spliced" into the link from one empty packet to the next one. The PS1's vertex transformation coprocessor, the GTE, also keeps track of the Z coordinates of the last 4 vertices processed and has an instruction to quickly average them out so that the resulting value can be used as an index into the ordering table.
I wrote a few SDK-less bare metal C examples showing how to build an ordering table [1] and leverage it for 3D polygon sorting [2], should anybody want to check those out.
[1] https://github.com/spicyjpeg/ps1-bare-metal/blob/main/src/07...
[2] https://github.com/spicyjpeg/ps1-bare-metal/blob/main/src/08...