Open aybe opened 1 year ago
You can try something like this.
Interesting read!
I just wanted to see up to where I could get spending a few hours on it yesterday night, to be honest, I was expecting much more resistance but a few commenting and replacements worked, surprisingly.
There is something interesting in how they did it, the variable HiOctane
which appears to be of fixed size is accessed using a bunch of constants. Tried changing segments permissions to see if IDA would translate this better but that didn't change anything.
I wouldn't be surprised if indeed that's how they did it, after all, level files are all of the same size and, most importantly; Hi-Octane has been written in only 6 weeks against the Magic Carpet engine. In such time frame there is no room for clean code.
Debugged the code, crashes are related to wrong stack, I guess because I've commented all __fastcall
to get it to compile...
At this point, I think the most worrying aspect would be to find people that are motivated and with lot of free time... Assuming there are, people should then agree on how to tackle it, another big issue in itself as well.
Personally, I would focus on ignoring everything but getting the race loop logic to work first. Now, that is a pretty depressing aspect to debug code only seeing numbers on screen and no graphics for weeks...
And obviously, between that, people have to live their life, understandably.
Let's see if anything ever comes out of that little experiment!
I wouldn't be surprised if indeed that's how they did it, after all, level files are all of the same size and, most importantly; Hi-Octane has been written in only 6 weeks against the Magic Carpet engine. In such time frame there is no room for clean code.
That's good to know. In case there are some similarities, you can check the current reimplementation of Magic Carpet 2: https://github.com/turican0/remc2
It was Magic Carpet 1 actually, but that's still welcome nonetheless!
Can already tell that compared to the Wipeout source code leak, they use the same pattern: lots of rendering intertwined...
Going to look at the code to try get a better understanding on how feasible it'd be to isolate physics and game logic from it.
Not sure if this is still a thing, but also check out the latest offshoot of the Syndicate Wars fan project here: https://github.com/swfans/swars My understanding is that most of the Bullfrog games used the same internal standardised libraries and the author of that project has been trying to create modern versions of them that can be used as building blocks for other Bullfrog game ports.
Oh, also check out this project which documents big chunks of how the game works: https://github.com/movAX13h/HiOctaneTools They actually started an open source re-implementation of the game but lost interest and did not finish it. As part of this they also corresponded with Sean Cooper and Alex Trowers from Bullfrog about how parts of the engine work, that's also documented on there publically.
https://github.com/aybe/HiOctaneBullfrog
It compiles but does not run, obviously.
It might be worth trying to:
Cheers!🍺