Kirby's Dreamland was programmed with a track ball running on a hacked up Famicom. [1] We haven't come too far since then.
[0] https://github.com/Eiriksmal/gameboy
[1] https://arstechnica.com/gaming/2017/04/the-first-kirby-game-...
Kirby's Dreamland was programmed with a track ball running on a hacked up Famicom. [1] We haven't come too far since then.
[0] https://github.com/Eiriksmal/gameboy
[1] https://arstechnica.com/gaming/2017/04/the-first-kirby-game-...
https://github.com/zeta0134/ludum-dare-42
We used the RGBDS assembler and its built in tools to make the thing, mostly because that runs on Linux and that's what we both wanted to develop on. My partner did the graphics and I got a decent flow going from LibreSprite using RGBGFX for the conversions.
https://github.com/rednex/rgbds
I'll admit that I did have a major advantage going in, having written a mostly functional gameboy emulator already, but emulating a system is very, very different from programming against its constraints. There are decent software libraries floating around, but since there's no real standard way to leverage the hardware once you get past the basics (even commercial games had wildly varying strategies from company to company) the best tool in the belt is probably your documentation. Pan docs and the various wikis were instrumental in understanding how to leverage the hardware to do what we wanted.
Really excited about it. Good luck!
Used Acorn for a while now use Paintbrush.
But they are all still too complex and don’t get the feel right.
Paint in WINE!
But I agree, tooling is complicated. I'm currently adding the finishing touches to the rewrite of my own Assembler / Compiler pipeline [1] and started work on a more "traditional" Metroid-like shooter, the sprite and map editor are both custom programs written in rust using imgui bindings and take care of the grunt work for generating all the data structures used in the game currently the dev efforts are 50/50 tooling/game though :D
[0] https://gitlab.com/BonsaiDen/vectroid.gb [1] https://gitlab.com/BonsaiDen/gbasm-rs
But in general I agree that the biggest problem with making retro games is getting a comfortable dev environment that just works. I think this is the motivation behind some of the 'simple' NES development environments that have been coming out.
I feel like a really good IDE / debugger and well documented library for the Gameboy + samples would go a long way.
Have you tried the SDCC C compiler? I use it for 8bitworkshop. It has a Gameboy CPU target.