[whizzter]

Probably yes, the NES is "easier" in this regard since char-rom is read from cart (so a cart only needs to provide the bits in correct order), the GB(C)'s have video-ram that contains all parts so you need to transfer it over. Don't exactly remember but iirc classic GB was a tad too slow for this, but GBC has a DMA that might be fast enough. (I've developed on classic GB mostly so don't know the characteristics of GBC mode).

[bbbbbr]

I don't think it's widely known (only found and documented somewhat recently) that there is a way for cartridges to directly drive the Game Boy Color LCD, bypassing the CPU/PPU (PGB Modes). At that point though it becomes even less of a Game Boy game than what the Wolfenstein and other carts are doing.

https://gbdev.gg8.se/wiki/articles/Gameboy_and_Gameboy_Color...

Also related: "There oughta be GTA5 for the Game Boy" about a Wifi cartridge that can stream video (gameplay, etc) directly to the GB screen. https://there.oughta.be/gta5-for-the-game-boy

[anthk]

GBC had GTA2 port which wasn't half bad but the Driver port was smoother and with better mechanics.

[msk-lywenn]

I played a bit with original gameboy too. I was very surprised when, iirc, the cpu is not even fast enough to clear the screen in one vertical blank, or even in one frame! It takes like three to fully clear the map.

[whizzter]

Yeah, you really need to structure your code around working with the tilemap system.

I did a small racing prototype with both vertical and horizontal scrolling and segmented my updates to 4x4 blocks of tiles per-frame (160x144 resolution so 20x18 of 32x32 tiles is visible at any point in time, so stippled updating 4x4 blocks outside of view is within the budget together with updating some of the tiles each frame)

[fallat]

This is false. You can do it in 1. It just involves mid-frame tile switching IIRC or using characters / sprites to fill in the rest.

[ant6n]

You need to do mid-frame tile updates just to show a full bitmap frame. There’s 360 8x8 tiles on the screen, but the tile indices are 8 bit (you can only reference 256 tiles). You can store only 384 tiles in VRAM - a bit more than a full screen. So the mid-screen update is to go from one tile dictionary to the other, so you can access 360 tiles in total.

You can update 1 tile per scan line (during hblank), so 154 tiles per frame (including 10 vblank scanlines). So you need 2.5 frames to replace all tiles.

If you are really smart about updates, you can “race the beam”, basically start updating tiles just as the frame starts rendering, just behind the active scan line. Then you can update maybe 280 tiles before the active scan line of the next frame catches up with you.

[fallat]

> You need to do mid-frame tile updates just to show a full bitmap frame.

Right!

> So the mid-screen update is to go from one tile dictionary to the other

Yes

I guess I'm missing something here, but I remember doing this myself like 15 years ago

[whizzter]

Perhaps it was about full-screen-bitmap(hblank tile-address/mapping switching) rather than full-screen-bitmap-animation?