Last week end I finally started to work on porting Doom on the Playdate.
This is a very early result, just to run the game, but that was the hardest part for me. Dealing with makefiles and compiler is really not my cup of tea so having the game running means that now I can focus on the game control, presentation and optimization.
This is a gif from the simulator but I got the game running on the hardware too.
The most difficult part was to deal with the linker that was complaining about some missing references in libc. After spending two evenings chasing every libc functions that might be problematic, I found out that there is some magical linker option.
I've added the following line in CMakeLists.txt add_link_options(-specs=nano.specs -specs=nosys.specs)
Since the linker was complaining about the symbol end missing, I've added it to the link_map.ld in the playdate SDK
But I have to say that this is possible mostly because the Doom engine is extremely well done and organized and can be easily ported. It is not a mystery why this is the game that is always ported everywhere.
Something I forgot to mention is that I used STM32Doom for the port which itself in based on chocolate doom. I will share the source when I am a bit further and after cleaning some code (If anyone want to source already, feel free to DM me).
For anyone interested, I also recommend the book from Fabien Sanglard which analyze the source code. That was the book that pick my interest in porting the game. https://fabiensanglard.net/gebbdoom/index.html
I didn't know that book existed . Although I never attempted porting, I dove into the source a few times to get inspiration for various clones and such. This makes my week!
What next steps are you planning, now that you got it up and running?
I was not able to work on the port so much this week. This is still a gif of the rolling demo and this is not playable yet.
This is still pretty rough. I tried to add controls but now the game crashes in the simulator when I try to launch the proper game. I also have a new crash on device, a totally different one. It will be (not) fun to track them down.
At least the rendering is a bit better. I use a dithering map texture which indicate which part of the screen is blue noise, ordered of just threshold. On the long term the key will be to add contrast to make some element like enemies pop more.
But now I went back to the blue noise rabbit hole and started to experiment generating my own blue noise textures. That will be interesting to improve the picture quality (and I have an idea that might force me to go back to my video experiments)
I don't want to throw extra work on your plate, but this made me think about a post about dithering in Return of the Obra Dinn, and how the dither pattern was rotated with the camera. Since you're working with Doom's source directly, I would imagine this means you have easy access to the camera rotation angle, yes? If so, I wonder how easy it would be to scroll the blue noise texture correspondingly, and if it would make the scene look any better or worse?
So if you don't go on the discord you might not have seen that Poom is kind of playable. I say kind of because I still have a lot of random crashes when navigating the menus. I am waiting to be able to debug on the simulator figure out what is the issue.
And because of popular demand I've added using the crank to use the Gatling.
We also had a discussion about Chex Quest and I don't think my code can support it so I am considering switch fully to Doom Chocolate. That would be an opportunity to clean up the code I did.
The early results are encouraging but there is still so much to do.
A couple friends of mine who don't know anything about playdate or that I'm in the preview, individually shared your update tweet with me saying how cool it is and how the device is so unique and looks fun.
This is not my specialty so I didn't even look at it yet. Especially since this seem to have been the least portable part of the original doom. But I will come to that [art eventually.
