Prince of Persia

[+MrFish]

I read the original author found his source code. Maybe there's a chance he open sources it and the world can get at all the nifty, rotoscoped animation.

 

http://www.geek.com/...later-20120329/

 

That's great news! Thanks for posting it. I wonder if he stepped up his search after hearing about the C64 version, and the fact that the poor guy who did it had to work from disassembled machine code?

[José Pereira]

Something I had the idea and I worked over the Weekend:

 

C64 is using each screen Playing Area 192scanlines high where:

-> Top 3scanlines as the last/bottom gfxs of the previous/above screen

-> Then 3parts/Walkways with 63scanlines each

 

To turn this into A8 in charmode I'll to have each of those 3parts with 64scanlines each. Just one more scanline in each, but where?

No problem as the top scanline of each part is right next to the previous/above part then I just separate it with a black scanline (that even looks beter)

 

Now the top 'just 3scanlines' of the previous screen it's indeed the last/bottom 3scanlines that we can show the 8scanlines/last bottom charline or in A8 we only have those 3scanlines because the top 5scanlines are blank ones (the charline it's there but only 3scanlines shown).

 

 

Now, about each of the parts 64scanlines/8charlines they beter go into 'Interleaved Charsets' in charsetsbecause the game is always build in those 3parts always same tall and that way it is possible that each charset/1charline all the Map width fit in 128chars.

Even beter as the guys sprites are maximum 7chars tall even with vertical shifting so the same soft sprite never cross more than one charset.

From C64 sprites the maximum width it's 24pixels that is 6+1 (shifting) = 7chars x (guy and Enemy) = 14chars.

On the charline 6and7 we have, sometimes, the bottle that is 2 more chars.

So, maximum chars per scanline need for soft sprites are 16chars leaving 112 chars free for gfxs (around 104 if we count the 'Falling/Break' ground).

Next my job is to get, at least one level and add one more scanline to each of the parts and separate them in 8charsets to see if they fit in around 100chars... but I have almost sure they will!

 

 

 

The C64 screen with 63scanlines each part:

 

And the A8 with one more scanline on each part:

(The White Bar it's one charline in Hi-resolution for the Status Area)

 

This one has 192scanlines/25charlines for the Playing Area but, like I said, we don't need that. If you think that it looks better just the 3scanlines shown then just put the previous/top ones as Blank scanlines:

 

 

THE EXPLANATION(s):

The screen use:

BACKGR.: Black

PF0: the Dark Walls/Ground colour (here it's Dark Blue)

PF1: White

PF2: The Light Walls colour (here it's Light Blue)

(it can be any colours and luminances on PF0 and PF1 on the diferent levels of the game...)

---------------------------------------------

PF3: Fire Yellow /DLI/ Dark Gray Bubbles /DLI/ Dark Brown /DLI/ Light Green in the Bottle

In each of the three zones there's these DLIs that are always same nº of scanlines steps for each one colour and never on the 'Badlines', like:

-> Yellow always 20scanlines

/DLI/

-> Dark Brown always 16scanlines

/DLI/

-> Dark Gray Bubbles always 8scanlines

/DLI/

-> Green Bootle always 20scanlines

 

Then on the next part it just repeats these DLIs in these 'steps'...

 

 

Just the Bitmap PFs gfxs:

The screen use:

BACKGR.: Black

PF0: the Dark Walls/Ground colour (here it's Dark Blue)

PF1: White

PF2: The Light Walls colour (here it's Light Blue)

---------------------------------------------

PF3: Fire Yellow /DLI/ Dark Gray Bubbles /DLI/ Dark Brown /DLI/ Light Green in the Bottle

In each of the three zones there's these DLIs that are always same nº of scanlines steps for each one colour and never on the 'Badlines', like:

-> Yellow always 20scanlines

/DLI/

-> Dark Brown always 16scanlines

/DLI/

-> Dark Gray Bubbles always 8scanlines

/DLI/

-> Green Bootle always 20scanlines

 

Then on the next part it just repeats these DLIs in these 'steps'...

 

Just the Bitmap PFs gfxs:

 

 

Now the guys 'way of'...

From what I see in all of the C64 version sprites frames done by Ste86 it's possible I get things this way (there's only 6or7 shapes that I need to cut/change one or two pixels that aren't important for the guys looking):

-> Use always White for the Prince clothes and sword

-> Again, use White for the enemy sword and one of his clothes (depends of the Enemy (Guard, Vizier,...) to choose each part in White...)

-> This time we will use PRIOR4 where:

- PM0+PM1 for Prince (1,10) for the skin

(because no Oring then the hair can't be Yellow but no problem because we can get a 'nice hat' and some version he has a turbant instead of hair)

- PM2 for one of the Enemy clothe

- PM3 Light Orange (2,10)

- On the 'Intersection' of the two we get the 'Oring' third colour on the turbant.

 

And the guys PMGs only:

 

 

 

I just changed some pixels on the pillars so they haven't Black on the front ones. As Black it's BACKGR. colour Register then the guys using PRIOR4 have the PMGs only overlaying Black BACKGR. colour Register that when going behind Pillars (or any other gfxs) you just need to do the Mask betwwen gfxs/PFs (the PMGs will always be Masked by any of the PFs because in PRIOR4 they are only above BACKGR. colour Register).

 

Of course that the pillars can be a little bit better (if you think so...) because of the removed black pixels but you get the idea.

 

 

 

 

Now the guys 'way of'...

From what I see in all of the C64 version sprites frames done by Ste86 it's possible I get things this way (there's only 6or7 shapes that I need to cut/change one or two pixels that aren't important for the guys looking):

-> Use always White for the Prince clothes and sword

-> Again, use White for the enemy sword and one of his clothes (depends of the Enemy (Guard, Vizier,...) to choose each part in White...)

-> This time we will use PRIOR4 where:

- PM0+PM1 for Prince (1,10) for the skin

(because no Oring then the hair can't be Yellow but no problem because we can get a 'nice hat' and some version he has a turbant instead of hair)

- PM2 for one of the Enemy clothe

- PM3 Light Orange (2,10)

- On the 'Intersection' of the two we get the 'Oring' third colour on the turbant.

 

Attachment:

pop charmode PMGs only.png

pop charmode PMGs only.png [ 1.16 KiB | Viewed 1 time ]

 

I just changed some pixels on the pillars so they haven't Black on the front ones. As Black it's BACKGR. colour Register then the guys using PRIOR4 have the PMGs only overlaying Black BACKGR. colour Register that when going behind Pillars (or any other gfxs) you just need to do the Mask betwwen gfxs/PFs (the PMGs will always be Masked by any of the PFs because in PRIOR4 they are only above BACKGR. colour Register).

 

Of course that the pillars can be a little bit better (if you think so...) because of the removed black pixels but you get the idea.

Edited January 28, 2013 by José Pereira

[emkay]

The main problem is the frames per second. You see games struggle just using "one" layer over another.

In this game you have to take care of "three" layers, as the protagonist and enemies walk over the background and have "walls", "Pillars" and other items where they walk behind.

You HAVE to change the graphics content that the calculations can be reduced. On the Apple many objects were always 1, 2 , or 3 bytes wide, so there is no calculation to handle. Same has to be done on the Atari. If you don't adjust the graphics, the CPU will get too much to handle, which takes the gameplay down.

 

Understood?

Edited January 28, 2013 by emkay

[José Pereira]

The main problem is the frames per second. You see games struggle just using "one" layer over another.

In this game you have to take care of "three" layers, as the protagonist and enemies walk over the background and have "walls", "Pillars" and other items where they walk behind.

You HAVE to change the graphics content that the calculations can be reduced. On the Apple many objects were always 1, 2 , or 3 bytes wide, so there is no calculation to handle. Same has to be done on the Atari. If you don't adjust the graphics, the CPU will get too much to handle, which takes the gameplay down.

 

Understood?

 

Edited by emkay, Yesterday, 9:07 PM.

 

I was to not answer to you because I don't want to re-sstart the 'ping-pong' with you on this and any other Topic like on the past because it's simply a waste of time. But, probably for the last time then here we go:

 

"it does masking in char's blocks but it relly doesn't. You just think that if you just do a quick saw of images or an Youtube video.

Apple Hi-Resolution it's that strange 7-bit cells (like oric 6-bit... Is there any more none 8-bit computer) and the masking isn't in chars blocks even on the common rock Pillars.

From MrSid C64 conversion blog:

 

Other linear vertical Pillars also aren't in Apple2 char's boundaries like the Pillars of the gates aren't exactly 1char 7Hi-resolution pixels wide:

this also the same on other levels Pillars like the Pallace yellowish ones)

 

And then there's also the non-linear gfxs masking like the Gates or the Blades (or even just the feet some pixels Masking with the little pieces of Rock), here it's the Amiga version because I can't find an Apple2 picture but it's the same:

 

 

There's not any version that just do things in char's boundaries as it's impossible because of the game way of designing the gfxs (probabably NES because of it's specific way (like on LN...) but I never study it).

 

From this video of Apple2:

You can see that it isn't doing Masking in chars boundaries:

-> Going up or down on the right side Platforms '/' type: at 2:50

(also when he is runnig jumping and fall at 3:21. Try to stop the video at 3:22 and that's a real proof)

-> Just some pixels Masking between the feet and the Ground pieces at 2:53

(also the same with the Ground skulls like at 3:46)

-> Masking on the Gates Front Pillar like at 3:06 (I said above that isn't one char wide Masking)

And the list can go on an on and on...

 

It is just impossible this game could be doing the Masks in chars boundaries.

 

The game if it was just moving the guy over gfxs you always have to do the 'LDA/AND/OR/STA' with gfxs with our Prince always go above all the others.

The trick here is that on all those things that him and the Enemy go behind that gfxs parts must be treated as soft sprites where you need to have a second, a copy of it 'in inverse' to use if the guys goes behind (that gfxs are real soft sprites but they, most of the times just don't move).

 

 

There is at the start of this Topic, I think, a file from Eagle where you can move the Prince behind non chars width Pillars.

Debug it and then see if there's cycles/cpu to have a secong guy/the Enemy (even adding more chars to the vertical shifting because we are in Char-Mode and then say something)!

 

Edited January 29, 2013 by José Pereira

[José Pereira]

Yes, I know that you'll say it's just the linear although not chars width 'one man show' but take it into a Monitor and see if it's in Char or Bitmap Mode and what cpu does it take by now.

Just found on my dusc the Eagle's file:

PoP_Eagle.xex

[emkay]

I was to not answer to you because I don't want to re-sstart the 'ping-pong' with you on this and any other Topic like on the past because it's simply a waste of time.

 

Müarai jerrue , müarai jerao

 

José , your whole writings are a full waste of time. Your "needs" on the A8 are far beyond the possible. What's really pondering is that coders listen to your words, even if they should know better.

Sometimes, only sometimes, you hit the border to the "possible" .That's the point where I write something.

If you're unable to learn things, it's not my problem.

Edited January 29, 2013 by emkay

[José Pereira]

Yours are the ones that are really a waste of time.

Your traditional 'put others work down' is what it's really a waste of time.

And, probably, that's why coders listen to me...

 

If all other computers can do it then why the A8 can't? Just because in your Head it can't.

As I only do gfxs like you think and you seem to be the 'Holy Grail' expert then we should have many proofs of what you're saying.

 

 

Scrollings no way... static screen no way... PMGs overlays or underlays or whatever, no way... NO WAY to have!...

It seems that A8 only way to have it's GR.7 (with digis of course) and 3D (what you think it's 3D).

 

 

 

 

 

I really need to say or post 100times: "I will never answer Emkay again!", "I will never answer Emkay again!", "I will never answer Emkay again!", "I will never answer Emkay again!",...

I could write those 100times but I certainly would cheat it with a copy and paste.

Edited January 29, 2013 by José Pereira

[Heaven/TQA]

I tend to say that PoP is possible on A8 even with masking as the Apple version. Speccy and Armstrad can do it and they do not have hardware sprites... so even on C64 the hardware sprites might not be best to use as you need to mask them, too.

 

the A8 has enough horse power to do it... what might be a problem is the RAM of the 64k machine. and in the end... XXL will take the zx spectrum version and make it run on A8

[emkay]

 

If all other computers can do it then why the A8 can't? Just because in your Head it can't.

 

 

I'm not saying, the A8 cannot do Prince of Persia.

PoP is just optimized to the hardware of the Apple where it comes from.

C64 has the hardware sprites which makes it as easy to move objects as to change some colours via DLI on the A8.

 

and so on.

 

 

 

As I only do gfxs like you think and you seem to be the 'Holy Grail' expert then we should have many proofs of what you're saying.

 

The gamebase is full of proofs.

 

 

 

Scrollings no way... static screen no way... PMGs overlays or underlays or whatever, no way... NO WAY to have!...

It seems that A8 only way to have it's GR.7 (with digis of course) and 3D (what you think it's 3D).

 

 

Is your recognition really that disabled?

I've also not written , what you wrote there.

It's simply utterly ridiculous how you stand on your point without any clue.

Even more funny, you push this nonsense joke in, that seems even show the level of those, writing at FormatWar sometimes.

I know what 3D is, and I know the different ways of how to get there on a computer.

A game has to look 3D as far as the "3d" rules were adopted into the gameplay.

Btw: Wolfenstein 3D is a 2D game with a "3D looking" presentation.

 

But the main point to the thread was that the graphics has to be adjusted to the boundaries of the A8, which is also not reaching your braincells as it seems.

 

Pillars on the Apple are 3 bytes wide and on the A8 you have to chose either 2 bytes or 3 bytes for the pillars.

 

 

I really need to say or post 100times: "I will never answer Emkay again!", "I will never answer Emkay again!", "I will never answer Emkay again!", "I will never answer Emkay again!",...

I could write those 100times but I certainly would cheat it with a copy and paste.

 

You should learn coding the A8 instead. It could help correcting many of your Braincells.

[emkay]

 

the A8 has enough horse power to do it... what might be a problem is the RAM of the 64k machine. and in the end... XXL will take the zx spectrum version and make it run on A8

 

32 bytes width hires, all in software . No Problem.

But José wants the C64 look on the A8, which simply doesn't work, if you don't want an interactive slideshow.

[Creature XL]

What ever Emkay or Jose write, I am enjoying it.

BUT, at least one point of Emkays writing is, in my view correct.

It might be possible to do PoP on the Atari the same way as it is done on the Apple. I don't know.

However, I do know it is much more easier to do it when you adjust the gfx to the A8. Here I mean, use 4x8-pixel chars. Not these Apple sizes (7x8) or what ever it is.

Further, I have read a section is 63 pixel high. Screw it. Make it 64. I am not sure if you, Jose, are doing it already.

 

Lastly, the easiest (to code) way for these gfx in front of sprite is, as you said, make them soft-sprites. If they are always sitting on char-boundaries they are fast to draw. As long as you are targeting a PAL game (as in 312 scan lines) I do not see any speed problems doing it in 50FPS.

If it should be run-able on an NTSC-A8 it might not work

[José Pereira]

Karol and others less Emkay:

If this way we have 8charsets per each type of level using Interleaved Charsets on the Playing Area gfxs more one for all game Status Area that is around 10KBs per level for screen and data but I'll see how many data for all levels we need. Then we just Load and Put each char on screen on those Interleaved Charsets using that 'mimic bitmap' mode.

 

 

CPC, for example, it's double the A8 with it's 4bpp where each screen takes around 16KBs and each cell/char 2x ours.

And they could get it. Ok, we have more data on the PMGs and on the guys soft sprites because if using charmode then there's also 1 more charline because of the sprites vertical shifting.

Even this I still think we will end up in having used the same amount of Memory as the CPC because our more data 2bpp will almost equal CPC 4bpp.

 

P.s.- My screen 'waste' it's around 11500cycles and PAL running at 50fps has 35568cycles to use... Is there anyone here that can say, that even if it was running at 50fps, that the 24000 free cycles to use we have on A8 for the game build, sprites, sounds,... aren't enough?

Edited January 29, 2013 by José Pereira

[emkay]

 

It might be possible to do PoP on the Atari the same way as it is done on the Apple. I don't know.

 

The most fluent result you get with Antic E and PM underlay "shape mode / no DMA" . This ends up in 3 colour objects with full masking where the CPU has nothing to calculate on.

 

 

Lastly, the easiest (to code) way for these gfx in front of sprite is, as you said, make them soft-sprites. If they are always sitting on char-boundaries they are fast to draw. As long as you are targeting a PAL game (as in 312 scan lines) I do not see any speed problems doing it in 50FPS.

If it should be run-able on an NTSC-A8 it might not work

 

Charmode movement? We're talking about a serious PoP conversion.

It could work, if PMg is used for masking parts of the screen, where chars would clip. Could be an interesting task

[Heaven/TQA]

emkay... dito... you should learn coding A8, too not only Turbo Basic

 

but you both should combine your both abilities in terms of "technical concepts" discussion. as long as it stays on a positive vibe.

[emkay]

 

 

CPC, for example, it's double the A8 with it's 4bpp where each screen takes around 16KBs and each cell/char 2x ours.

And they could get it. Ok, we have more data on the PMGs and on the guys soft sprites because if using charmode then there's also 1 more charline because of the sprites vertical shifting.

 

CPC has an approximatly 3 times faster CPU there. And the Amstrad's CPU has a 16 bit command, handling memory moves faster. AND the Amstrad has a real 16 bit colour mode. No need there to overlay two different calculated layers .... and the CPC game shows tearing...

[José Pereira]

Apple2 pillars aren't exactly 3Bytes wide like I posted on that top picture and all the other gfxs that need masking aren't in chars.

The Game Boy is one that has the masking done in chars, at least on the pillars.

There's no way of building all the game different maskings in just chars boundaries.

 

 

P.s.- CrtXL you should read my posts because I already have each section/part with 64scanlines because it's the only way to use charmode.

[emkay]

emkay... dito... you should learn coding A8, too not only Turbo Basic

 

No time and no need for that.

[emkay]

Apple2 pillars aren't exactly 3Bytes wide like I posted on that top picture and all the other gfxs that need masking aren't in chars.

 

Holy crap. The Pillars ARE 3 bytes on the Apple. You only see 7 pixels instead of 8, because one bit is used for the phase command of the colour generating(Artefacting).

[mrsid]

Still all talk and no code?

Guys, you have plenty of CPU time, the game doesn't run at 50fps

[Creature XL]

Charmode movement? We're talking about a serious PoP conversion.

It could work, if PMg is used for masking parts of the screen, where chars would clip. Could be an interesting task

Didn't mean to imply char-movement. If I said so sorry. What I meant to say, was using 8x16 tiles for example and not 7x16 or what ever.

Soft-sprites in char mode are very use-able and fast. I am pretty sure, everybody still saying bitmap is faster, doesn't calculate-in the cycles you save when storing the background.

Only drawback you have with char-soft-sprites is you limit the chars available for bkg gfx. However, the interleaved mode helps a lot.

 

EDIT:

As said, if I understood you correct you were already using 64 scanlines. I just wanted to make it clear.

But you can't expect me to read all your posts properly. They are way too long.

Edited January 29, 2013 by Creature XL

[mrsid]

Yes, 7 pixels are one byte on the Apple II.

Also don't underestimate the number of characters needed and the requirement of animating the tiles. Bitmap is probably the only feasible way.

[Creature XL]

Still all talk and no code?

Guys, you have plenty of CPU time, the game doesn't run at 50fps

 

You won't see code, unless someone else then Jose talks about PoP.

Not running 50FPS Would be cool, then there wouldn't be any problem with the soft-sprite memory.

As one frame can be used to pre-shift the data of the (N)PCs.

[mrsid]

Not "would". It actually does run at 12fps (NTSC) or 12.5fps (PAL).

[emkay]

Yes, 7 pixels are one byte on the Apple II.

Also don't underestimate the number of characters needed and the requirement of animating the tiles. Bitmap is probably the only feasible way.

I'd still prefer the "3 colour per graphical element" solution in Bitmap mode. But particular the building of graphical elements in straight byte width, saves a lot of CPU cycles, as those parts simply need no bit calculations and work properly for masking.

[Heaven/TQA]

Still all talk and no code?

Guys, you have plenty of CPU time, the game doesn't run at 50fps

 

yup. better said than me... with my ZX Spectrum/CPC example