Prince of Persia

[Rybags]

My recommendation would be 64K, nothing wrong with the occasional disk load. Use extra RAM over that as cache.

 

Then again, I've not thought much about the game - it might well be the case that 128K could be a squeeze.

[PeteD]

After dreaming about this stupid game last night (I hate when I go to bed and can only think of coding) I'm hoping any X movement can be built into the sprite data to save at least pre or runtime shifting of the data as that would be a nightmare in more ways than one. The anims do seem to line up nicely with sections of the screen and they've only got to stick to 8 pixel (4 clock) boundaries so it should be fine. If that's the case then the A8 shouldn't be too different from the C64 but I can already think of overheads on A8 that will steal just that extra bit of ram.

 

Afaik the anims run 15fps on a 60fps system so only every 4th frame but of course you don't want the logic running at that speed as well but it does give some leeway for the depacking/spriting code to be a bit slower.

 

I think aim for 64k, if it's not possible decide on either dropping frames or increasing ram. If there is extra ram found, use it.

 

I doubt I'll have much more to do with this than messing around with the sprite compression because I've got PC tools to finish/rewrite and Exploding Fist to be getting on with so I'm trying to make my code as useful on both machines as possible, I'm not recommending anyone actually use it It might be better (certainly easier) on A8 to just say 128k only and keep the sprites decompressed.

 

 

 

Pete

[pseudografx]

IMHO the dynamics of the game allows for reducing the overal framerate to half of the screen refresh, maybe even third (that would be 30/20fps on NTSC, 25/17fps on PAL system).

The thing I'm afraid of is pre-shifting. After some checking I found out that Kid is able to move in 4 pixel steps (half a char on Atari] which would double the memory requirements of the sprites. However, if the game was running in lower framerate, shifting might be done on-the-fly.

 

Another issue I found is the variable size of the sprites. Kid's sprite can be anything from 5 to 25 pixels wide, not counting the sword. Its height is up to 57 pixels. If the sprite was stored as equally sized frames, this would equal to 7x8 chars, that is, 56 chars just for the Kid. Now subtract another 40-50 chars for the enemy and you end up with about 20 chars for the background. Not to mention that this way the sprite data for Kid would occupy about 90 kB not counting PMG under/overlays. We have to find a more economic way to store the animation frames, otherwise even a 130XE wouldn't suffice.

[Rybags]

Shifting could be sped up with table-lookup, although that then makes for a bulkier soft-sprite routine, plus 768 bytes of table data.

 

Kid width - is that 25 hires or multicolour pixels ?

[mrsid]

i am not sure if this is common knowledge, but a "tile" on the pc version is 64 pixels high and 32 single (16 double pixels) across.

 

the total screen is 3x64 (192) high leaving an 8 pixel strip at the bottom for energy bars.

 

total horizontal width is 10x tiles 320 pixels which would equate to 160 doubles

 

this is exactly the dimensions u need for an a8/c64 conversion

 

so work your tile blocks around that or the game dynamics will not work.

 

Steve

 

This is not quite correct.

The 10x3 pieces that make up the screen are each 32x63 pixels in size.

So 3x63 = 189 (not 192), which leaves room for the top three pixels, which show the screen above the current one.

This is necessary, because you can bump against that top row of 3 pixels, and break loose floors in the

room above you.

 

So the whole background is not nicely aligned with an 8x8 tile grid (vertically). That's because neither the Apple II nor

the PC (or the Amstrad) have a tile-based background mode. They all just use bitmaps.

The only version that actually uses 8x8 tiles to draw the background is the NES version (The NES doesn't

have a bitmap mode). They had to slightly adjust the graphics, so that each block is 32x64. To keep the top

row, they've extended it to 8 pixels high. See: http://www.hardcoregaming101.net/princeofpersia/pop-nes.png

 

Also the drawing is using the Painter's algorithm. Due to the isometric perspective, the blocks overlap. This is explained

in Mechner's pdf on page 6. So the code starts drawing at the lower left of the screen, going to the right, and then continuing

at the floor above that. So this means that there's a large number of possible combinations of blocks that can be to the left

and below, which affect the current block.

Therefore, if you want to use 8x8 tiles to draw all possible block combinations, the number of required tiles explodes to

about 1000. That was not a problem on the NES, but it's pretty hard to solve on the C64.

 

Oh, btw, everything in the game runs at 15fps, the game logic and the animation code.

 

Hope this helps...

[PeteD]

@mrsid, thanks for the info

 

It's good to know it all runs 15fps, gives a lot of leeway with compression and runtime shifting of sprites etc

 

As far as the painter's algorithm, you can still store the tiles normally and build the screen from those using extra chars in the overlapping area. It'll take more than a standard tile set and it'll need something to run through all possible screens to get the total so some charset change DLIs can be done on A8. I think its 32x16 overlap? 8 chars * 9*2 = 216 max extra chars needed? Or am I not thinking that through right? I've been awake since 5am so I'm a bit useless atm If that's right that would be if every overlapping combo was different, I doubt that ever comes close to happening. Still another problem to overcome on A8 with only 128 chars to play with without a charset change, but I think we've all realised it'll need some anyway.

 

Free chars for sprites will probably be a problem. There's always the possibility of doing the chaset per line thing, 40 chars + 7+7 per line for the screen and 2 max size sprites, fill the rest in with sprite data but with ram probably being extremely tight anyway those 40 chars per line are a bit too much of a luxury. You can't build needed chars per line at runtime because the rest of the space would have to be filled with sprite/other data to save wasting 25k just for a screen.

 

Another thing to remember is on the DOS verison, that 37k file is just for 1 direction of sprites. If I can get that down to 1/2 the size it's still going to need a reversing routine. Simplest is a lookup to get the data flipped, more ram gone..

 

 

@Rybags, that's 25 a8 clocks, 50 "hires". Ste has chopped down the couple that are 25 to 24 so they fit in 2 c64 hardware sprites and therefore 6 chars.

[mrsid]

As far as the painter's algorithm, you can still store the tiles normally and build the screen from those using extra chars in the overlapping area. It'll take more than a standard tile set and it'll need something to run through all possible screens to get the total so some charset change DLIs can be done on A8. I think its 32x16 overlap? 8 chars * 9*2 = 216 max extra chars needed? Or am I not thinking that through right? I've been awake since 5am so I'm a bit useless atm If that's right that would be if every overlapping combo was different, I doubt that ever comes close to happening. Still another problem to overcome on A8 with only 128 chars to play with without a charset change, but I think we've all realised it'll need some anyway.

 

Not saying that it's impossible with tiles, but it will be extremely hard. Also, even if you can draw every possible screen that way, you still have not covered the problem of the animated background.

Just think of the opening/closing gates, the torches, or the falling floor pieces. There can be a lot of them at the same time, check some of the later levels in the playthrough videos on youtube.

 

So I guess in the end you'll probably find out that a bitmap is the best possible solution.

Edited November 5, 2009 by mrsid

[PeteD]

 

So I guess in the end you'll probably find out that a bitmap is the best possible solution.

 

That was actually my first thought

 

 

Pete

[Heaven/TQA]

I have always the Apple 4 col bitmap version in my mind...so why not trying to come up with Antic E? will that complicate things? of course the engine of the animation and draw screen routines will differ than from c64 to a8 but we could layout the A8 screen in standard 3 lines per charset and in c64 order so at least the engine can be similiar on both?

 

the sprite routine itself would be than a bitmap version with masking? and on c64 the hardware sprites would be used...

 

Animation of the background tiles seems to be the same like with the other bitmap versions, apple, cpc and speccy?

[PeteD]

I think if a decision to go with more ram or a cart to store the game is made for A8, all kinds of possible methods become open to use.

 

 

Pete

[Rybags]

I think it's a gimme that some compromises would be necessary, especially for 64K.

 

Character set usage mightn't be as bad as we might think - the kid may well have animations that need 25 characters, but they don't all appear on the one row.

 

Worst case scenario should be that 1 charset needed per 2 text lines, but I don't think it'd come to that.

 

1 charset per 3 text lines is more expensive than a bitmap of equivalent size, but IMO a small sacrifice for the extra colour and flexibility.

[analmux]

a real doddle til u work out that the sprites just for u take up about 50k

 

then it becomes somewhat more stressful

 

but as long as u can comprees the backgrounds, the engine and the music into 14k then you are away

 

Steve

We still could switch to a cartridge based version instead.

Nowadays we have flashcart (up to 1mbyte) and some guys here who could produce custom cartridges.

Just store all depacked, preshifted etc. sprite data in the cartridge area.

Code also.

RAM only needed to unpack level data & maybe some unrolled code loops etc.

 

 

...but isn't it time to ask who will do the port?

[GroovyBee]

Or you could just do a 7800 port . It has the painters algorithm built into the hardware with MARIA . All you need to do is arrange the Display List entries accordingly when you build the screen.

[José Pereira]

Hello all.

 

Like PeteD I sleep with this game on mind. Soo, I create this:

 

 

 

PF0-White

PF1- Middle Grey

PF3- Dark Grey

 

I've Put Backr.-Black on Top and Bottom. On the Playing area I put Backgr.-Darkest Grey(Colour nº02).

Like I said yesterday I change the flames to PF2. With many DLIs you have now different colours on different objects.

And the best is that in each Level you create the DLIs. for the first screen, all the others have the same DLIs. on the same lines nºs. This pictures proves that none of this objects are on the same lines and the DLI line it's the same nº for all Level:

 

 

 

 

 

 

And the same apllys to the other Levels (The Palce ones):

 

 

 

 

 

 

 

The Palace Levels can also have PM2/3 or P2/3 for this (if you use this for Enemy, it will never be on this Lines):

 

 

 

 

I use White as PF0, so that you can use it for our "Kid" Clothes and the Sword. Also for the Sword and some of the Enemy's clothes.

 

 

Two things to fix now:

1st - How to construct screen/Charsets.

2nd - Priority between "Kid" and the Walls.

 

 

 

For the second I think we can do as Analmux says: Always PRIOR1 and only change to PRIOR8 on that parrticular cases. I don't see any problem here. And you can use PF3/5th Player on that front Rocks.

 

About the first, and seen all the Maps I am trying to cut some lines and join all different objects, I'll try to post something about this today... I had an idea... I don't know if it works...

 

 

Bye now,

José Pereira.

[José Pereira]

Hello all.

 

Like PeteD I sleep with this game on mind. Soo, I create this:

 

 

 

PF0-White

PF1- Middle Grey

PF3- Dark Grey

 

I've Put Backr.-Black on Top and Bottom. On the Playing area I put Backgr.-Darkest Grey(Colour nº02).

Like I said yesterday I change the flames to PF2. With many DLIs you have now different colours on different objects.

And the best is that in each Level you create the DLIs. for the first screen, all the others have the same DLIs. on the same lines nºs. This pictures proves that none of this objects are on the same lines and the DLI line it's the same nº for all Level:

 

 

 

 

 

 

And the same apllys to the other Levels (The Palce ones):

 

 

 

 

 

 

 

The Palace Levels can also have PM2/3 or P2/3 for this (if you use this for Enemy, it will never be on this Lines):

 

 

 

 

I use White as PF0, so that you can use it for our "Kid" Clothes and the Sword. Also for the Sword and some of the Enemy's clothes.

 

 

Two things to fix now:

1st - How to construct screen/Charsets.

2nd - Priority between "Kid" and the Walls.

 

 

 

For the second I think we can do as Analmux says: Always PRIOR1 and only change to PRIOR8 on that parrticular cases. I don't see any problem here. And you can use PF3/5th Player on that front Rocks.

 

About the first, and seen all the Maps I am trying to cut some lines and join all different objects, I'll try to post something about this today... I had an idea... I don't know if it works...

 

 

Bye now,

José Pereira.

 

What happen to my .png pictures?

[José Pereira]

Hello all.

 

Like PeteD I sleep with this game on mind. Soo, I create this:

 

 

 

PF0-White

PF1- Middle Grey

PF3- Dark Grey

 

I've Put Backr.-Black on Top and Bottom. On the Playing area I put Backgr.-Darkest Grey(Colour nº02).

Like I said yesterday I change the flames to PF2. With many DLIs you have now different colours on different objects.

And the best is that in each Level you create the DLIs. for the first screen, all the others have the same DLIs. on the same lines nºs. This pictures proves that none of this objects are on the same lines and the DLI line it's the same nº for all Level:

 

 

 

 

 

 

And the same apllys to the other Levels (The Palce ones):

 

 

 

 

 

 

 

The Palace Levels can also have PM2/3 or P2/3 for this (if you use this for Enemy, it will never be on this Lines):

 

 

 

 

I use White as PF0, so that you can use it for our "Kid" Clothes and the Sword. Also for the Sword and some of the Enemy's clothes.

 

 

Two things to fix now:

1st - How to construct screen/Charsets.

2nd - Priority between "Kid" and the Walls.

 

 

 

For the second I think we can do as Analmux says: Always PRIOR1 and only change to PRIOR8 on that parrticular cases. I don't see any problem here. And you can use PF3/5th Player on that front Rocks.

 

About the first, and seen all the Maps I am trying to cut some lines and join all different objects, I'll try to post something about this today... I had an idea... I don't know if it works...

 

 

Bye now,

José Pereira.

 

What happen to my .png pictures?

 

 

 

Let's try again:

 

Dungeons PF2 DLIs. changes:

 

 

Palace Levels: PF2 DLIs. changes:

 

 

 

Palace (to use P2/3 here):

Palace_Top Logo.bmp

 

 

Let's all pray and/or cross the fingers that now it works...

José Pereitra

 

 

Player's and Enemy's clothes and Swords (PF0-white):

Kid.bmp

Enemy.bmp

Kid.bmp

Enemy2.bmp

[José Pereira]

It worked. But here is the MrFish screen I redone with all that PF2 DLIs. lines changing:

 

 

All done in the same way as on the first Post.

 

But I still don't see why I couldn't send the "Kid" and Enemy as .png and have to change them to .bmp...

 

José Pereira.

[pseudografx]

Shifting could be sped up with table-lookup, although that then makes for a bulkier soft-sprite routine, plus 768 bytes of table data.

 

Kid width - is that 25 hires or multicolour pixels ?

It's already converted to multicolour. The original sprite is up to 51 pixels wide (that is, for the PC version).

[STE'86]

excluding the sword fighting sprites, in which the sword is added separately, the largest sprite i have found so far is as stated 51 pixels wide (hires 1:1). the tallest is 53 pixels high, but when that happens the player is only about 14 pixels wide (hires 1:1 (7 multicolour) ).

 

however the frames i have converted never exceed 48 pixels (or 24 2:1 multicolour) which is the edited version of the 51 pixel sprite in the long jump.

 

Steve

Edited November 5, 2009 by STE'86

[mrsid]

excluding the sword fighting sprites, in which the sword is added separately, the largest sprite i have found so far is as stated 51 pixels wide (hires 1:1). the tallest is 53 pixels high, but when that happens the player is only about 14 pixels wide (hires 1:1 (7 multicolour) ).

 

however the frames i have converted never exceed 48 pixels (or 24 2:1 multicolour) which is the edited version of the 51 pixel sprite in the long jump.

 

Highest one is 57 pixels (middle of hanging straight), widest one is 56 pixels (middle of running jump).

Edited November 5, 2009 by mrsid

[PeteD]

excluding the sword fighting sprites, in which the sword is added separately, the largest sprite i have found so far is as stated 51 pixels wide (hires 1:1). the tallest is 53 pixels high, but when that happens the player is only about 14 pixels wide (hires 1:1 (7 multicolour) ).

 

however the frames i have converted never exceed 48 pixels (or 24 2:1 multicolour) which is the edited version of the 51 pixel sprite in the long jump.

 

Highest one is 57 pixels (middle of hanging straight), widest one is 56 pixels (middle of running jump).

 

Widest unedited running jump sprite I've got is 50 and tallest hanging is 54 ? From the DOS .dat files, exported with pr.exe

 

 

Pete

[mrsid]

Widest unedited running jump sprite I've got is 50 and tallest hanging is 54 ? From the DOS .dat files, exported with pr.exe

 

Oh, I guess you're cutting off the black pixels on the edge. I'm basing off of the Apple II animation tables, and there

everything is byte aligned, so there are extra margins on some frames. Removing them would cause image positioning problems.

 

Btw, have you looked at the freeprince project? It's an open-source reimplementation of the PC version. It shows how hard it

is to duplicate that animation state machine.

[PeteD]

There's black pixels still in these exported sprites, Ste has cut them out to get them in C64 hardware sprite size, then there's no positioning problems because you just move the hardware sprites to compensate.

 

Yeah, I've checked out freeprince, not looked at any code or anything though. If I was going to work on this I'd want to do it from scratch myself as I find working from something like a PC verison of a game gets you stuck in a rut of over-engineering things and that will mean no 8bit version..

 

*edit*

 

Middle frame of "standing" jump is 56 with black

 

Pete

Edited November 5, 2009 by PeteD

[Rybags]

I had a bit of a mad idea before I went to sleep last night:

 

How about some sort of "skeletal" animation system? Draw the player/enemies in sections.

Initial idea was to actually do rendering, but I feel that would likely use enormous CPU resources.

 

But, something like treating the upper and lower body as seperate animation entities?

Could some savings be had by using common animation sequences e.g. leg movement for walking/running combined with seperate upper body sequences e.g. upright, not much arm movement for walking and more active upper body when running.

[PeteD]

I had a bit of a mad idea before I went to sleep last night:

 

How about some sort of "skeletal" animation system? Draw the player/enemies in sections.

Initial idea was to actually do rendering, but I feel that would likely use enormous CPU resources.

 

But, something like treating the upper and lower body as seperate animation entities?

Could some savings be had by using common animation sequences e.g. leg movement for walking/running combined with seperate upper body sequences e.g. upright, not much arm movement for walking and more active upper body when running.

 

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.

 

The enemy sprites don't have many frames and there is only one enemy per level afaik (different palettes), it's the 220 for Kid that would ever be the real problem. Easiest would be to remove some choice frames here and there but not on the more visible anims.

 

 

 

Pete