Reburn 3: Development Blog
Re: Development Blog
Before i go enact plan "Sleep", i want to share a minor bug in the menu's. When scrolling through options in the main menu, the text below explaning what each option does, glitches by having a duplicate underneath the original location. It doesn't happen in any other menu, like drivers profile, crash nav etc. I might've explained it poorly so i include a video to show.
- Attachments
-
- It might have to do something with the animation when you go to a menu (the text slides down to the "glitched" position)?
Goin' Flipmode!
Re: Reburn 3: Development Blog
Haven't had much time to work on this lately due to some personal life stuff I've been sorting out, but in the mean time I have been thinking about a kind of conspiracy theory I want to discuss.
Cxbx started pretty early in the Xbox's life. From what I've read, it was at the proof of concept stage, working with sample applications from the XDK, within only a year of the Xbox's lifespan in late 2002, and could play commercial games not long afterward (well, a game, specifically Turok Evolution).
Microsoft must have known about this. They were well aware when "bunnie" dumped the secret ROM and published it on his website, so it's not a stretch to think they would have seen this too. Guess what else happened in 2002?
LTCG was implemented in Microsoft Visual C++. (article)
LTCG, as you're probably aware from my earlier posts, is one of the biggest roadblocks for Cxbx, exacerbated by its use in a huge amount of Xbox games. It's the thing that takes the concept of inlining and turns it up to 11. As you can read in that article above, functions optimized by LTCG are not just frequently aggressively inlined, but even the functions that aren't are still heavily optimized to the point that they don't end up following standard calling conventions anymore. Instead, they pass as many parameters as possible via registers (similar to fastcalls, but even more so), which I've noticed a lot in my analysis of B3 code.
This is a nightmare for reverse engineering, and especially for injecting, because the way functions are called can no longer be easily replicated with normal C++ code. To match what LTCG did in a lot of these cases, I will probably need to write some glue in raw x86 assembly to stitch their calls to my functions. It's a very manual and complex process that otherwise wouldn't need to exist, and it effectively prevents Cxbx from making clean injections/replacements of Xbox system calls; preventing it from being an ideal solution.
Am I suggesting LTCG was added because Microsoft discovered Cxbx? No, almost certainly not. The timing is too fast, you couldn't implement a major linker feature like that in such a short amount of time. Besides, other compilers (like the Intel C++ compiler) already had this feature, so it would be a fairly natural progression for them to make.
But I do wonder if there was some relation to the idea. Perhaps Microsoft realized injection could be used to run games on Windows while the Xbox was still being developed in 1999-2001, and set into motion plans to get LTCG implemented as soon as possible in their linker to circumvent that (also standardizing the XDK around statically linking all system libraries rather than dynamically linking, which would have made injecting them dead simple). There are in fact slight differences between the Win32 API and Xbox API (e.g. D3DSHADE_GOURAUD being 0x2 on Windows but 0x1D01 on Xbox) that it's hard to believe exist for any other reason than to prevent direct binary compatibility with Windows.
The prevalence of LTCG throughout the Xbox library certainly suggests Microsoft strongly recommended developers to use it. Up until now, I assumed this was to squeeze as much performance out of the hardware as they could (keeping the console competitive for as long as possible), but maybe it was actually a form of implicit DRM too. Maybe Microsoft knew this would break approaches like Cxbx...
Cxbx started pretty early in the Xbox's life. From what I've read, it was at the proof of concept stage, working with sample applications from the XDK, within only a year of the Xbox's lifespan in late 2002, and could play commercial games not long afterward (well, a game, specifically Turok Evolution).
Microsoft must have known about this. They were well aware when "bunnie" dumped the secret ROM and published it on his website, so it's not a stretch to think they would have seen this too. Guess what else happened in 2002?
LTCG was implemented in Microsoft Visual C++. (article)
LTCG, as you're probably aware from my earlier posts, is one of the biggest roadblocks for Cxbx, exacerbated by its use in a huge amount of Xbox games. It's the thing that takes the concept of inlining and turns it up to 11. As you can read in that article above, functions optimized by LTCG are not just frequently aggressively inlined, but even the functions that aren't are still heavily optimized to the point that they don't end up following standard calling conventions anymore. Instead, they pass as many parameters as possible via registers (similar to fastcalls, but even more so), which I've noticed a lot in my analysis of B3 code.
This is a nightmare for reverse engineering, and especially for injecting, because the way functions are called can no longer be easily replicated with normal C++ code. To match what LTCG did in a lot of these cases, I will probably need to write some glue in raw x86 assembly to stitch their calls to my functions. It's a very manual and complex process that otherwise wouldn't need to exist, and it effectively prevents Cxbx from making clean injections/replacements of Xbox system calls; preventing it from being an ideal solution.
Am I suggesting LTCG was added because Microsoft discovered Cxbx? No, almost certainly not. The timing is too fast, you couldn't implement a major linker feature like that in such a short amount of time. Besides, other compilers (like the Intel C++ compiler) already had this feature, so it would be a fairly natural progression for them to make.
But I do wonder if there was some relation to the idea. Perhaps Microsoft realized injection could be used to run games on Windows while the Xbox was still being developed in 1999-2001, and set into motion plans to get LTCG implemented as soon as possible in their linker to circumvent that (also standardizing the XDK around statically linking all system libraries rather than dynamically linking, which would have made injecting them dead simple). There are in fact slight differences between the Win32 API and Xbox API (e.g. D3DSHADE_GOURAUD being 0x2 on Windows but 0x1D01 on Xbox) that it's hard to believe exist for any other reason than to prevent direct binary compatibility with Windows.
The prevalence of LTCG throughout the Xbox library certainly suggests Microsoft strongly recommended developers to use it. Up until now, I assumed this was to squeeze as much performance out of the hardware as they could (keeping the console competitive for as long as possible), but maybe it was actually a form of implicit DRM too. Maybe Microsoft knew this would break approaches like Cxbx...
Re: Reburn 3: Development Blog
Can't believe Matt cheated Burnout 3 in favor of lego island i will never forgive him!!!
Goin' Flipmode!Re: Reburn 3: Development Blog
Lol sorry for going MIA, it's true that the LEGO Island decomp has taken a bit more of my time, but my plan has always been to alternate between these two projects, and the only reason I haven't yet is because of my silly 2-month-long move. Don't worry, I'll be back soon!