Overhauling Mario 64's code to reach 30 FPS and render 6x faster on N64 [video]
youtube.com
youtube.com
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.
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.
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?
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.
Anyway, a profitable software company will be looking at getting a big multiple of 10x the salary of their engineers
All hard. But there's also a lot of easy cases out there - even good engineers might code like monkeys if they're under time pressure and trying to grow the business.
I've done a lot of performance work, and while of course no one individual could achieve a 1% savings per month on the entirety of FAANG compute loads, there is lots of code out there that nobody thought would run at scale or be on the critical path of something important, but now it is and it has gotten expensive.
Though cost opt generally involves way more than optimizing code. It's normally about auditing things, creating budget tooling, right sizing, broader architecture redesigns, etc.
1M * 12 * 10% = 1.2M
500k * 2 * taxes >= 1M
Mario 64 was already pioneering basically everything in the 3D platformers, and maybe even 3D games as a whole.
Given it was a launching title, they had to stop somewhere and ship the thing. So, like any software with ever, they had to make tradeoffs.
And, well, here we are talking passionately about this game 26 years after. For me it’s an amazing proof that they made amazing tradeoffs.
Because, yes, we now have plenty of time to analyse the thing and find issues with the game. But, the 6yo me, the player me, they have nothing to criticize about this game.
For me it is still a perfect masterpiece given its era and technical context. I don’t think the game could have been really better than it is without breaking something and I’m pretty sure that the engineers at Nintendo considered the game as « finished » and liked the result themselves. It shows in the game. The better would have been the enemy of the good.
But in the meantime you are also right because Mario 64 DS was a really good extension. I miss this game, it really deserve to have its remake. But this version hugely benefited from the evolution of the Mario universe and the technical superiority of the DS so I’m not even sure it could have been done in the 90’s.
I hope we’ll today be able to play a newer version of this game. Be it official or not, I crave for SM64DS with the original controls.
Quake is a nice game as it is but it’s much simpler when the player is the camera.
[0]: https://quake.fandom.com/wiki/E1M8:_Ziggurat_Vertigo [1]: https://www.youtube.com/watch?v=a72k_XBi2ls
I'm not sure. A sophisticated camera is quite nice, but quake introduced a visibility determination solution that was used in dozens, perhaps hundreds of games afterwards. It also helped pioneer modding (it has a compiled scripting language), and later on had online deathmatch with predictive netcode (so it actually worked over the internet!) and was one of the first games to support hardware accelerated 3d graphics on pc.
It also has lightmaps, all surfaces are textured, and runs in software with no hardware acceleration, z-buffering, built-in perspective correct texture mapping, etc.
Obviously, that doesn't make it more fun to play, but Quake was an incredible technical achievement for the time, I don't think anybody would put Mario 64 in the same basket.
https://www.youtube.com/watch?v=NKlbE2eROC0
To summarize what he says: since the game was a launch title, it was likely being compiled with an early, less-stable compiler/SDKs, with known bugs that wouldn't be fixed until later (he even cited some official developer documentation that mentions this). So setting that flag could have caused known issues/instability at the time so they just left the optimization out.
And the other thing is the game is using a lot of libraries that were indeed compiled with the O2 flag, and the performance drop by removing those is far more significant than the tiny gain by adding it to the top-level of the makefile where the rumor suggested it should have been added.
Edit: Got farther into the video and he talks about this at 14:50 ( https://youtu.be/t_rzYnXEQlE?t=890 )
The focus is on all the cool improvements and it seems like there is a lot to like.
But at 6:40, the dev says their solution would not work on the stock 4MB ram included w the N64. It is kind of snuck in there.
It’s kind of an important detail, because like the GTA loading screen fix last year it’s way more interesting when stories like this have a What If?! slant to them.
Another commenter mentioned this below, but it’s buried.
If this Mario 64 mod requires the use of the Expansion Pak then it's definitely not typical of other N64 games and a point that, like the GP, I felt needed more emphasis rather than a passing remark that was very easy to miss.
I'm not taking anything away from the incredible work that developer has done though. It's impressive and really interesting to see. From a hacker perspective it makes total sense to use the Expansion Pak because most retro gamers who might be interested in this mod would likely already have one. But from an authenticity perspective, this is a little bit of a cheat.
[1] https://en.wikipedia.org/wiki/Nintendo_64_accessories#Expans...
These things are amazing for retro gaming enthusiasts because they let us play patches, mods, homebrew, and hard-to-find games on real hardware. Not that emulation isn't also wonderful.
Its hardware are amazing.
SSB also have a very specific Z management. Levels are drawn without Z buffer, from bottom to front, then the character section (1 meter width) is drawn with Z buffer enabled, and the rest of the from level is drawn without Z buffer, once again from bottom to front.
I never inspected FZX but I suspect its Z management is managed is a similar way.
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.
And I think they were right. I bought it just because of Mario64. Otherwise I'd have gone for Playstation.
They were technically possible but there wasn’t time to do them and still get the game out on schedule.
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.
The coders accidentally optimizing to reduce GPU compute load when there's GPU compute to spare and memory bandwith is limited, for example.
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.
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?
But hey, I guess I don't want to be judged on my mid-90s code either.
And it was a very long time before programmers (and compilers) realised just how bad of an idea loop unrolling was once we entered the era of superscalar processors with instruction caches and half-decent branch prediction.
Misprediction there means you computed one more vector or value, not a huge loss compared to a cache miss. Branch misprediction hurts a lot when it forces a cache miss mostly, whether it's for data or for instructions, or ties up a deep instruction pipeline completely with lousy abort, which most CPUs do not have. (See: Nehalem.)
My naive assumption is that they performed the majority of testing with debug code (as you would). And, since they had exactly one chance to get things right (being a physical cartridge), they couldn't afford to do all the testing again, with the new/different binaries generated with debug turned off.
Of course, it's a way worse problem that they compiled at -O0.
There was a Modern Vintage Gamer video going into this. Apparently it wasn't a mistake or misunderstanding, but a bug that existed in the original version of the compiler that caused issues when compiled with optimisation. Even then, the main library that did most of the heavy lifting was compiled with o2.
Super Mario 64 was a launch title, and they simply didn't have the time to work out the kinks in the compiler to get those few extra fps in Dire Dire Docks.
And the architectures have consolidated since then.
The most plausible explanation to me (and, IIRC, the one that Giles Goddard speculated was the case) is that they simply didn't want to take the chance that optimization could surface unknown bugs in the code, and they knew that the unoptimized version worked and played fine, so they played it safe and shipped the known-good unoptimized version. This is a perfectly understandable decision in terms of risk management, even if in retrospect it was too conservative. Less likely, but still very plausible, was that turning off optimization was just a mistake; mistakes happen when you're rushing a release for a deadline, and build deployment was not as orderly and automated back then as it is today.
Of course it "shouldn't make any difference" but who among us hasn't at some point been bitten by a "that couldn't possibly affect... ohhh. Ohhhhhhh." style bug?
When you're dealing not just with a single piece of software, but an entire hardware+software ecosystem, you don't risk jeopardizing the whole stack for an extra few FPS in some back corner.
Back in those days it had to ship as close to perfect as possible because you couldn’t just send out a patch layer.
I'm not just saying this in a theoretical sense either; I've seen much weirder bugs.
Even on today's high performance CPUs, which are far more sophisticated than the primitive 5-stage scalar in-order R4300 (not sure it even had any branch prediction actually).
I believe it didn't, with a short scaler pipeline (only 5 stages) the cost of waiting for a conditional branch to be calculated is relatively less, and MIPS of that era actually exposed the idea of a "delay slot" - rather than pausing the pipeline while calculating the jump, it still executed the next few instructions - so they were always executed no matter if the jump was actually taken or not. Filling this with NOPs makes it equivalently the same as a pipeline bubble, but I guess the intention was in some cases it could actually be used for something.
I think a few RISC architectures of that era did similar things, their entire goal was simplicity after all, the argument being that something like a branch predictor and the logic required to reverse speculatively executed instructions "should" instead be used to make the CPU smaller or higher performing in the best case (either as implementing better performing but larger logic, or higher frequency due to shorter critical paths).
I think this was dropped in later ISAs as it confused a lot of people, it wasn't well used by compilers (which is interesting as much of the MIPS ISA was explicitly designed around what would be easy for a compiler rather than handrolled asm), and improving process technology made transistors to handle the expensive superscaler speculative execution architectures relatively cheaper.
I just actually shouted when he said that if you simply compiled for release mode it ran 30% faster.
I think most of the cool stuff he did here is around restructuring the code to remove contention on the RAMBUS as it can do operations on different banks in parallel when servicing reads/writes from different components vs causing contention if they wish to read from the same bank. Also writing directly into the bank that will be used by the graphics unit from the CPU while disabling cache features of the RAMBUS, freeing up the cache for more code pages for the CPU to use.
Moving more of the code to execute on the "maxed out" GPU and actually cutting execution time because of the reduced memory bandwidth requirements was also pretty neat.
Mario 64 is a bit of a worst case as the game was being developed at the same time as the hardware and had to get out on day one no matter what. Between the Japanese and US releases I believe they even fixed some bugs.
Some of the things he did seem quite obvious, like cutting down the repeated calculations for every single coin on the screen. You have to think they would’ve thought of that if they have the time.
It would be interesting to see a series like this on a number of games over the console’s lifetime. Especially if it highlighted the tips and tricks the developers started to learn to get more out of the hardware over time.
Stuck forever in the issue tracker as "priority: low"
For example: It was almost impossible to profit on the “make a killer trailer, presell, then deliver junk and ‘patch it later’” model that’s unfortunately popular these days.
Now, years later, you comment explains a lot O_O
in response to mods, as well as speedruns (that may/may not use mods). sometimes the commentary from them is interesting.
Doesn't improve overall game performance though.
It helps that in this very particular case it was made much easier for him by basically enabling optimizations in gameplay code (it's fairly unlikely you'd get that one for free these days). But look at the difference in quality of launch titles for the PS4 vs what's being released today - that's 7-8 years worth of development. It's not unreasonable to expect that with another 2x that we could make similar gains. I've worked on a few AAA games and seen the codebases (and more importantly the issue trackers and profiling data). Today lots of these problems are "known" but it's a tradeoff - do you spend a person-week on fixing a frame drop in an awkward area or do you spend it on an incremental improvement across the board.
And this will almost certainly require a deep understanding of the instruction set, and dropping into inline ASM, periodically.
perf record -g myapp
perf report
Play with the output for a few weeks. "Why is this slow?" is a never-ending question leading down infinite corridors and weird specialist tools.
Cachegrind and VTune are also instructive to play with
It absolutely is. Look at its memory model, or look at any StackOverflow question or HackerNews discussion about edge-cases of undefined behaviour. Example: [0]. Alternatively, look at challenging interview questions that require a deep understanding of the C language.
C gives the appearance of being a simple language, but has many dark corners that many programmers are unaware of.
There are textbooks and classes on computer architecture. Funny enough, many of them use MIPS, which is the architecture used in the N64.
Optimizing for N64 also requires understanding how the RCP works, which is a separate topic.
https://www.amazon.com/Inner-Loops-Sourcebook-Software-Devel...
A simple example is if you have a 2D array, and you have the data from the individual rows consecutively in memory, but then you loop over the columns in your outer for-loop and over the rows in your inner for-loop. This means you access the first element from the first row, then the first element from the second row, then the first element from the third row, and so on. All these elements are far apart in memory, but every time you access one element, let's assume it's an uint32_t, the CPU fetches a whole cache lane of e.g. 64 bytes and puts it in the CPU cache in anticipation that you access data close to this in the near future. But you don't, so the CPU has to fetch another 64 bytes block for the first element of the second row, uses only 4 bytes from that, and so on. If your 2D array is large enough, by the time you finish the first iteration of the inner loop and start reading the second element of every row, the 64 byte cache lane that was fetched when you read the first element of the first row has already been evicted from the CPU cache again when you read the first element of row 2000, so the same 64 byte block has to be fetched from RAM again. This makes a huge performance difference, and is applicable to pretty much every programming language.
Nintendo did (supposedly) use an emulator for the N64 games in Nintendo Online (for the Switch); so it's possible that they don't have the source (or maybe it had enough machine-specific code that doing a source port would be more effort).
Of course, if they can re-sell it as a subscription service they probably would want to avoid releasing the source anyway…
The game was reverse engineered as 1-1 compilable to the original rom.
[1]:https://github.com/n64decomp/sm64
Fun fact: The people who did this moved on to Zelda 64 Ocarina of time and recently completed that project as well
There are ongoing projects by other people for Mario Kart 64, Goldeneye, Perfect-Dark, Banjo-Kazooie and others although I think the next target for completion may probably be either Majora's Mask or The Minish Cap.
If you're bored, his write up on the "Challenge 7 Bug" is great read: https://gitlab.com/ryandwyer/perfect-dark/-/blob/master/docs...
An updated version that was released later
In the 90s? It was 20 years old by then and mostly ruling the world already.
The first Nintendo handheld to use C was the GameBoy Advance which was also the first Nintendo console that had an ARM processor.
It’s true that C only really took off in the 90s while the 70s and 80s are more of a proto-C era which still built the entire Unix system.
It's also apparently unclear if the overhauled version will run on a real N64 or if it only runs in an emulator
The overhauled version will run on a real N64 as long as it has the RAM expansion pack.
So while I would not be surprised if he made some changes that assume more RAM is available in total beyond what was mentioned in the video, I believe most of the refinements covered could still be applied without.
Anyone have thoughts on how to make projects like this more sustainable?
And I will say his youtube skills are top notch. The video is very entertaining and informative. I just cannot imagine this person will have trouble making money in the future.
EDIT: Added a missing word
But the guy has a Patreon and this video already has a half a million views which should be at least $1000 in revenue, possibly 2-3x and it's still quite new.
A recent example is Among Us was released for 1+ year as almost a 'failure' with very little players. Received no major updates and just went by unnoticed until the right people pushed for a thing and now it's seeped into so many other things. e.g. Among us player count https://i.imgur.com/M1j0UOw.png
I guess you could argue a mario 64 custom levels mod competes directly with a new mario game. But halo and cod sell fine. Maybe I have a bias that thinks Nintendo is fearful that custom mods for old games will be more popular than anything new and official
Upkeep of the fiction that intellectual property is real property has societal benefits for a limited time insofar as works of art - and the original idea of copyright was reasonably limited. Over 100 years is inhumane.
You can debate whether capitalism is (or should have been) the only method for getting things done, but the use of private property as a viable incentive for driving innovation within that system is not really debatable.
You do not in any way need to enslave people in order to develop land; only to develop land AND enrich a bourgeois class of people.
The main reason why piracy is illegal is, that studios/producers/writers lose money, because people pirate instead of buy. If I cannot buy eg. Super Mario 64 from nintendo in my country, and if I copy the game (and emulate it or whatever), I never actually caused any monetary loss for Nintendo by doing that.
But my opinion stands for things that are not available this way.
Apart from the business/worker side, the ability for an IP holder to release continuing sequels to works (like manga, movie installments, etc) and the legal force against fan works essentially gives more power essentially to the original creator to shape what is "canon" in their work. Perhaps fans could still decide the original creator's later installments are canon, but the extra legal force sort of makes this defacto, while a world of limited copyright the power of the original creator is less so. Thus, the way fans consume media and experience it will change completely as well.
It would just be a completely different world, one where a lot of these ills are addressed (like the ones mentioned by GP), and things will be very different. It's hard to say from my vantage point whether the differences would also be "ills" or not (and that might be my bias), but it would certainly be a different world with different rules and different expectations from fans and audiences.
At any rate, fan-fiction is nothing new and while it might be a bit iffy to do commercially I see nobody even trying something remotely similar without at least the blessing of the original author.
So really I think society has decided who is allowed to continue a story and as far as I can tell it has little to do with copyright and everything to do with public perception.
If they released remakes at 20 year mark, anyone trying to take advantage of the now expired copyrights would have to compete with the new "official" versions of the IP.
The other side of that coin is millions of workers now available for new and original projects that have to take real chances and break new ground to get off the ground.
> Thus, the way fans consume media and experience it will change completely as well.
Should we prevent creators from selling their copyrights as well, or do we simply make the "canonical" rights non transferable in that case?
> but it would certainly be a different world with different rules and different expectations from fans and audiences.
Vaudeville and burlesque operated under those rules. Audiences didn't seem to mind. "Who's on first" was not an original act.
nintendo isn’t afraid of mods, they would rather just sell you mario maker and create an experience.
quake and cod are mostly online, and there’s no community anymore. there’s over 30 cod games, no scarcity on the experience since they’re so similar. the one mostly offline game series you mentioned, halo, is closed source and still sold today. it is far less likely quake 3 is going to be bought and played today vs mario64. those games are not active revenue streams and don’t have a good path to become one again
The whole 70 years after death nonsense is just an ugly hack to equalize the fact that copyright will last fewer years if you are older. It doesn't even solve the original problem! If you are younger you still get more copyright years.
This guys has clearly done a lot of work, building on top of the existing reverse disassembly of the Mario 64 codebase and has a great understanding of the heavily dissected 25 year old hardware. And that's where my paise stops.
The level of snark here is outstanding. Maybe its a cultural thing, maybe he's trying to hype up his Patreon, but he comes across to me as a complete egotistical a-hole. Does he really think the Nintendo programmers were 'smelling the grass' rather working 24/7 to get a ground-breaking game shipped. He does his best to call the team who made several of the most influential and important video games of all time incompetent.
Breaking down his snark:
- The RSP/RDP co-processor had microcode that the game programmers interacted with (you generated a rendering command list on the CPU and called a library function to start the RSP processing that scene). So any criticisms of things the Mario team could have moved to the RSP (ie billboard calculations) are short-comings of the microcode made available by the NCL driver/hardware team - post launch there were regular revisions to the microcode and optimizations made available.
- A lot of the matrix operations were provided in library form to game teams and you were encouraged (forced) to use them rather than rolling your own - there was probably a concern that an overly aggressive optimization would send bad data to the RSP/RDP and cause issues on current or future hardware revisions. The divide by zero checks were likely there for similar reasons - the RSP microcode could run in a mode that skipped near-plain clipping of triangles, which was faster but would blow up spectacularly (huge jaggie triangles all over the screen) if you had triangles that did indeed clip into the near plain.
- I have not seen the Mario 64 source but I imagine some of the lowest level code was written in mips assembly but has been decompiled into C. I may be wrong here, but if that is the case there were likely branch-delay-slot optimizations and cycle counted operations that have been trampled by the reverse engineering. I may be off-base here so would love to know if that is the case?
- Yes the gameplay code has unused variables, duplicated code, etc. But this was a brand new genre of game, there would have been a lot of experimentation, tuning, things would have been in flux until shipping and there certainly was no time to refactor and run the risk of breaking something.
- I suspect the debug flags in gameplay code were to avoid compiler bugs. The mips compiler would sometimes emit some back-back floating point operations that caused the N64 mips cpu to hang (but was fine for all other mips processors). That may have affected the gameplay code with optimizations enabled. Later there was a command-line tool you had to run on your game elf that would look for this bad combination of instructions (and you would then change the offending code until the compiler did not emit the 'bad' instruction combination). Gcc was not allowed by Nintendo until much later, and had its own issues.
- Older floating point units were less predicable with numerical accuracy, rounding errors etc. If early testing showed differences in game control/feel between the debug and optimized builds then I can see why the team would be more comfortable shipping with debug code rather than risking a bug that was not picked up until after you manufactured a million or two cartridges.
- The memory bank conflicts were well documented and games worked around/with that knowledge. Mario 64 was likely well under development before that information was known. As others have pointed out, using the memory expansion module is cheating - that gives you a whole bunch of un-conflicted memory banks to use. 2x the memory also gives a lot of optimization oppertunities.
- I don't see a 6x speedup. I see ~10% gains in most systems and a best case frame time improvement from 29 fps to 41 fps. Which is pointless. An NTSC tv runs at 60Hz, you either hit 60fps or 30fps, anything in-between results in horrible tearing of the screen or your frames bounce between 60 and 30 and movement feels horrific. The game was optimized to hit targets and to ship.
- His split screen optimization is crap! Reducing load on the RDP (rasterizer) by killing rendering area (big black bars on the screen) is lazier than most everything he snarked on. The slightly better approach would be to ab-use the TV output timing registers so that the screen buffer can be less than 320x240 but still fill the screen. You trade black bars for smeary sludge but on the target NTSC TV that was generally the way to go if you didn't want your game rejected by Nintendo QA. Or actually re-write the renderer and reduce the amount of pixel fill.
- And a minor nit pick, the sound processing was not done on the CPU (as he claimed). The cpu built audio command lists that the RCP then used to generate the output waveforms.
I just rewatched this video and didn't get any of that, like at all. A little banter to be entertaining but I think you're reading into that wrong.
>- I don't see a 6x speedup. I see ~10% gains in most systems and a best case frame time improvement from 29 fps to 41 fps. Which is pointless. An NTSC tv runs at 60Hz, you either hit 60fps or 30fps, anything in-between results in horrible tearing of the screen or your frames bounce between 60 and 30 and movement feels horrific. The game was optimized to hit targets and to ship.
The idea is to get more overhead for his mods.
Nope. You can target 30 FPS and use the spare cycles to do much more.
I thought his snark wasn't too off the charts in this video. I'd bet it's more a cultural thing. If you were working on the N64, you're probably like two decades above Kaze's target audience for his youtube videos haha. Like, he said that you can either be a weirdo who spends all day optimizing nearly 30 year old source code, or someone who "touches grass"[1]. He, of course, was referencing his own lack of life, not Nintendo's programmers. But, you'd have to pretty familiar with current online memes and insults to get his joke.
> I have not seen the Mario 64 source but I imagine some of the lowest level code was written in mips assembly but has been decompiled into C.
No, we only decompiled C code back into C code. The decompilation matches 1 to 1 with the released ROM images.[2] iirc, the only, non-libultra ASM code was the decompressor[3]. The C code was pretty obvious due to "wonders" of IDO -O0 optimization. We were forced to get surprisingly close to what Nintendo wrote. We were stuck with an `f32 [3]` 3-vec instead of a `struct`...
> I suspect the debug flags in gameplay code were to avoid compiler bugs.
As far as we could tell, this wasn't an issue. IDO 5.3 had no issues that we could find when compiling at -O2, but then again it was decompiled code. I personally subscribe to the '-O2 -g' IDO meme, but Giles Goddard thought it was out of fear of the unknown. So, I'd trust him.
We had the `mulmul` patch for IDO. I don't know the chronology for the release of that patch to devs, though. We also haven't been able to find any N64s that have the mulmul issue.
> An NTSC tv runs at 60Hz, you either hit 60fps or 30fps, anything in-between results in horrible tearing of the screen or your frames bounce between 60 and 30 and movement feels horrific.
I wonder what Kaze is doing. I know that there was work on a variable framerate mod/revamp for SM64. I'd guess it'd be outputting at the N64's 60 fps mode with duplicated frames, but you'd have much better luck asking one of the modders/coders who were working on that a couple years ago.
----------
[1] which is Twitter's insult du jour: https://knowyourmeme.com/memes/touch-grass
[2] https://github.com/n64decomp/sm64
[3] https://github.com/n64decomp/sm64/blob/master/asm/decompress...
The back to back multiplies definitely could cause hangs on real hardware (actually I'll back up and say it certainly could hang a dev-board and I think the hardware was the same as production). I don't know if there were particular registers or data that caused the hang but I remember QA picked up hangs with builds that had them in there.
Adding extra frame buffers lets you output at 60Hz without tearing but you'll bounce between duplicated frames and single frames. You technically get 40fps (or whatever) but smooth camera movements feel 'off'. That extra frame eats pretty badly into the remaining space in the 2Mb base memory (at 640x480 you could have just one frame buffer and render interlaced, so long as your frame rate always hit 60Hz).
float myValue = x_float + y_float * y_float * 3.0;
Looks ok, except the constant is a double. Performance killer.
You'd get pretty good at seeing the missing f (and we eventually wrote some simple tooling to find functions using doubles) but I'm sure a number of games shipped with accidental double calculations.
The wonders of C constants. Sometimes IDO can do the conversion at compile time, and sometimes it can't. But, the compiler will treat things "0.0f" and a compile-time "(f32)0.0" as different constants for code-gen purposes.
We have a kinda outdated document of weird IDO behavior which is worth a read if you want to trigger some PTSD: https://hackmd.io/vPmcgdaFSlq4R2mfkq4bJg#Compiler-behavior
Also, since SGI/MIPS/IDO was from Stanford (I think...?), there is actually a surprising amount of published papers on IDO's compilation model. Which comes in handy if you are trying for the ultimate joke of decompiling the written-in-pascal compiler into C: https://github.com/n64decomp/ido
Thanks for providing more context for what's going on - all of this stuff is neato.
Emphasis mine.
He regularly trashes the quality of other people's code in his twitter https://twitter.com/KazeEmanuar/status/1343569532976304131 despite building his following off the years of work of those same people.
I didn't interpret it as snark but as attempts to be funny - which for me were just irritating. I can't imagine how much time it took to put in all those "funny" images but for me it was wasted time. I could have done with 20-30 fewer "vroom vroom"'s too.
- Listen to the audio only, occasionally take a peek, don't tell me you are being productive 16 hours a day
- VideoGames are visual so it's a natural to present them with video, hardly a blame for the authors
90% of the video is just stock footage in the background while he talks about the technical details. A better approach would be a written article supported by a video demonstrating the speed up.
I really hate the type of guy who is lurking around enthusiast forums looking for topics to "cover" on his next YouTube stream. Yes, these guys exist and yes they do that.
It's not really an improvement in quality, but it is a degradation in wasted time and also in cooperation, since communication becomes mostly one-sided again.
Actually that sounds like a decent idea. You lose nothing by not watching the video and instead focusing on the forums and others who would not otherwise spend time on the forums can be made aware of exciting developments.