This has been posted a few times but a cool resource nonetheless. I played around with NES/assembly last year and just about got a scrolling engine fully working. Couldn't get the last 2 tiles to render before the NMI interrupt ended.
You don't have a lot of time in the VBlank to decide what tiles you're moving to VRAM.
I haven't developed an NES game before but I would assume you'd need to decode your game's map data into a buffer out of VBlank then stream it in after updating OAM. Unless you have the luxury of being able to just read it directly from ROM and write it to VRAM without a lot of intermediate processing.
I think most NES games had various schemes to represent the map data (compression schemes basically) with Metroid/Kid Icarus being a particularly elaborate one (a game editor "MetEdit" out there explains it). Not sure how they split the unpacking/VRAM writing workload.
I came across this a while back and, wow, the rabbit hole I’ve fallen down since reading it.
I don’t have a formal CS/CE background and only work with computers on a high level. I know how computers work, but wanted to _really_ understand. The author’s approach is very accommodating of beginners (like myself) and it inspired me to learn more. :)
I wrote an NES game for my senior project for school. I used this site a little. What I’ve found is that after you get the initial setup complete and the basic concepts of sprites and blanking, you’re kind of on your own to figure out how to make your game engine.
Interestingly, you can see the same engines used across titles from the same company. Or at least close variations on.
My favorite example of that kind of code reuse can be seen in the 3/4 perspective views in Sunsoft's Fester's Quest (most of the game) and Blaster Master (the extra-vehicular room explorations)
"Super Mario Bros. is quite likely the most iconic NES game of all time, and it, like Donkey Kong, was produced by a team of five people, two of whom were programmers."
I remember game credit scroll screens, at the end of video games, back in the 8 and 16 bit era. I remember thinking"who were these gods, and how did they do this??"
Now, I know how they did it, but I'm no less in awe of them, because they did these things with development tools that were barely anything. Remarkable generation of developers, laying creative and technical ground work for an entire planet of gamers.
An interesting thing about doom is that they actually made really nice level editing tools when they built the game there's some throw away lines in a few of the documentaries to the effect that they marveled at the levels people made given how shit the tools the community had invented (by reverse engineering the WAD format)
This is one of the few well written and enjoyable tutorials on the topic. There is a lot of older texts out there with inaccurate and inconsistent language, ascii-diagrams etc… but this a joy to read and follow
Oh what a coincidence, I just watched this guys talk yesterday and it was very interesting! Here it is if anyone is interested: https://youtu.be/TPbroUDHG0s
YouTube recommended this to me and I actually watched it... When he got to the end and talked about his site I realized it was on the front page! I was confused because I'm not into game programming, but I watched it anyways. I was surprised that it was more about system design, which I am actually into!
I'm just a little weirded out that YouTube knows me a little better than I know myself.
Anyone know what resources developers actually used for programming consoles back in the days of the NES/SNES (and even the PSX)?
Nowadays we have a lot of resources and open source games, but it's still pretty hard to make good homebrew. Was it just a matter of the mindset of the time that most programmers don't have anymore?
Usually a simple 6502 assembler, debugger combination with an integrated editor on a dedicated PC, hooked up a cable into some kind of magic box on the target NES. In the UK at least a system called PDS was popular though it wasn't uncommon for development houses to have custom written development environments.
At that time, if you were lucky, you'd have a 20Mbyte hard drive on the PC and 600k or so of Ram.
In our case we had written a few custom graphics tools but in the main graphics were either hand drawn onto graph paper, or drawn in deluxe paint on the Amiga.
Some of the Japanese companies had very peculiar rules.I know of one well known company who kept their programmers and artists in entirely separate offices. Artists would burn their finished graphics onto an eeprom and the poor programmers would simply be presented with the rom images to do what they could with.
> Kirby's Dream Land was developed by Masahiro Sakurai of HAL Laboratory. Much of the programming was done on a Twin Famicom, a Nintendo-licensed console produced by Sharp Corporation that combined a Famicom and a Famicom Disk System in one unit. As the Twin Famicom did not have keyboard support, a trackball was used in tandem with an on-screen keyboard to input values; Sakurai described the process, which he assumed was "the way [game programming] was done" at the time, as similar to "using a lunchbox to make lunch."
Quite a while ago I wrote up a stream of consciousness impression of the development experience for PSX and later consoles. The PS2 section is probably most relevant to your question :)
I’ll second the recommendation for Racing the Beam. Highly engaging, just technical enough, and a fascinating window into the gaming world a few (console) generations before my time
Some other cool resources for NES:
https://wiki.nesdev.org/w/index.php/Nesdev_Wiki
https://fuzzytek.ml/tutorials/nerdynights/