Starting a Prince of Persia port...

Got a programming project in mind? Tell everyone about it!
User avatar
kieranhj
Posts: 374
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Starting a Prince of Persia port...

Postby kieranhj » Mon May 15, 2017 10:47 am

Hello all,

At ABUG over the weekend I declared my intentions to attempt a port of Prince of Persia to the BBC Master. I've been doing plenty of research on the source thus far and have a very (very) early prototype of a MODE 1 plot routine that works directly using the Apple II sprite data. It's going to be a long and slow journey (not least because I am very busy with work at the moment) but I will post my progress here for general support, encouragement and hopefully some help along the way.

First prototype attached. It is designed for the Master but should load on any machine with 1x 16K swram + page at E00. Eventually this will be Master only because of the 128K memory requirements.

Enjoy!
Attachments
pop-beeb_001.zip
POP proto 001 (CHTAB1 sprites)
(6.28 KiB) Downloaded 22 times

User avatar
Rich Talbot-Watkins
Posts: 943
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Starting a Prince of Persia port...

Postby Rich Talbot-Watkins » Mon May 15, 2017 11:49 am

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?

User avatar
trixster
Posts: 441
Joined: Wed May 06, 2015 11:45 am
Location: York

Re: Starting a Prince of Persia port...

Postby trixster » Mon May 15, 2017 1:41 pm

Would it be worth chatting to the c64 chaps on lemon64 forum? They might be able to give some advice.
A3020 | A3000 | BBC B + 128K RAM/ROM + 20K Shadow + RPi2 CoPro | A420/1
BBC Master Turbo + Data Centre | Atom | A1200 + 80Mhz 060 | A500 | Jaguar
A4000/040 + 66Mhz 060 | Atari Falcon | Saturn | PS1 | SNES | CPC6128 | C64

User avatar
oss003
Posts: 2380
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: Starting a Prince of Persia port...

Postby oss003 » Mon May 15, 2017 2:21 pm

Wow ...... this is a real challenge ..... :)

Greetings
Kees

Prime
Posts: 2274
Joined: Sun May 31, 2009 11:52 pm

Re: Starting a Prince of Persia port...

Postby Prime » Mon May 15, 2017 3:06 pm

oss003 wrote:Wow ...... this is a real challenge ..... :)

Does that mean we'll see an Atom version at some point....... :) :) :)

Cheers.

Phill.

User avatar
oss003
Posts: 2380
Joined: Tue Jul 14, 2009 11:57 am
Location: Netherlands
Contact:

Re: Starting a Prince of Persia port...

Postby oss003 » Mon May 15, 2017 3:42 pm

Prime wrote:
oss003 wrote:Wow ...... this is a real challenge ..... :)

Does that mean we'll see an Atom version at some point....... :) :) :)

:shock: That's even a bigger challenge ....... first have to finish Thrust ...... :lol:

Greetings
Kees

User avatar
Dave Footitt
Posts: 770
Joined: Thu Jun 22, 2006 9:31 am
Location: Abandoned Uranium Workings

Re: Starting a Prince of Persia port...

Postby Dave Footitt » Mon May 15, 2017 4:23 pm

Best of luck =D>

Good to chat with you this weekend too!

User avatar
kieranhj
Posts: 374
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: Starting a Prince of Persia port...

Postby kieranhj » Tue May 16, 2017 11:50 am

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..!
Attachments
IMG.CHTAB1.bin.png
CHTAB1 sprites extracted as PNG

User avatar
Rich Talbot-Watkins
Posts: 943
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Starting a Prince of Persia port...

Postby Rich Talbot-Watkins » Tue May 16, 2017 12:39 pm

My initial instinct is always to choose colours over resolution, if it's a choice between MODE 1 and MODE 2. Isn't there some funny thing anyway where the Apple II essentially doubles up pixels when displaying different colours?

If you were to go with a 70 column wide MODE 2 * 24 lines, that's a 13k screen which is probably on the right side of acceptable. Although double buffering would be nice, I feel like it's not necessary, as for the most part there's only one moving sprite, and occasionally two.

One thing to consider would be a routine like Exile's which unpacks 2bpp graphics to MODE 2 with specified colours, and can optionally flip them and position them at a one pixel offset. That would help with the memory requirements. I'm not sure how PoP performs occlusion, but (not considering trying to make full use of all 16 colours via Palettemate for the moment) the top bit of the screen bytes (i.e. colours 8-15) could be used to specify tiles in the foreground.

One 'advantage' of reducing the horizontal resolution to 140 would be that at least it fits in a single byte - could potentially simplify some of the code, unless the full horizontal resolution is still required. Going back to the weird Apple colour handling, I wonder if it basically treats it as if it were a 140 wide screen anyway? From my vague understanding of the hardware, the colour depends on whether the pixel is at an odd or even position, so I assume a sprite would alternate between different colours if it moved pixel-at-a-time.

I hadn't realised that the CPC version was actually an official release, so I guess the graphics / code aren't in the public domain, never mind that the CPC's a Z80 beast anyway.

RobC
Posts: 1419
Joined: Sat Sep 01, 2007 9:41 pm

Re: Starting a Prince of Persia port...

Postby RobC » Tue May 16, 2017 4:18 pm

Really excited that this is happening - I'd looked at it briefly but decided that I didn't have the skills.

Any version would be great but something in mode 2 using my VideoNuLA would be fantastic (but I'm obviously biased :D)

In terms of memory, I wouldn't be put off even if it needs SWRAM and ROM. If it's only conveniently playable in an emulator, so be it.

Also, if you haven't seen it before, there's a routine called GFX Ripper at Retrospec: http://retrospec.sgn.net/game/gfxrip. It claims to be able to rip Amstrad graphics from a snapshot (although I've only been able to get it to work for other machines).

User avatar
kieranhj
Posts: 374
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: Starting a Prince of Persia port...

Postby kieranhj » Wed May 17, 2017 1:05 pm

RobC wrote:Really excited that this is happening - I'd looked at it briefly but decided that I didn't have the skills.

Any version would be great but something in mode 2 using my VideoNuLA would be fantastic (but I'm obviously biased :D)

In terms of memory, I wouldn't be put off even if it needs SWRAM and ROM. If it's only conveniently playable in an emulator, so be it.

Also, if you haven't seen it before, there's a routine called GFX Ripper at Retrospec: http://retrospec.sgn.net/game/gfxrip. It claims to be able to rip Amstrad graphics from a snapshot (although I've only been able to get it to work for other machines).

Thanks for the link, I've not heard of that before.

I presume your NuLA can program the palette in MODE 1 as well? So even if it was four colours we could at least get an accurate Apple II blue & orange? :D

I am currently combing the Apple II source to detail the existing memory map (and learning about the Apple II banking system in the process) to figure out where all this might be crammed on the Beeb. It will absolutely need a minimum of 64K swram which is why I was most likely to target Master only. I guess I could make it 128K swram only but that would be pretty restrictive!

On to Rich's points. I understand the coordinate system for sprites is 0-255 in x with 140 pixels representing the width of the screen (58 pixels are off screen left & right) so this could lend some possibility to using MODE 2/5. The background tiles are handled differently and would definitely be inconvenient at 14 pixels (at least in MODE 5.)

The POP sprite routine already handles flipping, masking and clipping of the Apple II sprite data. There are 10x3 background "pieces" on the screen, each piece is drawn using painters algorithm (back to front) to get the correct effect, with various layers employed to allow the sprites to be behind pillars etc.

Original Apple II POP runs at ~11 fps apparently so thankfully doesn't rely on high frame rate, it does use double-buffering however. Individual pieces can be flagged for redraw as sprites move so plotting is quite expensive. As you say, it might be possible to do something "clever" to avoid this on a Beeb in MODE 2.

Finally, yes the Apple II hi-res screen is technically 280 b&w pixels with an effective resolution of 140 coloured pixels, but you can kinda see individual hi-res pixels. It's weird. See: https://en.wikipedia.org/wiki/Apple_II_graphics. However I do like the hi-res look and always hanker for MODE 1 games. I haven't committed myself either way yet as still in exploratory phase.

RobC
Posts: 1419
Joined: Sat Sep 01, 2007 9:41 pm

Re: Starting a Prince of Persia port...

Postby RobC » Wed May 17, 2017 2:16 pm

kieranhj wrote:I presume your NuLA can program the palette in MODE 1 as well? So even if it was four colours we could at least get an accurate Apple II blue & orange? :D

Yes - the colours in any mode (including mode 7) can be chosen from the 4096 colour palette. The big advantage in mode 2 is that you get 16 genuine colours rather than 8+8 flashing.

sbadger
Posts: 144
Joined: Mon Mar 25, 2013 1:12 pm
Location: Farnham, Surrey

Re: Starting a Prince of Persia port...

Postby sbadger » Wed May 17, 2017 6:36 pm

Just recieved Issue 3 of Eight Bit magazine about Amstrad CPC and saw PoP and thought must mention it, (and now just seen RichTWs post to the same)

<goad>the Amstrad's only got 64k ram and even some schoolboy coder managed...</>








:twisted:
A3020 | BBC B x2 | Master | RPi x3
A600 | C64 "breadbox"| C64 C | XB360 | GB | GBC | GBA | GBASP | DS | 3DS XL | 3DS XL new | MD | MS
Atari 7600 | PS1 | PS2 | PS3 | PS4 | SNES | GC | N64 | Wii | Wii U | Switch | Jamma Cab | Sony PVMx2

User avatar
kieranhj
Posts: 374
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: Starting a Prince of Persia port...

Postby kieranhj » Wed May 17, 2017 10:44 pm

sbadger wrote:Just recieved Issue 3 of Eight Bit magazine about Amstrad CPC and saw PoP and thought must mention it, (and now just seen RichTWs post to the same)

<goad>the Amstrad's only got 64k ram and even some schoolboy coder managed...</>

I know where you live, remember? :D

hexwab
Posts: 21
Joined: Wed Jul 08, 2015 8:27 pm

Re: Starting a Prince of Persia port...

Postby hexwab » Thu May 18, 2017 4:22 am

Looking at the CPC version, it's 160x200x4bpp, so an extra 20 pixels horizontally, plus a status line at the bottom. The graphics seem to be stretched from the Apple II version, as the screen layout is identical and yet it takes more horizontal pixels. Hence it's not quite half the resolution (4/7) of the Apple II. http://www.jordanmechner.com/downloads/popsource.pdf says "Since all the character movements throughout the program are specified according to the 140-wide coordinate system, we would like to keep the character's X-coordinate on a 140-wide screen for all the different conversions. The character's position could then be mapped to the actual screen width for that machine--320,512, 640, or whatever--at the time the character is drawn." suggesting the author was expecting conversions to use non-multiples of 280 horizontal pixels.

It runs on a 64K machine (appears not to require 128K) and I don't think it uses double buffering (based upon a memory dump from an emulator). Maybe the CPC is sufficiently faster than the Apple that it can draw everything in vblank? If the CPC can do it, the Beeb almost certainly can.

This may or may not help you make a decision, but data is good, right?

Me, I'm voting for MODE 1 with 320x192 stretched graphics. Sure, more colours are nice but the Beeb has terrible colours (modulo NuLA, but nobody has one of those). Unless you use fancy tricks to make use of the extra bit per pixel there seems no reason to use MODE 2 on a vanilla Beeb. Go for extra resolution any day.
Maybe you could steal the graphics from the CGA version, which is also 320x192x2bpp (with full resolution colour)? Attached is a CGA screenshot and Beeb conversion for playing around with the palette.

Image

Tom.
Attachments
princecga.zip
(1.8 KiB) Downloaded 6 times

User avatar
Elminster
Posts: 1101
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: Starting a Prince of Persia port...

Postby Elminster » Thu May 18, 2017 8:38 am

hexwab wrote:Me, I'm voting for MODE 1 with 320x192 stretched graphics. Sure, more colours are nice but the Beeb has terrible colours (modulo NuLA, but nobody has one of those). Unless you use fancy tricks to make use of the extra bit per pixel there seems no reason to use MODE 2 on a vanilla Beeb. Go for extra resolution any day.


Although a mode 2 RobC NULA version would be awesome for demoing at shows and would help shift lots of NULAs.

But I guess ideally a version open to people with a standard machine would be ideal.

Two version maybe? Bare bones version and awesome version (NULA, BeebSID/OPL, Pi Tube etc. :D )

User avatar
Rich Talbot-Watkins
Posts: 943
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Starting a Prince of Persia port...

Postby Rich Talbot-Watkins » Thu May 18, 2017 9:07 am

Anyone fancy doing a mock up using the Amstrad graphics as a starting point to see what it could look like in MODE 2 with the standard colours? I can imagine that the Beeb's garish palette doesn't lend itself well to this game...

Image
Hard to know what to change that grey floor for. I guess some kind of stippled combination.

It's surprising that they changed the graphics to span the entire screen (160 pixels) on the CPC, so each tile is 8 columns instead of 7. The CPC uses a 6845 CRTC so shrinking the screen is not only possible (like on the Beeb) but also helps to save a bit of memory. But maybe with the lower resolution, they were able to get better looking graphics that way.

I definitely don't think double buffering the entire screen would be necessary on the Beeb, but it might still be too slow to plot two sprites without flicker during VBlank, particularly if they needed to be unpacked from 2bpp, or mirrored/offset on the fly. I would probably take the approach of copying the bounding rectangle to a back buffer, plotting the sprite there, and then block copying it to screen during VBlank. Apparently it has 3 or 4 frames per update, so this is more than enough time to do this.

User avatar
kieranhj
Posts: 374
Joined: Sat Sep 19, 2015 10:11 pm
Location: Farnham, Surrey, UK

Re: Starting a Prince of Persia port...

Postby kieranhj » Thu May 18, 2017 9:56 am

Thanks for the thoughts & suggestions everyone! I'm sure John could make an awesome mock up of a MODE 2 version but that will be an even more crazy amount of work to redo all the graphics. Other ports have taken the PC CGA sprites as a source and converted these.

The original Apple II version runs at ~11Hz so if we can get the Beeb version running in 3 frames then we'll be ahead at 12.5Hz. :)

I've spent a couple of days combing the Apple II memory map, which I think looks roughly like this:

Code: Select all

main ram
-----
$0000 - ZP vars and locals at $e8
$0100 - Stack
$0200 - Apple II Input Buffer (Vars = total 17 bytes)
$0300 - Apple II Vectors (Small arrays and some vars = 48 + 9 = 56 bytes)
$0400 - $07FF = I/O devices?
$0800 - chtab3 (kid) - main (5985 = $1761 bytes)
$2000 - 3FFFF = hi-res page 1
$4000 - $5FFF = hi-res page 2
$6000 - chtab1 (kid) - main (9165 = $23cd bytes)
$8400 - chtab2 (kid) - main (9189 = $23e5 bytes)
$a800 - chtab5 (kid) - main (6134 = $17f6 bytes)
-----
$C000 - $CFFF = 4K I/O DEVICES
-----
$d000 - rw18 (something to do with disc loader)
$d000 - peelbuf1 (presume size = $600)
$d600 - peelbuf2 (presume size = $600)
$e000 - hrtables (YLO & YHI, SHIFT, CARRY, MIRROR etc. = 192*2 + 16*128 + 7*6 + 6 = 2288 bytes)
$ea00 - unpack.s module, includes gameeq.s, eq.s
$ee00 - hires.s module, includes hrparams.s
$f880 - master.s module, includes eq.s, gameeq.s
-----
2k system + 16k screens + 30k kid sprites (48k main mem) + 4k disc buffer + 12k rendering code & buffers (main l.c.) = 64k

auxmem
-----
$0000 - ZP vars and locals at $e8
$0100 - Stack
$0200 - Apple II Input Buffer?
$0300 - Apple II Vectors?
$0400 - grafix.s module, includes eq.s, gameeq.s, soundnames.s
$0e00 - tables in EQ.S (dense - $488 total)
$1290 - frameadv.s module, includes eq.s, gameeq.s, bgdata.s <- included after jump table
$2000 - topctrl.s, includes eq.s, gameeq.s, seqdata.s, movedata.s, soundnames.s
$2800 - framedef.s (animation frames) (1200 + 200 + 450 + 192 = 2042 bytes)
$3000 - seqtable.s (animation sequences)
$3a00 - ctrl.s, includes eq.s, gameeq.s, seqdata.s, soundnames.s, movedata.s
$4500 - coll.s, includes eq.s, gameeq.s, seqdata.s, soundnames.s, movedata.s
$4c00 - gamebg.s, includes eq.s, gameeq.s
$5400 - auto.s module, includes eq.s, gameeq.s, seqdata.s, soundnames.s, movedata.s
$5e00 - redbufs (redraw buffers) (60 bytes unused then 250 bytes = 310 bytes total)
$6000 - bgtab1 (max 9185 = $23e1 bytes)
$6000 - chtab6 (princess in cutscenes) (overlaid)
$8400 - bgtab2 (max 4593 = $11f1 bytes )
$9600 - chtab4 (guard) (max 5281 = $14a1 bytes; top = $ab00)
$9f00 - chtab7 (princess in cutscenes) (overlaid)
$ac00 - imlists (image lists) (200x4 + 100x4 + 20x5 + 46x8 + 46x11 + 20x12 + 32x5 = 2574 bytes = $a0e)
$b600 - mobtables
$b6f0 - savedgame
$b700 - blueprnt (blue print) - $900 size (runs up to $c000)
-----
$C000 - $CFFF = 4K I/O DEVICES
-----
$d000 - ctrlsubs.s, includes eq.s, gameeq.s, movedata.s, seqdata.s, soundnames.s
$d400 - msys (music system ii)
$d900 - specialk.s, includes eq.s, gameeq.s, soundnames.s, movedata.s
$dfd8 - version.s (text string = 28 bytes)
$e000 - subs.s, includes eq.s, gameeq.s, seqdata.s, movedata.s, soundnames.s
$ea00 - sound.s
$ee00 - mover.s includes eq.s, gameeq.s, seqdata.s, movedata.s, soundnames.s
$f900 - misc.s, includes eq.s, gameeq.s, seqdata.s, movedata.s, soundnames.s
-----
1k system + 23k game code & data + 19k sprites + 2k level + 3k buffers (48k aux mem) + 4k music + 12k more game code (aux l.c.) = 64k

So, yeah, again a lot of code & data. Some complications to consider - two lots of zero page (hmmmm) and seems like the Apple has the ability to read & write from different memory banks.

After some pondering, my preferred approach is going to be MODE 1 but at original resolution (280x192) single-buffered. If double-buffering is essential then this will have to drop down to MODE 5 (140x192). As there is a clean separation between game + rendering code (aux + main mem in the original) I am thinking to put game code in SHADOW RAM + MOS RAM and leave the rendering code + buffers in main RAM below the screen. This would give me at least 24k of contiguous game code & data to play with. All sprites etc. will be in sideways RAM. Something like this:

Code: Select all

beeb mem
-----
&0000 - ZP
&0100 - stack
&0200 - vectors
&0300 - system
&0400 - buffers x 1k
&0800 - sound
&0900 - buffers x 1k
&0D00 - NMI
&0E00 - rendering code + buffers
&3D80 - screen
-----
&8000 - swram bank 1 - player sprites
&8000 - swram bank 2 - player sprites
&8000 - swram bank 3 - background + level
&8000 - swram bank 4 - enemy sprites + ?
-----
&C000 - MOS
-----
shadow ram = 20K
&3000 - &8000 = game code + data
-----
mos ram = 4K
&8000 - &9000 = more game code?!
-----

I will need to load files from disc between levels so not sure about the extra filing system RAM on the Master at &C000 - &E000. Does anyone know exactly how this is used and whether any of it can be stolen without interfering with file load?

User avatar
tricky
Posts: 1575
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: Starting a Prince of Persia port...

Postby tricky » Fri May 19, 2017 6:22 am

As I mentioned at aBUG, what do you think about mmfs only? Otherwise, I guess JGH would be a good place to start to find the minimum memory to leave untouched.
The c64 requires a particular add on.
If you draw top-down, you will have about a frame and a half.
I was also thinking about the NuLA, if you did end up with mode 2, you could use a flash colour and its identical nonflash and then use one as a highlight colour on the NuLA, but I guess, a second set of graphics will be a small addition in comparison to all the coding ;)

User avatar
Rich Talbot-Watkins
Posts: 943
Joined: Thu Jan 13, 2005 5:20 pm
Location: Palma, Mallorca

Re: Starting a Prince of Persia port...

Postby Rich Talbot-Watkins » Fri May 19, 2017 8:39 am

Some observations: the CPC version, while colourful, seems to have much more choppy animation - I suspect the reason it fits in 64k is because they dropped half the animation frames.

The Apple II version essentially does run in 4 colours (despite 6 being available, albeit with some peculiar limitations). It seems like black/white have a resolution of 280 pixels, while other colours are limited to 140.

Image

I do like the high resolution of the characters, and certainly for porting purposes it'd be a lot easier to be able to use the same graphics. That being the case, there are undoubtedly some ways to make things a bit smaller.

Here's the Bank0 file loaded into screen memory:

Image

There's a fair bit of redundancy there - half of it just looks like empty space (with the top bit set). I wonder if some kind of run-length encoding scheme to reduce the runs of empty space would be worthwhile. Presumably the sprites are stored row by row, while run length encoding would be best done column by column, so maybe that's not an easy option. The 1bpp Apple format is already saving you 3 bytes per pixel row, so that's a nice saving. But it really feels like there must be a reasonable way to compress that sprite data a bit more.

Given that the character sprites look like they are entirely 2 colours + transparency, is there any need to store that top bit at all? Not that it would help to fit a row into 3.5 bytes instead of 4! Or at least maybe the top bit could be used to indicate that this byte is repeated again. Might be worth processing that data blob a bit to see if anything worthwhile comes out of it.

User avatar
vanpeebles
Posts: 302
Joined: Wed Nov 28, 2012 10:01 am
Location: UK
Contact:

Re: Starting a Prince of Persia port...

Postby vanpeebles » Fri May 19, 2017 9:46 am

Different hardware but I had the gameboy version back in the day, and it was amazing. So if that can pull it off, the Master should walk it :mrgreen:


Return to “projects”

Who is online

Users browsing this forum: No registered users and 1 guest