Going great guns on a Prince of Persia port...

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

Re: Starting a Prince of Persia port...

Postby kieranhj » Tue Nov 28, 2017 12:47 pm

crj wrote:I don't see any reason that would necessarily be true? Other schemes might be a bit fiddly, but they're certainly possible.

And there's no rule that says you can't have data pertaining to more than one sprite in the same byte.

Rich Talbot-Watkins wrote:My €0.02 - PoP is all about the character sprite and animation. It was pretty much the USP back in the day. It seems like a heinous crime to halve the vertical resolution (particularly since the horizontal resolution has already been compromised!). Have you thought about making different compromises, e.g. to the scenery graphics instead? Or indeed is there some way to compress those (particularly since they don't need to be plotted as part of the animation cycle if you use the pixel bit 3 as foreground flag thing). Would that claw back enough?

I do not disagree with any of the above! For my own sanity and need to press on with the port (and the ever growing list of non-graphics related things that need to get done) I am going to pause any further investigation into sprite compression. I have a not ideal but scaleable and easily reversible solution in place for now that gives me more than enough RAM to complete the work (he says optimistically.)

Having committed to double-buffering, I have some refactoring work to do to enable the gameplay code + data to reside in two different SWRAM banks. I have a plan for this thanks to the handy jump tables (effectively a DLL system) but if that doesn't work then it will be back to the drawing board anyway!

I'll give everyone an update when there is something interesting to see (like a cutscene) or hear (like some music!) As always, thanks for the ideas, suggestions and general encouragement.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

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

Re: Starting a Prince of Persia port...

Postby kieranhj » Wed Nov 29, 2017 2:07 pm

Heh. I got a small mention in this month's Retro Gamer magazine. I wish they'd just ping me - I'm not that hard to get hold of!!
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
Lardo Boffin
Posts: 670
Joined: Thu Aug 06, 2015 6:47 am

Re: Starting a Prince of Persia port...

Postby Lardo Boffin » Wed Nov 29, 2017 3:51 pm

After folllowing this thread for some time I finally got round to getting a copy of Prince of Persia for my Apple IIe. Its awesome! It also doesn’t make my eyes hurt to look at unlike many other Apple games...

29B7F843-639C-4712-9488-D2B82AE78D08.jpeg


I am seriously looking forward to the Beeb version!
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Retroclinic Datacentre + HDD, matchbox co-proc, Viglen twin 40/80 5.25" discs, acorn cassette
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc, Acorn 6502 coproc

User avatar
Lardo Boffin
Posts: 670
Joined: Thu Aug 06, 2015 6:47 am

Re: Starting a Prince of Persia port...

Postby Lardo Boffin » Wed Nov 29, 2017 4:44 pm

If you need any comparisons doing between the Beeb and Apple versions and no-one else has volunteered let me know. Although it may be a while before I can test the later stuff as I am still figuring out the controls!
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Retroclinic Datacentre + HDD, matchbox co-proc, Viglen twin 40/80 5.25" discs, acorn cassette
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc, Acorn 6502 coproc

User avatar
jbnbeeb
Posts: 368
Joined: Sat Apr 03, 2010 8:16 pm

Re: Starting a Prince of Persia port...

Postby jbnbeeb » Wed Nov 29, 2017 5:29 pm

kieranhj wrote:Heh. I got a small mention in this month's Retro Gamer magazine. I wish they'd just ping me - I'm not that hard to get hold of!!


Yep just flipped to the homebrew section and there it is (I always go to that section first!) Cool that you got a mention.

Ages ago I got a mention with a WIP of biplane (sadly no review for the finished game) -- and like you the first I knew was when I opened up the magazine :) Still - it's a nice surprise isn't it? :)

Thanks for the continued updates.
I'm going to ..
ABUG North Halifax June 10-12
Image

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

Re: Starting a Prince of Persia port...

Postby kieranhj » Wed Nov 29, 2017 5:35 pm

Lardo Boffin wrote:If you need any comparisons doing between the Beeb and Apple versions and no-one else has volunteered let me know. Although it may be a while before I can test the later stuff as I am still figuring out the controls!

I don't have an Apple II (yet!) but from the code it appears to default to joystick control. You can select keyboard with ctrl-K and then I think the default keys are J/L/I/K for left/right/up/down and U/O for up+left and up+right. Apple key is Action.

I managed to get an Apple II emulator up & running so have seen it with my own eyes, as it were. I only ever played it on PC as a kid. :D
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

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

Re: Starting a Prince of Persia port...

Postby kieranhj » Wed Nov 29, 2017 5:38 pm

Since the port is getting some interest from a variety of places, I have created a landing page on our Bitshifters site: https://bitshifters.github.io/posts/prods/bs-pop-beeb.html

From now on the latest WIP for you all to try will have a consistent location rather than a new crazy name each time: https://bitshifters.github.io/jsbeeb/?disc=https://bitshifters.github.io/content/bs-pop-beeb-latest-wip.ssd&autoboot&model=Master

I will continue to post updates and RFC's here, of course, and will let you know when there is a new WIP worth checking out. :)
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

User avatar
Lardo Boffin
Posts: 670
Joined: Thu Aug 06, 2015 6:47 am

Re: Starting a Prince of Persia port...

Postby Lardo Boffin » Wed Nov 29, 2017 10:17 pm

kieranhj wrote:
Lardo Boffin wrote:If you need any comparisons doing between the Beeb and Apple versions and no-one else has volunteered let me know. Although it may be a while before I can test the later stuff as I am still figuring out the controls!

I don't have an Apple II (yet!) but from the code it appears to default to joystick control. You can select keyboard with ctrl-K and then I think the default keys are J/L/I/K for left/right/up/down and U/O for up+left and up+right. Apple key is Action.

I managed to get an Apple II emulator up & running so have seen it with my own eyes, as it were. I only ever played it on PC as a kid. :D


Thanks - I had googled and found the controls but could not get my stupid fingers to use them properly! I suffered many a fall into a spike laden pits...
And having finally kind of got my head round running around and not dying I now have to figure out how to finish off the guards! Argh! Made it to level 2 though. Then there are two guards in a row. Doh!

I think the keyboard layout was very much an afterthought in this on the Apple - having the action key so far away from the rest of them makes life difficult in the extreme. Maybe user definable keys for the Beeb?
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Retroclinic Datacentre + HDD, matchbox co-proc, Viglen twin 40/80 5.25" discs, acorn cassette
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc, Acorn 6502 coproc

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

Re: Starting a Prince of Persia port...

Postby kieranhj » Thu Nov 30, 2017 8:43 pm

Lardo Boffin wrote:I think the keyboard layout was very much an afterthought in this on the Apple - having the action key so far away from the rest of them makes life difficult in the extreme. Maybe user definable keys for the Beeb?

It's on the feature suggestion list! I have added everything that I am aware of which is outstanding or bugged to the issue list on the GitHub page: https://github.com/kieranhj/pop-beeb/issues. Everyone is welcome to post any specific problems or requests directly there.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/

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

Re: Starting a Prince of Persia port...

Postby kieranhj » Thu Nov 30, 2017 9:05 pm

No new build to share but just a quick note that my crazy "DLL" scheme worked for transparently spreading gameplay code across multiple SWRAM banks.

Because the code already has a jump table interface between code modules, I moved all of these to main RAM (above PAGE, below SHADOW) and changed the jmp opcodes to macros:

Code: Select all

\*-------------------------------
\* auto.asm
\*-------------------------------

.AutoCtrl JUMP_A AUTOCTRL, AUTO_BASE, 0
.checkstrike JUMP_A CHECKSTRIKE, AUTO_BASE, 1
.checkstab JUMP_A CHECKSTAB, AUTO_BASE, 2
.AutoPlayback JUMP_A AUTOPLAYBACK, AUTO_BASE, 3
.cutcheck JUMP_A CUTCHECK, AUTO_BASE, 4

.cutguard JUMP_A CUTGUARD, AUTO_BASE, 5
.addguard JUMP_A ADDGUARD, AUTO_BASE, 6
.cut JUMP_A CUT, AUTO_BASE, 7

Where JUMP_A macro looks like:

Code: Select all

MACRO JUMP_A name, base, index
{
    \\ Preserve X
    STX DLL_REG_X

    \\ Load function index
    LDX #(base + index)

    \\ Call jump function
    JMP jump_to_A
}
ENDMACRO   ; 3c+2c+3c = 8c + 7b overhead per fn call

And the jump_to_A function contains:

Code: Select all

.jump_to_A
{
    \\ Preserve A
    STA DLL_REG_A

    \\ Remember current bank
    LDA &F4: PHA

    LDA #6          ; hard code this aux A = 6
    STA &F4: STA &FE30

    \\ Load function address
    LDA aux_core_fn_table_A_LO, X
    STA jump_to_addr_A + 1

    LDA aux_core_fn_table_A_HI, X
    STA jump_to_addr_A + 2

    \\ Restore registers before fn call
    LDX DLL_REG_X
    LDA DLL_REG_A
}
\\ Call function
.jump_to_addr_A
    JSR &FFFF
{
    \\ Preserve A
    STA DLL_REG_A

    \\ Restore original bank
    PLA
    STA &F4:STA &FE30

    \\ Restore A before return
    LDA DLL_REG_A

    RTS
}   ; 3c+3c+3c+2c+3c+4c+4c+4c+4c+4c+3c+3c+6c+3c+4c+3c+4c+3c+6c = 69c overhead

So a hefty per-function call cycle overhead (and not insignificant per stub memory overhead) but the game seems to run OK! I guess the increase in CPU speed is enough to compensate for this and likely that the screen plot routines are dominating the frame time anyway (and are resident in main RAM.)

This only works if (non-sprite) data is either permanently resident (e.g. in HAZEL) or only accessed through a code interface - fortunately the animation frame data and sequence tables are accessed this way so can be grouped with the corresponding module.

Because the gameplay functions can be called from main RAM or from either SWRAM bank arbitrarily, the original bank has to be replaced by the caller otherwise we can return into the wrong place when these can chained together. Also there are instances where the sprite data is temporarily paged in to check the size of frames for collision detection etc. so this needs to be handled carefully.

Later on, once the memory map settles down, any function calls between code modules within the same SWRAM bank can be made direct rather than indirected through the DLL stub to save unnecessary cycles.

Obviously if you were writing a Master-only game from scratch you wouldn't add such an unnecessary overhead but it seems to be working OK and gives me lots of flexibility to continue moving code around and porting the remaining functions etc. The original Apple II code makes a nice clean separation between gameplay & rendering and uses a similar interface (main vs aux RAM) but even includes some similar extra stubs for those occasions when the game needs functions that are in an inconvenient place in RAM. It looks like Jordan ended up doing quite a bit of juggling towards the end of development as there are a few functions that are in the "wrong" code module.

Final quick question to the group - for simplicity's sake, I am thinking of changing the SWRAM handling to be hardcoded to the Master default banks 4,5,6,7 - does anyone have a reason why I shouldn't do that? At the moment there is a SWRAM check at boot and the game will barf if less than 4 are detected. It uses "slots" numbered 0-3 which will typically map to banks 4-7. Given this is Master only, would anyone have a setup with 64K SWRAM but not in banks 4-7? It would be weird to use the internal ROM slots then add the SWRAM back in a cartridge, for instance.
Bitshifters Collective | Retro Code & Demos for BBC Micro & Acorn computers | https://bitshifters.github.io/


Return to “projects”

Who is online

Users browsing this forum: No registered users and 1 guest