Prince of Persia

[GroovyBee]

POP sprite 8 bit conversion to 3 colours is now complete (i think)

 

Thanks for taking the time to do this.

[STE'86]

POP sprite 8 bit conversion to 3 colours is now complete (i think)

 

rename the .txt extension to .zip.

 

good luck

 

Steve

 

Cool!!!

 

so at least c64 port is on the way...

 

 

well in all fairness the same data can be used to do 4/5 colour a8 graphics. also even if POP is a non starter, simply because of the large amount of ram going to be consumed by the sprite frames. it doesnt stop someone using them as a base to do some other platformer with.

 

Steve

[Heaven/TQA]

well... active a8 coders < active c64 coders... ;=)

[José Pereira]

I finally got around to doing the GF2 for my sprite idea using PM's to add color. Two versions, one for "Xformer" palette and one for "OlivierN" palette.

 

 

Prince Sprites.zip

 

Although not used here, the second PM is reserved for use on the Prince in the cases when it would be necessary.

 

 

Hi.

Because of the Film now on scene, I remember this one?

 

Anyone done something?

 

 

MrFish do you get anywhere?

STE86 lot's of work, anyone takes it?

And the almost done C64 version?

 

 

Any answers?

 

Greetings.

José Pereira.

 

 

P.s.- I think more people have the same idea as me... more two anonymous seeing this Thread right now!...

José Pereira.

[+MrFish]

Hi.

Because of the Film now on scene, I remember this one?

 

Anyone done something?

I messed around with some ideas for a title screen. It's not finished, and there are some parts that I want to redo:

 

 

I also added some color to the guard in this mockup:

 

[luka]

nice pics, i think, that it is possible to make a small demo (like g&g), we need game map - 8 screens with 32chars in 5 colours (nice to see other colours in dli) and sprite - 16pix width in 3 colours

[Syfo-Dyas]

This would be awesome!!! It's a shame that Another World/Out of this World clone was never pushed passed demo stages...

[José Pereira]

Hi.

Because of the Film now on scene, I remember this one?

 

Anyone done something?

I messed around with some ideas for a title screen. It's not finished, and there are some parts that I want to redo:

 

 

I also added some color to the guard in this mockup:

 

 

 

 

Hello.

It seems very good.

But you're doing a thing wrong: you cannot use Blue on "our Kid" because colours would change on the otherr Levels.

You can only have one fix colour for all the Game Levels: the white. And use it on your Clothes and Swords.

 

But this take me into a question:

How it will be on Speed duplicating your work: cobination of Soft and Hardware Sprites (our kid it something like ttwo hundreds diferent shapes).

Isn't this too much? 200+200 just for "our Kid" and 15+15 or soo for each Enemy?

And somrething like 80Chars just for The Players.

 

 

I am trying something (Our Player just Hardware Sprites...) and think it will get new colours, Missiles possible on Enemy, DLIs. on PF3 (Fire/Candle Support/another Floor colour(if PF2 is Light Blue)).

ith this, prrobably just 1Charset on the PlayingArea.

 

 

Hope to show you my ideas tomorrow.

 

 

 

Thanks.

Greetings.

José Pereira.

[AtariNerd]

One thing working in favor is that all the possible animation is not necessarily needed at any one given time. Some are constant, but others, depending on the situation, could be omitted, depending on the screen. Of course the downside is that data would need to be loaded on the fly as the screens progressed. Maybe not so much of a problem with modern flash memory devices, but might be tedious on legacy devices.

[PeteD]

One thing working in favor is that all the possible animation is not necessarily needed at any one given time. Some are constant, but others, depending on the situation, could be omitted, depending on the screen. Of course the downside is that data would need to be loaded on the fly as the screens progressed. Maybe not so much of a problem with modern flash memory devices, but might be tedious on legacy devices.

 

The only problem with that is 90% of the anim data is your guy and you probably need about 80-90% of that on every screen (some screens may not have ledges for you to swing off for example). Add to that each level only has 1 bad guy type and you'll need to have him loaded at some point whilst still allowing the main sprite to do most of it's moves and you really won't save a lot of memory at any one point.

 

 

Pete

[snicklin]

The way that I look at this game is that if it has been possible to implement on other 8-bit computers, it can be done on the A8.

 

As for saving data, without having actually analysed all of the frames in the characters, would it not be possible to only animate parts of the body?

 

i.e. If he's only moving his legs and his upper body stays still, only animate the difference in consecutive frames, i.e. his legs.

[PeteD]

The way that I look at this game is that if it has been possible to implement on other 8-bit computers, it can be done on the A8.

 

As for saving data, without having actually analysed all of the frames in the characters, would it not be possible to only animate parts of the body?

 

i.e. If he's only moving his legs and his upper body stays still, only animate the difference in consecutive frames, i.e. his legs.

 

Well, you can say that about any game and the only problem arises when people expect more from their machine than coders have either the skill, time or inclination to handle (or the machine can handle) It's certainly possible to do on A8 and I'm pretty sure you could fit it in RAM all in one go (at least the "game" part of it). What the biggest problem is getting all the colours on screen (combined with keeping the data size down). I wrote a simple compression for the sprite data and drawing that into hardware sprites on the C64 would be simple and you've got the res and the colours to make it look nice. Doing the same on A8 involves some really nasty code that I just couldn't be bothered to even start writing that took that compressed data and split it into char data and pmg data, drew them both onto screen with sprite masking for the char parts and also masking of the background elements (pillars etc) of both char and pmg data.

 

From what I remember of looking through the frames there's pretty much none of that going on so no savings there.

 

I think the easiest route for anyone thinking of coding this is to forget 64k systems, use as much ram as needed on an expanded machine to make it easy to draw the sprites and backgrounds. I've only got a 64k machine but I'm happy to play games on machines they already exist on. If the majority of A8 owners have expanded machines, no problem

 

 

Pete

[José Pereira]

Hello.

 

It was a hard night... seeing/thinking/studying STE86 frames...

 

And some possible things can be done.

I think we can have "our Kid" a Hardware Sprite only and still having at least one Hardware for the Sprite for the Enemy.

But I would know one thing:

 

"In a static picture I can get the same PM number in different Lines with different shapes/colours/sizes,Priorrrs,...

 

 

 

But on a Moving creature on a Game?

The idea is thar I would need to re-use one Hardw.Sprite in "our Kid's" Skin like this:

- Colour, Size, Prior the same.

- But need to get it with differebt shapes at different x,y coordinates (P0:Head, P0-Left Arm, P0 (another y Line)- Right Arm, P0-Left Feet, Mo-Right Feet).

I think you understand, just different shapes at different y Lines and on differrent x Positions, like if you are on G2F... If they never get into the same Line, any problem?

 

 

Hope you underrstand and can send your thoughts...

 

 

Thanks.

Greetings.

José Pereira.

[José Pereira]

Hello.

 

It was a hard night... seeing/thinking/studying STE86 frames...

 

And some possible things can be done.

I think we can have "our Kid" a Hardware Sprite only and still having at least one Hardware for the Sprite for the Enemy.

But I would know one thing:

 

"In a static picture I can get the same PM number in different Lines with different shapes/colours/sizes,Priorrrs,...

 

 

 

But on a Moving creature on a Game?

The idea is thar I would need to re-use one Hardw.Sprite in "our Kid's" Skin like this:

- Colour, Size, Prior the same.

- But need to get it with differebt shapes at different x,y coordinates (P0:Head, P0-Left Arm, P0 (another y Line)- Right Arm, P0-Left Feet, Mo-Right Feet).

I think you understand, just different shapes at different y Lines and on differrent x Positions, like if you are on G2F... If they never get into the same Line, any problem?

 

 

Hope you underrstand and can send your thoughts...

 

 

Thanks.

Greetings.

José Pereira.

 

Sorry but I forgot to say one thing:

 

 

I also was thinking in this and what would affect in the "Bad Lines" nº of changes.

Taking MrFish good looking Screen examples and my ideas are almost the same in that, Backr.,PF0,1&2 the same on all ScreenPlay High. Only PF3 DLIs. changing on Fire,... but not on "...,8s. Bad Lines".

 

What would probably have to be is this Hardware Player changes sometimes on this Lines.

But it will be just only 1change: The xPosition.

The Prior, Size, Colour (skin colour) will be the same.

 

Just one change would take sometimes on "Bad Lines"... just 1 change is possible... isn't it?

 

 

José Pereira.

[+MrFish]

Anyone done something?

I messed around with some ideas for a title screen. It's not finished, and there are some parts that I want to redo:

I also added some color to the guard in this mockup:

It seems very good.

But you're doing a thing wrong: you cannot use Blue on "our Kid" because colours would change on the otherr Levels.

You can only have one fix colour for all the Game Levels: the white. And use it on your Clothes and Swords.

 

But this take me into a question:

How it will be on Speed duplicating your work: cobination of Soft and Hardware Sprites (our kid it something like ttwo hundreds diferent shapes).

Isn't this too much? 200+200 just for "our Kid" and 15+15 or soo for each Enemy?

And somrething like 80Chars just for The Players.

Using dark blue on the prince doesn't necessarily pose a problem. Either the dark blue could be used on all levels, or the dark blue could change on the prince as it does in the levels. I've done a few experiments with both of these... eventually I'll do some mockups to demonstate.

 

As far as "speed" goes, the only way to find out is to do some actual demos. There have certainly been plenty of games that combine soft and hard sprites together, in both character and bitmapped modes.

 

In terms of memory usage, I agree with Pete. Use as much as it takes to make it look right. It's not like there are any time or resource constraints on doing such a project. Doing a project like this is probably best suited to cartridge format, which offers the best in memory usage and quick access to data. As mentioned before the "Corina Cartridge" would offer some ideal functionality in keeping the memory usage to a minimum. In all honesty, I consider 128k (130xe) to be the base system for modern Atari development anyway.

[emkay]

This would be awesome!!! It's a shame that Another World/Out of this World clone was never pushed passed demo stages...

 

 

Particular Another World - depending on the colour usage- could be done in hires.

[PeteD]

PoP could be done on A8 in hires and looking pretty much the same as the Spectrum version. Use PMGs to colour the walls and probably the torches (depends what's on each line) and at least it's not just mono. It'd be waaaaaaay easier to do.

 

 

Pete

[Rybags]

I reckon it'd look crap.

 

If the game was to be done, may as well do it properly, which means multicolour items, not some watercoloured second-rate effort.

[PeteD]

I reckon it'd look crap.

 

If the game was to be done, may as well do it properly, which means multicolour items, not some watercoloured second-rate effort.

 

Never said it would look good the fact that it's a crap load easier to write though means at least there's more chance of a version ever appearing on A8. I personally wouldn't want to do a hires one but I also wouldn't be upset if someone did and the attitude of "it'll be crap because A8 CAN do better therefore it MUST", probably puts off some devs from coding anything.

 

 

Pete

Edited June 2, 2010 by PeteD

[GroovyBee]

Or you could just do it on the 7800 without making any compromises .

[José Pereira]

Hello.

 

 

Just MrFish with some DLIs. on PF3, gives 14colours in total.

80Chars maxim. by Charset gives 1Charset by 5/6 Lines (48Chars free for SoftSprites):

 

 

Sprites later on...

("our Kid" can indeed be just an Hardware Sprite)

 

Greetings.

José mPereira.

[PeteD]

Or you could just do it on the 7800 without making any compromises .

 

[Rybags]

Memory requirements would be much the same... if anything, less for multicolour because there's only 4 pixel positions to worry about if pre-shifted softsprites are used.

Then again, in hires there's no strict requirement to use character mode because it gives no colour advantage over bitmap. So I guess render speed of moving objects might benefit.

But I think for PoP, rendering the few moving objects you ever see in the game would be the least of the problems to overcome.

 

For something like a Dizzy game, coloured in hires might be acceptable, but for PoP, it needs the gradients to remain true to the originals.

[PeteD]

Memory requirements would be much the same... if anything, less for multicolour because there's only 4 pixel positions to worry about if pre-shifted softsprites are used.

Then again, in hires there's no strict requirement to use character mode because it gives no colour advantage over bitmap. So I guess render speed of moving objects might benefit.

But I think for PoP, rendering the few moving objects you ever see in the game would be the least of the problems to overcome.

 

For something like a Dizzy game, coloured in hires might be acceptable, but for PoP, it needs the gradients to remain true to the originals.

 

I'm pretty sure the sprites are (or can be) aligned to positions so a lot of the frames don't need multiple shifted copies of themselves. Even if not, who says you need double the pixel accuracy JUST because it's hires? that's going over and above what you'd do anyway so why bother?

 

The way I'd looked at it the memory problem is caused by the fact you can compress a sprite frame then just decompress/draw it if you're just drawing to either hires or PF OR PMG alone, when you start to use PF AND PMG at the same time you either need to have data for both or write code that splits the source data into the 2 forms needed to draw it with masking of both and software sprite masking for the PF stuff. José (I believe) is now talking about PMG only for the main sprite but with X shifts which means more data for those too but it should be a hell of a lot less than a split data method. I'm quite intrigued to see what he's come up with

 

As I say, nothing impossible but it's a pain in the ass and it's the kind of thing that'll make people think twice about even starting code.

 

*EDIT*

for typos, and making a bit more sense

 

Pete

Edited June 2, 2010 by PeteD

[José Pereira]

Memory requirements would be much the same... if anything, less for multicolour because there's only 4 pixel positions to worry about if pre-shifted softsprites are used.

Then again, in hires there's no strict requirement to use character mode because it gives no colour advantage over bitmap. So I guess render speed of moving objects might benefit.

But I think for PoP, rendering the few moving objects you ever see in the game would be the least of the problems to overcome.

 

For something like a Dizzy game, coloured in hires might be acceptable, but for PoP, it needs the gradients to remain true to the originals.

 

 

Hi-Resol. could be, but in an Aplle2 kind of... Artifact using and only to NTSCs. guys probably.

Then you could use 4Missiles (as 5th Player) for Torches, Bottles,...) and having the 4Players for Player and Enemy.

 

But I agree with Rybags. If someone do will do this, than it must have to be good (and also to everyone!).

 

 

José Pereira.