Anyone thirsty for some PoP?

[salstadt]

Hey guys,

 

I really need another hobby project to blow off steam from my commercial obligations, so I figured what better way to try and really max out the 2600 than to put one of the most fluid, strongest games on it? If a coder's interested, I'm really interested in trying to bring Prince of Persia to the 2600. Gameplay would be identical to the original PC game, with no-scrolling single-room areas, leaping from/to ledges and (if it can be handled) swordplay. The original game itself was very sparse on sprites, and very horizontal in layout so I think it'd work quite well on the system, and I know I could do Jordan Mechner's original animations justice in 8x16.

 

Below are several mockups, in descending order of complexity. The initial one is ideal, with more and more simplification down the post. If you're interested in attempting a PoP 2600, or would just like to comment as a coder on which of these mockups is possible, feel free. And beyond this, remember I'm always available for pixelling on any demo you might be working on.

 

- Adam

 

1.

Max color changes per scanline: between 0 and 10

Max colors per scanline: between 1 and 3

 

2.

(mirrored background)

Color changes: between 0 and 10

Max colors: between 1 and 3

 

3.

(mirrored background)

Color changes: between 0 and 6

Max colors: between 1 and 2

 

4.

(mirrored background)

Color changes: between 0 and 4

Max colors: between 1 and 2

 

5.

(mirrored background)

Color changes: between 0 and 2

Max colors: between 1 and 2

[miker]

Hmm... very good!!!

 

now some coder must deal with it

[+Nathan Strum]

And beyond this, remember I'm always available for pixelling on any demo you might be working on.

 

Nice looking mockups. Did you happen to see this post in the "fishie" thread? The author there is looking for some animated fish sprites for a game that's already under development.

[Thomas Jentzsch]

I suppose the structure had to be made out of PF-graphics. Mirrored graphics might be possible, but only with some striping. More than two colors/row (foreground, background) are most likely too much. Some additional color could be indroduced by mixing fore- and background colors (striping).

 

#3 looks very doable.

[Tom]

And beyond this, remember I'm always available for pixelling on any demo you might be working on.

 

Do you mean game demos, or demoscene demos ?

[vdub_bobby]

I suppose the structure had to be made out of PF-graphics. Mirrored graphics might be possible, but only with some striping. More than two colors/row (foreground, background) are most likely too much. Some additional color could be indroduced by mixing fore- and background colors (striping).

 

#3 looks very doable.

Hmmmm...let's see. If you weren't afraid of flicker and you were willing to give up using the left 16 pixels of the screen, you could probably do an asym PF background.

 

Use a player for the protagonist and the enemy (30 Hz flicker if an enemy is on the screen) and a missile for the sword, and you could fit it in.

 

I'm not real familiar with PoP, though - is there ever more than 1 enemy on the screen at a time?

[jeepnut24]

I suppose the structure had to be made out of PF-graphics. Mirrored graphics might be possible, but only with some striping. More than two colors/row (foreground, background) are most likely too much. Some additional color could be indroduced by mixing fore- and background colors (striping).

 

#3 looks very doable.

Hmmmm...let's see. If you weren't afraid of flicker and you were willing to give up using the left 16 pixels of the screen, you could probably do an asym PF background.

 

Use a player for the protagonist and the enemy (30 Hz flicker if an enemy is on the screen) and a missile for the sword, and you could fit it in.

 

I'm not real familiar with PoP, though - is there ever more than 1 enemy on the screen at a time?

 

Not that I remember, at least the old versions.

[vdub_bobby]

Hmmmm...let's see.  If you weren't afraid of flicker and you were willing to give up using the left 16 pixels of the screen, you could probably do an asym PF background.

 

Use a player for the protagonist and the enemy (30 Hz flicker if an enemy is on the screen) and a missile for the sword, and you could fit it in.

 

I'm not real familiar with PoP, though - is there ever more than 1 enemy on the screen at a time?

Revised that slightly: to have a multi-colored Prince (and enemies), I needed to drop 16 pixels on both sides of the screen.

I banged a little demo together of what I am talking about. Move the guy around with the joystick and push the button to turn on the sword.

 

This doesn't work in PCAE, I guess cuz it doesn't like it when you point the stack at ENAM1

 

But it works right in z26.

 

What do you guys think?

pop.zip

[miker]

good work - now add some animations and detection of collisions

[vdub_bobby]

Another option is to have the middle be reflected (mirrored) and have the sides be asymmetrical. I.e., not use PF0, have PF1 be asymmetrical and have PF2 be reflected. This would free up another 8 cycles in the kernel loop, bringing the grand total of free cycles up to 13.

With that you could change the color of the PF every line (getting shading effects like in #s 3, 4, and 5.

 

Or you could use those 13 cycles to halve the amount of PF data necessary - which might be the best idea, since right now the playing area is 100 pixels tall (only a little over half the screen) but it requires 400 bytes of data to draw!

 

Or another option w/ those 13 cycles is to combine them with the 8 cycles used for the sword and flicker the sword with the enemy, which would eliminate flicker for the Prince.

 

Just throwing stuff out there.

[salstadt]

vdub_bobby, awesome demo man. The layout is really interesting because it allows for a much larger playfield, although for PoP you'd probably want to stick more to the original style which was single-puzzle rooms with only a few platforms. I'll whip out some animations for you guys to play with today or tomorrow.

 

As for the gameplay, yes, there is only 1 enemy max at any time. So I'd imagine we'd have the player, and on one screen a sword he can pick up. Once he picks that up, he can swordfight. So the max of everything onscreen at once would be the hero, his extended sword and an enemy. Although due to the single action button, maybe he would only find the sword just before the enemy, so that the button could be both jump and slash (at different moments in the game). And in the end, sword fighting was hardly the most memorable aspect of the game so even if it was just a demo of leaping puzzles, I think that would still be pretty impressive.

 

Screen 3 would be great, although obviously I'm still holding out hope for 1 or 2. I'd have to take a look though at the original level design and really think about how puzzley levels could be when necessarily mirrored. I think I'd ultimately prefer to not mirror the levels, even if I had to take a hit in the graphics department because of it.

 

- Adam

[vdub_bobby]

vdub_bobby, awesome demo man. The layout is really interesting because it allows for a much larger playfield, although for PoP you'd probably want to stick more to the original style which was single-puzzle rooms with only a few platforms. I'll whip out some animations for you guys to play with today or tomorrow.

Thanks.

Sticking to a smaller playing area would mean less data would be necessary...though at the cost of a small playing area onscreen.

As for the gameplay, yes, there is only 1 enemy max at any time. So I'd imagine we'd have the player, and on one screen a sword he can pick up. Once he picks that up, he can swordfight. So the max of everything onscreen at once would be the hero, his extended sword and an enemy. Although due to the single action button, maybe he would only find the sword just before the enemy, so that the button could be both jump and slash (at different moments in the game). And in the end, sword fighting was hardly the most memorable aspect of the game so even if it was just a demo of leaping puzzles, I think that would still be pretty impressive.

 

Screen 3 would be great, although obviously I'm still holding out hope for 1 or 2. I'd have to take a look though at the original level design and really think about how puzzley levels could be when necessarily mirrored. I think I'd ultimately prefer to not mirror the levels, even if I had to take a hit in the graphics department because of it.

 

- Adam

This is how my demo is working now:

  blank     anything         anything           anything         anything      blank

+--------+----------------+----------------+----------------+----------------+--------+

|        |                |                |                |                |        |

|<-left edge of screen   center of screen->|                              right edge->|

The screen is divided into 6 sections; I am using 4 of them. The center four can be anything you want.

Here's a possible compromise between a completely asymmetrical PF (like my demo now) and a completely mirrored PF:

  blank     anything         reflected <-------> reflected       anything      blank

+--------+----------------+----------------+----------------+----------------+--------+

|        |                |                |                |                |        |

|<-left edge of screen   center of screen->|                              right edge->|

In this case the edges are blank, as before, and the 2nd and 4th sections can be different, but the center two sections are reflections of each other. Doing this would free up enough time to change the color of the playfield every line, and you could probably still figure out a way to recreate most of the original puzzles screens.

[vdub_bobby]

It just occurred to me: by making the center reflected, you could use those 8 extra cycles to use both players to draw your sprites, giving you an effective sprite that is 16 pixels wide.

 

Flicker is definitely unavoidable at that point, but I don't think you could avoid it anyway.

[vdub_bobby]

It just occurred to me: by making the center reflected, you could use those 8 extra cycles to use both players to draw your sprites, giving you an effective sprite that is 16 pixels wide.

 

Flicker is definitely unavoidable at that point, but I don't think you could avoid it anyway.

Here's a quick demo:

pro: wider/bigger sprites

con: sword is now same color as the player...not sure what to do about that.

con: PF is mirrored in middle=less flexibility in screen design.

 

Thoughts?

pop.zip

[StanJr]

I'm really digging it. The sprites look great. I think I like the idea of the bigger PF. Looking really nice though.

 

 

[Robert M]

Does anyone know a website that has screenshots of the original game. I have never seen it, and when I Google all I get are the modern 3D versions.

 

thanks!

[salstadt]

Here's a quick demo:

pro: wider/bigger sprites

con: sword is now same color as the player...not sure what to do about that.

con: PF is mirrored in middle=less flexibility in screen design.

 

Thoughts?

 

Well personally, I'd put all resources into gameplay and design over graphics. I can do fine with 8x16 1- or 2-color sprites. I'll do a few animation cycles tomorrow though, and you guys can fiddle with them.

 

- Adam

[Robert M]

Does anyone know a website that has screenshots of the original game.   I have never seen it, and when I Google all I get are the modern 3D versions.    

 

thanks!

 

Nevermind, I finally found a website with some of the level maps and other info about the game.

 

http://home.zonnet.nl/class-pc/prince_of_p...persia/maps.htm

[Thomas Jentzsch]

Prince of Persia has always been on my (looong) ToDo-list and those designs look great. Maybe I should shift my priorities now.

[Thomas Jentzsch]

Another option is to have the middle be reflected (mirrored) and have the sides be asymmetrical.

How should that work? You'd have to change CTRLPF two times/each row and only save one write to PF1.

[Cybergoth]

Hi there!

 

Another option is to have the middle be reflected (mirrored) and have the sides be asymmetrical.

How should that work? You'd have to change CTRLPF two times/each row and only save one write to PF1.

 

Easy. You don't touch CTRLPF, but leave it in reflected state. Then you just write PF1 twice per line and PF2 once. In a 2LK kernel that saves a lot, Just one PF2 read/write instead of 4.

 

Greetings,

Manuel

[Thomas Jentzsch]

Easy. You don't touch CTRLPF, but leave it in reflected state. Then you just write PF1 twice per line and PF2 once.

I see, thanks!

 

In a 2LK kernel that saves a lot, Just one PF2 read/write instead of 4.

Or none at all, if your graphics don't change. But still 4 PF1 writes.

[vdub_bobby]

Hi there!

 

Another option is to have the middle be reflected (mirrored) and have the sides be asymmetrical.

How should that work? You'd have to change CTRLPF two times/each row and only save one write to PF1.

 

Easy. You don't touch CTRLPF, but leave it in reflected state. Then you just write PF1 twice per line and PF2 once. In a 2LK kernel that saves a lot, Just one PF2 read/write instead of 4.

 

Greetings,

Manuel

You pretty much nailed it. The latest demo I posted has a reflected PF2 and asymmetrical PF1s (PF0 is unused in that demo).

 

I've been playing around with striping, which Thomas suggested earlier, trying to get writes to both player objects every line while drawing PF every other line...maybe I'll whip that one up and post it too. That would eliminate flicker, at the expense of striped platforms, and I don't think the second sprite could be more than one color.

[Cybergoth]

Hi there!

 

You pretty much nailed it.  The latest demo I posted has a reflected PF2 and asymmetrical PF1s (PF0 is unused in that demo).

 

I've been working a lot on stuff like that for Jumpman already. There I've written a system of 8 or 9 different kernels as macros for it, which can do all sorts of different levels, with varied PF stripe combinations symmetrical or assymetrical as required. It can even have differently behaving vertical stripes mixed as required. I still need to reduce it's complexity though, as currently with the most complex Jumpman levels there's no cycles left for displaying anything else but Jumpman himself

 

Greetings,

Manuel

[StanJr]

Prince of Persia has always been on my (looong) ToDo-list and those designs look great. Maybe I should shift my priorities now.

 

yes, please. ANYTHING that can Thomas back programming a game is a very very good thing. I'm still looking forward to mini-game tri-cart that is supposed to be coming out. We need more Thomas!