Unicorns season: Prince of Persia for the A8!

[_The Doctor__]

Seen a bug like that on 386SX of the past.... might be a mention of it in speed runs also... will look for TAS video and mail you link.... if anything it will be funny to watch, but the person will mention the off important bit of mention during play. give it a bit, google fu is weak these days... they might advertise and sponsor me to death

 

okay found one of the fastest tool assisted speed runs geared toward the x86 machines of old hereby referred to as DOS games...

for @rensoup

complete use of exploits glitches, spoilers, and bugs caution!

https://www.youtube.com/watch?time_continue=6&v=hfOocUkxJ08&feature=emb_logo

apple II+ or in that mode not speed play and not all the way through

https://www.youtube.com/watch?v=fggouSd3dr4

fast forward time compressed play through of apple ii+ mode video sped up

https://www.youtube.com/watch?v=JMc7cBVwF-k

source code...

github.com/jmechner/Prince-of-Persia-Apple-II

 

it only takes 14 minutes to watch, is not perfect for all ports of the game, but gives an idea of what is possible when getting a machine to play the game on DOS pixel perfect (but there are some issues that caused a save state, like enemy or player falling through walls) fast talker makes mention in passing

Edited April 8, 2020 by _The Doctor__

[rensoup]

18 hours ago, _The Doctor__ said:

https://www.youtube.com/watch?time_continue=6&v=hfOocUkxJ08&feature=emb_logo

That TAS was dense ? had to play it at 0.75 speed and even then the guy spoke too fast!

[xxl]

On 4/8/2020 at 12:29 PM, rensoup said:

So I have questions:
1. does Xbios support disk swapping ? (I don't care about multiple drive support). I suppose yes and I just need to try to load a file and if it fails, ask the user for a disk swap ?
2. Is the 180KB version usable for a cart version ?

1. open file and if it fails, ask user for disk swap...

2. you can use ATR of any size. you can also combine two ATRs together and save them on the card.

 

cartridge made according to this design: 

 

goes like this:

 

 

[rensoup]

5 hours ago, xxl said:

1. open file and if it fails, ask user for disk swap...

2. you can use ATR of any size. you can also combine two ATRs together and save them on the card.

? perfect!

 

(I know nothing about electronics, that DIY cart seems nice but I don't have a real machine ? )

[Wilheim]

18 hours ago, rensoup said:

? perfect!

 

(I know nothing about electronics, that DIY cart seems nice but I don't have a real machine ? )

It’s relatively simple to implement an atarimax cartridge version. Here’s my suggestions:

 

1. The cartridge memory area is on $a000-$bfff (8 kbytes)

 

2. Consider Bank 0 (newer versions) and Bank 127 (Older version) as an initial bank.

 

3. Use zone $bffa-$bfff on bank 0 and 127 to the init parameters.

 

4. to switch a bank on the cartridge, just write any value on $d500-$d57f, where $d500 is bank 0 and $d57f is bank 127.

 

5. to turn the cartridge off, just write a value at $d580-$d5ff. Then you will have zone $a000-$bfff available as ram.

 

if you need further information, please let us know.

 

Keep your hard work! Cheers!

 

 

[Jacques]

I just hope that disk version will stay on agenda, with carts being an option. 

[rensoup]

1 hour ago, Wilheim said:

It’s relatively simple to implement an atarimax cartridge version. Here’s my suggestions:

Didn't know that all these carts were incompatible... In theory though, @xxl method should work for any type of cart: you just stream from the cart into the disk buffer which is located outside the switchable areas.

 

But that means a slightly different driver for each cart...?

 

1 hour ago, Jacques said:

I just hope that disk version will stay on agenda, with carts being an option. 

The disk version is the primary version but it's quite simple for xxl to change the xbios version on the disk to make it work on a cart. In this case, the cart acts as a streamable (not sure about terminology) device, not as a real cart where each byte is instantly accessible (like the C64 PoP version which uses a 512KB cart)

[+Philsan]

@rensoup, a $50 multicart is compatible with all cart formats (no loading times and huge amounts of memory even for unexpanded machines) and executables (fast loading times), therefore you can choose whatever cart format you prefer.

 

Anyway, you should use the format (cartridge, executable, disk) you prefer, the easiest and most useful for your project.

[Mq.]

The video which was attached by xxl, presents short test performed by me. I did it for xxl (and probably for rensoup too?), to check if a new features of xbios really works on real machine and real cartridge.
We wanted to show you, that it is possible to transfer xbios based game developed on atr (floppy) directly to the cartridge. In fact, this feature don't need any programmer special design of a game for the cartridge. If you use xbios on atr, then it is possible to burn it later on Maxflash banking scheme compatible cartridge.

[Jacques]

44 minutes ago, rensoup said:

The disk version is the primary version but it's quite simple for xxl to change the xbios version on the disk to make it work on a cart.

Thanks rensoup ?I really like using disk drive, own two programmable carts as well, but disks make it more computer-feeling, while swapping carts remind me consoles, but it's just me ?

[Wrathchild]

2 hours ago, rensoup said:

But that means a slightly different driver for each cart...?

 

No, that's not really correct.

Many of the popular carts are able to run many different formats of cartridge binary images.

So whilst you can blow the image to an AtariMax cartridge, you can play the binary from an Ultimate Cart, The!Cart, AVG Cart etc

 

So just continue on as you were and it looks like others with prep the cart version for you

[rensoup]

 

Now you see me...

 

 

Now you don't!

 

 

[rensoup]

 

PMG masking is in... I was going to use GPRIOR %100 (PMGs under the playfield) but the foreground uses too much of COLBAK so it was still distracting.

So i went with classic PMG masking with a little simplification... it doesn't work for gates and slicers (software masking still works though) but it's not really noticeable.

 

So not perfect but works well enough, and the CPU cost is close to 0 ?

 

 

This means the game is now feature complete!

 

 

(unless I decide to add more stuff!)

 

[Rybags]

Very nice.

[Heaven/TQA]

Nice

[popmilo]

2 hours ago, rensoup said:

So not perfect but works well enough, and the CPU cost is close to 0 ?

 

Is that that done by simply not drawing column of bytes where something is in front ?

Looks great !

 

[rensoup]

27 minutes ago, popmilo said:

Is that that done by simply not drawing column of bytes where something is in front ?

Looks great !

 

well it's a tiny bit more complicated but yeah along those lines ?

 

I have to build a mask buffer every time I enter a screen like the C64: 

 

https://popc64.blogspot.com/2011/10/part-six-playing-hide-and-seek-with.html

 

except that in my case I just use a single line mask per row of tiles, so the buffer is 20 bytes * 3 rows. A mask can be a large 16 pixels wide block or a 2 pixels pole though.

 

I already had masking in the previous release for left and right clipping, I was able to recycle it and make it more generic, so now clipping is part of the whole masking process.

 

The only extra bit is the 16 bit mask shifting required to align it to the PMG X coordinate (up to 7 lsr+rol per mask, 1 mask per PMG with up to 8 PMGs), and I could probably use a 256 bytes lookup table for that...

 

 

[Wilheim]

3 hours ago, rensoup said:

 

PMG masking is in... I was going to use GPRIOR %100 (PMGs under the playfield) but the foreground uses too much of COLBAK so it was still distracting.

So i went with classic PMG masking with a little simplification... it doesn't work for gates and slicers (software masking still works though) but it's not really noticeable.

 

So not perfect but works well enough, and the CPU cost is close to 0 ?

 

 

This means the game is now feature complete!

 

 

(unless I decide to add more stuff!)

 

Great! Now to see an epic fight with the Fat-man!

[Jacques]

Rensoup, this is amazing and a milestone for our Atari. 

 

Do you plan to release next playable demo with it, before full game is ready? 

 

Pleeaaaaaaaase ?

 

Edited April 12, 2020 by Jacques

[TIX]

1 hour ago, Wilheim said:

Great! Now to see an epic fight with the Fat-man!

ermm..  let's get to work then

[rensoup]

2 hours ago, Jacques said:

Rensoup, this is amazing and a milestone for our Atari. 

 

Do you plan to release next playable demo with it, before full game is ready? 

 

Pleeaaaaaaaase ?

 

 

There's one more feature I want to add, it's not mandatory and a little complicated... but if it can be done, there'll be another demo before the full release...

 

2 hours ago, TIX said:

3 hours ago, Wilheim said:

Great! Now to see an epic fight with the Fat-man!

ermm..  let's get to work then

... and that feature involves characters, so let's not rush into things for fear of having to throw it all away ?

 

[twh/f2]

Maybe this is a bit offtopic. But when I see all this complex technical stuff to realize this in 2019/2020 I really wonder how this game could be ever be created on the apple2. I don’t know the specs of the Apple but had Jordan Mechner also to fight with bare metal hardware limitations? It must have been almost impossible so also a big risk to invest so much time and resources on such a project. 
 

The game on itself is just wow especially when you consider all the details, story and the extras. 8bit on steroids. 
 

[+slx]

24 minutes ago, twh/f2 said:

Maybe this is a bit offtopic. But when I see all this complex technical stuff to realize this in 2019/2020 I really wonder how this game could be ever be created on the apple2. I don’t know the specs of the Apple but had Jordan Mechner also to fight with bare metal hardware limitations? It must have been almost impossible so also a big risk to invest so much time and resources on such a project. 
 

The game on itself is just wow especially when you consider all the details, story and the extras. 8bit on steroids. 
 

There's a whole book about it....

[rensoup]

2 hours ago, twh/f2 said:

Maybe this is a bit offtopic. But when I see all this complex technical stuff to realize this in 2019/2020 I really wonder how this game could be ever be created on the apple2. I don’t know the specs of the Apple but had Jordan Mechner also to fight with bare metal hardware limitations? It must have been almost impossible so also a big risk to invest so much time and resources on such a project. 

Thinking outside the box! JMechner did many things that were counter intuitive.

 

Rotoscoping was a crazy idea but he used is experience from Karateka I suppose, and he still had to go through many hoops to get it to work. The result was spectacular though.

 

I'm a big fan of 50/60fps but PoP is the opposite, yet it's still responsive and great to play or watch someone play.

 

Then there's the 2.5D which makes the rendering so much more complicated but serves no practical purpose ? yet contributed to its unique look. 

 

It also took many years to complete the project, so many that the apple2 was a dying platform when it came out. It seems that success came from all the console conversions.

 

I'd say that the game has that interactive movie syndrome where the programmer really wanted to be a film director, only this time it actually worked!

Edited April 13, 2020 by rensoup

[Jacques]

Looking for a pause key in "our" demo, I checked BBC Master keyboard options: https://www.popuw.com/bbc.html

Is there a plan to incorporate some of them in Atari version?