3 ms·

Are modern compiler good enough / have good optimization on old hardware so that you don't need to write ASM? I remember that impressive opti on Mario64 and it

• jeffbee 4y ago
  Yes, the idea that wall-to-wall assembly is somehow superior is definitely flawed. High-level language compilers have many optimization passes and can transform code in ways that the user might not have imagined. Writing high-level code that causes the toolchain to produce the machine code the author wants is its own skill, though, and a habitual assembly programmer might not have that particular skill.
  • kingcharles 4y ago
    I agree with this. A smart coder is going to write it all in a high-level language and then profile it to see which tiny bits might be better off in assembler and then profile it again to test their theory. Modern compilers know a lot of tricks and can often find optimizations that would be hard to do manually in machine code.
  • drcode 4y ago
    Yes, but Randy also had to get uber-expert level understanding of the hardware to reach such performance... It would be hard to do that without writing copious assembly specific to the hardware somewhere along the way, regardless of compiler quality, so his "100% assembly" strategy served both goals.
• qbasic_forever 4y ago
  Yeah the GBA uses an older ARM processor and is really well supported by GCC and modern compiler toolchains. Heck you can even write Go and run it with TinyGo targeting the GBA: https://tinygo.org/docs/reference/microcontrollers/gameboy-advance/ https://tinygo.org/docs/reference/microcontrollers/gameboy-a... Plain old C/C++ is really well supported for hobbyist development though: https://github.com/gbadev-org/awesome-gbadev https://github.com/gbadev-org/awesome-gbadev
• pornel 4y ago
  Compilers are pretty good most of the time. If it was a platformer game, it'd have been fine in vanilla C. But this engine was desperate to squeeze absolute maximum performance (including hacky hacks to get extra registers), and you can't get that from C. GBA has some quirks, like the CPU with SRAM that isn't a cache, but an explicitly addressable small bit of memory. If you want functions "cached", you have to do it yourself. It's doable in C with some hacks, but it's an area where code size matters. Getting C code to be small and maximally fast is a https://en.wikipedia.org/wiki/Full-employment_theorem https://en.wikipedia.org/wiki/Full-employment_theorem
  • deleted 4y ago
    [deleted]
• djmips 4y ago
  If you want to be the best, you will have to write some of your code in ASM. Not all of it but the fastest paths will. And it really depends on how old your old hardware is. For example on the SNES you are not getting away with a compiler for more than the menus and other less taxing parts of the game if you want to be the best. Of course you can always use a compiler for every part of your game if it's something like Pong or Tetris.
• usrn 4y ago
  Apparently this guy came up with some pretty goofy optimizations like switching in and out of thumb mode to reuse the extra register file along with more "normal" stuff like self modifying code. I don't think there are any compilers that do that (and I think most people wouldn't want that.) You can totally write GBA games in just C though. In fact I learned C writing GBA homebrew in my teens.
• JohnBooty 4y ago
  I've been looking into the SGDK for the Genesis / MegaDrive and from what I've seen performance seems to be pretty competitive. There's been a resurgence of homebrew commercial releases for the console, and I believe the vast majority of them use SGDK. They seem to perform quite well. https://github.com/Stephane-D/sgdk https://github.com/Stephane-D/sgdk I'm not sure if this is a matter of GCC itself being smart enough in general to generate performant 68000 code. There may be a lot of custom work within SGDK itself to ensure that the generated code is performance competitive.