Starting a Prince of Persia port...

Got a programming project in mind? Tell everyone about it!
sirbod
Posts: 615
Joined: Mon Apr 09, 2012 8:44 am
Location: Essex
Contact:

Re: Starting a Prince of Persia port...

Postby sirbod » Sun Oct 01, 2017 12:18 pm

Begging for a NuLA colour map, looks awesome so far.

Just the sort of thing to show of in the Games Arcade at the London Show. I have room for a few more machines if anyone has the hardware ;)

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

Re: Starting a Prince of Persia port...

Postby kieranhj » Sun Oct 01, 2017 1:05 pm

Thanks for the kind words everyone and thanks trixster for making a quick video - I didn't even check that you could open the exit door! Certainly seems to have caused a bit of splash on Facebook. Much as I'd love to be able to squeeze the game onto a vanilla Model B, I don't think even Kevin Edwards would be able to manage that. :lol:

As for NULA, when I get round to redoing the graphics, or at least asking Dethmunk nicely :), I'll work on a specific NULA sprite set with custom palette because we'll be able to use all 16 colours rather than just remapping 8 colours from the vanilla version.

I'm going to carry on the port during my commute time but will be on holiday for two weeks across the London Show. We have the November ABUG meet up which is a great target for me to see where I can get to by then. :D

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

Re: Starting a Prince of Persia port...

Postby kieranhj » Fri Oct 06, 2017 10:43 pm

I thought you would all like another weekend treat. This is the first level of the game fully playable including all secret areas! I ported the guard & AI functions, along with the ability to pick up objects including the sword. I also re-implemented the keyboard handler, so the game is actually controllable - it used to do weird things before - and have re-written the sprite routines to correctly handle clipping and fixed other gfx glitches.

https://bitshifters.github.io/jsbeeb/?disc=https://bitshifters.github.io/content/wip/pop-beeb-play-level1-mode2.ssd&autoboot&model=Master

(Note: Return is the "action" key including grab & step, for timed jumps you'll need up-left & up-right which are mapped to the two keys either side of up '*'.)

Consider this a "teaser" :D and probably the last image I will upload here until the game is complete. I don't want you all getting bored and would like the final version to be fresh for everyone to play through and enjoy. :)

There is still plenty of work to do. I need to implement cutscenes and remaining gameplay features plus attract mode, save game etc. All the graphics need to be revamped for MODE 2 resolution and good palettes chosen (including NULA palettes.) Then I need SN music and sfx from our musician friend, Inverse Phase. Finally the whole lot needs to come together on a double-sided disc and any remaining Beeb specific support.

I'm also still not happy with the flickering and frame-rate. The good news is that there is plenty of memory free now - at least 6K - but not enough to double-buffer in MODE 2 (need around 13K.) The frame-rate gets quite bad when many sprites are being redrawn - I need to do some profiling (not jump to conclusions this time!) and have a good think about the best way to speed it up.

I'm still looking for an alpha tester to join our Slack channel and do playtesting with regular builds. Ideally someone who has played & completed the game on Apple II or PC and doesn't mind ruining their enjoyment of the finished Beeb version somewhat - it will mean replaying a lot of the same levels over again but at least you get some input into the development process. :wink: If you're interested please PM me!
Attachments
pop-beeb-play-level1-mode2.zip
PoP Level 1 fully playable
(55.57 KiB) Downloaded 36 times

User avatar
lazarusr
Posts: 599
Joined: Thu Sep 10, 2015 8:56 pm
Location: London

Re: Starting a Prince of Persia port...

Postby lazarusr » Fri Oct 06, 2017 10:55 pm

This truly remarkable. Who'd have thought this was possible on a Beeb. =D> =D> =D>

User avatar
billcarr2005
Posts: 1056
Joined: Fri Sep 09, 2005 3:01 pm
Location: UK
Contact:

Re: Starting a Prince of Persia port...

Postby billcarr2005 » Fri Oct 06, 2017 11:24 pm

Just played the level through. Fantastic achievement. :)
Can't wait for the finished game! =D>

User avatar
vanekp
Posts: 160
Joined: Thu Nov 30, 2000 7:09 am
Location: The Netherlands

Re: Starting a Prince of Persia port...

Postby vanekp » Sat Oct 07, 2017 7:52 am

Indeed looking good, never expected to see this game runnig on a BBC, graphics has a few glitches but then its not the final version.

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

Re: Starting a Prince of Persia port...

Postby trixster » Sat Oct 07, 2017 4:06 pm

It's stunning. Amazing work! I've popped another vid on the FB group.
A3020 | A3000 | BBC B + 128K RAM/ROM + 20K Shadow + Pi0 + VideoNuLA
BBC Master Turbo + DC | Atom | A1200 060 | A500 | Jaguar | A420/1
A4000/040 060 | Atari Falcon 060 | Saturn | PS1 | SNES | CPC6128 | C64 | 3DO | MD

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

Re: Starting a Prince of Persia port...

Postby tricky » Sat Oct 07, 2017 4:32 pm

Kieran, do you think you might have room to double buffer just the bit where the player is, or at least build it off-screen?

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

Re: Starting a Prince of Persia port...

Postby RobC » Sat Oct 07, 2017 4:45 pm

This is amazing - great work Kieran =D> =D> :D

User avatar
Matt Godbolt
Posts: 153
Joined: Mon Jul 31, 2006 10:02 am
Location: Chicago
Contact:

Re: Starting a Prince of Persia port...

Postby Matt Godbolt » Sat Oct 07, 2017 7:13 pm

Wow, this is totally *awesome* - great job Kieran!

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

Re: Starting a Prince of Persia port...

Postby kieranhj » Wed Oct 11, 2017 9:32 am

As always, thanks for the kind words everyone! Helps me keep up the motivation to get things finished.

tricky wrote:Kieran, do you think you might have room to double buffer just the bit where the player is, or at least build it off-screen?

I've been doing some profiling to take a look at how the screen draw works and take some rough raster timings. For a start the gameplay code overhead (without moving so limited collision detection and no AI) is around 1/2 frame. The draw order is:

1. erase mid-ground objects (copy back layrsaved screen buffers) - aka "peel"
2. clear solid rectangles (used to blank "transitional" background sprites, e.g. spikes, before next frame is plotted) - aka "wipes"
3. draw background sprites marked for redraw (can also be masked) - aka "fastlay" (byte aligned, no clipping, no mirroring)
4. copy existing screen buffer before drawing mid-ground objects - aka "layrsave" (restored with "peel")
5. draw mid-ground moving objects: player, guard, falling floor (masked) - aka "lay" (pixel aligned, can be mirrored, full clipping)
5. draw foreground objects in front of player: pillars etc. - aka "fastlay"

I didn't realise how much of the background gets (potentially) redrawn each frame and was still using the full-fat pixel aligned function for this. I rewrote the "fastlay" sprite functions to skip using the stack and just lookup MODE 2 pixel pairs directly from the packed MODE 5 data and achieved a substantial frame-rate increase. The game is much more playable now in the general case, although still slows down more than I'd like in places.

I'm not sure that I can assemble the player image off-screen - the background already gets saved out before being overdrawn by mid-ground and foreground sprites. I don't want to have to copy it back another time.

I have an idea to reduce sprite flicker - since the game uses image lists (containing all of the above) I could use a crude sorting method (top bit of Y coordinate) to make two passes over the lists for plot operations in the top and bottom half of the screen. I'd like to get the wipe closer to the background sprite redraw, for instance, so there is less flicker on things like the spikes etc.

Obviously the player is the most important sprite to get smooth. I also thought that I could potentially combine the background "layrsave" operation with the sprite plot, since these are directly correlated, so save out the screen buffer immediately before writing the masked sprite data. It would make the inner loop of the sprite routine more complicated as more pointers to keep track of, but might result in an overall speed up.

There is clearly going to be a lot of coherency between what gets "layrsaved" and "peeled" each frame because the player can't move ~that~ far per tick, but not sure how to exploit that.

Whilst writing the "fastlay" function that's all conveniently byte aligned, I realised that the Exile sprite routine is optimised to use as little RAM as possible because they were targeting vanilla Beeb with 16K SWRAM max. So one sprite plot routine handles every possible operation (mirroring, clipping, wraparound etc.) and the palette to pixel mapping is designed to use just 7 bytes. Since I'm targeting a 128K Master I have a "lot" (relatively speaking) more RAM to play with. For absolutely critical sprite plot routines I am happy to burn a page or several for lookup tables.

I'm also wondering whether using the top palette bit as a "background" flag helps me at all. Perhaps if the foreground objects had this bit set I could modify the mid-ground plot routine to not overwrite these pixels (ala Exile) and potentially save having to redraw the foreground objects at all.

Ideally, I would very much like to keep the 3 colours per sprite palette approach as I think this will make the eventual 16 colour NULA version truly stunning.

However, I have been pondering whether I will have to relent and adopt the 4 background / 3 foreground EOR palette mapped approach. I could plot the player sprite EOR with the background which would save the "layrsave" copy operation (still need to erase the sprite before the next frame so the "peel" operation would be replaced by another EOR plot.) There are foreground objects drawn on top of the player, but at least these are explicitly held in an image list. I would have to think about where any mid-ground objects intersect with each other, likely the AI guards and any collectibles. Some background objects, like the torches, would likely have to be special-cased as the background palette wouldn't have the right colours - they can't be foreground objects as the player has to walk in front of them.

Anyway, all thoughts and suggestions welcome as always! :)

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

Re: Starting a Prince of Persia port...

Postby tricky » Wed Oct 11, 2017 11:27 am

I was thinking of constructing part of the screen of-screen and then copying it to the screen. No copy/peel, just draw opaque back to front, it may just be to wasteful.

User avatar
Arcadian
Posts: 2733
Joined: Fri Nov 24, 2000 12:16 pm
Contact:

Re: Starting a Prince of Persia port...

Postby Arcadian » Wed Oct 11, 2017 12:06 pm

Hi, sorry it's taken me so long to pipe up in this thread, I can assure you I've been excitedly reading every update, trying out every test version as soon as they've been posted! Am simply amazed at how smooth/fast it's looking already and can barely believe how in an instant it went from mere concept sprite routines into a responsive, playable game!

Can't wait to hear the how the tunes sound once native Beeb music tracks have been composed. And do you think there could be mileage in adding options for BeebSID (using the C64 conversions?) and BeebOPL (using the PC/adlib tracks?) too?
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk

Image
ABug Leicestershire (17-19 November 2017)

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

Re: Starting a Prince of Persia port...

Postby kieranhj » Wed Oct 11, 2017 12:15 pm

Arcadian wrote:Hi, sorry it's taken me so long to pipe up in this thread, I can assure you I've been excitedly reading every update, trying out every test version as soon as they've been posted! Am simply amazed at how smooth/fast it's looking already and can barely believe how in an instant it went from mere concept sprite routines into a responsive, playable game!

Can't wait to hear the how the tunes sound once native Beeb music tracks have been composed. And do you think there could be mileage in adding options for BeebSID (using the C64 conversions?) and BeebOPL (using the PC/adlib tracks?) too?

Thanks Dave! I hadn't thought about BeebSID or BeebOPL music; I guess this would fall into the same category as the NULA version. Look forward to chatting to everyone and showing more progress at ABUG in November. :)


Return to “projects”

Who is online

Users browsing this forum: No registered users and 4 guests