itch.io

OK, got basic world rendering working. Using translucency to test basic occlusion culling but it will end up opaque eventually. Rendering's quite bad right now, and I honestly blame the sheer amount of divisions I'm doing in the CPU, so I should probably offload those to the GTE. That and I'm still not using DMA, and I should use it, but that can wait until tomorrow.

Also, adjusting the delays used for port I/O to the GPU makes me get back to 50fps for the most part, so actually, it's probably not the divisions.

Here's the basic idea of the renderer. I've got a 3D voxel world, and I do a breadth-first floodfill from the camera, taking care to ensure that I don't double-count a cell. I build an ordered list of cell positions and then I walk them back to front. The PS1 has no Z buffer so you basically have to do painter's algorithm to do things, and while it *does* provide surprisingly good facilities for handling this (it's basically got hardware radix sort support), I'm not using them here.

The floodfill is somewhat expensive right now so I only calculate it whenever the cell the camera's in changes, which happens a lot so I'm going to have to find a good solution for that.

Oh, as far as RAM usage goes, I'm using about 10% of 2MB right now, and that includes the music I've got in there as a placeholder. For VRAM I've got no textures so I'm only using two 320x200 video buffers in the 1024x512 space I've got. For sound RAM there should be plenty of space and the samples for the music fit just fine so I'm not concerned about that.

Anyway, we should be getting close to gameplay going in. I think tomorrow's going to be DMA and world collisions.

Doing a PS1 game. Started yesterday, got the camera working today. Haven't moved to using DMA for graphics yet, and I should probably get some quads in at some stage, and did I mention I'm not using the GTE (math coprocessor) yet?

I've got some game design stuff in mind and have been brainstorming it on my laptop on the train and it's got the potential to be a lot of fun. The concept is that of a parkour platformer where whenever you go through a window, gravity inverts and you end up in a dual of the level - if you've ever played a Flash game called Shift, it's a similar idea to that.

AFAIK nothing so far :( Want to have a go?

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.

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.

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.

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.

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

And yeah that map looks about right.

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

I dare you to use this really similar one instead:

Nice.

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.

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.

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.

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.

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.

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.

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.