Making a Game Boy game in 2017
gamasutra.com
gamasutra.com
I recently downloaded roller coaster tycoon for my gf, as we both used to play it when we were younger. She doesn't really play games, but during our 4th date at an amusement park we found out we both played it as children. That game was written in assembly by one person
Not really a point here, other than that nostalgia and craftsmanship can be far more powerful than the latest hardware or software
I was just listening to the original Warcraft soundtrack for nostalgia's sake and the Youtube video had scrolled through some of the old artwork. It brought back memories of playing at my friend's house when we were kids. The game also had such nice craftsmanship--the artwork, character and themes. It reminded me of what those old games on small budgets were able to do. Something about that seems missing in today's big gaming titles.
Meaning that if you went from say grayscale only graphics to color graphics, for years afterwards the industry would produce glossy but shallow games. This because the game devs were more focused on showing off how far they could push their new toys than making engaging games.
And with Nvidia pushing out a new GPU seemingly every quarter, i wonder if this has lead us into a kind of "eternal september" type scenario regarding games development.
That said, there are a number of good indie games bouncing around Steam these days. Many of them taking design cues from the NES era of gaming.
https://itunes.apple.com/au/app/rollercoaster-tycoon-classic...
https://play.google.com/store/apps/details?id=com.atari.mobi...
Instead he got BASIC and Z80 game programming books, like these http://www.computinghistory.org.uk/cgi/archive.pl?type=Books...
A friend just bought me an xbox controller (to use with my PC) as an early christmas present. I've been replaying Final Fantasy 7 which I briefly tried with mouse/kb but was miserable.
I'm literally blown away by how much there is in this game. I've been playing for 30 hours, am nominally on disc 2. The storyline is cool, the characters are a bit one dimensional in places but I still care about them. The cleverness in what they achieved with what they had (interspersed FMV and game, clever environments, all backed by pretty drawings and really good music) is just kinda magical.
I'm loving it as much this time as I vaguely remember loving it the first time - UI warts and all.
You can look at some of the GameBoy demos from the demoscene to get an idea of what others have been able to get from the hardware:
http://www.pouet.net/prodlist.php?platform%5B%5D=Gameboy&pag...
It looks like you have multiple layers in the background moving at different speeds but of course on the GB you only have one background layer so it's just the game modifying the offset when it reaches certain lines.
To help with that the console lets you configure an interruption when the GPU reaches a certain line so you don't have to poll the line register or use an external timer.
And as those systems supported color displays (in a limited fashion), it was used for things like swapping palettes mid draw.
While it takes whole different level of effort to do so, it is quite impressive what can be done on limited hardware when one do not have multiple layers of abstractions on top.
Modern systems are so capable that using raster interrupts wouldn’t add anything but if you change the display without Vsync you can see that it still works by scanning lines.
the reason for the CRT requiring the data "serially" was the electron beam that refreshed the phosphor.
Actually in many protocols you have to keep the blanking periods because people crammed tons of things in them over the years (audio, subtitles, timecode, remote control protocols, various metadata...).
Having random access to the pixels would be beneficial if you only wanted to only update specific portions of the screen but you have to know which parts of the screen have to be updated (either by diffing each frame with the previous or by being tightly coupled with the drawing code and know which parts have been updated). However in very dynamic content like movies or video games you'll often end up having the entire screen changing at once so you'll have to be able to support that anyway and the additional complexity of optimizing for the simpler cases is probably not worth it.
It seems to be the season of homebrew - Tobu Tobu Girl is another Game Boy game on a physical cartridge to come out this month, with full source code (also using GBDK) http://tangramgames.dk/tobutobugirl/
But the machines live on and many elite developers are quite fond of them, so lately, every few months or so, we get new stuff for the Oric-1/Atmos systems. The latest game that blows everyones minds (because who knew you could do it on Oric), is Blakes7:
http://www.defence-force.org/index.php?page=games&game=blake...
Its quite an achievement as a point 'n click adventure and there is much to the 8-bit aesthetic in this game that would appeal to those who came here for the Gameboy look.
Remember kids, old machines never die - their users do!
(More great Oric games here:)
http://www.defence-force.org/index.php?page=games
(.. and here:)
Wish someone with a brain would redo the series though; even though the effects are dated, the series drips misery more than what goes for dystopian these days imho.
The guys at Defence Force are making a dual-Oric: two Orics' chained together to combine graphics and audio capabilities .. if you get the druthers, follow the progress here:
http://forum.defence-force.org/viewtopic.php?f=8&t=1771
(tl;dr, two Orics are wired up, they're gonna work in sync to build a hi-res image .. yay!)
it has a very simple 8-bit (risc) architecture, but obviously tailored for games (for example, it has a dedicated sprite memory sector). i recommend people to try it out because it is has fun quirks compared with "regular" architectures, like arm and x86, for example in the way it handles cartridges, or in that some cartridges actually had non-trivial logic inside them and weren't just a rom.
it always amazes me how active gameboy research and development is still today, for example there's a very recent gameboy emulator / research project done in rust https://github.com/Gekkio/mooneye-gb
there are even test roms with which you can test your emulator to see if it implements all opcodes, interrupts and whatnot correctly (where correctly not only means "with respect to the effects" but also with respect to how many cycles everything should take). example of these test roms: http://gbdev.gg8.se/files/roms/blargg-gb-tests/
also for example this disasm of pokemon red: https://github.com/pret/pokered
if you want to write an emulator or a game and you have basic computer organization knowledge, i'd start with the famous pandocs.
The 8080/Z80 variant that is used in the Game Boy is not a RISC architecture - it is a processor architecture from a time long before the term "RISC" was even used the first time.
While the terms RISC/CISC are defined somewhat vaguely, there are still some common properties of architectures that are considered RISC:
- Load-store architecture:
Counterexample: ADD A,(HL)
- Lots of general purpose registers:
The 8080 has rather few:
B,C,D,E,H,L,A as 8 bit registers and BC,DE,HL,SP as 16 bit registers
- Very orthogonal instruction set:
Counterexample: AND has always destination A
- Often pipelined architecture (though this is not very specific to RISC)
- Instructions typically aim to be run in one cycle (when pipelined)
Counterexample: Look at the instruction timing tables
- very uniform instruction format
Look at the instruction encoding
Look at the instruction encoding
The instruction encoding is quite regular -- it follows the 2-3-3 pattern that came from the 8008 (if not earlier), and thus looks much better in octal than hex:
http://www.pastraiser.com/cpu/gameboy/gameboy_opcodes.html
http://www.z80.info/decoding.htm
As for everything else, I would agree with you --- it's not RISC.
While it is true (and I am aware of it) that the Z80 instructions follow the 2-3-3 pattern, it is nevertheless not that regular. Best look at the "purest example" for this that is referred in the literature all the time and acted as a model for the criterion that in RISC the instruction format is very regular: the instruction format(s) used by MIPS. Here there only exist 3 different types of instruction (R-type, I-type and J-type) and all have a very regular pattern. One can find very suggestive pictures at
If memory serves, that pattern has its roots in the PDP-11 instruction encoding.
There are similar testing ROMs for NES emulators, too. My emulator tends to pass the CPU tests and fail some of the PPU ones; guess I need to write a 4th implementation of that chip!
A common trick was to have a logic chip sit between the ROM and the console, doing bank switching. This allowed a game to consist of much more data than could be fitting directly on the data lines provided.
Some games, particularly those sold in Japan, had improved sound chips for example.
And by the time we reach the SNES, Nintendo used this to even introduce rudimentary 3D acceleration in the form of the SuperFX chip.
They don't seem to care about NES/SNES/N64/GB/GBA flashcarts anymore however, those are readily available from NA and EU based stores.
http://www.nintendolife.com/news/2010/01/british_r4_card_imp...
http://www.nintendolife.com/news/2010/07/high_court_outlaws_...
I assume the DMCA anti-circumvention rules let them make a similar argument in the US.
> the judge argued that "the mere fact that the device can be used for a non-infringing purpose is not a defence."
That judge is unfit to be a judge.
On the other hand, while I appreciate this voluntary hardship (a bit like esoteric languages), I guess you get about 90% of the "engendering art with constraints" with a lot less pain by using something like PICO-8.
Maybe you should document it, then make it easily accessible so that people have minimal friction getting started.
Doing that on a PlayStation 1 would be already significantly more complicated. Even if you don't bother with 3D you need to figure out how to upload the texture to the (significantly more complex) GPU, configure a bunch of stuff and then you might be lucky enough to draw something on the screen. Take for instance this code for a "virtual terminal" on the PS1 GPU, this is what the GPU init code looks like: https://github.com/simias/psx-hardware-tests/blob/a72e0ba0c8...
And keep in mind that it's a super simplistic case, for anything more serious you'll want to configure double buffering, DMA, the GTE coprocessor for the 3D transforms and probably a few other things. Even just reading data from the CD-ROM is significantly more complex than accessing the memory mapped ROM of the GB.
I expect the PS2 to be even more complicated, although I don't have a significant experience coding on it. So you end up coding on a machine that's very limited by modern standards but at the same time might be more complicated to develop for than if you used Unity or the Unreal Engine.
Also its programming model is closer to something like Vulkan, thanks to the Emotion Engine.
Meaning having to create command buffers and command lists, and then dispatch them via DMA to the GPU.
Or by doing GPU shaders, which on the PS2 means Vector Unit Assembly (similar to MIPS).
So even for 2D games there is quite a bit of boiler plate to write up, until something gets properly displayed on the screen.
Those lucky enough to get a Linux Kit for the PS2, could use a kind of mini-GL implementation, PS2GL, that would make it a bit easier, given that PS2 Linux did not have access to the APIs for professional game developers.
There is a copy of the web site still available, with the programming guides.
http://ps2linux.no-ip.info/playstation2-linux.com/index.html
2D pixel graphics arguably have aged better than early 3d graphics, and simple pixel graphics is also far more doable for a solo dev (or a very small team) than complex 3d scenes.
I often ask whether part of the reason for this is also that the (graphics) tooling for 2D pixel graphics is better than for 3D graphics.
I guess a better experience would be to plug an ESP32 to a LCD screen. :)
I'm a graphic designer and definitely not a coder for anything fun like this --- but I love seeing how people design low res sprites more than almost any other type of image. I think it speaks to my desire for minimalism, in a sense.
Fantastic work. That game looks pretty fun too.
I wonder how much would it be to forge valuable gameboy games.