Amstrad Prince of Persia Screenshots?

[STE86]

i have already redone almost all of the graphics based on an 8x8 grid and aligned to character edges.

to do so would require a c64 version to use tiles based on a 64 pixel height instead of the pc/apple versions 63 pixels. i realise that it is set to 63 to enable the 3 pixels at the top to be used for the  tiles from the screen above. however at 64 pixels high 3 levels would make 192 out of 200 lines, the top 8 could then be used for the blocks from above. this however would mean there was no room for the "life" bars and timer, so the most obvious solution to this on the c64 would be to open the bottom border and sprite them in there.

locking the c64 to 64 pixel high tiles would have the effect of reducing the character count by 2/3 as the characters in the tiles for each of the 3 "levels" on a screen would then be repetitious.

the attached image generates somewhere in the region of 125 characters (i think) and another point is that the 256 character limit only applies per screen and not all tiles are used on each screen so maybe it is reasonable to "construct" your character set as you need it dynamically?

bearing in mind that there are many characters that are common to all screens. many of which are on that screen below and that generally speaking only the left edges of the floor tiles would change with any frequency and they only number 3 or 4.

[sigh]

Nice to see an example which also looks great. Do you have an image of the sprite and enemy? Would be nice to see the whole mock up.

[mrsid]

You know that you'll also need to animate those screens, right? Gates moving down, jaws chopping, floors jiggling, torches with flickering flames, and constantly build a mask every frame for the player and enemy sprites. Also any of those tiles can be partially obscured by the block to the right (and they are in many levels).
And didn't you cheat there with the flame colors? Or are those supposed to be sprites?

[STE86]

well i figure that certain liberties would need to be taken on the animation. to make it work.

the gates for instance "could" animate on 8 pixels steps, you will also note that the grid on the gate for the most part is a single tessellating character and only the 4 or so at the bottom would need to change once to being on black background.

jiggling of the floors could be done by swapping character definitions. The left and right sides of the raised "pressure" tile can double as jiggly floor. swapping alternately. the falling of them would cause some aggro, but if they fell on 8 pixel steps this could be minimised.

torch flames tho not shown on this pic i have defined currently as hi res 1 char wide and 2 high 3 frame animation in characters. their graphics are never crossed so 2 bytes of colour ram could be used to colour them and flickered like mad thru white, yellow and red to provide a flame look i think.

you will also notice that the outline brickwork is currently depicted as dark blue colour ram currently conjectural.

chompers can again animate on 8 pixel boundaries and again will use minimal additional "edge" characters something like the pic below (the white stripe of color ram is also conjectural at this time).

pretty much all of the blocks to the right that intrude are solid characters like wall and you will note that i have repositioned the twin square columns slightly so their left edges are byte based (blocked on rather than sprited on)
masking against columns would therefore become an exercise in knocking uniform vertical stripes out of sprites. going behind and infront of chompers could still be a royal pain in the arse to do tho

[andycadley]

Well the C64 can, IIRC, put sprites either in front of or behind the foreground. So assuming you can avoid situations that need both it's probably possible to let the hardware handle sprite masking for you.

[PeteD]

Well the C64 can, IIRC, put sprites either in front of or behind the foreground. So assuming you can avoid situations that need both it's probably possible to let the hardware handle sprite masking for you.

When you do the sprites behind foreground using hardware they don't go behind ALL the colours   they still appear over background and one of the other colours (can never remember if its the character colour or one of the multicolours).   Masking the sprites in software isn't a problem though.

[TMR]

When you do the sprites behind foreground using hardware they don't go behind ALL the colours   they still appear over background and one of the other colours (can never remember if its the character colour or one of the multicolours).

If memory serves, it's the multicolour generated by %01 bit pairs in the graphics data.

There's a couple of games that use it such as Implosion, a quick flick of a priority register and the player's sprites appear to be moving between the two layers of background without any software masking needed.

[sigh]

As they always do : sprite multiplexing.

http://codebase64.org/doku.php?id=base:sprite_multiplexing

Getting them in large pixel enable 4 colours (3+transparent)

Sorry, I just noticed this. So a "normal" hardware sprite (24x21) holds 3 colours which are 2 PLUS transparency? (and not 3+transparency as I thought?)
Double Dragon 2 sprites has 4 colours+transparency making 5 colours. The game has 2 players and 2 enemies on screen at once.

International Karate for the A8 also uses this method where it creates both players from sw using its 5 colour mode. examine the c64 and a8 versions on youtube you will see that the c64 sprites for IK cross into the "picture" area whereas the a8 ones are always over flat colour.

So you could get an extra colour (light grey or blue) on the main sprite if need be?

[arnoldemu]

on the c64, you can choose hi resolution for sprites, which gives you 1 colour + transparency, resolution is then 48x21.
or you can choose multicolour, which gives 3 colours + transparency, resolution is then 24x21.

You can give each sprite 1 unique colour. in multicolour, 2 other colours are then shared over all sprites.

Now you can re-program the sprite positions and graphics locations -> "multiplexing".
You can also overlay hi resolution sprites over multicolor (so you can do hi-res outlines, with multicolour to fill the internal areas).

[TMR]

Sorry, I just noticed this. So a "normal" hardware sprite (24x21) holds 3 colours which are 2 PLUS transparency? (and not 3+transparency as I thought?)

In 12x21 pixel multicolour there are four colours in total with pixels being generated from bit pairs; one sprite colour each, two shared colours that are used by all sprites and transparency.

Double Dragon 2 sprites has 4 colours+transparency making 5 colours. The game has 2 players and 2 enemies on screen at once.

In Double Dragon 2 each fighter is two hardware sprites, one for the top half of the body and i'm guessing that one is set to pink, whilst the other for the lower is set to whatever colour the trousers need to be; the shared colours are brown and, if i'm right about pink for the upper colour, brown.

[TMR]

on the c64, you can choose hi resolution for sprites, which gives you 1 colour + transparency, resolution is then 48x21.
or you can choose multicolour, which gives 3 colours + transparency, resolution is then 24x21.

24x21 for high res and 12x21 for multicolour.

[arnoldemu]

24x21 for high res and 12x21 for multicolour.

thank you for the correction

[sigh]

Ahhhh right. So you can have "8" 12x21 multicolour wide pixel sprites on screen at once without having to resort to multiplexing and dealing with raster lines etc. Hmmm - I'm beginning to understand a little better about STE86 approach to the POP and enemy sprites...

[MacDeath]

24x21 for high res and 12x21 for multicolour.

yet using the same surface on screen... isn't it ??

[sigh]

You can also overlay hi resolution sprites over multicolor (so you can do hi-res outlines, with multicolour to fill the internal areas).

Would doing this use an extra sprite? (Just thinking of high res POP)

Edit: I suppose it would as using this method would be 2 + transparency instead of 1.

[arnoldemu]

Would doing this use an extra sprite? (Just thinking of high res POP)

Edit: I suppose it would as using this method would be 2 + transparency instead of 1.

Yes.

It would work like this:

1 sprite, which is multi colour. This uses 3 colours + transparency. it defines the colours for the areas.
The pixels have been setup carefully so that when the hi-resolution one is overlaid they do not "spill" out.

You then take 1 more sprite, which is high resolution. It has 1 colour and transparency. You can set it's colour.
Position the high resolution one over the top of the multi-colour one. Now you have colour with hi resolution outline.

So you would need x2 the amount of sprites to make the pop main character this way.

[TMR]

yet using the same surface on screen... isn't it ??

Yup, the C64 essentially "thinks" at 320x200 pixels all the time (which is why it can mix modes between sprites or indeed on a cell by cell basis in some character-based screen modes) and just has bits pairing up when objects are set for multicolour mode.

[STE86]

Target Renegade

http://www.lemon64.com/games/details.php?ID=2603

is one of the best examples of this method on the c64.

the sprites however are all designed to fit into exactly what the c64 display in order to do this.

unfortunate PoP was never designed to be c64 "friendly"

It also helped that Dave Collier was IMHO one of the most technically proficient coders the c64 ever had.
and probably one of the least publicised.

Steve

[sigh]

Would you consider making use of the C128 instead of the C64 if the squeeze got too much? I know that that the C128 is pretty much a completely different machine, but having the extra MHz and the extra 64k memory for animation frames and loading data, you may be able to use some software sprites if needed, seeing as the game doesn't scroll, and the background is black most of the time.

[PeteD]

It'd be better to go to cartridge than a different machine.   They're emulated so no problem there and for people who want to use hardware, flashable ones are available relatively cheaply.    Personally I think it will fit in 64k (after various calculations, compression methods, using character screen instead of bitmap and checking memory usage with Ste's graphics) with cutscene stuff being read from disk when needed then the data that replaced being read back again.   It's a wait of X number of seconds that C64 users are all too used to anyway.

[MacDeath]

Target Renegadeon C64

Graphics are good, but the limitation in displayed sprites is somewhat drastic.

Yet yes, this one manage to be better looking than CPC's Target Renegade, which was notoriously screwed concerning graphics (depends, some levels are OK btw....).


I aggree concerning cartridge game.
As told in GX4000carts topic, it is a way to freeed the RAM a lot and get a lot of extra stuff...

BTW C64 retains its Video limitations.
And C128 is perhaps not that better on Video. More RAM is OK... but the Extra hardwares and MHz are not that usable in games. Are they ?

Perhaps in Cartridge format, more SoftSprites may be used but As i told, C64 is not that well designed to be that good in SoftSprites.
But tthis is better than nothing.

[mrsid]

Pete, would you mind letting me have a look at your calculations? To make sure you didn't miss something?
Btw, my version is close to alpha status now. Main missing features are the mirror/shadow man stuff and cutscenes/titles.

[PeteD]

Pete, would you mind letting me have a look at your calculations? To make sure you didn't miss something?
Btw, my version is close to alpha status now. Main missing features are the mirror/shadow man stuff and cutscenes/titles.

Yeah, I'll tot it all up later.  There's nothing definitive yet, just stuff based on how I'd do it all starting from scratch and then calculations based on Ste's graphics (how many chars he needs etc), anim frame info and the sprite compression test I wrote last year.  I've not continued much on the code (only really thought about doing anything on it again when Ste started to convert the title sequence) because Ste told me you'd got quite far with your version since the last time we saw what you'd done on it so there probably is some stuff I've missed.   Even if I have missed things though I still think it'll fit, maybe have to drop a few sprite frames here and there but with the converted ones in 2:1 ratio there are some that are sooooooo close they're kind of redundant.

[STE86]

yes at least 5 if not 7 out of the amazing 15 frames it takes to animate drinking a potion would be the first candidates for a kickoff.

[sigh]

Graphics are good, but the limitation in displayed sprites is somewhat drastic.

Yet yes, this one manage to be better looking than CPC's Target Renegade, which was notoriously screwed concerning graphics (depends, some levels are OK btw....).

I actually prefer the character designs on the CPC version, despite the C64 high res look. The animations on the CPC for that game are nicer too.

And C128 is perhaps not that better on Video. More RAM is OK... but the Extra hardwares and MHz are not that usable in games. Are they ?

I really hope thats not true.....