Comment by dijit
7 years ago
I’m always surprised when I see you here but I’m not sure why.
Anyway. I can corroborate this. Debug code is /really/ harming performance in AAA games. Also, you want to remove your “cheats” that QC use to skip chunks of the game.
Older games are known for still containing various cheats to skip chunks of the game or make them easier. I'd guess a PS1 game might still have debug left in along with cheats simply either due to time pressure or someone forgot.
In my experience, we would leave the cheats in retail builds of those old games mostly because leaving them in was less risky than removing them. They had been there during all of development and testing, and we were reasonably certain of the build’s stability, but.. pull them out and your compiled code layout changes, data layout potentially changes, and who knows whether it’ll expose a new misbehaviour we’ve never seen before or know to regression test.
It’s just much much much safer to leave the debugging assistants (level skip, etc) in place. Especially back in the days when we couldn’t issue patches after release!
(Also, depending on era, you could feed a cheat code or two to magazines/websites/etc to get another article written about your game.. doubt that trick works any more, though!)
As a kid from the 90s, I can confirm that I purchased more than a couple PS1 games that I learned about by reading their cheats lists! I wouldn't have found out about the games any other way, since we didn't get reliable internet access until much later. Those game magazines were a big influence on my younger years.
It really depends on what you mean by "debug code". If you mean special versions of the code built with "-O0 -g" (or the equivalent in whatever compiler/toolchain they're using) then obviously that's going to be a problem. If it's just helper methods like "go directly to section X in the game", "spawn any monster" or "if global variable DEBUG is 1 then log this" then that can easily make it in the final product if they're not optimized away in production builds. Those won't seriously harm performance either, just bloat the binary a little (which will most likely be totally negligible since modern games routinely end up using dozens of GB).
I’m sorry, I don’t know what statement you’re making really.
Maybe (uncharitably) you’re trying to look smart or maybe you’re also in the industry and I just don’t understand what you’re saying :/
When I talk about “debug” builds it’s actually a large thing; Not _only_ is it switching the compiler (Microsoft C++ compiler ofc) to build stripped/optimised binaries, it’s also removing things like, built in command consoles, logging subsystems and “phase handlers”, budget profiling for subcomponents of the game (AI, lighting/shadows, props) and also removing all assert statements.
Simple things (like asserts, which are essentially switch statements) need to run in tandem with other processes, when you’re trying to push 60/120 frames per second nearly every switch statement is going to “cost” something. That cost can be high very quickly. So, you don’t tend to leave things in which check conditions of various environment variables.
I'm always trying to look smart but I don't always succeed.
Anyway, I'm not part of the industry but I do hack around in emulation circles and I've dug pretty deep in some of these old games, my point was that you can definitely end up with dead or almost-dead debug code that doesn't harm performance significantly (because it's never or almost never called) and lingers in the final binary.
>when you’re trying to push 60/120 frames per second nearly every switch statement is going to “cost” something
I mean it obviously depends on the frequency of the test. If you have some check every second that reads like:
Then it's obviously going to have a negligible impact performance-wise as long as enable_stats is false. Then if this code is not explicitly disabled in the production build you might be able to use a memory hack to switch enable_stats to true and get some potentially interesting output out of it.
This is not (just) me trying to look smart, it's stuff that you can actually encounter in some games and firmwares in the wild.
Obviously you know what you’re talking about, but this comment comes off as unnecessarily rude to me. And not befitting of Hacker News.