πŸ€‘ Indie game storeπŸ™Œ Free gamesπŸ˜‚ Fun games😨 Horror games
πŸ‘· Game development🎨 AssetsπŸ“š Comics
πŸŽ‰ Sales🎁 Bundles


A member registered 3 years ago · View creator page β†’


Recent community posts

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.

Posted in Free websites

There's this little-known site called itch.io, have you tried that? ;)

GBs did have a link cable so 2-player at the very least is plausible.

Posted in LURK - Progress

Looking good. Looking really forward to playing this actually.

I'd be tempted to port this to the real thing after the jam.

TIP: Render to a 160x144 canvas, and then draw that to your main screen.

Posted in Sizing

Technically the rules let you completely ignore the restrictions, but they're really not hard to follow. It's just that there's a particular restriction which is a pain to actually enforce (10 8-wide sprites per scanline), and thus if you're aiming for authenticity and not using the actual hardware you should really only use it as a reminder to not spam sprites and not make your sprites too wide. (If you want it strictly enforced, it's better to just use "actual hardware" and by that I mean you'll probably use an emulator.)

On real hardware it's fairly typical to use 8x16-sprite mode and combine a bunch of sprite objects together. I'd imagine that Pokemon pairs sprites together, one next to another, to get 16x16 sprites.

The Sonic games for the Sega Master System, which has similar hardware, combine 4 of these to form a 16x32 player sprite. (The Mega Drive games most likely take advantage of the fact that you can set the sprite size to 16x32. I've not confirmed that this is what the games do, but I know that the hardware lets you do this.)

Remember that sprites have transparent pixels, and thus can have an effective size smaller than what you would actually use.

If you aren't using real hardware you can just straight up use e.g. a 24x12 sprite - on real hw you would pad the height out to 16 by using transparent pixels and it would end up being 3 8x16 sprites.

32x16 is fine, although because of the sprites-per-scanline limit tall is better than wide.

For the main tilemap any multiple of 8 for width and height will do, although if you don't use a power of 2 it'll be a bit weird. But still perfectly doable. But still weird. Either way, you'll want these aligned to an 8x8 grid if you're aiming for authenticity. Using 16x16 tiles tend to work well.

As for fonts, just use an 8-wide fixed width font, and when spanning several lines, step down by 8 or 16 pixels each time (it depends on the font height).

Best part about this is if you add CGB support you don't have to bother with the second VRAM bank, you can just tweak the tints to your liking. However, you no longer have the BGP/OBP0/OBP1 registers so you'll have to do everything through the main CGB palette (in other words, fades will be different), and you'll use a different attribute bit to select the sprite palette.

If you do it w/o outlines, make the road darker.

As it turns out, I decided to bite the bullet and go with real hardware, and by real hardware I mean an emulator but *theoretically* it would work on the real hardware.

No pixel alignment problems here!

Current situation: If I'm going to have more than a 16x16-tile level I'm going to need to get scrolling working. I'm already banging 64 bytes into VRAM each frame for the player sprite, I have just enough room in vblank (which is 10 scanlines) for another 64 if necessary but I think I can safely fit 32 in if I precalc the tilemap data outside of vblank (that is, 144 scanlines).

On the GB you cannot touch VRAM during active video. Technically I could bang bytes in during hblank but that complicates things and seriously eats into the outside-of-vblank period. The vblank period is the longest continuous length of time in a frame (well, technically between two frames) where you can write to VRAM, and that's why the timing there is so precious. You've got 4560 cycles of vblank, which realistically (assuming an average of 8 cycles per instruction) is about 570 instructions executed.

Bump. Can we get this stickied?

> Bouncing on collision

What are you using to make this? My tip here would be to push back just after you've applied movement within the same tick.

Also, you've got a few issues with your camera - I'm seeing some rather nasty subpixel artifacting. If it's Game Maker you'll want to manually set the camera left/top - try something like view_left=floor((x/4)-((160-60)/2)); if you are using, say, 4x upscaling.

What's the zoom level here? With 8x8 tiles you'd fit 20 tiles wide, and w/o HUD 18 tiles high. If what you have is roughly the zoom level you want, consider going for 16x16 tiles (on real HW it'd be made up of 4 8x8 tiles).

By the way, join us on Discord, I or someone else could possibly help you out a bit with your tiles. I recommend using more colours per tile here.

I'd be tempted to port that to actual hardware. It'd require using a mix of sprites and BG tiles for the pieces, but it can definitely be done.

Then use smaller graphics. 16x16 sprites should be fine. It gives you plenty of detail to work with.

Oh yes, I love that game. Would be awesome seeing a top-down version of it.

And yeah that map looks about right.

(Edited 1 time)

Here, have a template: https://gist.github.com/iamgreaser/9cccd24dd4519a0ae95240d8b8eeb252

I dare you to use this really similar one instead:


Personally I just use WLA-DX for my GB stuff.

For me I tend to start with rough lines and then fine-tune them at the pixel level.

As I'm not much of a mock-up sort of person I tend to not bother with testing the size, I just start making a tilemap straight away. Having said that, 16x16 is a nice tile size to use for this.

As for 5" phone vs 24" monitor, render your game to a 160x144 canvas/image/FBO/whatever and upscale that.

(Edited 2 times)

To be blunt this should be a rule. It's not a huge challenge, but it's enough of a limit that it can force you to get creative.

Until then, feel free to make Typing Of The Dead.

It really boils down to "git gud". With that said I'm not sure what your problem is.

Mind posting a screenshot?

Gnarly. I like this.

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.

(Edited 1 time)

Reusing the engine should be fine, but you'll probably want to make a new game out of it.

If you'd rather keep to the same premise and gameplay, I guess you could make it a sequel?

Everything mentioned so far is probably fine.

I use my own tool which you can get here (if you want a tutorial I can write one for you): https://fanzyflani.itch.io/pixra

It only outputs 256-colour tga files, so you'll probably want to convert them for use in your engine.

I also use GIMP from time to time. It can be used to turn those tga files into other formats.

But basically, if anything looks bad, make it look less bad, and repeat this process until it's good enough or you've had enough. Tutorials will help you make things look less bad, especially that one neptuneisadrift linked.

(Edited 1 time)

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.

Pretty much.

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

I look forward to seeing your walking simulator then

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.

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.

Totally going to abuse that. Thanks for the idea.

(Edited 1 time)

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.

(Edited 1 time)

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.

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.

The rules say "use 4 colours only".

I recommend that you find a nice tint and go with a light-to-dark palette.

No it doesn't.

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.

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.

(Edited 1 time)

Concerned about having "only" 10 days?

For comparison, the main Ludum Dare category only gives you 2.

10 is plenty, especially if you're using a game making tool.

Oh yeah, as for format, if you can get it working on the web on a not-phone it should be fine, if you only release an apk you are seriously limiting your audience.

Created a new topic The actual GB limits

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.
  • 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.
    • 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.