Most of the game runs on an external Cortex-M0 chip in the cart. GBC is incapable of this much computation per frame. This solution is elegant and not unlike what some of the fancier NES games did. Overall, very well done.
Wolfenstein 3D for Gameboy Color on custom cartridge (2016)
31–39 of 39 posts
Re: Wolfenstein 3D for Gameboy Color on custom cartridge (2016)
#32Earlier quoted context omitted.
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.
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 til…
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
Re: Wolfenstein 3D for Gameboy Color on custom cartridge (2016)
#33Re: Wolfenstein 3D for Gameboy Color on custom cartridge (2016)
#34Re: Wolfenstein 3D for Gameboy Color on custom cartridge (2016)
#35Earlier quoted context omitted.
I had a similar experience with Quake when it first came out... it felt more like a slideshow on my AMD 5x86 @133mhz w/ 64mb ram and large cache module. My computer was entirely lopsided for games, I got the AMD a few months before a crazy deal on the ram and cache module for it, so I maxed it out. I will say it tore through business apps with OS/2 and later NT4 ran like a champ on that little box. I couldn't afford…
Well you could have played Duke Nukem 3D which has semi-3D environments based on real life places.
Re: Wolfenstein 3D for Gameboy Color on custom cartridge (2016)
#36Re: Wolfenstein 3D for Gameboy Color on custom cartridge (2016)
#37Earlier quoted context omitted.
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 til…
> 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
Re: Wolfenstein 3D for Gameboy Color on custom cartridge (2016)
#38Re: Wolfenstein 3D for Gameboy Color on custom cartridge (2016)
#39Most of the game runs on an external Cortex-M0 chip in the cart. GBC is incapable of this much computation per frame. This solution is elegant and not unlike what some of the fancier NES games did. Overall, very well done.
Some SNES games offloaded varying degrees of computation to on-cart chips, but I don't believe any NES games did. There was a Hellraiser game in development for the NES that was supposed to ship as a Z80-powered "super cartridge" but it was canceled.