4 ms·

Every time someone resurfaces the Pan Docs in a new form, I'm reminded of how I haven't touched my Gameboy dev efforts[0] in months. As fun as it is to conquer

Every time someone resurfaces the Pan Docs in a new form, I'm reminded of how I haven't touched my Gameboy dev efforts[0] in months. As fun as it is to conquer the Z80, it's difficult to get motivated working in an ecosystem that is still almost utterly without development tools. 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 https://github.com/Eiriksmal/gameboy [1] https://arstechnica.com/gaming/2017/04/the-first-kirby-game-was-programmed-without-a-keyboard/ https://arstechnica.com/gaming/2017/04/the-first-kirby-game-...

BonsaiDen 8y ago
I actually wrote a Asteroids "Clone" that uses Vector Graphics last year :) [0] 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 https://gitlab.com/BonsaiDen/vectroid.gb [1] https://gitlab.com/BonsaiDen/gbasm-rs https://gitlab.com/BonsaiDen/gbasm-rs
zeta0134 8y ago
There a few good homebrew tools and libraries available. We did a gameboy game for a Ludum dare a short while back, and while it's certainly not pretty z80, the tooling got the job done. (Be gentle, it was my first time trying to do anything serious directly in assembly and we had a 72-hour time limit.) https://github.com/zeta0134/ludum-dare-42 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 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.
chrismaltby 8y ago
I’ve been working on a little adventure game maker for GameBoy over the last few months actually. I’ve been sharing a few alpha builds on a mailing list and pretty close to releasing now. Was hoping to post a Show HN soon! https://www.gbstudio.dev https://www.gbstudio.dev
- chronogram 8y ago
  I still cannot find a good Paint alternative for macOS but soon it will have a gameboy game maker :-) Really excited about it. Good luck!
  - bluedino 8y ago
    I really like Pixen
  - Crinus 8y ago
    Have you tried Paintbrush? It is basically a modern mix between MacPaint and MS Paint (the good one, not the abomination introduced in Windows 7). https://paintbrush.sourceforge.io/ https://paintbrush.sourceforge.io/
  - jamiek88 8y ago
    Me too and I’ve tried dozens of ‘em. 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!
sehugg 8y ago
Utterly without? https://github.com/gbdev/awesome-gbdev https://github.com/gbdev/awesome-gbdev Have you tried the SDCC C compiler? I use it for 8bitworkshop. It has a Gameboy CPU target.
- djmips 8y ago
  I've tried the SDCC C compiler and I did have to fix a lot of code generation bugs, thank goodness it had source. It was a few years ago now so maybe it's been fixed. I didn't contribute my fixes at the time because I didn't know about how to do that. Today would be different.
djmips 8y ago
The Sharp LR359021 CPU is what you're conquering which is an 8080 CPU with a few throw-ins from the Z80. There are enough tools to write a GB game but perhaps there aren't enough good samples or a library (mini engine). 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.

BonsaiDen 8y ago

I actually wrote a Asteroids "Clone" that uses Vector Graphics last year :) [0] 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 https://gitlab.com/BonsaiDen/vectroid.gb [1] https://gitlab.com/BonsaiDen/gbasm-rs https://gitlab.com/BonsaiDen/gbasm-rs

zeta0134 8y ago

There a few good homebrew tools and libraries available. We did a gameboy game for a Ludum dare a short while back, and while it's certainly not pretty z80, the tooling got the job done. (Be gentle, it was my first time trying to do anything serious directly in assembly and we had a 72-hour time limit.) https://github.com/zeta0134/ludum-dare-42 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 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.

chrismaltby 8y ago

I’ve been working on a little adventure game maker for GameBoy over the last few months actually. I’ve been sharing a few alpha builds on a mailing list and pretty close to releasing now. Was hoping to post a Show HN soon! https://www.gbstudio.dev https://www.gbstudio.dev

chronogram 8y ago
I still cannot find a good Paint alternative for macOS but soon it will have a gameboy game maker :-) Really excited about it. Good luck!
- bluedino 8y ago
  I really like Pixen
- Crinus 8y ago
  Have you tried Paintbrush? It is basically a modern mix between MacPaint and MS Paint (the good one, not the abomination introduced in Windows 7). https://paintbrush.sourceforge.io/ https://paintbrush.sourceforge.io/
- jamiek88 8y ago
  Me too and I’ve tried dozens of ‘em. 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!

sehugg 8y ago

Utterly without? https://github.com/gbdev/awesome-gbdev https://github.com/gbdev/awesome-gbdev Have you tried the SDCC C compiler? I use it for 8bitworkshop. It has a Gameboy CPU target.

djmips 8y ago
I've tried the SDCC C compiler and I did have to fix a lot of code generation bugs, thank goodness it had source. It was a few years ago now so maybe it's been fixed. I didn't contribute my fixes at the time because I didn't know about how to do that. Today would be different.

djmips 8y ago

The Sharp LR359021 CPU is what you're conquering which is an 8080 CPU with a few throw-ins from the Z80. There are enough tools to write a GB game but perhaps there aren't enough good samples or a library (mini engine). 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.