Making a Game Boy Game in 2017

https://www.gamasutra.com/blogs/DoctorLudos/20171207/311143/Making_a_Game_Boy_game_in_2017_A_quotSheep_It_Upquot_PostMortem_part_12.php

by tosh • 7 years ago

366 82 7 years ago

gamasutra.com

juliangoldsmith• 7 years ago

I'll have to take a look at BGB. I've been using NO$GMB, but I don't think it's maintained any more.

One thing I didn't see mentioned in the article are the Pan Docs. Those document basically everything about the Game Boy at a low level.

shinkarom• 7 years ago

BGB is the only emulator I know that emulated Pinball Deluxe without problems.

Keyframe• 7 years ago

NO$GBA v2.9d 23 Feb 2019 - https://problemkaputt.de/index.htm

ionforce• 7 years ago

I find using <OLD TECHNOLOGY> in <MODERN_ERA> endlessly fascinating. I love stuff like this!

sdegutis7• 7 years ago

Just the other day I was looking for a good NES IDE for my son who's interested in learning assembly and who has maxed out his PICO-8 skills. I think this would be a good way for kids to learn some niche skills like assembly that are still going to be needed in some careers but aren't as widespread as JavaScript or Python.

mikepurvis• 7 years ago

I feel like there's a lot of value in the whole "knowing how the sausage is actually made" thing. You'll still take collections and the garbage collector for granted 95% of the time, like everyone else, but at least you will have some sense what's going on under the hood if you've had to implement pieces of it manually somewhere along the line— and an actual working implementation, not just a toy one for some undergrad class.

RodgerTheGreat• 7 years ago

It's a platform a good bit older than the NES, but you might have some fun with http://octo-ide.com

cbm-vic-20• 7 years ago

This guy has been streaming development of a NES game: https://www.twitch.tv/zorchenhimer

AnIdiotOnTheNet8• 7 years ago

The thing I love most about older computing technology is that it wasn't ridiculously over complicated yet. In order processors with fixed instruction sets, no MMUs, no caches, no 500 layers of abstraction between you and what you're actually trying to accomplish. You know, stuff you could form a solid mental model of and reason about. Part of me really wants to go back to that world, even if it does mean a huge loss of performance.

chocolatebunny• 7 years ago

There are still some developers who work on microcontrollers and the like. Also a lot of the embedded world still has MMUs and caches but there's not a whole lot of software between you and hardware.

zzo38computer3• 7 years ago

I agree, and is much of what I try to design by computer design (although there is ways to improve the performance (in different ways than what is common now; some of it is strange and may have some unusual (but still simple) features), and there is other improvements from the old designs too, while still having a lot of the features of the older designs). It doesn't use superscalar, out of order execution, automatic caching (there is a cache but it must be programmed explicitly, and otherwise it does nothing), and all of that mess.

kuu• 7 years ago

Quite interesting!

straws• 7 years ago

Previously:

https://news.ycombinator.com/item?id=15884051

ArmandGrillet• 7 years ago

And in 2019: https://www.gbstudio.dev/

chrismaltby• 7 years ago

The author of this article was really helpful chatting with me on Reddit while I was building GB Studio and still working it all out :-)

calewis• 7 years ago

This is so well written and so cool! I love how it's on a real cartridge. I had no idea this would even be still possible. Amazing work!

voqk• 7 years ago

I bought this Game Boy Color Replacement LCD https://www.mw-embedded.com/product/gameboy-color-replacemen... which gives the device a really nice backlight. Here's the 8-bit guy's video of the process: https://youtu.be/WG8loyh-kFw

Another great GB development resource is https://github.com/gbdev/awesome-gbdev

jweir3• 7 years ago

A correction. We didn’t use graph paper for the art work. Maybe be very first artists did, but not any I know.

The tools were pretty good. Deluxe Animator II and Deluxe Paint - both for MS DOS - is what I used for all my console games - Game Gear, Game Boy, SNES etc.

tosh• 7 years ago

Which games were you working on? (<3 Game Gear)

jweir3• 7 years ago

Double Dragon for Virgin Games

https://www.mobygames.com/game/double-dragon___

I don't think I did any art for it – as I recall I calculated sprite x,y offset to hand off to the programmer for the motion.

Pretty happy to be doing it to - this was my first job out of high school.

GelatinousSqure• 7 years ago

Deluxe paint for the Amiga.... I still have a copy of that. They are the classic versions.

corysama• 7 years ago

Every Deluxe Paint fan out needs to watch this video of the master of that tool explain his craft

Mark Ferrari: 8 Bit & '8 Bitish' Graphics-Outside the Box

https://www.youtube.com/watch?v=aMcJ1Jvtef0

RickSanchez2600• 7 years ago

There was Deluxe Paint for DOS also, many games got created with it.

pcwalton• 7 years ago

Deluxe Animator II

Google doesn't bring up anything about this--do you mean DeluxePaint Animation or Autodesk Animator?

jweir3• 7 years ago

Yes. I reversed the two - been over 20 years since I worked with em.

MS DOS Deluxe Paint II and Deluxe Paint Animation are correct.

https://en.m.wikipedia.org/wiki/Deluxe_Paint

https://en.m.wikipedia.org/wiki/Deluxe_Paint_Animation

I did use Autodesk Animator some - but for games the Deluxe Paint tools were better.

vkaku• 7 years ago

Gameboy is a fun console.

I encourage Gameboy enthusiasts to check out the pret project on Github: https://github.com/pret

Asesprite is currently my favorite pixel editor / animator ATM: https://www.aseprite.org/

jldugger• 7 years ago

https://boingboing.net/2015/06/16/super-mario-maker-design.h...

derefr• 7 years ago

We didn’t use graph paper for the art work. Maybe be very first artists did, but not any I know.

I mean, whether or not pixel-paint software exists, graph paper, even today, is still great for sketching and ideating pixel art [and/or level designs, but I'll just say "pixel art" from here on.] If you try to come up with a design for a 8x8 or 16x16 sprite or icon by freehand sketching it, you'll probably come up with something that won't look legible at that size. Better if you have the constraints of the grid even in your sketchbook; and so, better if your sketchbook is graph paper. (In fact, I believe they've make special-purpose graph-paper sketchbooks for forever now, specifically for ideating cross-stitch and latch-hook art.)

We're really only just barely out of the era of ideating pixel art using physical media, with the advent in the last ten years of cheap tablets that can run pixel-painting software, that are light and convenient enough that an artist would prefer to lug them around in place of their sketchbook.

Of course, after the ideation process—once you've got a draft you like—you'd likely be using some kind of software (visual or not) to input it. Scanner tech, and downsampling algorithms, were both far too crap back then to rely on faithful digitization of "discrete" information like pixel-art pixels. (Unless you were using a special scanner, special software, and special constraints on your inking process. Remember Scantron sheets? A 1980s pixel-art scanner would require basically the same fraught workflow.)

But also, on the other side of the urban-legend scale (that the article thankfully doesn't repeat), no artist was ever having to do bit math to get packed words to type into a resource file. Programmers may have done that for first tests with crappy programmer-art, but even back then, comparative advantage was a thing, and any artists on a project weren't hired to be good at calculating on long strings of numbers.

Instead, from the very beginning of computers being hooked up to displays and having character/tile display modes with configurable character/tile memory, there were already "textual graphics" formats like NetPBM, where you could use a visual editor like DOS edit or Unix vi as your "pixel art editor." These files can then be compiled, resulting in the a C or ASM source file defining some constant as a uint8-array literal. (They weren't necessarily standardized; but it was very easy to reinvent these formats and their tooling, and many companies did in the process of producing early game software.)

There was pixel-paint software too, even in the early 80s... but it wasn't on every platform. And, since you were often stuck on the platform you were targeting, that was a problem. (You were fine when targeting closed platforms like the gameboy, because the SDK would usually be built for a workstation-class system; but when targeting your average 8-bit micro, this was often the case, and 8-bit micros had no niceties like "standardized floppy disk formats" or "networking standards" to transfer in data from your nice graphics workstation. If you want to write e.g. ZX Spectrum software, you write it on a ZX Spectrum—or one of its younger brothers, once those came out.)

But, no matter the platform, if it was display-oriented, you could pretty reliably get a visual text editor. (Even on the ZX Spectrum!) So writing textual "1"s and "0"s into text files was indeed a thing—for a while, at least.

IceWreck• 7 years ago

Despite a mere 4Mhz speed, all the Game Boy games are displayed in constant 60fps. Take that PS4 Pro and Xbox One X!

My favorite line from the post.

basementcat• 7 years ago

The Gameboy has the advantage of a smaller display with fewer pixels (with less colordepth) to update. 16 bit pointers are also (relatively) easier to push around than 32 or 64 bit pointers.

ekimekim• 7 years ago

I would wager that doesn't make up for how much slower the hardware is, though.

The 4MHz value is the clock speed, but all instructions take a multiple of 4 clock cycles to accomplish, so you often talk about it as a 1MHz "instruction cycle" machine.

The fastest memcpy implementation I've seen for it (not including in-hardware DMA features, which are only available for copying to OAM (sprite) RAM on the original gameboy) takes 4.5 cycles per byte (one 16-bit word every 9 cycles).

That means that if you were trying to update every pixel on the screen (which doesn't actually work - the GB's screen pixels aren't memory mapped directly but generally specified via a combination of up to 384 unique 8x8 tiles, which are then arranged on a 20x18 tile grid), which would be 160 * 144 * 2 bits/pixel = 5760 bytes, it would take 25920 instruction cycles ~= 24.72ms, which comes out to approx 40.45 FPS.

Of course, as I mentioned, the actual GB doesn't work like that, and has a Pixel Processing Unit that handles writing to screen every frame. While the PPU is writing to the screen, the CPU cannot access VRAM, which means that the CPU actually only gets what's called the v-blank period, which is only 1140 instruction cycles, which is only enough time to copy up to 254 bytes or so (I'm skipping over some detail here, like how you could squeeze a few extra bytes out by loading the first 4 or so bytes into registers before vblank begins, or how you can also (with very careful timing) write to VRAM during a ~60 cycle window on each line knowing as the h-blank and OAM search periods).

In practice, games work despite these limitations because they generally only have to modify a small amount of the screen in any one frame. Scrolling is implemented in hardware, and you can write new data off screen then scroll into it so you can take multiple frames to write it if needed.

This plus other tricks (for example, animating 50 copies of a common tile by editing the tile's pixel data, which affects every copy at once) let these games accomplish so much with so little.

It's impossible to compare to a modern sytsem with a polygon-based GPU, they're entirely different things.

mywittyname• 7 years ago

For those interested in classic game dev, the guys at the Computerphile YT channel did a series with a guy that wrote a Genesis game a few years back using an original dev kit on a mid-90s PC.

https://www.youtube.com/watch?v=GH94fKtGr0M

azhenley3• 7 years ago

After reading the post a few days ago about the Playdate console and reading this post, it makes me wish there was a popular retro-style handheld console that I could develop for.

sneakernets• 7 years ago

Honestly, I can't recommend the GBASP enough. It's small, it has a lot of power for a handheld of that era (enough to pull off texture-mapped polygonal graphics at an acceptable frame rate) and the addressable ROM size is practically limitless, going all the way to 64 MB.

azhenley3• 7 years ago

I guess I should add another requirement to my wish list: a modern app store so indie devs can sell their games :)

I am considering teaching a university course where the students implement a NES or GB emulator though. Should be a blast!

tieze2• 7 years ago

yea, I posted with another suggestion on this thread, but the GBA itself is just such a dream machine. It's the sweet spot for retro programming in my mind. All the cool console features, streamlined hardware, simple interface. So good.

tieze2• 7 years ago

not popular I guess; it's not even out yet, but the Pimoroni people are doing a GBA-like handheld kickstarter geared towards developing, called 32blit. Doesn't have all the cool bitmap, sprite, etc hardware I'm sure, but they try and give a pretty integrated environment. Also maybe geared a bit more towards beginners, but I really like the idea. And because it's modern hardware, you can just use all your standard tools. It's also got hardware debugging, looks like.

azhenley3• 7 years ago

I actually just saw this a few minutes ago (Jeff Atwood retweeted it). It looks very nice! I only hope it gains traction.

Lerc• 7 years ago

The difficulty in making retro style (programming) hardware is that any technique you use to use to make it nowadays could be trivially be boosted to be much more powerful, sufficiently powerful in fact you could probably just run a software emulator for the thing.

I'm going the route of others with making a fantasy console, and will be content to run it on mobile platforms in an emulator, which is what happens with the pico8.

That said, I do have a half baked idea in my head to make something from a AtMega and an ESP32. If the higher clockspeed of the esp32 is enough to make it pretend to be a valid xram interface for the AtMega. Then output s-video out the DACs.

orionblastar• 7 years ago

My Nephews stole my Gameboys by borrowing them and never returning them. I still got a DS my son owns. But I had the Classic Game Boy, Game Boy translucent case, Color Game Boy yellow shell, Game Boy Advance SP. All gone now. They are collector's items now worth a lot.

I had an Atari Lynx but had to sell it because I needed the money. It was like the Game Boy but Atari and it had color graphics and slim cartridges.

I think Free Pascal or some other language can make console games by cross compiling.

Right now I have a Raspberry PI with RetroPI to play Gameboy games.

ngcc_hk• 7 years ago

That is what learning to compute all about. Since day one. What is the driver of internet. Or pdp machine. To play game developed and maintained by us and fellow hackers.

Stay hungry and hack.

Lyrkan• 7 years ago

I'm wondering if selling physical copies of the game doesn't come with legal issues...

The "Nintendo" logo you see when booting a Game Boy comes from the cartridge and is checked against one stored in the console.

If they don't match the whole thing stops, which means that you have to add (and distribute) a Nintendo logo to your game in order for it to work on real hardware.

philistine• 7 years ago

I have not tested this particular game on real hardware, but multiple games found ways around the console's logo checksum. It has a buggy implementation that can be circumvented, allowing you to never have the logo on your cartridge.

jkoudys• 7 years ago

Great read! I was active in the gb dev scene in the late 90s (hmu if you remember gbdev99 or the bunghk contests), and it's amazing to see so many of the names and libraries built so long ago still come up today. The Game Boy is still one of my favourite platforms today; such a great example of what you can accomplish with very limited resources if you have enough creativity. We've seen some of the best games of our generation come out on a battery-powered device with a CPU that can't even multiply.

Kipters• 7 years ago

For anyone interest, I recommend watching "The Ultimate Game Boy Talk" [0] from 33c3, lots of interesting details about how a Game Boy works, including the PPU

[0] https://www.youtube.com/watch?v=HyzD8pNlpwI

Making a Game Boy Game in 2017

Related Stories