Prince of Persia

[oky2000]

Hello all.

 

Very good STE and OKI. If you don't mind probably someone can tranfer them to 5colour A8 Antic4.

If someone wants some of my ideas from the last posts, just see this picture. You'll probably understand better than if I use my "always bad English":

 

Bye.

José Pereira.

 

I can convert them to 5 colour maps yes, I'm not sure how Antic4 works though (so for example in mine no 8x8 has more than 1 different colour and 2 pre-set multicolour mode colours) so I need to understand any restrictions to take into account too.

[+MrFish]

Here's one I did in G2F. No PMs, two DLIs, and 3 char sets:

 

[PeteD]

Here's one I did in G2F. No PMs, two DLIs, and 3 char sets:

 

 

Looks nice. Can you upload the g2f file so I can have a quick look? What you've got to be careful of is it's near impossible to make the sprites out of just PMs so it needs a PF colour and then that's not as simple as saying ok use one of those, because that'll likely look really wrong. Also ram is going to be veeeeeery tight so using 3 charsets is possibly a bit much, especially as not all the elements are on that screen and the more charsets used per screen the more space wasted on software sprite chars as well. It's probably unavoidable to be honest but would be nice to keep it lower.

 

What I'm working on as far as colours goes is 5 colour mode, pink (yeah I know), black, medium (blue in this case), then light/dark as 4/5 colours. Looks like yours might be something similar but maybe with the yellow as one of the standard PF colours?

 

I'm thinking of pink as background colour because it's the only one used in some of the sprites that can be easily masked by PF colours and other PMs. The majority of colours on the sprites is white so blasting some expanded players below them makes filling that area easy. Harder part is masking them but I've got a sprite compressor in the works that should make that "fairly" easy.

 

 

Pete

Edited November 4, 2009 by PeteD

[pseudografx]

Looks nice. Can you upload the g2f file so I can have a quick look? What you've got to be careful of is it's near impossible to make the sprites out of just PMs so it needs a PF colour and then that's not as simple as saying ok use one of those, because that'll likely look really wrong. Also ram is going to be veeeeeery tight so using 3 charsets is possibly a bit much, especially as not all the elements are on that screen and the more charsets used per screen the more space wasted on software sprite chars as well. It's probably unavoidable to be honest but would be nice to keep it lower.

 

What I'm working on as far as colours goes is 5 colour mode, pink (yeah I know), black, medium (blue in this case), then light/dark as 4/5 colours. Looks like yours might be something similar but maybe with the yellow as one of the standard PF colours?

 

I'm thinking of pink as background colour because it's the only one used in some of the sprites that can be easily masked by PF colours and other PMs. The majority of colours on the sprites is white so blasting some expanded players below them makes filling that area easy. Harder part is masking them but I've got a sprite compressor in the works that should make that "fairly" easy.

 

 

Pete

The pink is kind of hard to work with in the background graphics, better make it more into orange. If this is gonna be the skin colour, it should not pose a problems since the Persians are not pink anyway :-)

[PeteD]

 

The pink is kind of hard to work with in the background graphics, better make it more into orange. If this is gonna be the skin colour, it should not pose a problems since the Persians are not pink anyway :-)

 

Yeah, it's a bit of a waste losing a PF to pink but I'd rather it look right than look odd by forcing a weird colour if you know what I mean. pretty much any version of the backgrounds anyone has done so far can be done using 4 of the 5 colours with PMs for sprites, spikes, bottles, flames etc

 

 

 

Pete

[José Pereira]

>Hello all.

 

MrFish you're picture is great. For me I'll prefer White/Gray colours like STE done on that c64 shot.

From what I see in your picture you're using flames as PF3 (or 2). Yes, simple, so forget my ideas of DLIs. for the floor (probably later for the windows on the Palace levels).

 

 

But I see a problem in your and others screenshots: How to move your Player on top and behind the back and front Rocks?

It is possible to work with PRIORITY8. But here you only have two colour to put on the front Rocks. But you can always have a trick...

If you use PF0-White/Lightest Gray colour, PF1-Middle Light colour and PF3 as Darkest light colour (PF2 will be for the the flames), then you can use Priority 8.

You can put 5th Player above PF3 pixels (The front rock right side) every time a Player walks behind. And 5th Player always has priority over Pfs. About the Players used on Players Bodys/Clothes that's no problem. If you read and remember the other Thread ("All Priorities Modes") that "Bug/Thing" in the PRIOR8 particulary case: If a Player is overlapping a PF and 5th Player, in Prior8 you'll get the correspondant PF that is on that place (and in this case you have PF3).

 

And on the back Rocks you have: PF3-Darkest light colour and Backgr.-Black colour. And also PF2 as the flames.

 

PROBLEM FIX!

 

 

 

 

 

About the Players frames: If you use White/Lightest Gray as PF0 you'll get it for the Players clothes (the largest area on the Players shapes). You can use this one to the Man's Clothes and the Swords. Now you can use P0/1 to your "Kid" and P2/3 to the Enemy in Multicolour format that gives you a 3rd colour. The Players have now 4colours and O.K. with the Priority8 use.

The majour problem is that, if you use 5th Player, you cannot use it for the Players shapes.

But, like Analmux said with a DLI for the Players you'll get 2 on top of the Body and 2 for the bottom of the Body.

 

Greetings,

José Pereira

[José Pereira]

I forget one thing:

 

If on G2F you choose Limit 40chars you'll have one charset in each line. And you'll get 88chars free for Objects/Soft Sprites.

Now this turns to a one screen mode and a Screen Multi-Load game (like I'am using in my Last Ninja screens port/conversion), but more simple (I think...), you only cut from the Maps and rework each screen in G2F with 5th colour/DLIs and Players.

 

Hope this fix some problems and be usefull to someone. It'll be great to see PRINCE OF PERSIA on A8.

José Pereira.

[oky2000]

Here's one I did in G2F. No PMs, two DLIs, and 3 char sets:

 

 

I really like that design

[+MrFish]

Here's one I did in G2F. No PMs, two DLIs, and 3 char sets:

 

Looks nice. Can you upload the g2f file so I can have a quick look?

 

Thanks for the compliment. My thoughts on the sprites are, that the white/gray highlight could be used for the players body and the PMs would be used for hair/face/feet.

 

As far as memory usage goes, "pseudografx" has the best idea. He lined up all bricks on vertical characters, as well as horizontal. Mine line up horizontally. To make mine line up vertically, I would have to add one row of pixels to each brick. The design is 9 bricks high, so the playfield are would have to expand by that much. Optionally, using STE's method yields 2 char sets.

 

Here's the G2F file. The XFormer palette was used for colors, as this is my standard emulator palette. I can't remember if it's included with G2F, so I included it with the image file:

 

prince.zip

[José Pereira]

 

The pink is kind of hard to work with in the background graphics, better make it more into orange. If this is gonna be the skin colour, it should not pose a problems since the Persians are not pink anyway :-)

 

Yeah, it's a bit of a waste losing a PF to pink but I'd rather it look right than look odd by forcing a weird colour if you know what I mean. pretty much any version of the backgrounds anyone has done so far can be done using 4 of the 5 colours with PMs for sprites, spikes, bottles, flames etc

 

 

 

Pete

 

 

Here I am again.

 

Your Lightest Colour as PF0-Major area Player' clothes and the Swords.

 

And I discouver this:

Using MrFish example: PF2-Yellow(Flames),PF3-Dark Blue. Just create some DLIs.

You'll get PF2(1)-Flames,PF2(2)-Base of the flames(one of the 2colours you're using on it), PF2(3)-Bottle Top, PF2(4)- Bottle Liquid.

If you scroll the Maps you'll see this is horizontally possible.

 

 

José Pereira.

[Thelen]

Some really nice charset are being developed here !

 

In my opinion The (soft)sprites will be the real challenge, all the char GFX can be done well.

 

Why not make it a VBXE game ? The sprites will just get much easier to do...

[analmux]

...But I see a problem in your and others screenshots: How to move your Player on top and behind the back and front Rocks? It is possible to work with PRIORITY8. But here you only have two colour to put on the front Rocks. But you can always have a trick...

Might be simple. Just a fast reply from me...not thinking about possible prior problems in detail, but:

 

Just swap between PRIOR mode 1 and 8 in certain zones.

 

Many times the player is in front of everything. Then just select PRIOR=1.

Only sometimes, when walking through a door, select PRIOR=8.

 

We could split up the screen in zones of say 32*64 (antic E) pixels. Everytime the (x,y) coordinates of the player change zone, we change the PRIOR setting.

 

OK, some more data would be needed, f.e. a bit table for each screen or level. Or, we should add some logic which 'decides' when to choose PRIOR=1 or 8.

 

Only problem is, we'd need zones inbetween with only PF2&3, but also 5th player might help here. This way we won't see a 'sudden' priority switching.

 

Just a though experiment, but maybe other ideas are possible

[STE'86]

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

[Heaven/TQA]

the most important part... Pete's sprite depacker... not the background imho?

 

Key is the animation system and not the background?

 

c64 seems to be piece of cake...

[PeteD]

Sprite compression is coming along It should work very nicely on C64 and be "possible" on A8 but won't be the fastest routine in the world but then there isn't too much else going on at the same time so should be doable. Decompression + masking + shifting != fast although the compression is quite simple.

 

 

I've been looking again at the backgrounds and sprites because I was originally worried there wouldn't be enough PMGs to do anything useful with apart from underlaying expanded players to get big coverage of colour. It now seems that the maximum with of any solid coloured area of sprite is less than 40 pixels (20 clocks) so a fully detailed (although mono) layer of 2 platers+missiles per onscreen sprite is possible. It'll need something along the lines of MrFish's palette of a light grey, blues and black + skin colour. That way the Kid suit can be made from white pmgs, the skeleton the same, the guards from a mix of the blue from the PF colours and pmgs.

 

I'm not sure that using PRIOR is the way to go. The sprite code I'm writing for C64 masks the data with a background mask as its drawing it into the hardware sprites. The way I'd envisage the same type of code working on A8 it would be as easy to do the same and as it'll likely be part software part hardware routine you've got to do some masking anyway, this code should do it all in one go (I'll let you know when the C64 one is done and I think more about the A8).

 

The most important thing for A8 is how much ram is it going to use? Do you want a 64k version that uses extra ram to have decompressed preshifted sprites or do you just say screw it 320k only. Personally I'd try for a 64k version and if it really isn't possible then think about extended ram.

 

 

 

Pete

[STE'86]

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

[PeteD]

Even with compression from tests I've done so far I can maybe get the kid.dat file from 37k to 2/3 maaaaybe 1/2 its size. If we were to lose frames too that would drastically reduce it of course but if not, 18-24k just for your player, nothing is going to be "easy"

 

 

Pete

[Heaven/TQA]

well... on A8 a compromise could be 130 XE so you can bank in the data... ?

 

I guess the sprite depacker is a simple RLE?

[PeteD]

well... on A8 a compromise could be 130 XE so you can bank in the data... ?

 

I guess the sprite depacker is a simple RLE?

 

 

RLE, bitpacking, etc I keep looking at different methods and then thinking about speed/ease of depacking and drawing so I've not decided on a final version yet.

 

 

Pete

[Heaven/TQA]

have you checked our flashpack? 128 byte depack routine, can depack 30kb/s?

Edited November 4, 2009 by Heaven/TQA

[Heaven/TQA]

http://sources.pigwa.net/?page=2

 

here are the sources...

[Heaven/TQA]

here is the depacker and comments by Fox

 

http://www.atariage.com/forums/topic/78655-exomizer-beta/page__p__961472__hl__flashpack__fromsearch__1entry961472

 

and somewhere is a zip file... gimme 5 minutes...

[PeteD]

The problem is it really needs to depack in a sensible manner inside a sprite routine else you're doubling up on the work you're doing. I've looked at both RLE the way the DOS version works (afaik) working on colour changes and on columns considering we're working with 2bpp and they both come out at around the same size so now I'm moving to bitpacking which can also be done in rows or columns. All my methods will be fast it's just you've got to do the shifting/masking/spriting as well which is what will slow the whole thing down, the decompression itself actually means you never sprite any blank areas so means it actually speeds up a "solid" software sprite routine.

 

*edit*

If you say a depacker can do 30k/sec, that's about 614bytes per frame on PAL. Some of these sprites work out to about 252 bytes. Two of those per frame 504 bytes. Without any game, music, spriting being done You'd then have to go back over all the data again once it was depacked into a sensible ram configuration. Building it into the spriting routine and keeping it as simple as possible means you average out about the same speed as a normal block sprite routine because you skip gaps, repeat sections (no reading more data) etc.

 

 

Pete

Edited November 4, 2009 by PeteD

[Rybags]

I think some sort of JIT workahead system might be the go.

 

Depending on what moves the character is performing, the sprite data could be made ready in a background task.

To keep up the speed, I reckon some definitions would be best kept uncompressed, e.g. the first 2 or 3 animation frames of a particular move sequence.

 

It's been a while since I played... does the animation actually happen at 1:1 frame rate, or is it every second frame?

 

It might also be worth considering sacrificing some animation frames... it could well be that the game might retain most of it's fluidity of motion by only using half the definitions.

[oky2000]

The problem is there will be a massive difference between doing this as the best technical conversion possible and the compromises you take realistically complete a game level. If you go bananas getting creative with colour ram say on the C64 backgrounds you just eat up into the sprite memory etc etc. Classic example is the Shadow of the Beast tech demo on the CPC...looks fantastic compared to the crap game released...but no memory left to write the game with it. I had this problem already messing about with Sonic sprites...gave up in the end the compromises needed were too great for my skills but my sprites look awesome on their own

 

Also what is the target machine for the A8 version people are working on...64k? 128k?