Prince of Persia

[Tempus]

Question to all the programming expers here: What's your estimation about the time needed for an fluently running A8 adaption? Based on the Apple source code or nor?

[Heaven/TQA]

I would go for the c64 source...

[mrsid]

There is no c64 source...

[emkay]

The Apple version should fit best as a "source". The Graphics could be adjusted to colour mode. As game mechanics often get repeated, there could be fixed rules for PM underlay/overlay, saving 3 colours for every moving object and a distinguished color setting (moving objects get a "black/ a common Playfield colour, and a specific PM colour.

So "masking" is partly done , using the 1 byte boundaries for the Playfield graphics , and temporary overlays cover PM using the priority settings.

Walking "behind" a pillar costs no CPU, as the bytes where objects stand in front, simply don't need to be drawn. So it saves

actually CPU time. Same with traps... what's behind, has to be calculated for bit shifting. what's in Front of the protagonist, needs no additional handling. The "depth" illusion gets perfect.....

And, I don't see where had been the problem. adjusting the bitmap graphics for that.

[José Pereira]

Because of 'the many' that ask for the Pillars beeing in chars boundaries I decided to give it a try.

I have now the last Level Map 5screens all re-done that today I'll send to someone to extract me the chars in the 8charsets Interleaved that I think it's the solution as I'm sure I can have the Rocks and the Yellowish levels in, at least, 2x 8charsets = 16KBs.

The 1st Level of the Rocks one it's also almost done but I really need all so that I can put them all 'one next to the other' to extract all the chars...

Then it would be time to see how many KBs for the guys sprites and I have the Ste86 of the C64 version that seems that almost all 100% directly translated into A8.

 

I also remake the game Maps to fit in Char-Mode with each section beeing 8char-Lines = 64scanlines and the Top showing the previous csreen last scanlines beeing a full Char-Line = 8scanlines then our Playing Area is now 200scanlines.

It probably not be, or maybe, the greatest Artistic gfxs but I think they aren't so bad at all.

 

 

As said previous it's only the PFs soft sprites that need Masking because I am using PRIOR4 so 'our guy' use PM0+PM1 and each Enemy use PM2 + PM1 Multicolour underlays so the Pillars and other stuff will always be in front on the PMGs.

 

 

The 1st Level/a screen would look like this:

(The Pillars are chars alligned but also without Black, that is the BACKGR. colour Register so you will never see the PMGs when you pass between the Pillars)

 

 

Other Levels still 'in the making' to get the other type Pillars in chars but with something already done:

 

And today I'll try this Collums of the Rocks Levels that are the only ones that I didn't remake untill now to chars boundaries:

 

 

 

The last screen game before we encounter our lover:

 

 

 

 

And, as I said, the last/Level13 it's already done and on the way to extract the chars:

 

The game will always be for all levels the PFs colours like this:

BACKGR.: Always Black

PF1: Always White (also used the same at the Bottom Hi-Resolution Status Area letters/numbers. The Eneergy are PMGs only)

PF0: the darker colour/luminance, any can be used

PF2: the lighest colour/luminance, any can be used

PF3: always at the same 'fixed' scanlines there's DLIs that gives the diferent colours in Windows sky colour, Torches, Bottles,...

 

So it's just simple as this... Now that is 'simple' I am expecting that there is nothing to complain and say that this isn't the possible A8 way to go, right?

Edited February 5, 2013 by José Pereira

[mrsid]

What if the player is standing behind a gate or a chopping jaw?

Let me remind you of this:

[José Pereira]

MrSid the problem here is to get the majour/most common things in chars boundaries then we still need to have the other things, like this and Blades as soft sprites.

Bu that is exactly the same as when we are facing/passing/battle with an Enemy.

 

At your particular screen you have left Pillar just chars -> Grade as soft sprites (everything that has 'empty pixels in it) -> Collum in chars.

Edited February 5, 2013 by José Pereira

[Creature XL]

Must say the gfx in the pics look great. Strange, they aren't particularly colorful or detailed drawn. But somehow I like 'em.

Would be cool if someone really pics this up and do it. My fear is that no one has the stones to fiddle the Apple2 logic code into a A8-renderer.

Only mrsid can tell how much work it really is.

 

@Jose: just to clarify it for me, you need the 8 interleaved charsets? Or is there a way to squeeze the gfx in 4 interleaved sets?

Just asking, because I would like to test the gfx out in my engine, however, modifying it to use 8 charsets is to much trouble for a quick hack

The sprites are standard C64 (12x21) I presume? Upgrading my 9x16 sprites to 13x24 would be doable rather easily

[José Pereira]

CrtXL the 8 by now, it's because each section it's 8charlines tall and sprites can 'share' all the 8.

The way all gfxs are made in a way that they don't repeat in a 4+4 but only in a 8 steps. From my previous chars extractions it's this the only way that each level more the soft sprites and shifting fits in our 'pain' 128chars on each charset.

 

 

P.s.- MrSid, how many maximum number of '>' for the prince and enemy can be/have displayed at the bottom energy Status Area?

[jvas]

Would it be too bad, if we completely skip the pillars? I mean, it doesn't add to the gameplay, only to the visuals ...

Or keep the ones in the background only ...

[emkay]

What if the player is standing behind a gate or a chopping jaw?

Let me remind you of this:

 

Not a real hard task.

The PMg has to be used in shape mode. So you need a "DLI" to position, select size and colour for the full height of a player/missile.

Player one has the highest priority, so the masking works itself there.

[mrsid]

P.s.- MrSid, how many maximum number of '>' for the prince and enemy can be/have displayed at the bottom energy Status Area?

 

10 each

Edited February 5, 2013 by mrsid

[emkay]

Would it be too bad, if we completely skip the pillars? I mean, it doesn't add to the gameplay, only to the visuals ...

Or keep the ones in the background only ...

 

Without the "foreground" objects, the game loses it's reliability. They would never be a problem, if kept always 1, 2 , or 3 bytes wide. You simply have nothing to do in that ranges, thus things don't get faster then

[Creature XL]

Without the "foreground" objects, the game loses it's reliability. They would never be a problem, if kept always 1, 2 , or 3 bytes wide. You simply have nothing to do in that ranges, thus things don't get faster then

 

Okay, I am not an expert so take my opinion not too serious.

First, you are right, it was mentioned enough times in this topic, that pillars/objects which are completely above the player should have a size multiple of 4 (as you said 1, 2, 3, x bytes)

BUT, "nothing to do" is not quite right. You need a list of objects which have to be rendered over the player. The rendering itself is, as I pointed out, rather simple and was never the problem when doing PoP. But the management of the map data is.

I only accept mrsid's opinion on my last statement, as he is the only one who can judge this!

 

These are the things people do not realize when talking about coding a game. They always see the "rendering" but never the real hard part (collision detection, data management and stuff like that).

That's why I could do help coding the rendering part, but the rest (in-cooperating the game logic and handling of the maps and data) NO! I do not like PoP THAT much.

[emkay]

Okay, I am not an expert so take my opinion not too serious.

First, you are right, it was mentioned enough times in this topic, that pillars/objects which are completely above the player should have a size multiple of 4 (as you said 1, 2, 3, x bytes)

BUT, "nothing to do" is not quite right. You need a list of objects which have to be rendered over the player.

 

 

?

You have to check the position of the moving objects. Then you always have the same types of overlay.

On the playfield side it is simple as it is. If the byte x on pos y(*40) is reached, you can drop the whole "column", no need to render anything.

 

 

The rendering itself is, as I pointed out, rather simple and was never the problem when doing PoP. But the management of the map data is.

I only accept mrsid's opinion on my last statement, as he is the only one who can judge this!

 

 

Seems, you put too much into the gameplay?

 

 

These are the things people do not realize when talking about coding a game. They always see the "rendering" but never the real hard part (collision detection, data management and stuff like that).

 

 

You don't need collision detection in the whole game. You have the positions (Y is always defined) of the moving objects and you have the exact size of them.

 

That's why I could do help coding the rendering part, but the rest (in-cooperating the game logic and handling of the maps and data) NO! I do not like PoP THAT much.

 

No comment ...

[Creature XL]

?

You have to check the position of the moving objects. Then you always have the same types of overlay.

On the playfield side it is simple as it is. If the byte x on pos y(*40) is reached, you can drop the whole "column", no need to render anything.

wouldn't do it like that

Now, when I think about it, it i snot so difficult as I first thought. I guess what i would do (assume using soft-sprites and) I would check if a char of a sprite overwrites a "column char". If so, this char would go into a buffer. After the sprites are set the buffer will be checked and if needed the chars will be re-set on the screen (and so, overwriting the sprite). This may sound non-optimal but we there is lot's of raster time left (remember 12FPS

 

When I understood you correct I must say that it is not a good way. Remember that the screen is scrolling and you would have to track all the positions of the objects, so you would have to have a list of objects (columns and so on). Or maybe I got it wrong.

 

 

 

Seems, you put too much into the gameplay?

Or you put too less into the game mechanics? It's not only the game play. The falling objects, the switches and all that stuff. It's maybe not difficult, but I am sure it not easy either

 

You don't need collision detection in the whole game. You have the positions (Y is always defined) of the moving objects and you have the exact size of them.

This part was more general and not specific to PoP. The point was, in a game there is always more to code then the "simple" displaying of sprites and scrolling.

And this are things you really only see when you actually start to code the game.

In German:"Der Teufel steckt im Detail"

[emkay]

wouldn't do it like that

Now, when I think about it, it i snot so difficult as I first thought. I guess what i would do (assume using soft-sprites and) I would check if a char of a sprite overwrites a "column char". If so, this char would go into a buffer. After the sprites are set the buffer will be checked and if needed the chars will be re-set on the screen (and so, overwriting the sprite). This may sound non-optimal but we there is lot's of raster time left (remember 12FPS

 

 

So why do unnecessary stuff. You don't have to "buffer" stuff that doesn't need to get handled.

 

 

 

When I understood you correct I must say that it is not a good way. Remember that the screen is scrolling and you would have to track all the positions of the objects, so you would have to have a list of objects (columns and so on). Or maybe I got it wrong.

 

 

Where is the screen scrolling? And, Yes, you get it all wrong.

 

 

 

 

Or you put too less into the game mechanics? It's not only the game play. The falling objects, the switches and all that stuff. It's maybe not difficult, but I am sure it not easy either

 

 

Switches are not reliable for fps issues . You'd need a table of switches for every screen, where the prince can return to.

 

 

 

This part was more general and not specific to PoP. The point was, in a game there is always more to code then the "simple" displaying of sprites and scrolling.

 

Yeah, at least programming

 

And this are things you really only see when you actually start to code the game.

In German:"Der Teufel steckt im Detail"

 

Hier nicht. Dazu ist das Spiel viel zu einfach gestrickt.

Der Teufel steckt in der Umsetzung, und dass es niemand macht.

[emkay]

Example: You have exactly 3 different relevant vertical positions on a screen. So you need to store 1,2, 3 there...

If a trap is at pos. 1 and the prince is at position 2, the trap isn't there.... easy huh?

 

For the horizontal movement, you have already an indicator, if you use PM overlay.... it's needed to set the hor. position of the used player. From that position you can calculate the horizontal size , incl. the weapon.... if it's enough to reach the enemy that is at pos. 2 , the "hit" is given via calculations.

 

and so on.

[emkay]

Probably, there is even no need to calculate the size of the "Sprite", because you could set a value of the "current width" of the actually shown softwaresprite. Just compare the difference....

[Creature XL]

Okay, I admit defeat. In the soft-sprite routines I have here lying around it is much more easier to draw the sprite and overwrite it with the buffered data, then checking in the sprite drawing routine for special cases. Maybe those routs of Emkay or others are better coded. But then again, I never said I have the best routines. just that I am pretty happy with them

 

And honestly, I can't understand why her is still so much talk about the rendering part. We are talking about 4 frames per scene.

So one doesn't even need fast routines E.g. it should be possible to check in one frame if a pillar (or what ever) is in front of the sprite. without even drawing it.

 

 

I am out of here until mrsid posts anything

 

have fun

[emkay]

Okay, I admit defeat

 

 

?

 

 

I am out of here until mrsid posts anything

 

 

?

 

What's Your problem now?

Check the game, how it is done on the Apple. The A8 has more to offer there though.

And, where is the point only to listen to MrSID? He's neither coding the A8 nor aware of it's capabilities, referring to his posts.

[emkay]

This sentence earns a crown:

 

 

And honestly, I can't understand why her is still so much talk about the rendering part. We are talking about 4 frames per scene.

 

 

... because the last 2 and half posts explained parts of the game mechanics...

[peteym5]

I had some recent success in using a Super IRG Antic 4 and Player / Missile multicolor multiplexing at 60 frames per second for my Adventure RPG ideal. But all my characters are 8x20. Up to 8 sprites on screen at once. Super IRG seems to be ideal for games that are not scrolling and go screen by screen. Looks like "Prince of Persia" does not have more than 2 animated characters on screen at once. Can the charaters be done with 2 missiles + 2 players [10 wide by 32 tall ]? Where the 2 players / missiles overlay, produces the "OR" value color.

 

Then again it looks like you are doing pretty good with what you got doing it so far.

Edited February 6, 2013 by peteym5

[emkay]

Question to all the programming expers here: What's your estimation about the time needed for an fluently running A8 adaption? Based on the Apple source code or nor?

 

Depends on the timespan between the big bang and the 1st intelligent lifeform.

[VladR]

The rendering itself is, as I pointed out, rather simple and was never the problem when doing PoP.

 

But the management of the map data is.

 

These are the things people do not realize when talking about coding a game. They always see the "rendering" but never the real hard part (collision detection, data management and stuff like that).

That's why I could do help coding the rendering part, but the rest (in-cooperating the game logic and handling of the maps and data) NO! I do not like PoP THAT much.

Are you serious ? This is a simple platformer game from the gameplay coding standpoint.

 

Management of the map data ?

 

- The game has 12 levels

- Game has roughly 249 screens in total (I might have missed few when I counted them recently).

- Each level has anywhere between 14-28 screens.

- Each Screen has 3 Rows with 10 Columns

- Each Screen takes up 60 bytes (30 for Sprites and 30 for Collision)

- TOTAL : 249 * 60 = 14.6 KB.

- If we *really* need to save on RAM (not sure how much the sprites take), we could precalculate the Collision data upon entry to new level (taking up under 1 KB for current level), thus halving the above requirement to mere 7.3 KB

 

struct SScreen
{
 unsigned char SpriteData [3*10]; // Sprite Index
 unsigned char CollisionData [3*10]; // Collision Detection Data
};

Collision Data:
- Bits 0-2 : specify if player can go right, up(on right side)/down(on right side) in current quad:precalculated at level init
- Bits 3-5 : specify if player can go left, up(on left side)/down(on left side) in current quad:precalculated at level init
- Bit 6 : Floor Switch
- Bit 7 : Falling Floor

 

- Now some additional basic data structures:

// This holds the absolute position (within level) and relative position (within screen) of the gameplay element
struct SLevelScreenPos
{
char ScrRow, ScrCol; // Screen Index
char Row,Col; // Position within the screen
};

// Stores position of the switch and position of the connected door/trap
struct SSwitch
{
struct SLevelScreenPos SwitchPos;
struct SLevelScreenPos TrapDoorPos;
};

 

- And now the actual data structure for the Level holding info on Medikits, Traps, Enemies, Spikes, Doors

- Since there is never more than 20 of those things in any level, this would take up 10*sizeof (SSwitch) + 10*sizeof (SLevelScreenPos) = 10*8 + 10*4 = 80+40=0.1 KB. For 12 levels, the total would be max 2 KB

struct SLevelSummary
{
char ScreenRowCount;
char ScreenColCount;
char TrapDoorCount;
char FloorSpikeCount;
char SliceDoorCount;
char MedikitsCount;
char EnemiesCount;
};

struct SLevel
{
struct SScreen * Screen; // NULL for empty screens (thus zero space waste)
struct SSwitch * TrapDoor;
struct SSwitch * FloorSpike;
struct SLevelScreenPos * SliceDoor;
struct SLevelScreenPos * Medikits;
struct SLevelScreenPos * Enemies;
struct SLevelScreenPos ExitDoor;
};

 

The above are ALL data structures you need to handle with regards to gameplay / level layout. Seriously, this is the least of your problems when coding PoP.

 

The animation system, on the other hand, is a FiniteStateMachine beast with lots of possible states.

Handling transitions between them, corner cases, and alignment is really way, way more complex than figuring out where in the map you are and where you can move.

 

Here are most of the animations I noticed (I am pretty sure some are still missing):

enum EStatus
{
Stand,
SmallStep,
RegularStep,
Walk,
Run,
TurnAround,
WalkJump,
RunJump,
HangDown,
HangUp,
DeathBySword,
DeathByFall,
DeathBySpikes,
DeathBySlice,
GrabItem,
DrinkPotion,
RaiseSword,
RunIntoExit,
SwordWalk,
SwordAttack,
SwordDefense,
};