9 ms·

This is a good lesson about the benefit of time when it comes to software development. Mario 64 could have been a much much better game on the same hardware, b

by Lerc 5y ago

This is a good lesson about the benefit of time when it comes to software development. Mario 64 could have been a much much better game on the same hardware, but the time cost would have resulted in a release late enough that the entire game might have been considered irrelevant. Game consoles have had the benefit of the platform freezing for a few years allowing improvements to accumulate and later titles utilizing knowledge gained from the earlier titles. Much of the software we use every day could benefit from this level of scrutiny but the pressure to deliver on time means we won't get to see such benefits unless it becomes a crazy persons labour of love.

ChrisRR 5y ago
It's not completely about time, and as much the benefit of 25 years of experience, not writing for brand new prototype hardware, not writing a brand new 3D engine when 2D had been the norm for decades.
- AstralStorm 5y ago
  That's the part about batch rendering. Everything else there is architecture specific and typically not a problem on modern hardware anymore, unless you really force it to its limits. The coders accidentally optimizing to reduce GPU compute load when there's GPU compute to spare and memory bandwith is limited, for example.
noobermin 5y ago
This is why honestly developers need to stop seeing issues as technical problems and more as being social ones (which they often are).
- nomel 5y ago
  This is why we have product software engineers, and UI designers. The UI is a social problem and the purpose/goal of the product usually is. The guts that make that UI and achieve that purpose are very rarely social.
finnh 5y ago
> ... unless it becomes a crazy persons labour of love Or there are valid business reasons to keep chipping away, in particular on performance-per-dollar problems at scale. If you're spending $1M/month on hardware to run something, each 10% win is worth enough to employ a couple senior engineers.
- deleted 5y ago
  [deleted]
- abriosi 5y ago
  Many senior engineers who operate systems which spend 1M/month make 500k yearly 1M * 12 * 10% = 1.2M 500k * 12 * 2 * taxes >= 1.2M How many 10% wins do they have to achieve in what timeframe to have a good ROI on micro-optimization, considering that these seniors could be producing stuff that allows for multiple times their salary in revenue?
  - charleslmunger 5y ago
    Improvements are one-time investments of engineering time, but ongoing savings in infra costs. Consider also that these savings also permit scaling to more customers or more work. Suppose you have two engineers that total to $1M of personnel cost. If they deliver a cost savings of 1% per month (compounding) the savings-per-month will have surpassed their pay per month; you will see your infra costs at 85% of what they were after 16 months, and on month 17 you will have made a net profit on those engineers, where the savings they got you has totalled more than what you've paid them. If your business is growing, you could project your infra costs to grow beyond $1M per month, and the numbers become even more favorable.
    - abriosi 5y ago
      Unless a company is running an engineering team composed of monkeys, it will be hard to achieve 1% optimization per month, even without compounding. There are a lot of optimizations which look good on paper but in practice bring other unforeseen cons Anyway, a profitable software company will be looking at getting a big multiple of 10x the salary of their engineers
bscphil 5y ago
I watched the video through only once, but unless I'm mistaken (the video is a little confusing on this point), the claim is that the original game did run consistently at 30fps (the design framerate of the console), and the point of these hacks is to improve framerate for mods and devices that can play the game at higher rates. Unless I misunderstood something, it sounds like the original game was exactly as good as it needed to be, as released. And that's before you get to the fact that the mods require the RAM expansion pack.
- kibwen 5y ago
  The original Mario 64 would suffer lower framerates in certain areas (e.g. Dire Dire Docks). We can also imagine that if the artists had had more headroom to work with, then they would have spent it on making levels larger and more detailed.
  - jbay808 5y ago
    Wasn't that because it had compiler optimizations disabled, due to a bug in the compiler that was subsequently fixed after the initial cartridge release?
    - jsiaajdsdaa 5y ago
      No, it wasn't compiler flags. Put simply, there are too many objects on the screen in that particilar part of the level, and the engine has wasteful code that computes a certain piece of physics three times for every object on the screen iirc, among other things
    - ed25519FUUU 5y ago
      That’s particularly why performance in dire dire docks was bad, but Kaze goes WAY beyond just enabling -O2 in the compiler.
    - mcronce 5y ago
      It wasn't the only reason, but -O0 was a contributing factor. -O2 alone improves things, but doesn't bring the frame rate in DDD up to 30
egypturnash 5y ago
There are externalities to consider that make a later release less likely, too - it was a launch title, to match the pack-in of SMB in the NES and Super Mario World as one of two games available when the SNES launched. Wikipedia’s entry on SM64 tells me that the N64’s launch was delayed because Miyamoto wanted more time to polish the game. I don’t think a later release would have been possible. This was the flagship title, the system seller. Come play Mario. In 3d.
- carlmr 5y ago
  >This was the flagship title, the system seller. Come play Mario. In 3d. And I think they were right. I bought it just because of Mario64. Otherwise I'd have gone for Playstation.
  - larrik 5y ago
    I decided to buy it for Shadows of the Empire, but Mario64 was actually great (while SotE was not).
    - GauntletWizard 5y ago
      You take that back. SotE was rough, but had some excellently varied gameplay and interesting, fun levels with cool enemies. Also some losers in there, but every great game has a bad level. :)
gernb 5y ago
Much of the software we use every day does benefit from this level of scrutiny. There was a popular post today about changing C++ std::sort for more perf. There's JavaScript engines running 100x faster for a given CPU than they were in the 90s? gcc and llvm optimize more than ever?
- bombcar 5y ago
  But there’s tons of untapped potential that is rarely realized - compare some of the greatest Doom PWADs made today (on the vanilla Doom engine, not on limit removed engines) vs the original game. They were technically possible but there wasn’t time to do them and still get the game out on schedule.
  - Zardoz84 5y ago
    Or simply nobody thought that could be done things like that (for example, the classic "invisible" sector bridge), before a PWAD did. Plus the game was released targeting to work under a 80386, so the stock maps was limited to ran at an acceptable performance on these kind of CPUs.
    - anthk 5y ago
      Check FastDoom too :).
    - bombcar 5y ago
      Yeah, “limits” are sometimes in hardware and sometimes conceptual. Look at the demoscene - most of what they do is designed to run on period hardware, but far surpasses anything anyone did at the time (it’s the whole point).
giantrobot 5y ago
Super Mario 64 was a launch title for the N64. One of two launch titles in North America. There really was no way to delay the game without delaying the console. With that in mind, SM64 is a pretty impressive game for a console launch title. It makes good use of the N64 controller, performs well, and is pretty fun. It's not the best game of all time but it's definitely not a bad game.
agumonkey 5y ago
I don't know if there's a term for this. The limit of reach any task has. Everything has a deadline and we all live with partial results in a way. It's like civilization internal resistance (with a cycle of survival on top)
Jesus_piece 5y ago
This is completely true for non -cloud, on-prem hosted code/programs, but this notion disappears when programs/software is hosted in the cloud, and updates can continuously occur
deleted 5y ago
[deleted]
eternityforest 5y ago
This is a good reason to stop changing the core frameworks every 5 minutes, and stop building one off infrastructure to solve individual problems, unless there's a really good reason. When something is stable and widely used, you can do optimization like this, and justify it for real production systems, and everything built on it benefits.
- robertlagrant 5y ago
  You clearly need to spend more time in a JavaScript team. Knock that nonsense right out of you :-D
  - eternityforest 5y ago
    JS: The mediocre language made wonderful by it's great ecosystem.... with a dev community constantly trying to use random crap instead... Seriously guys we have great utility libraries and bundle optimizers... why are we still piecing together micro libraries like this is an old UNIX mainframe?

by Lerc 5y ago

ChrisRR 5y ago

It's not completely about time, and as much the benefit of 25 years of experience, not writing for brand new prototype hardware, not writing a brand new 3D engine when 2D had been the norm for decades.

AstralStorm 5y ago
That's the part about batch rendering. Everything else there is architecture specific and typically not a problem on modern hardware anymore, unless you really force it to its limits. The coders accidentally optimizing to reduce GPU compute load when there's GPU compute to spare and memory bandwith is limited, for example.

noobermin 5y ago

This is why honestly developers need to stop seeing issues as technical problems and more as being social ones (which they often are).

nomel 5y ago
This is why we have product software engineers, and UI designers. The UI is a social problem and the purpose/goal of the product usually is. The guts that make that UI and achieve that purpose are very rarely social.

finnh 5y ago

> ... unless it becomes a crazy persons labour of love Or there are valid business reasons to keep chipping away, in particular on performance-per-dollar problems at scale. If you're spending $1M/month on hardware to run something, each 10% win is worth enough to employ a couple senior engineers.

deleted 5y ago
[deleted]
abriosi 5y ago
Many senior engineers who operate systems which spend 1M/month make 500k yearly 1M * 12 * 10% = 1.2M 500k * 12 * 2 * taxes >= 1.2M How many 10% wins do they have to achieve in what timeframe to have a good ROI on micro-optimization, considering that these seniors could be producing stuff that allows for multiple times their salary in revenue?
- charleslmunger 5y ago
  Improvements are one-time investments of engineering time, but ongoing savings in infra costs. Consider also that these savings also permit scaling to more customers or more work. Suppose you have two engineers that total to $1M of personnel cost. If they deliver a cost savings of 1% per month (compounding) the savings-per-month will have surpassed their pay per month; you will see your infra costs at 85% of what they were after 16 months, and on month 17 you will have made a net profit on those engineers, where the savings they got you has totalled more than what you've paid them. If your business is growing, you could project your infra costs to grow beyond $1M per month, and the numbers become even more favorable.
  - abriosi 5y ago
    Unless a company is running an engineering team composed of monkeys, it will be hard to achieve 1% optimization per month, even without compounding. There are a lot of optimizations which look good on paper but in practice bring other unforeseen cons Anyway, a profitable software company will be looking at getting a big multiple of 10x the salary of their engineers

bscphil 5y ago

I watched the video through only once, but unless I'm mistaken (the video is a little confusing on this point), the claim is that the original game did run consistently at 30fps (the design framerate of the console), and the point of these hacks is to improve framerate for mods and devices that can play the game at higher rates. Unless I misunderstood something, it sounds like the original game was exactly as good as it needed to be, as released. And that's before you get to the fact that the mods require the RAM expansion pack.

kibwen 5y ago
The original Mario 64 would suffer lower framerates in certain areas (e.g. Dire Dire Docks). We can also imagine that if the artists had had more headroom to work with, then they would have spent it on making levels larger and more detailed.
- jbay808 5y ago
  Wasn't that because it had compiler optimizations disabled, due to a bug in the compiler that was subsequently fixed after the initial cartridge release?
  - jsiaajdsdaa 5y ago
    No, it wasn't compiler flags. Put simply, there are too many objects on the screen in that particilar part of the level, and the engine has wasteful code that computes a certain piece of physics three times for every object on the screen iirc, among other things
  - ed25519FUUU 5y ago
    That’s particularly why performance in dire dire docks was bad, but Kaze goes WAY beyond just enabling -O2 in the compiler.
  - mcronce 5y ago
    It wasn't the only reason, but -O0 was a contributing factor. -O2 alone improves things, but doesn't bring the frame rate in DDD up to 30

egypturnash 5y ago

There are externalities to consider that make a later release less likely, too - it was a launch title, to match the pack-in of SMB in the NES and Super Mario World as one of two games available when the SNES launched. Wikipedia’s entry on SM64 tells me that the N64’s launch was delayed because Miyamoto wanted more time to polish the game. I don’t think a later release would have been possible. This was the flagship title, the system seller. Come play Mario. In 3d.

carlmr 5y ago
>This was the flagship title, the system seller. Come play Mario. In 3d. And I think they were right. I bought it just because of Mario64. Otherwise I'd have gone for Playstation.
- larrik 5y ago
  I decided to buy it for Shadows of the Empire, but Mario64 was actually great (while SotE was not).
  - GauntletWizard 5y ago
    You take that back. SotE was rough, but had some excellently varied gameplay and interesting, fun levels with cool enemies. Also some losers in there, but every great game has a bad level. :)

gernb 5y ago

Much of the software we use every day does benefit from this level of scrutiny. There was a popular post today about changing C++ std::sort for more perf. There's JavaScript engines running 100x faster for a given CPU than they were in the 90s? gcc and llvm optimize more than ever?

bombcar 5y ago
But there’s tons of untapped potential that is rarely realized - compare some of the greatest Doom PWADs made today (on the vanilla Doom engine, not on limit removed engines) vs the original game. They were technically possible but there wasn’t time to do them and still get the game out on schedule.
- Zardoz84 5y ago
  Or simply nobody thought that could be done things like that (for example, the classic "invisible" sector bridge), before a PWAD did. Plus the game was released targeting to work under a 80386, so the stock maps was limited to ran at an acceptable performance on these kind of CPUs.
  - anthk 5y ago
    Check FastDoom too :).
  - bombcar 5y ago
    Yeah, “limits” are sometimes in hardware and sometimes conceptual. Look at the demoscene - most of what they do is designed to run on period hardware, but far surpasses anything anyone did at the time (it’s the whole point).

giantrobot 5y ago

Super Mario 64 was a launch title for the N64. One of two launch titles in North America. There really was no way to delay the game without delaying the console. With that in mind, SM64 is a pretty impressive game for a console launch title. It makes good use of the N64 controller, performs well, and is pretty fun. It's not the best game of all time but it's definitely not a bad game.

agumonkey 5y ago

I don't know if there's a term for this. The limit of reach any task has. Everything has a deadline and we all live with partial results in a way. It's like civilization internal resistance (with a cycle of survival on top)

Jesus_piece 5y ago

This is completely true for non -cloud, on-prem hosted code/programs, but this notion disappears when programs/software is hosted in the cloud, and updates can continuously occur

deleted 5y ago

[deleted]

eternityforest 5y ago

This is a good reason to stop changing the core frameworks every 5 minutes, and stop building one off infrastructure to solve individual problems, unless there's a really good reason. When something is stable and widely used, you can do optimization like this, and justify it for real production systems, and everything built on it benefits.

robertlagrant 5y ago
You clearly need to spend more time in a JavaScript team. Knock that nonsense right out of you :-D
- eternityforest 5y ago
  JS: The mediocre language made wonderful by it's great ecosystem.... with a dev community constantly trying to use random crap instead... Seriously guys we have great utility libraries and bundle optimizers... why are we still piecing together micro libraries like this is an old UNIX mainframe?