Prince of Persia

[andym00]

That's an old and much loved trick and unfortunately won't really work on PoP There are so many different animations that really have little to do with each other. There aren't many characters/sprites to work with either, You (Kid), a guard (who has totally different clothes/ a cape), a fat guard, The "shadow" (ok, that one IS you but I'm not sure if the frames are similiar/same), a skeleton and I think the Vizier.

 

Regards the 'shadow', if you read Jordans diaries you see him mention that the shadow is drawn using only the players frames, but then drawn again shifted one pixel left or right, but since it's all drawing using eor drawing you get the outline effect..

[PeteD]

I thought that was the case but wondered why there was a shadow.dat that contains frames. Mechner's doc isn't the most reliable when you get into the nitty gritty of looking at the way things are actually done in some cases so I was leaving leeway for having shadow loaded in ram juuust in case there was something different about it.

 

*edit*

Ahh, it's in his diaries online? I've not read through all of that yet..

 

Pete

Edited November 6, 2009 by PeteD

[mrsid]

I thought that was the case but wondered why there was a shadow.dat that contains frames. Mechner's doc isn't the most reliable when you get into the nitty gritty of looking at the way things are actually done in some cases so I was leaving leeway for having shadow loaded in ram juuust in case there was something different about it.

 

*edit*

Ahh, it's in his diaries online? I've not read through all of that yet..

 

Pete

 

The PC version is obviously doing things differently. On the Apple II Jordan had to use all kinds of tricks to fit it in memory and make it fast, so he recycled the player frames.

 

Hi Andy, btw...

[Heaven/TQA]

I thought that was the case but wondered why there was a shadow.dat that contains frames. Mechner's doc isn't the most reliable when you get into the nitty gritty of looking at the way things are actually done in some cases so I was leaving leeway for having shadow loaded in ram juuust in case there was something different about it.

 

*edit*

Ahh, it's in his diaries online? I've not read through all of that yet..

 

Pete

 

I love the project and the fair discussion so far... honestly. keep it going. I still can not see why POP would not work on 6502 machines...

[PeteD]

I thought that was the case but wondered why there was a shadow.dat that contains frames. Mechner's doc isn't the most reliable when you get into the nitty gritty of looking at the way things are actually done in some cases so I was leaving leeway for having shadow loaded in ram juuust in case there was something different about it.

 

*edit*

Ahh, it's in his diaries online? I've not read through all of that yet..

 

Pete

 

The PC version is obviously doing things differently. On the Apple II Jordan had to use all kinds of tricks to fit it in memory and make it fast, so he recycled the player frames.

 

Hi Andy, btw...

 

Is shadow on a level with another enemy then? There don't seem to be many frames in the .dat so I don't see the difference between that and guard.dat or skeleton.dat being loaded. If he is on a level with a guard as well then of course that makes sense to reuse what's already loaded.

 

 

Pete

[PeteD]

I thought that was the case but wondered why there was a shadow.dat that contains frames. Mechner's doc isn't the most reliable when you get into the nitty gritty of looking at the way things are actually done in some cases so I was leaving leeway for having shadow loaded in ram juuust in case there was something different about it.

 

*edit*

Ahh, it's in his diaries online? I've not read through all of that yet..

 

Pete

 

I love the project and the fair discussion so far... honestly. keep it going. I still can not see why POP would not work on 6502 machines...

 

There is only one reason I can think of and that is ram but then what about the CPC version?

 

*edit*

Obviously I know CPC is Z80 Still needs the same amount of data.

 

Pete

Edited November 6, 2009 by PeteD

[mrsid]

Is shadow on a level with another enemy then? There don't seem to be many frames in the .dat so I don't see the difference between that and guard.dat or skeleton.dat being loaded. If he is on a level with a guard as well then of course that makes sense to reuse what's already loaded.

 

He's basically a guard, with different logic. But I haven't fully reverse-engineered that part yet. He definitely has the same limited amount of animation frames as the guards, i.e. he can't climb or jump or drink potions.

[mrsid]

There is only one reason I can think of and that is ram but then what about the CPC version?

 

*edit*

Obviously I know CPC is Z80 Still needs the same amount of data.

 

Pete

 

AFAIK, it only runs on the 128K CPC 6128, but I'd really like to be proven wrong on that one. I can't confirm

the claim.

[PeteD]

I just tried it on the emu with it set to 64k and it worked fine. Not sure if that's an emu problem or not but I've had other 128k only stuff crap out or tell me I need 128k. Could be that if I played it for a while it would just crash

 

 

Pete

[andym00]

 

*edit*

Ahh, it's in his diaries online? I've not read through all of that yet..

 

Pete

 

Yup There's some fascinating stuff in there about the entire development, lots of technical details, and some interesting points of view (more related to the 'other' thread) about the market position of the various computers at the time

 

But I only went there to have a quick look-see, and ended up reading the next god knows how many years of his life.. But PoP is in some detail there..

 

Other key fact (mentioned when he was trying to get a PC programmer to the port) was that all the clipping/masking is byte aligned, which is rather handy when it comes to making life easy

 

I've not been following this properly since I've hardly any time at all of late, but maybe one option to reduce the data size might be to store the frames as just the outlines, but in a eor'filler friendly format, and then just compress the outlined shapes, and eor fill the frame.. Maybe also applicable to Fist as well ?

 

I personally don't see any problem getting this on any of the 6502s at all.. After all if the Apple IIe can handle the thing any of them can.. The one thing I'd really like to see done well is the Apple Double-HiRes stuff used into the Intro, or at least HiRes please, pretty please

 

 

[andym00]

Hi Andy, btw...

 

 

 

Hey there Andreas.. Didn't expect to see you over in this neck of the woods

All's good I hope

[PeteD]

I've looked at outline+fill, runlength (horizontal based on colour changes) and vertical byte based 0 skipping (and possible runlength on the bytes there too although there are barely ever 2 the same) and there is so little actual data at 2bpp that it all works out at about the same any way you do it. It's also much faster just doing columns of stuff, you can draw it in pretty much any method and mask it with the background easily too. I'm just adding bitpacking to my column compression method which should bring the size down a bit more for a slight speed loss.

 

eg one of the sprites (the standing still one) is 6 mc/clock pixels wide. Some sections of it have transparent/black, white, pink, white again. If you stored those changes as bytes it would take 4 for 1byte+2bits of actual data. You can pack the bits of the runs/edges but you've got to be careful because some of the gaps/runs can be fairly large so really you're going to need at least a nibble for each thing, 2 bytes again.. There are other methods of course, variable bitpacking etc but I really think for the gains they're not worth it on this amount of data. The simplest seems to be the best all round so far.

 

 

Pete

[Rybags]

Maybe a method of keeping the elemental colours of the kid seperated, then merge at render time would work better.

 

The majority of the pixels are the clothing colour. Immediate 50% saving by keeping them seperate, then translating back to 2-bit pixel data before rendering.

 

The skin, hair etc are only small parts of the overall character, so some sort of compression or optimisation could take place there.

[PeteD]

Maybe a method of keeping the elemental colours of the kid seperated, then merge at render time would work better.

 

The majority of the pixels are the clothing colour. Immediate 50% saving by keeping them seperate, then translating back to 2-bit pixel data before rendering.

 

The skin, hair etc are only small parts of the overall character, so some sort of compression or optimisation could take place there.

 

I honestly don't see how you can get things smaller by seperating out their individual components because then you not only need to compress those but also have the info available for where they came from. These sprites when reduced to 4 colour are about as simple as you can get and compressing them very much is near impossible because of that. Adding data to the equation is just going to make them bigger. The only real reason I can get them smaller than the DOS files isn't because my compression is any better, it's simply because there are less colours.

 

Please let me know if you can come up with a good way to do it though because it might solve some problems at least on the A8 version where if the sprites are going to be part PF and part PM there'll be some table reading and stuff to split out the 2bpp data into those 2 formats.

 

I think what is probably best is I just carry on with mine for the C64 and someone else does an A8 one tailored to the problems therein and presume you're going to have min 128k to play with.

 

*edit*

One thing that would save a lot of heartache on A8 is if the sprites could all be done with PMGs. That's not going to happen, they're too wide and have too many colours. It might help with using white as BG colour or something then you've only got to poke holes in the background then use DLIs to move X positions of the PMGs to fill in the pink areas etc.

 

 

Pete

Edited November 6, 2009 by PeteD

[mrsid]

I might just as well let the cat out of the bag now.

I initially decided to keep mum until I'm done, but I don't want anyone to duplicate work just because I didn't tell.

Talking about the project actually makes me less motivated to finish it. I'd rather get on with coding.

 

So to make it short: I've been working on a C64 version of PoP for the last couple of months.

I've recently reached the milestone of having all level elements working, so I can completely play

through a level. The last big missing thing is the guards and the whole sword-fighting stuff.

I'll tackle that next, but I have to do a good round of optimizations first, before I can continue.

Then I'm feature complete, and the rest should fall into place.

 

Some people here have already seen it, but I'm not going to release screenshots or movies to the public just yet.

Mainly because I only use a set of automatically converted graphics, which are ok, but need to be redone by a real graphics artist.

I have someone who's working on that (no, it's not STE'86), but until he had at least a chance of doing a

rough first pass, I don't want anyone to get the wrong impression of the visuals.

I also have someone who's hopefully going to do the music/sfx side of things.

 

That's about it, I'm going to shut up now and go back into underground hacking mode.

I appreciate any comments or suggestions, but I don't have plans to share the development effort with other people at the moment.

I do hope to see an A8 version though, so whoever's going to do it, if they need help with details, I can

probably be of some use.

[PeteD]

As I'm one of the people who have seen it but don't want to say anything about it that mrsid doesn't want known maybe you could give a little more info (if you want) on how you're doing it and the constraints you're working in Will give people more of a clue what is possible on A8 then.

 

 

 

Pete

[mrsid]

As I'm one of the people who have seen it but don't want to say anything about it that mrsid doesn't want known maybe you could give a little more info (if you want) on how you're doing it and the constraints you're working in Will give people more of a clue what is possible on A8 then.

 

My current approach is using a bitmap for the background, and a sprite grid for the characters. The character images are plotted into the sprite grid and masked where necessary with the background. This is the area I'm currently trying to improve. Pretty straightforward really. Memory is a huge problem, but there are ways of optimizing that later. In the meantime I'm using a REU to fit everything in. My main concern is getting all the features in first, not doing any premature optimizations.

[Heaven/TQA]

just again a simple question for the A8 guys... why the hell don't use Antic E bitmap mode and use PMs f.e. for the tourches or other small bits and pieces to spice up?

[Heaven/TQA]

mrsid...

 

for what are you using the hardware sprites? and are you using multiplexor?

[mrsid]

mrsid...

 

for what are you using the hardware sprites? and are you using multiplexor?

 

Hardware sprites are used for kid/guard and their swords. I'm using a basic multiplexer to keep the layout simple.

[Heaven/TQA]

what is your memory footprint on c64?

 

this would give us an idea?

[mrsid]

what is your memory footprint on c64?

 

this would give us an idea?

 

This is not entirely up-to-date, and to be taken with a grain of salt:

 

; $0000-$03FF : Game state

; $0400-$3FFF : Code

; $4000-$5FFF : Bitmap

; $6000-$63FF : Screen + Sprite pointers

; $6400-$6FFF : Sprite buffers

; $7000-$79FF : Seqtable

; $7A00-$7EAF : Framedef list

; $7EB0-$7FFF : Tables 2

; $8000-$A80B : Background imagetable

; $A80C-$AFFF : FREE (might be used by background image table of palace levels)

; $B000-$B5FF : Tables 3

; $BC00-$BDFD : Kid imagetable header

; $BDFE-$BFFF : Kid image buffer

; $C000-$DFFF : Mask bitmap

; $E000-$EBFF : FREE => music/sfx

; $EC00-$F4FF : Level blueprint

; $F500-$FFE8 : Tables

 

Kid image table is in REU bank 0

[Heaven/TQA]

ok... still tough... but I would suspect $0002-$03ff is better?

[mrsid]

ok... still tough... but I would suspect $0002-$03ff is better?

Of course. One of my pet peeve's with the C64 is that they've sacrificed two perfectly fine ZP locations for stupid

I/O which also could've been mapped to $FFF8/$FFF9 or whatever.

 

Do I need to mention that PoP on the Apple II uses every last byte of the ZP?

[+MrFish]

Here's a mockup of a "possible" simple way to do some decent sprites for either a bitmapped or character graphics version:

 

 

Prince

-------

1 Player + 2 Missiles (used for skin only)

 

 

Guard

-------

1 Player + 2 Missiles (1 player + 1 missile for clothing, 1 missile for skin)

 

 

The rest depends on the mode to be used.

 

Bitmapped Graphics

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

The remaining 2 players would be used for the torches & the bottle (split with dli)

 

Character Graphics

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

The remaining 2 players would be used for the bottle & "optionally" enhancing the upper colors of the guard.

 

 

Everything else is just playfield graphics. This is just a mockup, of course. I'll do a couple of G2F pics to illustrate the two methods in the next couple days.

 

These are just ideas/suggestions. Either way, It's fun to do and look at the possibilities.

 

BTW, I believe there is one place in the game where you can actually encounter 2 guards at once, if I'm not mistaken. Anyone recall this? If so, the second guard could be done using playfield graphics only.

Edited November 7, 2009 by MrFish