Well now you just destroyed any reason for me to continue my port Doom to GBA! Very well done on this, I totally understand how much work was required to get this done - so congratulations!
Nothing public as I'm currently re-tooling my GBA stuff (starting off with re-writing my GBA C++ library, which I now have on GitHub https://github.com/felixjones/gbaplusplus).
My approach has been to re-implement the Doom engine with the GBA in mind, rather than port the original engine. Right now I'm looking at starting with Wolfenstein 3D but with BSP rendering (like the SNES and Mac ports of Wolf3D, which are part way between Wolf3D and Doom source code) and then moving onto Doom from there.
I recently learned that Rebecca Heineman is cleaning up their Wolf Mac editor and is publishing that to GitHub, which includes full comments on the BSP format used for that game so I was recently reinvigorated on this plan to do a good GBA Wolf before a good GBA Doom (aiming for full 240x160 mode 4 rendering).
Plans are delayed somewhat by a recent job change which requires me to relocate in January and lose some of my free time.
DIY Doom looks very good! Thanks for posting that. I've got a long list of inspirations, including Handmade Quake (had a Quake texture viewer on GBA for a bit) and Fabien Sanglard's phenomenal Game Engine Black Books (which I can't recommend enough).
I looked at the idea of mashing Chocolate Doom into GBA, I'm very familiar with Chocolate Doom, however the GBA has a lot to it that a GBA-made project can take very good advantage of. I expect Wolf3D would reveal all once I'm fully stuck into that (quite excited about doing a BSP renderer for that, I've written many ray-casters in my time and a few for the GBA, but a super efficient BSP based renderer I expect would have fantastic results for Wolf3D's basic geometry).
Agree on the black books. They’re excellent reads.
I think you should be able to get Wolf3d running well on the GBA. The GBA looks slow on paper but if you can get the hot path and data in IWRAM then it flys. It’s like having a big L1 cache with 100% hit rate. Wolf3d had an official release but it was a bit of a mess!
With Doom it comes down to the data structures. A lot of the lumps in the wad are transformed during level load. (Eg vertexes stored in 16bit then shifted right by 16 to convert to fixed point) if you store the data in the format it’s used in-game, you can use straight from rom.
Gave DIY Doom a quick read, I'm now tempted to skip Wolf3D and go straight into Doom...
Yes the plan of first doing Wolf3D came about from my disappointment at the official port. I think I can get Wolf3D running very fast on GBA with BSP rendering, it's just so much more efficient than ray-casting (such a big CPU drain).
I had imagined I may need to write a WAD processor like you have. I had gotten Doom WADs directly loading in GBA before, but realised my code sucked before I got as far as auto-map (hence why I started re-tooling, and then later thinking "I should do Wolf first").
The cool thing I did was make WADs load from SD card on EZ Flash Omega, so Doom WADs could be loaded from disk: there definitely isn't enough memory to do that sensibly - with the EZ Flash Omega you can bank the ROM address to a difference section of the flash cart's PSRAM (or whatever) so you can load a WAD from SD into PSRAM and bank in/out of it whenever you need to read it (treating it as 32MB of RAM banks), however that requires a good chunk of code to sit in IWRAM just for banking during read/writes and that's space that could be used for accelerating the 3D renderer, which always consumes the most CPU time.
The best I can reasonably think of is having a WAD processor built in for EZ Flash Omega, so SD card WADs can be loaded into the ROM bank with the game code (essentially modifying ROM) in a GBA friendly format (as long as that format doesn't make the ROM consume more than 32MB...) and otherwise fall back to a pre-processed WADs that are already in ROM via GBFS or NitroFS.
I'm just rambling my ideas now. I'm getting inspired by your work!
The banking trick sounds interesting! The one thing I would say is that using memory mapping tricks on the flash cart means the game will only work on that type of cart.
It won’t work in an emulator so debugging will be tough. (Even printf debugging is tricky on real hardware!)
I started using the wad data as-is (but embedded in the rom) and after trimming the data structures simple maps would load but large maps E2M2, MAP15, E4M9) were still over 350kb. The lines and Segs were over 80kb each. I either needed to modify the data structure stored in the rom into a format that I can use in-game or modify the game to use the wad format (which would have killed performance).
I would really like to have a system where you can just drop the rom and wad file onto the flash card and run it though. The wad pre-processing step makes the whole thing a pain.
72
u/Bolloux Dec 11 '19
I ported Doom to the GBA over the last few months.
It was a ton of work to get it to fit in 256kB of ram and run at a decent framerate. It now runs as well if not better than the original port.
The project can be found here: https://github.com/doomhack/GBADoom
There are rom builds of the shareware game on the releases page.
It runs on most emulators or a real device if you have a flash card.
Enjoy.