Writing a NES game in C was fun but I don't know if I'd do it again. The overhead of having to learn how someone's library and toolchain expects you to use it can be significant, and for me seriously diminishes the meditative simplicity of low level development. Assembly can mean a much slower pace but also necessitates a more thorough personal understanding of what is happening and why.
For me the real joy of 8bit development is when things like this happen.
In this instance the music player library was using the same memory region as my video update buffer, so changes to the audio state were being reflected as a kind of semi-chaotic visualisation.
In the end I was able to manually relocate the music player's RAM region to a valid area where nothing was being clobbered. Shows that you can't always trust the linker to do a safe job of assigning space
I made a #nes game using a web IDE over the weekend. You can download / play / edit it here http://8bitworkshop.com/redir.html?platform=nes&githubURL=https%3A%2F%2Fgithub.com%2Fvoxel-public%2Fakj11_ancient_ruins&file=ancient.c
Code quality actually started out OK but over the last 1/8 of the jam deteriorated into a real mess. Feel free to judge me #theLudarium #gamedev
I've entered a #gamejam this weekend and decided (perhaps unwisely) to try and make a #nes game in 48 hours. I'm using C in a free web IDE designed for this purpose https://8bitworkshop.com/v3.7.1/ learning to work with neslib is slow going, but realistically I'm probably miles ahead of where I'd be if I were learning 6502 assembly for this
i feel like an assembler for 6502 or Z80 would be good for a phone. Fairly terse syntax, doesnt need many screen columns, emulatable on mobile without using an entire battrry charge
You can also listen for "free" on Spotify, Deezer, Apple Music, Tidal, and probably all the others.
Or download for free at https://megabyteghost.bandcamp.com
Thanks for the support!! You're helping make my dreams come true.
also I need a way to author collision geometry intelligently - I don't want to use the complex 'visual' geo for collision detection because it will be too slow, so every map area needs an additional invisible 'collision' geometry layer, a hidden world or dimension that can not be seen by the player but can be 'felt' as it determines where the characters can move
the maths is fairly hard (definitely the most mathematically complex part of the project), especially to do efficiently. But the bigger issue is the choices I make here have far reaching design decisions. For instance, if I limit the game to a (conceptually) flat plane, even though it's visually 3D I could treat it as 2D for purposes of collision detection and eliminate an entire dimension of problems
I have to implement collision detection and response for my 3D game engine, while keeping it as lightweight as possible (it runs on Dreamcast, have to conserve cpu cycles) and I'm really dreading it #gamedev
Previous dreamcast prototype saw me defining all map geometry 'by hand' per vertex and hardcoding it into the engine. This was fine for a boring square room but not really practical for a game with more than a couple of locations. Plus it's hell to edit after the fact
Low bit and retro developer