I haven't really looked into it in detail, but AFAICT GB Studio is honestly incredible. I program the Game Boy as a hobby; this machine has basically no RAM and a CPU that's - depending on how you measure a "cycle" - either ~1MHz or ~4MHz, with a shockingly limited and non-orthogonal instruction set (and don't even get me started on dealing with bank switching). Historically games for it have been almost exclusively coded in assembly. And yet someone's come along and built a seemingly fairly flexible WYSIWYG game engine for it? If it didn't exist I would've told you it was impossible. I still don't quite believe it's possible, despite the proof being right in front of me.
Thanks, one of the things I’ve always tried to do (at work, before I started on GB Studio) is make difficult things seem easy and accessible. Though I’d have also told you this was probably impossible before starting too!
I just built it up slowly, making small tools to help me make sense of what was going on while learning GBDK, before I knew it pretty much had something I could package up. I’ve had a lot of help along the way though, untoxa’s [0] engine rewrite, and the work pau-tomas [1] did on the music editor have been especially helpful to the project.
Been a bit absent from the community recently, not had the time, but hoping to get back on it again soon!
I’m always amazed at how many awesome games people keep making though, it makes me really happy as this the first of many failed side projects that I pushed on through to completion.
GBStudio does use cart ROM banking (for code and assets), but extensible cart RAM (SRAM) is typically only used for save data if I remember correctly.
In general for Game Boy games the constraining factors are most often CPU and ROM (for large worlds and lots of graphics) and less so RAM.
Some of GBStudio's core is in C and some is in asm. The underlying compiler (SDCC) has been making noticeable gains in recent years, which helps. Plenty of room for SDCC to improve still, but very usable for projects.
FWIW, There is a large Game Boy homebrew competition put on by the community that just started this past week and runs for 3 months. (disclaimer: I'm one of the organizers)
Many participants (of all skill levels) will submit games written in GBStudio, and some will also write games in ASM and C.
GB Studio is a great way to mess around with making a gameboy game! It exports a rom that can be flashed onto a blank cart, and played on real hardware—with recent versions adding gameboy color support. The recently hyped McDonald’s Grimace game was reportedly made with GB studio: https://gbstudiocentral.com/news/mcdonalds-celebrates-grimac...
I've been making a game using GBDK (C) and a little engine called ZGB for the past several years, but the work that Chris and the team have done on GB Studio makes me want to switch to the platform. I'll still finish my game using C because I'm so far into development now there's no point in starting over, but if I was starting fresh, GB Studio would be the way to go.
That said, I'm glad I made my game in C because I've learned so much more about coding. I feel like I get better every day. Not sure I would have that same experience using GB Studio.
It's amazing that this software exists. And any game you can make with it can be played on a range of new emulator hardware.
There's the Pocket Analogue, which is the high-end option that runs games directly from cartridges using two FPGAs, no emulation at all. https://www.analogue.co/pocket
And there's the cheap Miyoo Mini and the Anbernic handle-helds that let you run everything up to PS1 games on a tiny handheld. They have SP-style (vertical) and PSP-style (horizontal) versions.
It would be so cool to make a game and flash it onto one of these to show to your friends.
A nitpick: FPGAs aren't based on the hardware-descriptions used to create the original chips, they're based on the community's best guesses, so they're still emulation. They're just not software emulation. They might even be less accurate than software emulators, if the community has done more research since the last time the FPGA was updated.
Gotcha, that makes sense! I wonder if there’s any difference in latency/jitter. Or maybe the GameBoy is so old that it’s easily possible to run games without any lag at all.
It's the opposite. A browser game will stop running in few years due to the never ending browser standards. An actual GB ROM will be playable for as long as emulators exist - which is forever.
I know firsthand that standard Xbox controllers work with all mainstream OSes (Windows, macOS, iOS, Android, iPadOS). The same's probably true for PlayStation ones as well :)
I used to contribute to the project back in v1 days. I'm not sure if the architecture has changed since then, but basically it worked by compiling the game logic as a kind of byte code that got interpreted at run time.
Like on top of the CPU’s opcodes? I imagine you mean the opcodes. That CPU probably can’t handle much abstraction. What impresses me the most is that to get performance out of these games, they’re often very carefully coded in the Sharp/Z80/8080 assembly. This compiler must be quite something.
Yes exactly. It's not a zero cost abstraction, but it's a very simple format, each byte code oppose maps directly to function and passes its args. So it's basically just a conditional jump
You might also like the fact that the Apollo Guidance Computer (which ran at a similar speed) was also programmed using something like bytecodes. It didn't have to drive a graphical display though, only a spaceship.
Ahahaha. But my understanding was that they wanted it to be somewhat field programmable? You can tediously write in a program with all the VERB NOUN stuff?
The verb/noun stuff I understand was the UI for the astronauts (the DSKY). There was also the native instruction set for the CPU as well as an interpreter with a richer instruction set built on top of that, and they used this to more easily write complex navigation programs. Wikipedia mentions some of this at https://en.wikipedia.org/wiki/Apollo_Guidance_Computer around the phrase "virtual machine." I'm not sure it being interpreted code would aid in field reprogrammability, since it would have been woven into the rope memory just like the rest of the software.
Yeah, I assume this is posted again because of the buzz over the Gameboy Çolor game that was created using it that McDonald's released in a recent promotion
Are there any projects/tools for ripping existing game boy sounds/music and importing them into this format? It would be a great way to learn how various effects are produced, remixing them, etc.
It seems do-able: essentially an emulator whose APU implementation records a time series of the data/config passed to each of the four channels.
It’s the “anti-Pokémon”. I’d say stealing Pokémon instead of catching them in the wild is the main difference, but the soundtrack was very “unlike the others” (strong rock vibes), the mechanics of doubles battles and colosseum “tournaments”. That you yourself were a criminal was unique too.