How I Fixed a 10-Year-Old Guitar Hero Bug Without the Source Code [video]
youtube.com
youtube.com
This also demonstrates how much "human working memory" reverse engineering requires. No matter how much the tools try to assist, you need a tremendous amount of context to be able to make sense of what you're seeing. Really impressive work.
Check out https://godbolt.org/, you'll learn some assembly.
But I was fortunate in that I could run the game in the debugger and see what was happening, the path from reading the data to decrypting it was rather simple to figure out, and the algorithm was pretty easy to spot. If I were to reverse engineer the actual asset formats I'd imagine it would take months as you need to know how everything is tied together in order to make sense of what is happening. It looks like in the case of guitar hero, this guy has spent an extortionate amount of time reverse engineering everything.
https://www.youtube.com/channel/UClcE-kVhqyiHCcjYwcpfj9w/vid...
Very nice video.
But what bothers me, is the bug itself. It is shocking to me that someone set a hard limit on a pool and didn't add any code for replenishing it. I would just never do such a thing.
One of the first programming environments that I used was MicroWorlds LOGO, and they had a cheaper version which allowed a maximum of 200 turtles, and a more expensive version that differed only in that the number of turtles was unlimited. My father got me the cheaper one and since then I've had a religious hatred of arbitrary limits in programs. But even if you didn't have this experience, I'd have a hard time respecting any programmer who would have left that pool unreplentished and called it a finished project. I accept the fact that we all make mistakes and make bugs, but that wasn't a mistake bug, that was consciously sucking out of laziness and not even bothering to gracefully handle failure.
So there are a lot of these things in games where they just run a script on all their assets and what not to figure out how much memory they will need for it, then allocate fixed pools at the start. These programmers would love to just throw that stuff into a vector but given their growth strategy you can end up wasting half your memory. Even worse, every element added into the vector might now cause it resize and when that happens during gameplay it might just ruin your 16 ms frame target. A fixed pool is as fast as you are going to get, no random chance your game is going to stutter and no waste.
Here is a great talk on this:
- This code was written for the XBox 360 which only has 512MB of memory.
- Because the game was made for a console, it needs to go through the notorious Xbox certification process. This involves running the game for hours at a time at maximum load to ensure no memory leaks exist and that the game runs at a consistent 60 fps.
- Games are not the same as long-living applications. They are made on a project basis. There are constant trade-offs where good enough is the correct decision.
- This is a port, so there's care to be taken in reducing the footprint of changed code.
It's unfortunate that this particular bug wasn't found before release but I think the root cause wasn't necessarily this pool size being low but instead insufficient testing.
Source: Ex-gamdev who's shipped things on x360, ps3 and psp.
For reference we usually split the psp 8MB/24MB System/Video+Audio so you'd have to get everything in < 8MB. For stuff that was highly dynamic we'd use Lua in a fixed block of 400kb. Usually that was enough to do all the game state and could be reset from level to level.
Best public information I've seen on this stuff comes from Mike Acton, he's got lots of great stuff around Data Oriented Design which touches on this(and also why caches are so friggen important).
There was nothing awfully wrong with the code, sure, much of which had been through numerous PC games, and a lot of which was shared with the PS2 version... but finding all the stuff that wasn't awfully wrong, just a bit wrong, and wrong enough to cause problems after running it for 3+ days solid, was surprisingly painful. But I figured it out. Even if I'm not the sharpest tool in the box, I'm persistent, and I've been served well over the years by my ability to bring this to bear on whatever problem I'm facing. So I did that, and it all got fixed, and it shipped like that.
Once it got signed off, I started working on another Xbox title that was nearing completion. But by the time that one reached the certification stage, about 3 months later, the requirement had mysteriously changed to just 2 days! I wonder why...
(I expect what they had in mind was using it in shops, either running in the shop window, or as part of a counter display, and so on, and that drove the requirement that it had to run for a week.)
Unless I'm misinterpreting the video, the bug only occurs if you modify the game to add extra custom songs. The bug won't occur with the original unmodified game data. As with so many things in tech, it works just fine for the intended use case.
Downloaded songs were part of the intended use case on the lead platform, but no official DLC ever came out for the PC version to make use of it.
Having a setlist with 200+ songs was probably never even tested.
Your relatives probably have 2gb of memory and a i3 cpu or something similar.
[1] http://techreport.com/review/27909/the-ssd-endurance-experim...
Killing PRO's in 100T is an aberration
Besides, RAPID mode seems to destroy performance if you care about number of operations per second(and I do very much, I'm writing millions of files to the drive every day)
http://techreport.com/review/25282/a-closer-look-at-rapid-dr...
https://blog.codinghorror.com/the-hot-crazy-solid-state-driv...
(where's ssd's 'hotness' is more important than their 'craziness')
SSD + disabling animations go a long way to increase "speediness"
I'd agree that it's sloppy coding, but I can also see it from the original developers point-of-view. Why check something you know isn't going to change?