Work has started back up on Reburn 3! It's taken longer than I'd hoped, but we're officially making progress once again!
To be honest, part of the reason I was putting it off was because I felt a little unsure about the direction to take this long-term. As I've alluded in earlier updates, I'm currently working with two builds of the game: the Xbox build, which can be made to run on PC with the help of Cxbx-Reloaded, and the prototype PS2 build, which I have a large amount of documentation for.
But the Xbox version has a big problem from a reverse engineering standpoint. It uses heavy LTCG (Link-Time Code Generation) optimizations that make it immensely more difficult to work with and modify. What could have been a simple injecting/hooking process now requires significantly more effort.
It's been enough for me to consider just saying "fuck it" and decompiling the documented PS2 prototype instead. But then we'll be waiting ages (potentially years) before we actually see any results.
So it's tricky. Ultimately, I want the portable codebase that we would get from a full decompilation, but we have something today that's probably 85% of the way there to a usable Windows port. It's hard to know which approach is worth prioritizing; which one is more worth my time.
What I've decided is somewhere in between. I'm still going to build off the Xbox version - still using the PS2 proto as a reference - but I'm not just going to correct the handful of Xbox push buffer calls so it runs well on Windows.
Instead, I'm going to try my hand at
rewriting the graphics system, so it could theoretically run well on
anything. I see this as a reasonable compromise - we don't have to decompile the whole game before we get results, but we're still progressing towards what could be a full decomp
one day, rather than just tweaking some low-level Xbox stuff.
So how is this going to work? Well, hopefully, this will actually be easier than it sounds. Burnout, as I've mentioned earlier, uses RenderWare, whose primary selling point (apart from making the PS2 easier to develop for) was cross-platform compatibility.
In theory, detaching the game from its own Xbox version of RenderWare and linking it up with the Windows version of RenderWare - and smoothing over platform differences as necessary -
should work. Unfortunately, this is complicated by the fact that LTCG has inlined much of the RenderWare and D3D8 code; it can often be hard to know exactly where one function begins and another ends. But hey, what's reverse engineering without some new puzzles and challenges to be solved?
If this works out, it should then be pretty trivial to switch it over to librw - an open source reimplementation of RenderWare that supports more modern platforms like Linux, macOS, and the Nintendo Switch, and also shields us from having to distribute any confidential RenderWare code. Once again, this will bring us a significant amount of the way towards a portable/decompiled codebase.
So in the interest of setting small achievably goals for myself, my first is simple: try to get the initial "loading" screen to appear entirely natively through Windows RenderWare.
This screen is super simple, but is still assembled and rendered in realtime by the game (you can see in
another thread where I was able to edit the text). It's also completely isolated from the main game loop, so it should be relatively easy to get working without having to worry about the rest of the game.
RenderWare proper supported D3D8, D3D9, and OpenGL. If we can get this loading screen to display in all three, it'll be the first time Burnout 3 has ever rendered natively in OpenGL. I don't know about you, but that sounds pretty interesting to me.
Stay tuned, I'll keep you guys posted!
P.S. I've also updated the project's
README page to better reflect Reburn's updated goals and make it easier for newcomers to understand what we're trying to do.
