As much as I respect Shiru's work (all done in C, I know) the "time saving" example looks like total nonsense to me. No one in their right mind would "hand-write" assembly code like that.
To begin with, trying to index a 32x32 map is a fundamentally wrong approach. To start off with, you wouldn't / shouldn't be storing a map without metatiling in the first place, but use metatiles to get things addressable on a byte size. The saying goes that premature optimisation is the root of all evil... but on the 6502, you need to optimise from the start to avoid 16-bit maths in the first place, and premature implementation is the bigger evil. Most of the time I do 6502 coding, I will often spend 90% of the time working on toolsets just to get data in the right format. It's a necessary evil in nesdev, and something I personally think you need to enjoy the process of to really enjoy the homebrew.
But *if* you are determined to use 32x32 uncompressed maps as your format, then you'd at least use a lookup table to just fetch two bytes from in ROM, into a zp pointer and omit the addition of my altogether. Sure, lookup tables wastes a lot of space. But if you're already wasting space by using a uncompressed map format, then there's little arguments to be made for trying to conserve size anyway.
But even ignoring that, why on earth would you make the final lookup, with a y register of zero and an additional addition of the "mx" variable? Just put the x variable into the Y register and let the 8-bit addressing feature of the CPU solve the problem for you.
It just looks to me like the most contrived example ever, designed to try to argue a point through a straw man argument...
I do however agree that assembly isn't best tool in all stages of development. This especially goes for gameplay logic which you need to tweak and refine a lot of times, such as player control and enemy AI. It's very important to get these things right, and a quicker test cycle helps immensely. But I'm not convinced that C is the best solution here. You might be far better off working on this tweaking in a dedicated modern game making tool / engine, and then bring that over to the NES once you're happy with how it works. There you have scripts which often reload and change object behavior instanteneously, giving you a time-saver people back in the 80s / 90s would be dying to have.
One thing that comes to my mind, is that too few of us - myself included - realise we've already got a pretty decent scripting language to do initial experimental nesdev in: Lua. It's generally used for adding hacks to exiting commercial games, but makes for a pretty good tool for prototyping / debugging your actual game as well.
Sure, Lua might have some awkward features, but is a decent scripting language that a lot of successful PC games have shipped with. If one is losing too much time trying to prototype stuff in asm, then I'd argue saving that time using the Lua scripting features in emulators such as FCEU or Mesen will get you there sooner than having to recompile C code and trying to debug all the low-level issues you still don't get rid of by switching from asm to C.
Lua scripts reload instantly in emulators, does bounds checking, is interpreted - so avoids the whole compilation step. So it allows you to prototype your code in stages: using simple floating point numbers to start with - not even needing to care about storage. Then add quantization to fixed-point numbers and store things to your actual NES RAM object data... and only once you're satisfied with the game dynamics start converting all those operations to their final assembly form. The best form of writing is re-writing...
It would also be cool to see a hardware implementation for Lua scripts. I think possibly an Everdrive N8 Pro might just be powerful enough to run a softcore capable of a Lua interpreter. But frame buffer access obviously wouldn't work - at least not without a lot more complicated hardware setup. And you'd suddenly have race conditions between the NES code and the Lua code that an emulator won't have. Still, it:)
Finally, I would also say that Movax's high-level macros for ca65 is my own personal favorite for when logic gets a bit too complicated to maintain in standard-assembly code. They've been around for long but are still great and not known to everyone:
http://mynesdev.blogspot.com/2012/10/ca ... again.html
I find that they give you just that one-step-up-from-pure-asm to be more productive when it comes to things like gameplay logic, while keeping you more connected and aware of what the final code output will be. The way they are an add-on to bring some structure to your asm code really appeals to me. But like I said, trying some 6502-dedicated language such as Millfork has long been on my todo-list...