Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags

The actual GB limits

A topic by fanzyflani created Sep 30, 2016 Views: 24,827 Replies: 60
Viewing posts 1 to 20

Here they are, for your convenience. These are not part of the rules, but you should make at least some effort to follow some of them. Namely the thing about 8x8-pixel tiles.

Note, there are ways to skirt around them a bit using scanline-sensitive or even cycle-exact hackery but you have to know what you are doing.

Most important thing: Everything is made up of 8x8-pixel tiles, and on the background layer these all scroll together on a uniform grid.

  • Resolution: 160x144 pixels (AKA 20x18 8x8-pixel tiles)
  • Framerate: 59.73fps
  • Tilemap: 8x8 pixels per tile
  • Background layer: 32x32 grid of 8x8 tiles, scrollable, and scrolling wraps
    • Practically, you can use any size grid you want, as on the real hardware you'd replace tiles while they're offscreen.
  • Colour gamut: 4 "colours"
  • Sprite object sizes: 8x8 or 8x16 determined by a global flag - larger sprites are made up of
  • Colours per BG tile: 4
  • Colours per sprite: 3 + 1 transparent
  • Palettes for background+window layers: 1
  • Palettes for sprites: 2

And here's some of the tighter ones where you should consider them but you shouldn't actually enforce them:

  • Max number of tiles in tilemap: 384 (with some nasty tricks), 256 (w/o nasty tricks)
    • Technically you can stream in new tile data as you scroll. Think of this as a discouragement from having too much variance on a single screen.
  • Max sprite objects: 40
  • Max sprite objects per scanline: 10

If in doubt, check this: http://gbdev.gg8.se/wiki/articles/Pan_Docs

Just don't get distracted by the GBC/CGB stuff as that thing lets you do a lot of things that you can't do on the DMG.

Important notes:

  • Respect the 8x8 grid.
  • Respect the 8x8 grid.
  • SERIOUSLY RESPECT THE 8x8 GRID IT'S NOT HARD
  • Punch everyone who does not respect the 8x8 grid.
  • There is a window layer. The actual specifics of it are kinda weird, but basically you set the top-left corner, you cannot scroll it past the top-left corner of the "screen", and everything rightwards and downwards is part of your window.
    • In other words, if you use bidirectional scrolling, put the HUD on the bottom and/or the right, or use a small number of sprite objects.
    • Yes you can just have it in the bottom-right corner.
    • Yes, it's a grid of 8x8 tiles. Beginning to see a pattern here?
  • Don't go overboard with parallax. There's only one background layer, and sprite-background priority is only determined on a per-sprite basis. But on real hardware you can abuse the scanline interrupt and adjust the horizontal scroll, or you can scroll a few tile bitmap entries if you know what you're doing. Looking at those options:
    • The scanline-interrupts method will scroll the whole horizontal section of the background layer.
    • The tile-bitmap-scroll method will scroll every instance of a few given tiles. Feel free to emulate that using separate scrollable layers. Although in this case... yes, it'll have to be 8 high, and probably 8 or 16 or 32 wide.
  • Respect the 8x8 grid.
  • Sprites are 3 colours plus transparent, not 4. If you want to use all 4 colours, you can overlay sprite objects. Some GB games did this, AFAIK some NES games did as well.
  • Sprites use one of two shared palettes. The palette which is used is determined on a per-sprite basis. Yes, they have 3 colours each.
    • All palette colours are sourced from the 4-colour gamut, so no, you will not get a 5th shade of grellow.
  • DO NOT MAKE AN ACTUAL PERSPECTIVE 3D GAME UNLESS YOU ARE DOING IT FOR THE REAL HARDWARE IT WILL NOT WORK IF SOMEONE WERE TO TRY AND PORT IT TO REAL HARDWARE
    • The closest you'll get to 3D is some form of orthographic projection. Isometric is kinda tricky here (it's best to go with 16x8 for each edge), but a basic oblique projection (e.g. the later Commander Keen games like Keen 4) should be fine.
  • Pick or make a font where each character fits into 8x8, then respect the 8x8 grid and draw a character every 8 pixels across.
    • Completely acceptable exception: Static HUD text can be proportional, but the width should ultimately be a multiple of 8 pixels, unless you implement the HUD as sprites.
      • You still shouldn't spam lots and lots of sprites here!
  • Finally, respect the 8x8 grid.

You sound a little angry. Anyway, here are some examples of 3D on the GB/GBC which I feel give a pretty good impression of what the system is capable of for those that are interested in keeping within the restrictions.

GB games that are '3D':

GBC games that are '3D':

Toy Story Racer was brilliant. IIRC what they did was they pretty much used a bunch of well-compressed video segments.

But yeah, unless you know the hardware well enough to know how hard you can push it, stick with 2D.

Submitted

Good guide, though thankfully for productivity's sake the jam doesn't require sticking to the technical limitations of the Gameboy :P Just the colors and resolution. It'd be a nightmare to stick within each of those limitations just for the sake of doing it.

Is this guideline official? Are you one of the organizers? I would like to know some of the organizers thoughts on this matter, especially because I've seen in multiple places now that the "keep it as GB as you can" isn't really enforced. Also if you go all out on the specifics why nothing about audio/sound?

Consider it this way: Probably nobody will appear at your door and kick you in the stomach if you break any rule, even the resolution one. :)

Stick to the given resolution, four colors, and use tiles and sprites rather than anything polygonal/dynamic and you're fine in most people's opinion.

If your game plays well and feels like it could have been on the Game Boy it's fine, even it would have been slow as hell.

If you want, look up "Elite" for the Nintendo Entertainment System. Yes, it's been done and it's in full wireframe 3D even though the NES had no 3D hardware (or software) support and essentially tiles and sprites only.

For most it's just for fun, a learning experience, or some creative way to try something new and share it with others.

If you want to participate, just do it. Don't worry too much about the rules or restrictions. Bend them as you see fit, just try to stick close to them.

Also keep in mind the notes above are mixing up GB/GBC a bit. Originally you only had your 4/3+1 grayscale palette and nothing more. The palette swaps for sprites were introduced with the GBC for obvious reasons.

Phu! I mean, for us n00bs that are just starting out with game dev. that would have probably been... impossible? :D Well, not necessarily, but definitely harder for sure. So I for one like those bendy rules a lot more, I don't think the goal here should be creating an emulator for this thing :)

Nope, there are two palettes for sprites which source from the 4-shade gamut. IIRC GBC uses 8 palettes for the sprites and those are sourced from that 5:5:5 RGB cube with the really weird gamma ramp and side effects.

Yeah, had a look around and there are indeed two palettes, but the only difference is the transparent color as far as I know. There's still a total of 4 colors only obviously.

Submitted (1 edit)

They're not official guidelines. The guidelines on the main page are the only guidelines. They're neat meta objectives though.

(1 edit)

The main page has rules. My post has optional guidelines. They're not official.

As for sound, easy solution is to just make something in Deflemask.

Here's what it uses anyway:

  • 2x pulse wave (12.5%, 25%, 50%, 75% duty cycles)
  • 1x 32-sample 4-bit wav channel with very limited volume control (best to assume this just does on/off)
  • 1x 15-bit/7-bit (selectable) LFSR noise channel, frequencies are kinda weird, if you don't do any freq sweeps you should be fine

Each channel supports hard-panned stereo (left/centre/right).

Volume goes from 0 to 15 inclusive. Not sure what the actual lower/upper bounds are on the period. It appears to be a simple voltage sum, unlike some chips which use logarithmic volumes.

For the curious, at least one pulse channel has a freq sweep unit, and I think both have a volume envelope unit each. You do not actually need to know about these as you can replicate their behaviours manually.

framerate of 59.73fps, yea right dont forget to add the ghosting :P

Ghosting is always nice, especially if you can abuse it to introduce more colors or good transparency. :)

Totally going to abuse that. Thanks for the idea.

LOL, got a few former pro Gameboy developers here in the room with who enjoyed a chuckle at that :) They spent years trying to avoid those limits.

"DO NOT MAKE AN ACTUAL PERSPECTIVE 3D GAME UNLESS YOU ARE DOING IT FOR THE REAL HARDWARE IT WILL NOT WORK IF SOMEONE WERE TO TRY AND PORT IT TO REAL HARDWARE"

Fuck that. I do game jams for fun. I program games for systems with hard limits like those everyday.

Rules are resolution and 4 colours (preferably 3 progressively darker shades plus one unshaded) the rest is up for grabs.

I'm not going to respect the 8x8 grid, you don't own me.

Submitted
  • Colour gamut: 4 "colours"

Someone clarify please what does it mean? Only 4 colors(include transparent) or 3 main colors with shades + transparent?

Here's examples of games with 4 colors

You can only have absolutely 4 colors at any time

You can make original Game Boy games display more than four colours on static 8x8 areas of the screen with Super Game Boy (SNES).

Here are a few examples:



none of those examples have more than four colours in an 8x8 area of the gameboy screen though, only in the SGB border. Still, I think including an SGB style border for future GBJAM entries might be a really cool idea!

What I meant to say is that you can change the 4 color palettes of the static 8x8 sections of the Game Boy screen to allow the game to display more than 4 colors on the screen when used with Super Game Boy, but the 8x8 tiles still display 4 colors each.

I have a question, is respecting the 8x8 grid important?

Submitted (1 edit)

Yes it is important, but don't actually punch someone if they don't respect it! A 16x16 grid is OK but 8x8 is technically the best size!

(1 edit)

No, you can use as a personal challenge, but it's not a rule, maybe depending of how your game will be, it's important. But many games in the past jams don't have 8x8 grids. And the only rules you have to follow is the original jam rules. A good example is the games who won the gbjam3 and gbjam4, both are awesome, and they use more than 8x8px, maybe more than 16x16.

It's not that hard to respect. You should give it a crack.

16x16 is completely fine as you can just make a 16x16 tile using 4 8x8 tiles on the real hw.

nope

Submitted

why are you so upset

I'm not as mad as the OP about this but it IS kinda weird that this jam rewards entries that break the rules. Obviously not respecting the sprite limitations means you can draw nicer sprites. I went back through previous jams and p much all of the winning entries used sprites at whatever sizes they wanted, didn't keep to the grid, used all 4 colors for every sprite etc.

And the response to that is generally "the official rules are only that you should make a game with 4 colors and it should have a 160x144 resolution" but why are we calling it GBJam then? At that point it's the Four Color Small Screen Jam. #FCSSJAM2017

I mean it's just a game jam so it's fun regardless, but it is a lil' odd!

Submitted

The rules are simple :P The jam doesn't reward any entries that break the rules, because the rules aren't "stick to gameboy technical limitations"

I think people are taking it a little too literally. The idea is to just make games that have the spirit of gameboy games, not actually be gameboy games.

Sure, it's not really rule-breaking. I'll rephrase: The jam rewards entries that have the least spirit of gameboy games.

I love this jam, it's my favorite of all game jams, but you can't tell me that it makes sense.

You nailed it.

The actual Gameboy has a lot more limitations than just 160x144x2bpp. It has different challenges other than "just keep to this res". In fact, thanks to the wonders of postproc shaders, dithering, and FBOs, you can make anything 160x144x2bpp.

And then what limits are there to push? What makes the games different other than "hey you can just dither everything to 4 shades of grey"?

Thus rule 1, "The aim of GBJam is to create a GameBoy themed game". And that's where arguments start to break out. Because no longer is it OK to just take any old game, confine it to 160x144x2bpp, and be done with it. Or is it?

Everyone has their own interpretation of rule 1. For at least some entrants it's "LOL MAEK A GAEM :D :D :D :D :D". For me it's hard to nail because there's some good stuff that happens that does violate the limitations, but OTOH doesn't outright piss all over the GB.

Limits are a good thing. They force you to be creative. They inspire you to work to them. They cut out a lot of the clutter, letting you focus better. They are there to be fought to the bitter end. But they are NOT there to be outright violated.

But when you have a limitation as murky as that, suddenly you're in some state of uncertainty, and you have no idea where the line actually *is*. You don't feel like you really have anything to push.

And the thing is, if you are confined to the limitations of the actual GB, you will be inspired to make something different from what you would if you were only confined to, well, 160x144x2bpp.

If this were called FCSSJam or 4CJam, this thread would not even exist.

Submitted

Exactly. And let's not then get into the joy that is bankswitching, 16kb ROM Banks and tiny RAM limits ;)

But yeah, Argonaut software did make what was effectively a proto-type version of what eventually became Starwing / StarFox on the SNES. With sampled speech and everything! It's amazing what could actually be done on a machine with a lil 4MHz modified Z80 processor!

I'm using a flat 32KB ROM for my entry (almost using half of it here), and the RAM limit is completely fine - ideally I'd have a 64x64 map which would chew up exactly half of the memory, and then the other half would, as usual, be hardly touched at all.

But if I need more ROM space, I can always just shove tilesets and music into the second slot. I'd have to manually pick the bank numbers (this is because you can't put bank 0 into the swappable slot) but WLA-DX can automatically find a spot to put them in each bank.

I'd say these days, bank switching really isn't an issue, as I highly doubt that your *code* exceeds 16KB.

Submitted

That's cool. Yeah MBC1 style switching is much easier to deal with than MBC5 :) Most of my needs for bankswitching come from asset loading but I have had to resort to placing screen manager code in other banks for safety as I'm down to ~3k left in bank 0 with a few more fetures to add and possibly extern into other banks. It's fun experimenting with how to use bankswitching in general though.

Best of luck with your entry fanzy flani, looking forward to playing through it!

Submitted

next jam were only allowed to accept actual gameboy playable roms you have to mail them all to the jam host and he will play them on his sweet ass real gameboy

(1 edit)

Said jam host with said sweet ass real gameboy would have a sweet-ass flashcart and could download sweet-ass games off the sweet-ass internet. Mailing is unnecessary.

Submitted

thats not real enough we need to make actual nintendo verified game carts

I look forward to seeing your walking simulator then

please only submit entries in assembler

Submitted

Although it's not the rule, I think it should be included in the rules in future GBJams, at least the 8x8 grid. It would be a way to look more like a GB, and fun to challenge.

"Sprites use one of two shared palettes. The palette which is used is determined on a per-sprite basis. Yes, they have 3 colours each."

Didn't know that one! That's p interesting.

[img][/img]

so you could have 2 of these 4 combinations and that's for the entire game? Dang.

You aren't limited to that for the whole entire game - the palettes can be changed at pretty much any point. But there are two of them, they have 3 colours each, and they are sourced from the only 4 colours you'll be using for the entire game.

With that said, there are games which put one sprite on top of another and achieve all 4 colours. So if you're not spamming sprites you can probably get away with 4+transp.

(1 edit)

We are here for fun and personal challenge. We shouldn't turn this into a homework or thesis.

The main point of any game jam should be to finish a game even if it is very small, noob-ish or lacking (almost all) features, but definitely not to get frustrated and walk away with nothing.

what if homework is my idea of a fun and personal challenge

Submitted

then you do it with your extra rules if you find it fun, jams are just to inspire people to do something, in this case, gameboy-like games, not actual games to be run on an actual gameboy

So... this would be a no-no? XD

Pretty much.

But what's stopping you from doing a top-down 2D view of that?

Top-down it looks completely incomprehensible. Besides, it was just a test to see how easy it would be to implement a dithering fragment shader. I actually have no idea what I'm going to do for this jam, yet.

Looking around, it seems it was pretty common to have sprites that weren't 8x8... in the Pokemon screenshot above, the Pikachu and the Eevee are probably bigger than even 16x16. If bending the rules was acceptable then, why bother with having a grid now?

(1 edit)

Because if they broke them, it would no longer work on the gameboy.

The answer is that they didn't break them. They most likely used several 8x8 or 8x16 sprites together (8x16 sprite mode involves using two tiles to form your sprites and is a hardware feature).

You'll probably never see an actual sprite wider than 80 pixels on an actual GB, and if you do somehow see one of that width, either they're actually putting it onto the scrollable "background", or they have left absolutely no breathing room to handle sprites on either side, OR they're flickering through the sprite objects.

okay, then I'll bend the rules of GBJam harder than anyone ever has, just wait for my entry!

VR?! :)

(1 edit)

Well VR wouldn't really push any rule since you'd just be looking at the same game through your visor. You could take any entry really and throw VR at it, although it could be cool with a 3D game like I'm doing. I'm too cheap to have any vr accessory anyway :)

Anyway, I was talking more about pushing the 4 colors limitation to its limit. Since it's 4 colors at any given time and not 4 colors max for the whole game, you can expect copious amounts of palette swapping. Like literally swapping the palette every frame to crossfade between different palettes, change brightness, fade in/fade out, oscillating, taking certain colors and flickering them with another color every other frame so the brain fills in the gap and creates the illusion of more than 4 colors, etc. A bunch of crazy stuff like that. I've already got some of that implemented too and it's awesome.

It's almost poetic really, developers back in the day tried to push the limitations imposed by their hardware, and now we're pushing artificial limitations imposed for fun.

Yeah I think it's best to do as you please really. Not being limited by the other GB limitations is the beauty of this jam.

8x8 grid, what does it mean? is it 8x8 px squares to use in the art?.... Aaahhh time is ticking and i dont even know how to try to make the art

On the actual hardware, everything is made up of 8x8-pixel tiles. However, any multiple of 8 will work just fine on the real hardware as you can make them out of several 8x8 tiles. 16x16 is a good size to work with.

just ignore the whole 8x8 thing... the rest of us do not care.

Submitted

I have a question: did the original Game Boy allow to have transparency in tiles? I mean, having a tile using all 4 palette colors plus transparency (for example to make a platform slope).

This is discussed at least twice above. You get exactly four colours total. Basically sprites can be drawn with transparency, background tiles cannot.

What about tile priority? When a sprite is behind a tile, the background color will be transparent, so the sprite is seen through one of the colors in the tile.

great point Mypka_Max, just three years late :p