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
designing everyone's favourite directional slidey puzzle
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
Sorry, I mean software development, not photo development of bad lightning pictures
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
However, I am making some good progress with the renderer. The idea is to model arbitrary modular rooms in blender and munge them into a format I can display efficiently on the Dreamcast. The rooms snap together at predefined portal points, and select appropriate mesh geometry depending on whether they're connected to another room or not. Although I have no plans to let players build levels, the map editor will run in-engine rather than being a standalone tool. #theLudarium #gamedev
Low bit and retro developer
Merveilles is a community project aimed at the establishment of new ways of speaking, seeing and organizing information — A culture that seeks augmentation through the arts of engineering and design. A warm welcome to any like-minded people who feel these ideals resonate with them.