[cube13]

Assuming a 15 minute quarter(though most Madden games have shorter quarters, especially if they're multiplayer), to get 255 points in a quarter, a team would need to score a touchdown + 2 point conversion every 30 seconds. For a full game, that's every 2 minutes.

Any given play generally takes 10-20 seconds, and you're going to be running, bare minimum, 2 plays per 8 points(1 for touchdown, 1 for 2 point conversion). So that's about 25 seconds per score.

If the teams are remotely well matched(i.e. aren't a Breaking Madden team), they'll take at least 2-3 minutes per possession, since you're most likely going to have 4 downs, which have a play clock of 40 seconds(most teams use around 30/play), so the "average" shortest possession is something like 2 minutes.

The point of all this? The Breaking Madden games are really an outlier that you'd have to specifically code for.

[doktrin]

> The point of all this? The Breaking Madden games are really an outlier that you'd have to specifically code for.

Rather than coding special exemptions or rules, it seems that using 8 bit storage would have to be a deliberate choice on any modern platform.

[m_myers]

Sure, on any modern platform. But you don't change 25-year-old code unless there's a pressing reason.

[BlackDeath3]

Fair enough. I suppose I could see twenty-five year old code relying on data sizes in such a way that a seemingly trivial change could cause issues.

The real question is, what the hell does a Madden developer do for the rest of the time that dealing with data type changes is not worth it?

[GFK_of_xmaspast]

How about things like 'physics' and 'ai'.

[scott_karana]

I think BlackDeath's point is just...

Who wouldn't just use "int" for all of this logic? It's so simple that you could do it on autopilot. You'd have to specifically try to limit to 8-bits.

[BlackDeath3]

If 'char' in-place of 'int' is a legacy quirk, then I get it. I just find it odd that over the course of twenty-five years the required expense couldn't be made to update the data type. It just makes more sense.

[gfodor]

If you find it odd you haven't worked on any large projects that have enormous backlogs of bugs and features to build which need to be prioritized. Bugs that will never actually manifest in normal usage should be far down the list of things to fix, particularly if they are in 25 year old code that is battle hardened and in the critical path.

[BlackDeath3]

So all that they could manage, over the course of twenty-five years, is to grow (or keep unchanged) the size of their bug list?

OK...

[sokoloff]

You have to remember that consoles are very limited devices, especially if core code was developed 25 years ago. Even in the late 90s, developing for the original Sony PSX, we were carrying flags in high bits, removing file names from our file systems for prod builds (relying on known sectors and offsets instead), making sure that no unnecessary strings were in the final build, etc.

While it was annoying at times to be so worried about bits and cycles, it was also a very rewarding type of puzzle, figuring out how to squeeze just a little more performance out of the limited system we had to work with.