Wich one of these two Prince of Persia you prefer?

[José Pereira]

Sprites and colours&luminances (can be others) apart, what of these two Rocks type you think look better designed/better looking:

Your voting please...

 

 

P.C.:

C64:

 

 

(don't say anything... the guys aren't coloured yet )

Edited October 10, 2011 by José Pereira

[sack-c0s]

I prefer the C64 way to be honest, but I wouldn't overdo the colouring just because you have lots more colours available. I'd be inclined towards maybe finding a better fit for the highlight colour (if there is one) but otherwise keeping it like that.

[potatohead]

IMHO, this game is all about the animation, and the various movement options.

 

Just played it on the Apple ][ this weekend. Even at 1Mhz, the character moved very nicely. That computer has more colors available on it's high-res screen than I am seeing here, and it "looked" nice, but... that isn't really core to the game. The main character is just white, and I'm sure that was done for speed both due to the CPU clock, and the convoluted high-res and double high-res screens. What I like is the simple white or black character brings the minds eye right to the motion. There is some art there, I am sure. Coloring things actually might distract from that, even though that presentation is often done to deal with other constraints in play.

 

A faster machine, particularly one with sprites should be able to make the motion 2X fluid, and do so consistently. That's the primary metric, IMHO. When that's said and done, the "window dressing" then is a nice to have. Put another way, if the motion is the same, only color improvements done, there isn't a lot of value added to the experience overall.

Edited October 10, 2011 by potatohead

[emkay]

How about using an Antic Mode for it. Since we have square stones and the depth angle is fixed, the low resolution will not look that bad. Antialiasing will be cheap then.

No need for special colour DLIs then.

The protagonist could be build on all PMs, missiles could enhance it a bit.

Let the enemies flicker, if needed.

 

Or use gr. 10 with 9 colours. The colour registers will solve the priority problem.

 

GR.9 Mockup....

 

Edited October 10, 2011 by emkay

[sack-c0s]

That looks quite blurry to me, and PoP is more about the fluidity of the movement than the colour depth. That implies to me that the priority is to trade off colours for resolution.

[SlowCoder]

The shading of the PC version is more calm, which I like. But the stone detail of the C64 version looks nicer. Either way, I always liked that game.

[José Pereira]

Like to see you were talking in a good way...

In this time I just made something...

Only 4votes by now but it's 100% for the C64 looking and that is the best to get something good and simply on A8...

 

 

Technically it's like this:

-> PRIOR0

-> Our guy: PM0&PM1

-> Enemy: PM2&PM3

-> DLIs. on the PF3 for Torches, Bottles,...

-> PF0: White on Rocks/Palace Yellowish Lines/... gives you the colour of the 'Kid' Clothes and the Swords, but also (PMs0&1 Ored PF0) gives you the Skin Light Brown colour

-> I have seen all Levels to get our guy PRIOR0 with PF1 but also the Enemy (and there are more than one coloured Enemy...)

-> Guys frames and PMs. confirmed with all the games frames sprites from C64 real ones that STE86 done some time ago.

 

 

Now it's just someone builds a Soft Sprite Routine and the Charsets stuff (sure C64 uses all it's 256chars, the Torche Fire seems Hardware sprite, the Charset sure is full of chars)

Edited October 10, 2011 by José Pereira

[José Pereira]

Better looking guy Skin vs Backgr. Gfxs. colours:

(The guy with Blonde Hair also looks better)

[PeteD]

C64 version is in bitmap mode not chars, one of the reasons for it being cart only..

[+MrFish]

Better to just post this link Jose, if you want to turn us on to the soon to be released C64/128 version: http://noname.c64.or...318&firstpost=2

It looks like an awesome job. Hats off to those who pulled it off.

[José Pereira]

C64 version is in bitmap mode not chars, one of the reasons for it being cart only..

Hi, PeteD have just post asomething about Pop on FormatWar about our in the past talking and your '?' of how will I get the STE86 frames into A8.

Now I just don't need any of those 'tricky' solutions

[PeteD]

C64 version is in bitmap mode not chars, one of the reasons for it being cart only..

Hi, PeteD have just post asomething about Pop on FormatWar about our in the past talking and your '?' of how will I get the STE86 frames into A8.

Now I just don't need any of those 'tricky' solutions

 

Well from the work me and Ste did on C64 PoP I think it'll fit into 64k (with a bit of squeezing) and it uses char mode (variable amounts of chars as it builds a new charset for each screen by doing the painters algorithm drawing and checking for existing chars to reuse). The biggest problem on the A8 was and still is if you're mixing chars and PMs for drawing the guys it's a lot harder to a) compress them as you're kind of compressing two lots of stuff and b) draw/mask them with the background objects such as the columns they have to go behind. If they could all fit into PMs it would basically be the same as the C64.

[José Pereira]

C64 version is in bitmap mode not chars, one of the reasons for it being cart only..

 

 

Oops, forgot to what I really want to say/quoting...

Yes, I saw that. It's all in 4colours, the Torches/Fire burning are Hardware sprites.

Yes, that the problem on Pop, the great number of Chars, they are more than 256chars that's for sure the reason why the C64 coder went into Bitmap Mode.

But if not scrolling, we can go for a 'pseudo Bitmap Mode' using ANTIC4 Char-Mode on A8 (same way as we would do on a Last Ninja '->A8' conversion)

[José Pereira]

C64 version is in bitmap mode not chars, one of the reasons for it being cart only..

Hi, PeteD have just post asomething about Pop on FormatWar about our in the past talking and your '?' of how will I get the STE86 frames into A8.

Now I just don't need any of those 'tricky' solutions

 

Well from the work me and Ste did on C64 PoP I think it'll fit into 64k (with a bit of squeezing) and it uses char mode (variable amounts of chars as it builds a new charset for each screen by doing the painters algorithm drawing and checking for existing chars to reuse). The biggest problem on the A8 was and still is if you're mixing chars and PMs for drawing the guys it's a lot harder to a) compress them as you're kind of compressing two lots of stuff and b) draw/mask them with the background objects such as the columns they have to go behind. If they could all fit into PMs it would basically be the same as the C64.

 

 

But you know that to get the same as C64 it would be exactly the same you see here, but when two guys they will Flicker...

I have in UWOL and Creatures2 soft sprites and PMs. overlays but not that Rocks/Pillars Mask need. But that is workable the same way as it would be in Last Ninja.

 

LN and Pop are in the same type because there's not much going on screen... And the guys nº of bytes size are almost the same.

If for LN it would work then here it would also work.

 

If Apple2 worked and it is Soft Sprite only, I think that more the PMs. overlay would still be possible.

Edited October 10, 2011 by José Pereira

[José Pereira]

The Tree, Sun and Blood are PMs only and the Big Creature and RadCliffe are soft sprites, only the Big Creature has PM3 overlay

(on previous screen it goes behind the Tree)

 

But here it's impossible to have the Pillars as PMs only and still have PMs to cover the guys

Edited October 10, 2011 by José Pereira

[+MrFish]

Better to just post this link Jose, if you want to turn us on to the soon to be released C64/128 version: http://noname.c64.or...318&firstpost=2

It looks like an awesome job. Hats off to those who pulled it off.

My bad. I now see you already posted it over in the "argument thread". I wasn't in the mood to go in there this morning.

[PeteD]

Like I said above (or at least tried to), the chars needed for each "individual screen" will fit into a single 256 chars (which doesn't really help the A8). The reason it's bitmap on Mr SIDs version is he's chosen to reverse engineer the Apple version and use as much code and data as he can which has resulted in a screen that has tiles that are 63 pixels high so you end up with nothing being on char boundaries which would result in way too many unique chars if you don't just dump it all into a bitmap. Moving the graphics just that 1 pixel (and shifting a few things left or right) means you can fit everything nicely into the 256 chars.

 

On the A8 you'd no doubt have to go for a new set of characters every X number of lines to allow for all that stuff and the soft spriting. Because of that you're already looking at more ram usage than the C64 so it's going to be an >64k machine OR a cart If people are happy with that conclusion then my explanation of the difficulties in the soft+hard sprite mix (post above somewhere) becomes somewhat moot because you can spend the extra RAM/cart space on allowing a compression method that handles the 2 parts separately. Doing that means you can come up with a less processor intensive decompression which means despite having to work on chars AND PMs the A8s extra bit of CPU grunt should take up the slack..

[high voltage]

Apple ][ is the original version, not PC

[José Pereira]

Like I said above (or at least tried to), the chars needed for each "individual screen" will fit into a single 256 chars (which doesn't really help the A8). The reason it's bitmap on Mr SIDs version is he's chosen to reverse engineer the Apple version and use as much code and data as he can which has resulted in a screen that has tiles that are 63 pixels high so you end up with nothing being on char boundaries which would result in way too many unique chars if you don't just dump it all into a bitmap. Moving the graphics just that 1 pixel (and shifting a few things left or right) means you can fit everything nicely into the 256 chars.

 

On the A8 you'd no doubt have to go for a new set of characters every X number of lines to allow for all that stuff and the soft spriting. Because of that you're already looking at more ram usage than the C64 so it's going to be an >64k machine OR a cart If people are happy with that conclusion then my explanation of the difficulties in the soft+hard sprite mix (post above somewhere) becomes somewhat moot because you can spend the extra RAM/cart space on allowing a compression method that handles the 2 parts separately. Doing that means you can come up with a less processor intensive decompression which means despite having to work on chars AND PMs the A8s extra bit of CPU grunt should take up the slack..

 

 

Great to know that my idea can work.

[José Pereira]

quote name='high voltage' timestamp='1318278403' post='2386517']

Apple ][ is the original version, not PC

 

Thanks, but I know that... I said original in the 'clear looking Gfxs type'

 

On Apple2 if you see things at some distance or the screen in a small size it looks coloured and O.k.:

 

But in a T.V. if there wasn't the artifacting it would look like this:

[emkay]

 

 

Like I said above (or at least tried to), the chars needed for each "individual screen" will fit into a single 256 chars (which doesn't really help the A8). The reason it's bitmap on Mr SIDs version is he's chosen to reverse engineer the Apple version and use as much code and data as he can which has resulted in a screen that has tiles that are 63 pixels high so you end up with nothing being on char boundaries which would result in way too many unique chars if you don't just dump it all into a bitmap. Moving the graphics just that 1 pixel (and shifting a few things left or right) means you can fit everything nicely into the 256 chars.

 

 

On the A8 you'd no doubt have to go for a new set of characters every X number of lines to allow for all that stuff and the soft spriting. Because of that you're already looking at more ram usage than the C64 so it's going to be an >64k machine OR a cart If people are happy with that conclusion then my explanation of the difficulties in the soft+hard sprite mix (post above somewhere) becomes somewhat moot because you can spend the extra RAM/cart space on allowing a compression method that handles the 2 parts separately. Doing that means you can come up with a less processor intensive decompression which means despite having to work on chars AND PMs the A8s extra bit of CPU grunt should take up the slack..

 

 

 

 

Great to know that my idea can work.

 

 

 

 

 

Really?

 

 

Colour mode and big Softwaresprites, we have in Karateka. And it's rather slow. And the screen is less high.

 

Now we try to use charmode + Softwaresprites + PM overlay + 200 lines?

 

How about :Forget it?

 

Possibly it could be reached with full preshifted objects. Even then it might not be fluent.

[PeteD]

 

 

 

Really?

 

 

Colour mode and big Softwaresprites, we have in Karateka. And it's rather slow. And the screen is less high.

 

Now we try to use charmode + Softwaresprites + PM overlay + 200 lines?

 

How about :Forget it?

 

Possibly it could be reached with full preshifted objects. Even then it might not be fluent.

 

Go take a look at the code and exactly how Karateka works then you'll be able to make an informed comment

[emkay]

 

 

The scene in Karateka always shows 4 colours. There seem to exist one or two DLIs.

Screensize is max 182 lines . No complex colour register filter or PM overlay is used.

 

 

[José Pereira]

Like I said above (or at least tried to), the chars needed for each "individual screen" will fit into a single 256 chars (which doesn't really help the A8). The reason it's bitmap on Mr SIDs version is he's chosen to reverse engineer the Apple version and use as much code and data as he can which has resulted in a screen that has tiles that are 63 pixels high so you end up with nothing being on char boundaries which would result in way too many unique chars if you don't just dump it all into a bitmap. Moving the graphics just that 1 pixel (and shifting a few things left or right) means you can fit everything nicely into the 256 chars.

 

 

On the A8 you'd no doubt have to go for a new set of characters every X number of lines to allow for all that stuff and the soft spriting. Because of that you're already looking at more ram usage than the C64 so it's going to be an >64k machine OR a cart If people are happy with that conclusion then my explanation of the difficulties in the soft+hard sprite mix (post above somewhere) becomes somewhat moot because you can spend the extra RAM/cart space on allowing a compression method that handles the 2 parts separately. Doing that means you can come up with a less processor intensive decompression which means despite having to work on chars AND PMs the A8s extra bit of CPU grunt should take up the slack..

 

 

 

 

Great to know that my idea can work.

 

 

 

 

 

Really?

 

 

Colour mode and big Softwaresprites, we have in Karateka. And it's rather slow. And the screen is less high.

 

Now we try to use charmode + Softwaresprites + PM overlay + 200 lines?

 

How about :Forget it?

 

Possibly it could be reached with full preshifted objects. Even then it might not be fluent.

 

 

Values including shifting:

-> Price of Persia maximum size each guy it's about 30chars=240bytes x 2guys=480bytes

->Yie Ar Kung Fu over Gfxs. Bitmap Mode have two soft Sprites and PMs overlays it's 280bytes that is about, more than 400/500bytes the two guys

-> Yie Another Kunf Fu (remake) uses ANTIC4 Char-Mode with the same size as the previous one but with more chars needed on the vertical shifting and it works really fast.

You have there at least each Player 8chars Tall (that is one more char tall than on PoP)

Yie Another Kung-Fu (emulator included).zip

Edited October 10, 2011 by José Pereira

[emkay]

-> Yie Another Kunf Fu (remake) uses ANTIC4 Char-Mode with the same size as the previous one but with more chars needed on the vertical shifting and it works really fast.

 

 

Yie Ar Kung Fu doesn't do background handling. The enemies always move in the blank region. It's also using only one charset for the enemy. AND it doesn't use PM overlay...

Edited October 10, 2011 by emkay