and cut everything needed to make it compile on SDCC, for a megarom. So the game logic actually compiles nicely and fits well in 8k segments for an ASCII8 or konami-scc mapper. I left out disk access, and with this also audio, and graphics.
What did kill me is the enormous amount of magic numbers in the code. It seems very hard to me to make it consistent, so probably a re-implementation is actually easier.
About the graphics, I was aiming at a resolution of 240 horizontal pixels. PoP screens are divided in 10x3 cells (albeit the perspective allows you to see one more cell in some circumstances. However, if you follow the PoP technical documentation, all gameplay information should be calculated in a resolution of 140 pixels (as of the original Apple II), and then mapped to the target visual representation. Source:
PoP technical guide: https://www.jordanmechner.com/downloads/popsource.pdf
The aim for 240 pixels is easy: each cell will be 3 tiles wide, so that all tiles will have the same color clash effect.
As said, the amount of magic numbers was what killed me, but I aimed to get an identical clone to the PC version.
@salutte I am indeed using the same starting point: SDLPoP.
I don't plan to use the original code by any means (maybe just the logic related to reading the map data) because it is really really messy. I assume this is because it is based on a disassembly from the MS-DOS version and important parts of the structure were lost in translation.
