AFAIK nothing so far :( Want to have a go?
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.
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.