Hacker News Reader

Comment by teej | Hacker News Reader

This limit is anything but arbitrary. There's a few things to keep in mind:

- 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.

View on HN

I worked on an Xbox title many years ago, when I was still a bit inexperienced, and one of the requirements was that it had to run the attract mode for a week without fucking up. The other guy working on it was even worse than me, so no prizes for guessing who ended up sorting that out. And what a huge pain it was!

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...

That sounds like a pretty painstaking process, I would've been a bit deflated after finding the requirement was more than halved after you were done!. BTW what is meant by "attract mode" ?

Attract mode is where a game cycles between front end, intro video, rolling gameplay demo, and so on: https://en.wikipedia.org/wiki/Glossary_of_video_game_terms#A

(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.)

Ahhhhh makes sense, thanks!

Holdover from the arcade days where games were competing to 'attract' players.

Oh yeah. Hard limit pools are the bread and butter of console engines. You want to preallocate everything because fragmentation will murder you.

Source: Ex-gamdev who's shipped things on x360, ps3 and psp.

Interesting. Yes, fragmentation is a big problem on memory constrained systems. So the memory pool approach is quite a nice solution, but did you use caching allocators where memory could be allocated and marked as purgeable, so it could be reclaimed when memory gets low? Just curious. By the way do you know any good resources that cover memory management on consoles?

The problem with making pools purgeable is you've now just moved your memory fragmentation problems up a level in the stack to the allocator. Now when you need to bring in a ~30mb level asset you might have one of those cells right in the middle again.

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).

Ah, that's very interesting - thanks for the explanation. I see what you mean about the fragmentation. When the cached blocks drop out they may not be necessarily be usefully re-used, so you end up with memory looking like Swiss cheese again. Thanks also for the reference - I will go check that out now - this whole question of memory management on consoles sounds like it could be a fascinating area for me to read up on! Cheers!

> 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.

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.

You misinterpreted, yes. Custom setlists and downloaded songs are a big part of the intended use case of Guitar Hero.

Custom setlists were most definitely not a big part of the intended use case, as they were hacked in after release by modders.

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.

Reply on news.ycombinator.com