Making a Game Boy Game in 2017(gamasutra.com)
gamasutra.com
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
84 comments
Which games were you working on? (<3 Game Gear)
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.
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.
I loved the hell out of that game. Probably spent 100+ hours with Double Dragon.
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/
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/
> Deluxe Animator II
Google doesn't bring up anything about this--do you mean DeluxePaint Animation or Autodesk Animator?
Google doesn't bring up anything about this--do you mean DeluxePaint Animation or Autodesk Animator?
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.
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.
> 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.
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.
Deluxe paint for the Amiga.... I still have a copy of that. They are the classic versions.
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
Mark Ferrari: 8 Bit & '8 Bitish' Graphics-Outside the Box
https://www.youtube.com/watch?v=aMcJ1Jvtef0
Small world- I just finished watching this again today. I've been trying palette-cycling techniques with 32blit to see if I can learn the ropes and put together a half-decent tutorial. I've had these - http://www.effectgames.com/demos/canvascycle/ - up on my screen for the last few days. I managed to get - terrible - palette-cycled fire sprites working with smooting (which Joe calls "Blend Shift Cycling") and I think there are still some interesting interactions to be found between these classic techniques and modern hard/software.
It's really exciting to see renewed interest in these techniques and "8-bitish" games in general since it probably means we've chosen the right time to make our handheld.
It's really exciting to see renewed interest in these techniques and "8-bitish" games in general since it probably means we've chosen the right time to make our handheld.
There was Deluxe Paint for DOS also, many games got created with it.
And in 2019: https://www.gbstudio.dev/
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 :-)
> 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.
My favorite line from the post.
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.
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.
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.
I find using <OLD TECHNOLOGY> in <MODERN_ERA> endlessly fascinating. I love stuff like this!
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.
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.
I have a few problems with that, though. For one, I don't really care about the vast majority of projects that kind of stuff is used for, and for another they often have closed proprietary toolchains.
Really? Because it's used in so many fields there should be something interesting there one would think. Of the top of my head:
Defense, agriculture, home automation, industrial automation, finance, automotive, oil&gas, space resarch, robotics. The list goes on!
I think the proprietary toolchain stuff is also changing, but slowly.
Defense, agriculture, home automation, industrial automation, finance, automotive, oil&gas, space resarch, robotics. The list goes on!
I think the proprietary toolchain stuff is also changing, but slowly.
If nonproprietary is #1 issue for you, you could design your own CPU or emulate an existing one using a hardware design language and FPGA.
Although there's no way past proprietary chips, at least the open-source toolchains for them are coming along.
Although there's no way past proprietary chips, at least the open-source toolchains for them are coming along.
> Although there's no way past proprietary chips
Yeah, see, that's a hold up for me. If I'm going to go through the effort of building something completely non-commercially viable than I want it to at least be completely open. And before you say anything, no, I'm not at all interested in making anything commercially viable.
Yeah, see, that's a hold up for me. If I'm going to go through the effort of building something completely non-commercially viable than I want it to at least be completely open. And before you say anything, no, I'm not at all interested in making anything commercially viable.
As long as you get something with an ARM, you don't have to worry about a proprietary toolchain.
ARM itself is proprietary though, and also I'm not sure there are ARMs as simple as I'm describing.
All the retro platforms were proprietary, though? Can't get much more proprietary than Nintendo.
Cortex-M0 is very comparable to a 68k with 32-bit registers. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....
Cortex-M0 is very comparable to a 68k with 32-bit registers. http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc....
Many old Nintendo systems are now well documented and you can potentially make a fully non-proprietary hardware clone and software tools.
Retro platforms were current technology. If I'm going to use technology with several orders of magnitude less power, then I'd at least like it to be open, is all I'm saying.
I mean, everything is propeitary then. Even SiFive has issues publishing their preboot code. https://www.bunniestudios.com/blog/?p=5127
And a ARM CortexM0 is about 12k gates, it's hard to get much simpler than that.
And a ARM CortexM0 is about 12k gates, it's hard to get much simpler than that.
> I mean, everything is propeitary then.
Yeah, that's precisely the problem. Though you're right, the M0 at least does fit what I'm talking about pretty well, in-order, no-MMU, etc.
Yeah, that's precisely the problem. Though you're right, the M0 at least does fit what I'm talking about pretty well, in-order, no-MMU, etc.
So what, you just don't code for hardware at all?
If I'm going to use technology with several orders of magnitude less power, then I'd at least like it to be open, is all I'm saying.
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.
You write a lot of Lisp don't you?
Actually, no I don't write Lisp so much.
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.
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.
Having done no CS in school and jumping right into python and JS, learning how the sausage was made was immensely satisfying. I wrote a CHIP-8 emulator in Python and then a Game Boy emulator in Rust. None of those skills have been practically useful but were very educational.
>None of those skills have been practically useful
Honestly you never know when something you are familiar with becomes important later.
Something that was important to get it done may not be as important in later tasks. (My Operating Systems Class at university was greatly useful in my first job, not as much after) My dabbling in JS got me job programming timecard apps for blackberries and changed my work trajectory.
This field changes so fast and you can't learn everything, so learning things you enjoy and help you get what you are working on now.
That and data-structures and databases, you can never know enough about both.
Honestly you never know when something you are familiar with becomes important later.
Something that was important to get it done may not be as important in later tasks. (My Operating Systems Class at university was greatly useful in my first job, not as much after) My dabbling in JS got me job programming timecard apps for blackberries and changed my work trajectory.
This field changes so fast and you can't learn everything, so learning things you enjoy and help you get what you are working on now.
That and data-structures and databases, you can never know enough about both.
Confidence is immensely useful
Unrelated question: what resources did you use to write your CHIP-8 emulator? I've also been wanting to write one in Python for educational purposes, but haven't found any great resources yet in Python. Granted there are a few in C that I could try to translate over, but I'm curious to know what you used.
I looked at the Wikipedia page and a couple PDFs from Google front page.
I stole a collection of games from someone else's project to use for testing.
My goal was to get in the door so I picked a language I knew well and set some constraints:
1. Doesn't have to be fast. Just has to run.
2. Write opcodes as pure functions, passing in an array of memory and returning a new array of memory. This made it easy to test and debug. But also made it super slow.
3. DO NOT look at someone else's code. This forced me down a way slower path where I learned a whole lot more than I would have if I just reimplemented others' work.
I stole a collection of games from someone else's project to use for testing.
My goal was to get in the door so I picked a language I knew well and set some constraints:
1. Doesn't have to be fast. Just has to run.
2. Write opcodes as pure functions, passing in an array of memory and returning a new array of memory. This made it easy to test and debug. But also made it super slow.
3. DO NOT look at someone else's code. This forced me down a way slower path where I learned a whole lot more than I would have if I just reimplemented others' work.
Fully agreed. Currently doing web dev as a daily job, and even most of my personal projects are all fairly high-level. However, I cannot under-appreciate how useful and eye-opening building my own CPU pipeline and learning assembly was back in college. Just the fact of understanding how it ALL works under the hood (even if it is just a simplified version of it) made me feel amazing and gave me a lot of insights I wouldn't have gotten otherwise.
It's a platform a good bit older than the NES, but you might have some fun with http://octo-ide.com
I found https://8bitworkshop.com which seems to be just what we're looking for, but since it's a web app and we don't have internet at home, it's going to take some effort to get it working for him.
Curiosity got me - why don't you have internet at home?
It's a huge time sink. We've gotten more done at home in the past 6 months since getting rid of TV and internet than we have in the past 6 years. And our family life is significantly more connected and alive than when we had TV and internet.
I heartily recommend everyone try it for a couple months. No TV, no mobile data plan, no home internet, no radio. It's amazingly refreshing.
Edit: another reason is that almost all social media is geared towards making you addicted to it and encourages hopelessness, and when you get rid of social media, not just deleting accounts but even to stop consuming it regularly, your attitude will just change for the better on a daily basis. Waking up will feel refreshing, not burdensome, like today is a new opportunity, not a new day of drudgery. Well, at least it will play a big part in this shift.
I heartily recommend everyone try it for a couple months. No TV, no mobile data plan, no home internet, no radio. It's amazingly refreshing.
Edit: another reason is that almost all social media is geared towards making you addicted to it and encourages hopelessness, and when you get rid of social media, not just deleting accounts but even to stop consuming it regularly, your attitude will just change for the better on a daily basis. Waking up will feel refreshing, not burdensome, like today is a new opportunity, not a new day of drudgery. Well, at least it will play a big part in this shift.
so how are you, uh, posting on the internet right now?
I'm a software consultant, but I can do most of my work offline. When I need internet for my work, I go to the local library during ordinary work hours (9-5pm) and use their free wifi. Most documentation that I need is available offline in Dash (or Zeal for Windows) and I can download that and whatever else I need while at the library. It's a lot easier than I thought it would be.
Consider getting into their Friends of the Library program, or whatever they call it. That helps fund them beyond what they get from taxes.
https://en.wikipedia.org/wiki/Friends_of_Libraries
https://en.wikipedia.org/wiki/Friends_of_Libraries
I think they're surviving well enough.
What I am interested in, though, are the public library board meetings that they hold monthly, open to the public. I can't imagine what kind of things they discuss, and I'm thinking of attending one just to find out.
What I am interested in, though, are the public library board meetings that they hold monthly, open to the public. I can't imagine what kind of things they discuss, and I'm thinking of attending one just to find out.
This seems like a good question to ask one of the librarians.
What kind of consulting do you do, if I may ask? I assume something unrelated to web applications? Working on a web app with a thousand dependencies, even if working on the backend, would be terribly frustrating and almost impossible, I believe.
Mostly React.js and Node.js, and I use NPM to install dependencies while I'm at the internet, and they still work when I go offline since they're downloaded.
The hard part is dealing with live APIs, but fortunately these can be recorded while online and replayed when offline, which seems like a good practice anyway during development.
The hard part is dealing with live APIs, but fortunately these can be recorded while online and replayed when offline, which seems like a good practice anyway during development.
> The hard part is dealing with live APIs, but fortunately these can be recorded while online and replayed when offline, which seems like a good practice anyway during development.
Cool. How do you do this?
Cool. How do you do this?
Just record the important parts of an HTTP request using your server software, such as Node.js, save them to disk, and replay them on matching subsequent requests when offline mode is enabled. Or use a high level library that already does this; I'm looking into yakbak[0x00].
[0x00] https://github.com/flickr/yakbak
[0x00] https://github.com/flickr/yakbak
This reminds me of the days when I downloaded webpages to a palmpilot...for “offline” use
This guy has been streaming development of a NES game:
https://www.twitch.tv/zorchenhimer
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.
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.
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.
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.
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!
I am considering teaching a university course where the students implement a NES or GB emulator though. Should be a blast!
> I am considering teaching a university course where the students implement a NES or GB emulator though. Should be a blast!
I was considering doing the same for my Machine Language class, but it seems that many games rely on the precise timing of the emulation to work. And, because the output was an anolog TV, there are a lot of tricks that need to be figured out. I thought that was a no-go for a course.
I was considering doing the same for my Machine Language class, but it seems that many games rely on the precise timing of the emulation to work. And, because the output was an anolog TV, there are a lot of tricks that need to be figured out. I thought that was a no-go for a course.
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.
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.
I actually just saw this a few minutes ago (Jeff Atwood retweeted it). It looks very nice! I only hope it gains traction.
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.
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.
NO$GBA v2.9d 23 Feb 2019 - https://problemkaputt.de/index.htm
BGB is the only emulator I know that emulated Pinball Deluxe without problems.
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
Another great GB development resource is https://github.com/gbdev/awesome-gbdev
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.
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.
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.
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
https://www.youtube.com/watch?v=GH94fKtGr0M
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.
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.
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.
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
[0]: https://www.youtube.com/watch?v=HyzD8pNlpwI
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!
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.
Stay hungry and hack.
Quite interesting!
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.