Rich Talbot-Watkins wrote:You're braver than I am. There's a lot of data to try and fit in there!
Have you seen Prince of Persia on the Amstrad CPC?
I would recommend going for MODE 2 resolution graphics so you can make use of the extra colours. The animation is already so detailed that the lower resolution is hidden by the intricate movement. Looking forward, I'd even say it would be a superb candidate for creating graphics in 16 colours (resorting to the closest RGB colour on standard hardware) which could then make the most of RobC's Palettemate in the future! I assume all the CPC graphics are available somewhere?
I must admit I haven't checked out the CPC version so not aware if the gfx are already available. I will take a deeper look at this though as it is nice & colourful. Choosing which mode is a big decision, so would appreciate your thoughts.
I have been working from the original Apple II source on GitHub and my intention was to try and port this as directly and cleanly as possible to preserve the original gameplay. Given that it is all in 6502 and very well structured for the era (29 discrete code modules, all reasonably well documented and with a clean jump-table interface between each one) in theory it should be "relatively" easy to insert a set of BBC plot routines to replace the Apple II hires functions. Squeezing it all into RAM is a different matter, that we'll come to.
The Apple II screen is 280x192 pixels in hi-res mode which has 6 "artefact" colours in a weird 7 pixels per byte format. You can only have 4 colours per byte (2 are always black & white) and only change colour every 2 pixels. I wrote a small tool to extract the sprites from the original source files so I can convert these to something convenient (see example png attached.) Because of the Apple II hi-res limitations, all the sprites are 4 colours maximum, so MODE 1 would seem to be the ideal target to get a nice clean hi-res Beeb look.
However from a memory POV this is tough. Apple II has 2x 8k screens for double buffering. An equivalent 280x192 MODE 1 screen would be 70x192x2 = 26.25k so we've already lost 10.25k. The Apple II version uses up the entire 128k of RAM, which is configured in 2x 64kb contiguous banks. Even on a Master it is hard to piece together that much memory and will require a great deal of bank switching.
I thought about MODE 5 potentially, since colours only change every 2 pixels giving an apparent horizontal resolution of 140, as this would halve the memory requirements. Yet because of the weird way the Apple hi-res screen works you can see individual colour pixels, so not sure it would look as good. It also complicates the plot routines as each background piece is 28 pixels wide, which is nicely divisible as 7x MODE 1 bytes but in MODE 5 they would be 14 pixels wide which is more awkward.
I hadn't really thought about MODE 2, I would need to get hold of the CPC sprite data and see what I could make of it. It would introduce the added complication that all x coordinates in the game are 0-279.
After extracting the Apple II sprites, I ran the numbers and turning the 7 pixels per byte format into 2bpp MODE 1 would bloat the data by 50-66% depending on the sprite set. This blows out the memory requirements before we even start. The extra kicker is that the POP sprites can all be displayed on any pixel alignment, but there's no way we can store 4x copies of the MODE 1 sprites. POP handles this internally by having lookup tables to rotate the Apple II sprite data (since it is effectively just 1-bpp.)
I decided my next step was to write a simple (albeit slow) sprite plot routine that draws directly from the Apple II data as a test (attached in previous post.) This way I keep the same memory overhead and drawing functions but "just" replace the Apple II hi-res module to plot the data to the Beeb screen.
During gameplay POP requires ~30k for the player sprites, ~13.5k background tiles, ~6k for enemy sprites on each level ~= 49.5k which will comfortably fit in Master swram. More difficult is the approximate 48k of game code (at least according to the POP technical documentation.) I reckon I can piece together ~30k from various (non-contiguous) addresses around the Master but that doesn't include the additional buffers required etc.
So yeah, a challenge for sure. The level plot routine is well documented, I figured if I could get this up & running to display each screen from each level that would be a good next step. If I can then get the sprite frame animation code going I would have enough to spur me on to come up with a cunning solution to the memory issues. Maybe..!