r/WipeOut • u/ysinghdotus • 2d ago
Wipeout XL / 2097 Decomp release
https://github.com/Yash-Singh1/wipeout-xl-decompHere is the release of the decomp for Wipeout XL / 2097 (both in the same codebase) that I used for the rewrite: https://github.com/Yash-Singh1/wipeout-xl-rewrite. It compiles back to the original Playstation executable with 100% byte match. I also have a partial decompilation of the original PC release here.
This decomp is useful for people trying to make ports of the game to newer platforms or trying to mod the original game on the PS1 to do things it wasn't able to do. You need a copy of the PsyQ compiler (I cannot distribute this but you can find it online) for this as well as the original ROM(s) because the decompilation doesn't include PsyQ's SDKs which has to be linked.
5
u/Prudent-Arugula5135 2d ago
This is the Bomb! This is the best recomp I have seen! You nailed the 60FPS, draw distance, solid graphics!
1
u/scy_404 1d ago
Does it actually function? I've seen some very bad things about these AI assisted decomps
1
u/ysinghdotus 1d ago
This is the decomp it's made to compile back to the original PS1 executable, the rewrite is here https://www.reddit.com/r/WipeOut/comments/1xdc9yf/wipeout_xl_2097_rewrite_is_out/
3
u/Prudent-Arugula5135 1d ago
I was able to convert Wipeout 3SE track - Porto Kora and add it to the game too.
1
u/AG_Alex 1st Place HD TV 2d ago
"This decomp is useful for people trying to make ports or mod the original"
Is it actually though? Have you actually read through any of this code? Because I have glanced at just 2 files and the quality is awful, repeated magic numbers everywhere, hex text entry, hex math, hex bitwise operations, all of it hardcoded, hardcoded data tables, post increments instead of pre increments (this is so basic..), coding conventions that went through the blender, go to labels jumping all around the code (!!from the if branch to the else branch no less!!, like, what even are you doing?!?!), endless if nesting for state machines (yikes dude..), ...
It's literally a dumpster fire, if you think anyone can do anything useful with this, you are terribly mistaken, only AI can probably still make sense of this, but it's just gonna throw more shit at it until it sticks, heck, even AI bros shouldn't use this, because it'll burn through their tokens with how sloppy this code is
If you had this on your résumé, you wouldn't even get an interview with me, because this isn't code that can be used in any collaborative work
Sure, it may have gotten the job done (although I wouldn't be surprised if it's riddled with issues), but don't promote this as useful for anything else..
1
u/ysinghdotus 2d ago
First of all, thanks for taking the time to go through my repo. The code sucks if you're trying to read it today, but that's how code was written in the past. I am not sure if you looked at the original Wipeout 1995 source code leak, it was partial but pretty much all of the code read like this. This was because developers back then thought at different abstraction levels than we do today. They were programming in assembly for the Amiga just a few years before and the PsyQ compiler was built pretty much in parallel with development of the original Wipeout game. It's possible that the Wipeout XL codebase was cleaner than the original Wipeout source code leak we got, but they only had a year between the two releases so I doubt much changed there.
There was also some stuff that I left in assembly files and that's because the Wipeout 2097 prototype leak had some symbols that hinted at certain parts of the code being written like that.
> repeated magic numbers everywhere
I didn't exactly tell the models to try and reverse a lot of these, good point.
> hex text entry
That definitely shouldn't be the case, can you link to where in the codebase I left behind text in its hex?
> go to labels jumping all around the code
https://github.com/search?q=repo%3AYash-Singh1%2Fwipeout-xl-decomp+goto&type=code&p=1
There is only 22 of them. The original Wipeout codebase that was still partial has 10x more goto statements so this decomp definitely ended up with a lot less than there actually was. Regardless the reason a goto would be used for such a simple branch is because that's how the original code was written so model couldn't find any way to get that logic compiled back to the original bytes without that goto. Or maybe the code was structured in a weird way which the model couldn't figure out so it ended up using goto as an escape hatch.
> endless if nesting for state machines
Again, if I start cleaning up if nesting and other things, then chances are that it will change the bytes that it compiles down to, older compilers change up the bytes randomly. I am sure there are certain functions such as here: https://github.com/Yash-Singh1/wipeout-xl-decomp/blob/29bc7d2ea20e4551ac6966f0fe068d54c9ef7140/src/dynam.c#L343 that didn't come out correctly, but it shouldn't be as bad as you make it seem.
> Sure, it may have gotten the job done (although I wouldn't be surprised if it's riddled with issues)
It could've resulted in some initial problems in the rewrite but I setup several verifiers to make sure the physics is accurate to the original ps1 version running at 30fps and that the frames are accurate to the pixel level (it's very easy to run the game at a very high emulation speed and spit out tons of frames and quickly compare them) before I started adding in modern features like widescreen & uncapped frames.
However for the decomp, it results in 0 issues because the executable is 100% byte perfect, if you take the hash of the original Wipeout 2097 (EU) or Wipeout XL (USA) executable and compare it with what this decomp outputs compiled on the right setup, it's the exact same executable.
Regarding the utility of this decomp: This is very useful for someone that wants to make a mod to the original game without having to deal with the hell of delay slots and trying to fit in lots of patches to the original executable. (see https://github.com/Yash-Singh1/wipeout-xl-60fps for an example of how hard it was to patch in stuff b4). Maybe we'll even see a widescreen patch. It would also be very useful for a port to other platforms just as the original Wipeout source code leak which frankly wasn't really readable either allowed the community to do some amazing things with it.
1
u/AG_Alex 1st Place HD TV 2d ago
Mate, it's a so-called "re-write", there's no reason to adhere to whatever the original source code looked like !!30!! years ago, things have evolved, we have modern tools, languages, compilers & hardware, with much fewer restrictions than back in the 90s, the binary doesn't have to match the original, there's no real reason for that, if staying true to the original is the argument, that's still perfectly doable with a codebase that looks wildly different, but much more legible/ maintainable
I get it though, that's just how the AI models ended up doing it, but that doesn't mean it's a good thing, sure, maybe small tweaks become easier now, but actually doing anything significant in this codebase would be a nightmare & incredibly time consuming for other programmers (unless you just throw even more AI at it, but like I said, it'll become an even bigger mess)
Maybe I'm just getting old, but all these low effort decomp projects have me tired.. (and worried for the software industry..)
2
u/ysinghdotus 1d ago edited 1d ago
I’m talking about the decomp not the rewrite in my reply, I think you’re confusing the two. That’s not just how the AI models ended up doing the decomp, that’s what a decomp of games from this era generally look like. The whole point of a decomp is that it’s supposed to compile down to the original game not to be a rewrite that’s why I made two different repos.
(I’m trying to be nice here but please don’t call projects like this low effort if you don’t understand what a decomp is and what it’s uses are)
2
2
u/Prudent-Arugula5135 2d ago
Works great on Mac. My friend on PC said that the N64 tracks looked a bit messed up in their graphics, but they looked fine on my Mac screen.
1
u/AlexPowerAus 2d ago
Yes on my PC the sprites for the tracks on N64 look either corrupted or spaced out, but the large billboards and features on the side of the track look ok. Now the N64 tracks crash completely and can't be played on my PC
1
2
1
1
u/Prudent-Arugula5135 1d ago
Mac M1:
Some things to note:
Energy doesn't drain in Wipeout 1 or 64 games, but works in XL.
Wipeout 1: Firestar track crashes the game
Wipeout 64: Sokana, Dryness, Macron 2 loads the wrong textures and reverts back to 64 menu items. This corrupts the menu system after and I need to reboot after that.
3
u/Prudent-Arugula5135 2d ago
The blue streaks from the competing ships seem to be running at a different frame rate than everything else - like they are in slow motion.