Wich one of these two Prince of Persia you prefer?

[PeteD]

I really don't think a rewrite is THAT big a job. It's all basically data driven and the data is there to be pilfered and then you get to do the rest of it how you want (ie chars instead of bitmap) because you're no longer limited by another machines foibles. Still, someone might feel more comfortable working from an existing modern version if they've never taken on writing a game before because sometimes it's "the game" part and making it a whole that's the biggest problem.

[potatohead]

Maybe so. In my mind, being one of those that does struggle in that area, working from one that runs on another 6502 computer seems less of a task, particularly given what Mr Sid did. Of course that's all relative to people's skills too.

 

Then again, if the capabilities don't match up well, the choice between just running at a lowest common denominator, and getting something of the machine capability into play might end up overly complicating things, justifying the rewrite. I'm always interested in seeing that discussion play out. Very intriguing stuff to me, just because the differences in the old machines are so much fun.

 

Maybe we shall see. I sure like this one, and will follow any project with great interest. Played it on the Apple and wish I had a C64 to play that one. Might just have to go and do the work to get emulator output onto the TV....

[emkay]

which of the versions run in 50 FPS? the Apple 2 version? I mean is the gameplay based on FPS?

 

Frames wouldn't need to be at 50Hz (or even 60Hz) . But the controls, gamelogics and minor stuff has to run faster .

 

15fps is simply a quarder of 60Hz. Not sure how it is solved on the C64. 3.33fps seems odd.

This point is to look at. For example in Salmon Run you see the "50Hz" problem. While you swim slower (VB depending), the grizzly gets you almost twice as fast (more cycles in the VBI).

[popmilo]

What I don't get is why there isn't some discussion over the excellent material Mr Sid has posted up so far: Recommended, BTW...

 

If you think I didn't read each post on his blog at least twice from first to last letter you are mistaken

Yes, his long effort and thinking that went into recreating PoP are remarkable.

Will be nice to know the whole story (and get the source files too ).

 

There really are two basic paths here. One is to rewrite the game, using only media assets, and perhaps a routine or two from the original, and the other is to port the original over, mapping the necessary bits into the computer capability, whatever that is.

I really don't think a rewrite is THAT big a job. It's all basically data driven and the data is there to be pilfered and then you get to do the rest of it how you want (ie chars instead of bitmap) because you're no longer limited by another machines foibles...

I found out (hard way) few years ago that rewrite was much faster and easier then reverse engineering old code (To make matters worse it was my own code from 93-94 ).

 

And I agree with Pete - most of us have +20 years experience in coding since those routines were written. Data driven approach would be easiest to develop. Especially if speed is not such a problem as it seems.

 

One more fact that is pushing me towards rewrite is that I'm pretty convinced (or it is just such a nice challenge to be missed ) it can be done in 64K (at least as a multiload, level by level).

 

But then again - if MrSid provides nicely commented and explained code - "simple conversion" would be fastest I guess...

[Irgendwer]

Guarantee it won't fit in 128 chars Maybe some screens will but there are ones that there's too much overlap of different types of tile which creates a heap of unique chars AND you've got to draw sprites into it all somehow. I've posted more info on FW about chars v bitmap..

 

Could you please provide an example which screen you regard as to complex? I will try to rebuild it.

ATM I think a 'conventional' reconstruction seems possible (char background, PMGs for protagonist etc.).

I would reserve some chars for animations, where I don't change the char but the content of them (e.g. when moving a gate up) - connecting the advantages from char & bitmap mode.

Also masking only PMGs behind a pillar seems to be easier/faster for me. (And we would have the 5th colour advantage in char mode).

Edited October 24, 2011 by Irgendwer

[PeteD]

I'll have a look for something later (don't have the time now and all this stuff is backed up on an external hdd) but it's easy to just go find a screenshot of a screen with a few walls, columns, gates/chompers and work from that by inserting lines to align the tile heights to 64 (to get things on char heights). I think you'll be surprised how many chars some of them will use, especially if you don't reserve enough chars for the animating objects which can be quite numerous and sometimes overlap each other and animate at different times. I'm also not sure there are enough PMGs to draw you and an enemy guy and your swords..

 

*edit*

 

I do have this screen which was built by Ste (not sure it's an existing game screen) to test his Palace level tiles. It's by no means the most complex the levels can be but does contain most of the tile types.

 

Bear in mind it's been reduced to 4 colour, and not in a sensible way so a lot of detail (front facing walls etc) has been lost but it still has quite a high unique char count.. I'll try to find a better one later.

 

test.bmp

Edited October 24, 2011 by PeteD

[Irgendwer]

I'll have a look for something later (don't have the time now and all this stuff is backed up on an external hdd) but it's easy to just go find a screenshot of a screen with a few walls, columns, gates/chompers and work from that by inserting lines to align the tile heights to 64 (to get things on char heights).

 

Maybe you could pick one out of those: http://twinbirds.com/prince_of_persia/maps/ ?

 

Just for clarification: I don't think that one charset per screen is sufficient, nor that graphics may have to change.

 

Regarding the opponent problem: It looks helpful, that the fights take only place horizontally -> opponent may consits of chars...

I'm thinking about a char repository where the needed ones are placed into the set screen-wise.

[PeteD]

 

 

Maybe you could pick one out of those: http://twinbirds.com...of_persia/maps/ ?

 

Just for clarification: I don't think that one charset per screen is sufficient, nor that graphics may have to change.

 

Regarding the opponent problem: It looks helpful, that the fights take only place horizontally -> opponent may consits of chars...

I'm thinking about a char repository where the needed ones are placed into the set screen-wise.

 

Makes more sense if you're using more than 128 per screen The opponent also masks behind pillars/chompers etc and I believe can fall down holes? (might be wrong about that last one) So you'd need a char/char sprite masking routine anyway.

[José Pereira]

Maybe you could pick one out of those: http://twinbirds.com...of_persia/maps/ ?

 

Just for clarification: I don't think that one charset per screen is sufficient, nor that graphics may have to change.

 

Regarding the opponent problem: It looks helpful, that the fights take only place horizontally -> opponent may consits of chars...

I'm thinking about a char repository where the needed ones are placed into the set screen-wise.

 

Makes more sense if you're using more than 128 per screen The opponent also masks behind pillars/chompers etc and I believe can fall down holes? (might be wrong about that last one) So you'd need a char/char sprite masking routine anyway.

 

The Enemy can be behind Pillars but also fall, dead between Blades.

[Irgendwer]

Makes more sense if you're using more than 128 per screen

 

Did I wrote something different? (Edit: Of course I meant with the 'pick' a single screen crop out of the maps.)

 

The opponent also masks behind pillars/chompers etc and I believe can fall down holes? (might be wrong about that last one) So you'd need a char/char sprite masking routine anyway.

 

These may be places where I wouldn't act so strict - like removing the pillar.

Let me explain:

I would prefer an existing, maybe slightly different PoP - contrary to a perfect non-existant one.

Like I would prefer a 5th colour in over 90% of the screens, than a correct pillar representation in less than 10% of them.

 

But I fear, that this to much blasphemy for a single post...

Edited October 24, 2011 by Irgendwer

[PeteD]

Makes more sense if you're using more than 128 per screen

 

Did I wrote something different? (Edit: Of course I meant with the 'pick' a single screen crop out of the maps.)

Nooo I just read into your earlier post that you were trying to do each "screen" (never mind the whole map) in 128 chars, probably just because you didn't mention multiple splits per screen as everyone else has.

 

The opponent also masks behind pillars/chompers etc and I believe can fall down holes? (might be wrong about that last one) So you'd need a char/char sprite masking routine anyway.

 

These may be places where I wouldn't act so strict - like removing the pillar.

Let me explain:

I would prefer an existing, maybe slightly different PoP - contrary to a perfect non-existant one.

Like I would prefer a 5th colour in over 90% of the screens, than a correct pillar representation in less than 10% of them.

 

But I fear, that this to much blasphemy for a single post...

 

It's the type of idea I used to suggest a year or so ago and have again in this thread. There's no need to try to recreate exactly a game from another platform if doing so means that game will never be finished. Much better to work to a lower spec/different design and at least have something to play. For example Ste's ideas of the hires text screens for the intro. That could be done and dusted within a couple of hours and imho looks really good (and is kind of what the original was supposed to be, silent movie style if you read Mechner's blog).

 

Despite what some people think, I promise we won't all point fingers and laugh if a finished A8 PoP is released and god forbid it's not as good in some way as the C64 version.

[PeteD]

Sorry, that last bitmap I posted was a bit of a bastard son of part of 2 different levels Here's a better one, it's the first screen from the game, reduced to 4 colour again but that only really effects the torches and the rear wall brickwork (which can have colour ram in on the C64). It's about 150 unique chars.

 

test2.bmp

[popmilo]

I would prefer an existing, maybe slightly different PoP - contrary to a perfect non-existant one.

...

But I fear, that this to much blasphemy for a single post...

...There's no need to try to recreate exactly a game from another platform if doing so means that game will never be finished. Much better to work to a lower spec/different design and at least have something to play

...

Agreed...

 

And if I may I would mention another blasphemous idea

 

Game I used to play a lot more then Prince:

 

http://www.youtube.com/watch?v=WafqCyIwAWw

 

ps. But first lets finish at least one screen of any of started projects before indulging into fantasizing about a new one

[Rybags]

The graphics are there for the using (C64).

 

All this masking talk is irrelevant - partial byte masking has to take place, just see what happens when you climb onto any platform when it's to the right hand side of the player.

 

It might come to be that the quickest way for the game to run involves double-buffered bitmap (16K) + a fullscreen worth of masking data (8K) which could bloat the RAM need to 128K. If it turns out that way then so be it.

 

The real "issue" at hand is going to be the abilty to generate the kid + an enemy using combined PF + the PMGs.

[emkay]

I would prefer an existing, maybe slightly different PoP - contrary to a perfect non-existant one.

...

But I fear, that this to much blasphemy for a single post...

...There's no need to try to recreate exactly a game from another platform if doing so means that game will never be finished. Much better to work to a lower spec/different design and at least have something to play

...

Agreed...

 

And if I may I would mention another blasphemous idea

 

Game I used to play a lot more then Prince:

 

http://www.youtube.com/watch?v=WafqCyIwAWw

 

ps. But first lets finish at least one screen of any of started projects before indulging into fantasizing about a new one

 

Yeah . The duels would look nice, seing them "hiding in the shadow", it could look nice, using the palette.

[emkay]

The graphics are there for the using (C64).

 

All this masking talk is irrelevant - partial byte masking has to take place, just see what happens when you climb onto any platform when it's to the right hand side of the player.

 

Not really a problem when using the walls and pillars at full bytes.

 

It might come to be that the quickest way for the game to run involves double-buffered bitmap (16K) + a fullscreen worth of masking data (8K) which could bloat the RAM need to 128K. If it turns out that way then so be it.

 

 

I wonder myself , for what the A8 has the DL .... Double Buffer was only needed for the main object. Every screen has 3 floors, setting LMS commands every 64 scanlines, makes only 2/3 of the screen to be needed double buffered.

The real "issue" at hand is going to be the abilty to generate the kid + an enemy using combined PF + the PMGs.

 

Look at the C64 version, it is always avoided to overlap the "fighters" .

[emkay]

Same with masking. On the A8 I wouldn't try to make "heaps of masking data".

 

Comparing the height , there isn't much to handle. Every Screen is build on given patterns, and each pattern has it's own rule of "overlay/underlay" ,

 

This stored with the height(1,2,3) , it's just like "now draw only this" , when reaching position X , do this or that

 

[Rybags]

The latest blog entry has the drawing procedure.

 

The tiles are diagonal, so it's partial-byte masking. Just check some of the early C64 WIPs without masking and you can easily see the difference.

 

The masking data itself mightn't be such a big issue. Given that the screen is drawn with regard to playfield object precedence, masks might be able to be generated at screen draw time for little extra cost.

[mrsid]

Look at the C64 version, it is always avoided to overlap the "fighters" .

There's no technical reason for this. It just like in every version of PoP: If the prince gets to close to the opponent, they just swap places.

[emkay]

Look at the C64 version, it is always avoided to overlap the "fighters" .

There's no technical reason for this. It just like in every version of PoP: If the prince gets to close to the opponent, they just swap places.

 

 

The technical reason ist the capabilities of the Apple

 

For the Atari a benefit to ease up some overlay calculations and PM handling.

 

[sack-c0s]

but then you aren't preserving the original game, you are just writing a new one.

 

In the context of swordplay though I can't imagine it being much good both fights being on top of each other - they'd either need to swap places, or jump over/under each other.

[+orpheuswaking]

This thread makes my balls itch!

[emkay]

Something impossible here:

2 16 bit voices and bass .... just a test

 

http://www.youtube.com/watch?v=Am7NFw3lEbQ

[emkay]

but then you aren't preserving the original game, you are just writing a new one.

 

Why?

In the context of swordplay though I can't imagine it being much good both fights being on top of each other - they'd either need to swap places, or jump over/under each other.

 

???

 

The point is, that we don't need to fear about wrong PM overlay , because they never cross each other. Which is saving a lot of calculations.

[sack-c0s]

 

The point is, that we don't need to fear about wrong PM overlay , because they never cross each other. Which is saving a lot of calculations.

 

Sorry - I was at work trying to do 5 things at once when I posted that so I missed what you were saying. I see what you mean now

(if it's any consolation i screwed the other 4 things up as well...)