Wich one of these two Prince of Persia you prefer?

[PeteD]

BTW, the tiles have all been redrawn into chars on char boundaries with the overlap (tile over tile to it's left) and masking (columns etc) areas made as code friendly as possible by me and Ste for the C64 version we started working on a while back. They're probably about as close to optimal as they can be for the A8 without them looking weird.

[sack-c0s]

why do I get the feeling at this rate mrsid is going to give up and code the damn thing himself on the Atari?

[mrsid]

I used the source code documentation mentioned earlier here (http://jordanmechner.com/wp-content/uploads/1989/10/popsource009.pdf) and a memory capture from an Apple 2 emulator.

[mrsid]

why do I get the feeling at this rate mrsid is going to give up and code the damn thing himself on the Atari?

Not a chance, the stuff you guys talk about here, PM0, GR.17, PF, is all gibberish to me. I only have a very basic understanding of how an 8-bit Atari works, and no real interest in learning more.

[Heaven/TQA]

Mrsid... come on... Pete & Sack can help you out.... TMR is more on Shoot 'em ups...

[Heaven/TQA]

and mrsid... let's say... A8 gives you a linear 160x240 4 color bitmap mode... should be possible?

[potatohead]

Seems to me like the Apple code could be used for things like the animation, decisions, etc... New renderer code would be needed for any other platform though. The original had graphics on byte boundaries too. The 7 bits of graphics data / byte on Apple warrants a re-do of the graphics to work for 8 bits of graphics data / byte offered elsewhere.

[Heaven/TQA]

so actually on Apple 2 a 16 pixel graphics would need 3 apple bytes?

[Rybags]

1 byte in Apple bitmap = 7 pixels. The other bit decides colour choices.

 

Either way, using C64 or Apple 2 code, the graphics system for bitmap is suffiently different to make porting not so straightforward.

[mrsid]

No, actually it's very straightforward. A byte is still a byte, doesn't matter if it has 7 or 8 pixels. The Apple 2 code does everything internally in bytes, when painting background tiles. Each tile is 4 bytes wide and can only be placed a one of 40 X-Coordinates.

The character is tracked with a 140 pixel X-Coordinate, which you need to map to 320 pixels. That's a simple lookup table.

[Heaven/TQA]

and the gfx on the apple was stored %11111110 11111110 which need to converted to %1111111111111100 ??

[mrsid]

No, you have to redesign the graphics anyway, or use my C64 ones. On the Apple 2 the highest bit is the color shift bit, the other 7 bits are visible.

 

You change graphics like %x1111111 %x1111111 (a 2 byte wide pillar) into %11111111 %11111111.

So something that is 14 pixels wide becomes 16 pixels wide. Since your whole screen is also larger by that ratio, 280 pixels vs. 320 pixels, it works out perfectly.

 

Still, all the high-level drawing code stays the same, the graphics data is even the same amount of bytes in memory.

[Heaven/TQA]

well... then take the gfx set of the c64 version... and STE can give us the sprite definitions which can be converted simply from .spr format to bitmap format (21 bytes per sprite collum)

[emkay]

well... then take the gfx set of the c64 version... and STE can give us the sprite definitions which can be converted simply from .spr format to bitmap format (21 bytes per sprite collum)

 

How many screens does the game have exactly? What could be reused? Using the Apple pictures, making the pillars to 3 bytes and change the stones from one to two colours shouldn't be a life's work to do

[mrsid]

What does that matter? The screens are dynamically generated from a small set of bitmaps. There's a maximum of 24 screens per level, 14 levels in total.

[Heaven/TQA]

mrsid... what is the memory print of the c64 version? wich area in ram is the "banking" done? if it is a similar model (f.e. 16k window at $8000) even code could be reused...

 

and is there any chance to have pictures of all background tiles to see how many they are?

[emkay]

 

What does that matter? The screens are dynamically generated from a small set of bitmaps. There's a maximum of 24 screens per level, 14 levels in total.

 

 

 

So the screengraphics were the least problem.

 

[mrsid]

I use almost all RAM in the C64, there's only a bit left under the IO area. ROM banks are visible at $8000 and $a000 (sometimes they are disabled to read RAM at those locations).

 

There are 131 images used in dungeon levels, you can get them here: http://twinbirds.com/bgtab_c64.zip

Palace levels have more, but let's deal with those later...

[Heaven/TQA]

thanks. so actually still see no problem... here are the PNG, convert them to bitmap format (in collums format for easy LDA,x STA (),Y and the "draw procedure" would need a small update... I guess that these blocks are the ones referreded in the docs?

[José Pereira]

I use almost all RAM in the C64, there's only a bit left under the IO area. ROM banks are visible at $8000 and $a000 (sometimes they are disabled to read RAM at those locations).

 

There are 131 images used in dungeon levels, you can get them here: http://twinbirds.com/bgtab_c64.zip

Palace levels have more, but let's deal with those later...

 

EDIT: Delected, sorry...

Edited October 13, 2011 by José Pereira

[Heaven/TQA]

and what about the masks?

[mrsid]

and what about the masks?

They are included in that .zip

[potatohead]

Earlier in this thread the core game structure document was linked. Go read it. The room graphics are well documented, including the draw order, methods, etc...

 

On Atari, BTW the lookup table would then map 160 pixels to 140 pixels? No 320 pixel positioning possible on Atari, unless somebody wants to do this one on the high res screen.

[Heaven/TQA]

mrsid... sorry... did not went through all PNGs on my Mac... esp. the small ones...

 

for drawing the background i am sure you don't need the 320x mapping... so the 320x is for the sprites for the c64... but on A8 when using softsprites no mapping is needed anyway.

[José Pereira]

DELECTED

Edited October 13, 2011 by José Pereira