voxel @voxel@merveilles.town

Starting a thread for a little side project with no explanation

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

Development from your phone, is it possible? I'm usually not more than a few steps away from a desktop computer so I've never really put much effort into researching the viability. But it's storm season here and I'd like to do something on my (i)phone other than browse cat photos on mastodon

how do I write a multi-toot thread without spamming the local timeline, anyone?

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

Not to suggest you should ever need an excuse to play, but one great side effect of having a 5 year old kid is that he's always keen to play Lego, which means *I* get to play Lego too.

Annoyed Possum just got thrown out this tree by a bigger Possum and is now pouting, didnt even care that I was there

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