Anyone thirsty for some PoP?

[pmpddytim]

If this gets made (which I would like to see) will you be able to use the Prince of Persia name? Probably not, but I was just wondering.

 

[Haydn Jones]

How about a competition for a name, artwork and title screen (maybe a kromawhatsit screen if you have space)

just so un non geniuses can join in the fun

[StanJr]

WHEN this gets made, tim, when. We have to think positive!

 

I figure you could just call it "Persian Prince" and be done with it.

 

 

Looking great guys, keep it up!

[vdub_bobby]

The main kernel should become at least ~180 pixels tall, so even with a 2LK for the playfield you end up whith 360 bytes each screen. I haven't counted the screens of PoP yet, I suppose there are a few hundreds of them.

How about this: Playing area of screen is 128 lines tall (leaving 64 lines split between timer (and score? Can't remember now) at top and life meter at bottom. That's for a 192-scanline kernel.

With a 2LK, you can fit all the data for a single screen in 1 page. (4 sets of 64 bytes). Still a lot, but I think it is doable, partly because of...

But they are repeating, so we might be able to recylce some whole screens or at least stripes of them.

Actually, after giving the maps a quick look, I think we could do a lot of recycling.

But then we still have the problem with the dynamic parts of the screens. Those have to be done in RAM for display (bookkeeping of all changes is another RAM related problem). Fortunately the dynamic areas are vertically quite small, so probably a mixture between RAM and ROM based graphics will be the optimal solution,

Actually, you might be able to do all of the dynamic areas of the screen with player graphics and the ball. The screens with an enemy pretty much don't have anything else, so you could do the gates/spikes/falling platform with the player. Doing it that way would probably require some, hopefully mostly minor, modifications of the level design.

 

Couldn't you just use a fixed HM value for the sword? And then calculate back to the top of the screen and position it? Inside the kernel you only had to HMOVE it then.

That's a good idea. I think that would actually work...and save cycle time in my kernel loop, too

Hm, that would pretty much limit the possible angles. How about drawing the sword like the player graphics? That shouldn't cost any extra cylces over your current solution, but save a lot of ROM, allowing for multiple angles.

I'm not sure what you mean by "drawing the sword like the player graphics," but if I use a player for the sword, then we have to flicker to get the enemy onscreen. Maybe I misunderstand.

 

Oh, and your idea about working on the same screen is a good one; I'll post a demo + screen shot (hopefully) sometime this weekend

Yours looks pretty nice!

[Thomas Jentzsch]

How about drawing the sword like the player graphics? That shouldn't cost any extra cylces over your current solution, but save a lot of ROM, allowing for multiple angles.

I'm not sure what you mean by "drawing the sword like the player graphics," but if I use a player for the sword, then we have to flicker to get the enemy onscreen. Maybe I misunderstand.

No, my fault.

 

I meant to say, that you could use the player drawing code (e.g. "skipdraw") and just add the sword code into.

[vdub_bobby]

How about drawing the sword like the player graphics? That shouldn't cost any extra cylces over your current solution, but save a lot of ROM, allowing for multiple angles.

I'm not sure what you mean by "drawing the sword like the player graphics," but if I use a player for the sword, then we have to flicker to get the enemy onscreen. Maybe I misunderstand.

No, my fault.

 

I meant to say, that you could use the player drawing code (e.g. "skipdraw") and just add the sword code into.

Oh. That makes sense - I should have been doing that anyway.

 

Here's a mockup using an essentially unchanged kernel from the last demo I posted. You can see right off the bat the limitations of using only a partially asymmetrical PF.

[Robert M]

Here's a mockup using an essentially unchanged kernel from the last demo I posted.  You can see right off the bat the limitations of using only a partially asymmetrical PF.

 

How about 2 separate partially symetrical PF kernel? One that reflects only PF1, and another that reflects only PF2. Then you can have rooms with detail on the edges, or rooms with detail in the middle.

[Thomas Jentzsch]

How about 2 separate partially symetrical PF kernel?  One that reflects only PF1, and another that reflects only PF2.   Then you can have rooms with detail on the edges, or rooms with detail in the middle.

Yes, but still you had to almost completely redesign the levels. And I am not sure, if it would be flexible enough even then.

 

I redesigned the kernel internally, now displaying two sprites and two missiles (swords) flickerfree (31 cycles free). The sword color is a problem, I could replace one with the ball. Though I suppose I'll need that for the gates, since there are screens with an enemy and a gate (even on the same row).

pop005.zip

[Inky]

I figure you could just call it "Persian Prince" and be done with it.  

 

 

Baron of Baghdad?

Tyrant of Tehran?

Sultan of Saudi?

Royalty of Rihad?

[Thomas Jentzsch]

After I realized that I still had 31 cycles left, I wondered if...

 

(still 12 to 13 cycles left)

 

I thought double sizes players are more appropriate, now we need someone who designs some nice, taller graphics for the prince.

 

Nathan, salstadt...?

pop006.zip

[Thomas Jentzsch]

An experiment in "3D". Opinions?

[Tom]

3d looks cool, but how do you make the prince walk between two pillars ?

[Nukey Shay]

It would be difficult to get the player to be hidden by the pillars if every other scanline is skipped to create the shading.

IMO 2-D looks better anyway, due to the 2600's low resolution.

[Thomas Jentzsch]

Yes, I suppose 2D will look better (and RAM would be a problem anyway with 3D). Walking between the pillars isn't possible.

 

I have two more options for "2.5D", I could only display the horizontal or the vertical parts of the 3D effect.

 

This is one of those two options:

[+Nathan Strum]

An experiment in "3D". Opinions?

 

I really like the look of the 3D layout, even if it may not work for this particular game. It's a good idea to keep for future use elsewhere.

[salstadt]

"How about a competition for...artwork and title screen (maybe a kromawhatsit screen if you have space)"

 

Hellooooo, resident Atari homebrew artist here! Unless our coders are opposed to it, I'd really like to do all art myself.

 

Thomas, I'm loving the way those screens are looking. Alternating scanlines for the 3rd dimension never even occured to me. So hey, what format do you guys want the animations in? I can do either animation files, still gifs or even as X's in text files if you need them as such. Be as specific as possible (ie, "8x16 2-color 6-frame max") so that I can really make the most of my resources.

 

- Adam

[Thomas Jentzsch]

"How about a competition for...artwork and title screen (maybe a kromawhatsit screen if you have space)"

 

Hellooooo, resident Atari homebrew artist here! Unless our coders are opposed to it, I'd really like to do all art myself.

I am not opposed at all. But I'll only do the kernel and maybe algorithms for efficient storing, somebody else will have to do all the remaining (boring) stuff.

 

Thomas, I'm loving the way those screens are looking. Alternating scanlines for the 3rd dimension never even occured to me.

It's not looking that bad, but full "3D" is most likely too much. I'll try the other 2.5D option, before we decide which is best. And maybe we'll have to switch back to 2D, due to RAM restrictions anyway.

 

So hey, what format do you guys want the animations in? I can do either animation files, still gifs or even as X's in text files if you need them as such.

X's in text files would probably most convenient, though of course we I'd like to see the animations before coding them.

 

Be as specific as possible (ie, "8x16 2-color 6-frame max") so that I can really make the most of my resources.

It's probably still a bit early fo exact specifications. When using RAM for displaying the dungeon, we should have about 3K for the animations, which is not that much

 

We could duplicate the kernel over several banks and exchange the enemies animation (plus some eye candy like torches, windows, bricks etc.), but that would only gain us little extra space since the Prince's animations hat to be in every bank. Though... if we split that too (e.g. with/without sword)...

 

The current format requires 8xY*2 (graphics and color) bits for each animation. You can use as many colors as you like (one each row). Y has yet to be determined. IMO the best would be, if the animator does it (maybe something around 2/3 of the room height, which is ~30 pixel ). Something around 20 might work. That would be 40 bytes for each animation frame, though we might be able to share some color data and a lot of graphics might not use the full height.

 

The number of frames depends on how many animiations we need and how much space we have. With 3K we could store ~100 of them. With "wasting" a few banks, we might be able to store ~200. And if we find a lot of frames which share the colors, this number would grow further. And we only need the animations for one direction, since we can "reflect" both players data.

 

BTW: The sword is currently limited to constant widths and horizontal moves for each frame and the visibility is linked to the color data. This should save some valuable space.

 

I hope that was not too complicated.

[salstadt]

"It's probably still a bit early for exact specifications. When using RAM for displaying the dungeon, we should have about 3K for the animations, which is not that much "

 

Okay, for now (over the next week) I'll do the basics - a walk, jump forward, land, grab ledge from jump, climb ledge. Then as you guys get further into the code, we can set a frame count and I can ration it out among objects and characters.

 

As for the prince, even though we can have him as tall as 30+ pixels, I'm still leaning toward 16 or so with the two colors (sinc ethe stretched 8 horiz. make a pseudo 16x16). Remember that the prince gets very horizontal in particular animations, like his leaps, his death, etc. So even though it limits detail, the more square we keep his dimensions, the freer I'll actually be to make his limbs move naturally. For example, if he's 32 pixels tall, making each leg at least 12 tall, it becomes impossible for him to do a big jump with his legs outstretched. Same with the color - it'll be tricky enough (but I can manage) to keep his pants on seperate scanlines from everything else, so even though hair, feet, etc. might look nice in a standing frame, it would compound the difficulty to match it up in a scanline for every movement.

 

And here's some art I did tonight. Lemme know what you guys think.

 

- Adam

 

[Thomas Jentzsch]

As for the prince, even though we can have him as tall as 30+ pixels, I'm still leaning toward 16 or so with the two colors (sinc ethe stretched 8 horiz. make a pseudo 16x16). Remember that the prince gets very horizontal in particular animations, like his leaps, his death, etc. So even though it limits detail, the more square we keep his dimensions, the freer I'll actually be to make his limbs move naturally. For example, if he's 32 pixels tall, making each leg at least 12 tall, it becomes impossible for him to do a big jump with his legs outstretched.

Well, we have at least three options of overcome these restrictions:

1. merge two sprites (only works without enemy or by indroducing some flicker then)

2. temporary quad-sized sprites

3. use the "sword" (missiles) for a few missing pixels

 

And we should not forget the aspect ratio (~1.6:1) of a 2600 pixel.

 

Since the kernel is already 2LK this aspect ratio remains constant (each spirte pixel covers 2x2 pixel). So 8 pixel width are equal to ~13 pixel height. If we combine both sprites, we could even go to 26 pixel.

 

And IMO it would look pretty unrealistic if a quite tiny prince jumps too high or too far.

 

Same with the color - it'll be tricky enough (but I can manage) to keep his pants on seperate scanlines from everything else, so even though hair, feet, etc. might look nice in a standing frame, it would compound the difficulty to match it up in a scanline for every movement.

Yup, I suppose it depends how noticable those "color errors" become. If the animation is fast enough, you might not even notice that he temporarily e.g. lost his shoes.

 

And as long as the Prince is alone, we still have the 2nd sprite option, which would allow 2 colors for each row.

 

And here's some art I did tonight. Lemme know what you guys think.

LOL!

[salstadt]

Yeah, I'm just not sure ultimately it's gonna be worth the hassle of all that. Plus, the larger the sprite, the more manueverability we lose - less arch to his jumps to avoid ceilings, less impressive leaps, etc. I'll do a couple of sprite tests though, for you guys to mull over.

 

- Adam

[keilbaca]

And here's some art I did tonight. Lemme know what you guys think.

 

OMG That's hilarious! Thats just about as funny as that voicemail cpuwiz posted. I about fell out of my chair laughing. That right there, has my vote to be on the homebrew cart.

[Thomas Jentzsch]

Yeah, I'm just not sure ultimately it's gonna be worth the hassle of all that.

Neither am I. I just don't want to give up, before we checked all possibilities.

 

Plus, the larger the sprite, the more manueverability we lose - less arch to his jumps to avoid ceilings, less impressive leaps, etc.

As long at the size ratio is about the same as in the original game, where would we lose then?

 

I'll do a couple of sprite tests though, for you guys to mull over.

That would be nice. Some theory is good, but practice is better.

 

BTW: @vdub_bobby, I hope you are still there?

[Thomas Jentzsch]

It would be difficult to get the player to be hidden by the pillars if every other scanline is skipped to create the shading.

Yup.

 

IMO 2-D looks better anyway, due to the 2600's low resolution.

Probably you are right.

 

BTW: Would you be interested in helping to finish this project? IIRC that's something you where looking for.

[salstadt]

"As long at the size ratio is about the same as in the original game, where would we lose then"

 

You have a point. It might be nice to free up a little more headroom than the original title anyway, to give it somewhat of a feel like the recent console PoP games (that Ico-like nailbiting of making massive, flailing leaps and barely making it) but we'll do some tests and see how everyone feels about it.

 

- Adam

[salstadt]

"It would be difficult to get the player to be hidden by the pillars if every other scanline is skipped to create the shading."

 

I'd suggest making everything background anyway, just from the standpoint that if we use singular pillars we maximize visibility so that the player's never in a spot where they need to see the prince but can't) and also, to really sell the pillars, we'd need to have two lined up (one to fall in front of him, and one behind. That's a minimum of 6 pixels wide (when the screens's only 40-wide total) per chunk of pillars, which might bite us when designing the actual levels. Keeping it single-pillar will only suck up 3 pixels (space/pillar/pillar edge).

 

Here's a site that has pixel-perfect maps of all the original PoP levels:

 

http://west.club.fr/Nostalgie/Persia1/g_persia1.html

 

You guys might want to start with 12b - it's only 10 screens, and it has every type of player action required in the game at large. On that note, what sort of screen limit do you think we'll be facing total? I'd imagine we won't be able to get more than a few levels. If that's the case, it might be cool to have some sort of a compilation, like a few levels from PoP1, a few from PoP2 and 1 custom level.

 

What do you guys think about 2-player? Unless I'm mistaken, we can have two sprites and a ball, right? It would be pretty incredible if there was a co-op game. Or maybe sort of a race between players - start each screen, and the first person to reach the 'checkpoint' gets a point when the screen scrolls to the next one. Or maybe the players race to grab a sword. First person to get it can then go slash his/her opponent. I don't think we could have the most obvious 2-player game (fencing battles) because of the sprite limitations, but a co-op addition of the game, sans enemies would be really incredible.

 

- Adam