Anyone thirsty for some PoP?

[vdub_bobby]

New PoP demo. I'll try to attach a screenshot...

 

This one has the same PF setup as the demo I posted immediately before :reflected PF2 (the center), asymmetrical PF1 and blank (unused) PF0 (the edges).

 

Changes:

Striped platforms which allows:

Both sprites to show on screen without flicker. Move one with joystick 1, the other with joystick 2. Use joystick button to activate sword. For two swords you would have to flicker (the ball in this case).

Sprites are 8 pixels wide.

One of the sprites can be multi-colored - the other is monochrome.

Since there is only time to turn on/off the sword every other line, the sword will only appear (when pressing the button) if the Prince is on an even-numbered line. Or odd...? Every other one, in any case. And when the sword does appear, it will be drawn for two scanlines.

Also, since I only draw the PF every other line, this cuts the amount of data required in half

 

Thoughts?

 

(I'll post my code if anyone is interested, but I figured nobody would be. But if anyone can optimize it, that would be fantastic!)

pop.zip

[StanJr]

I am liking a WHOLE lot thus far! This is really coming along nicely.

[Thomas Jentzsch]

Here is a quick mockup hack of #3.

 

There still is plenty of space for players and maybe (partial) asymmetrical PF graphics.

pop001.zip

[vdub_bobby]

Here is a quick mockup hack of #3.

 

There still is plenty of space for players and maybe (partial) asymmetrical PF graphics.

:)

Pretty!

[Thomas Jentzsch]

I have a problem with the player graphics.

 

They have a 2LK resolution, so VDEL would work perfectly here. But its also required to change the colors, which are not vertical delayed.

 

So now we have some options:

A: single line resolution, but that would require more cycles

B: imperfect coloring, which might look odd

C: 2LK without VDEL, but then we would also have 2L positioning

D: ...

 

And on top of that, any non-single line solution will make 1L resolutions for the PF also quite hard (e.g. that thin bright stripe on top of the platform would have to become 2 lines)

 

Any ideas?

 

BTW: Are the enemy objects vertically restricted? Or can they move between platforms?

[Robert M]

I have a problem with the player graphics.

 

...

So now we have some options:

...

C: 2LK without VDEL, but then we would also have 2L positioning

...

 

I think option C is the best choice for this game. All vertical motion in the game is jumping and maybe gates opening and closing. The motion should be so quick that single line vertical motion is overkill, IMO.

 

Nice demo BTW.

[Tom]

BTW: Are the enemy objects vertically restricted? Or can they move between platforms?

 

the enemies didn't jump or climb by themselves, but it was possible to drop them down ledges (during fights, when they retreat)

[vdub_bobby]

I have a problem with the player graphics.

 

They have a 2LK resolution, so VDEL would work perfectly here. But its also required to change the colors, which are not vertical delayed.

 

So now we have some options:

A: single line resolution, but that would require more cycles

B: imperfect coloring, which might look odd

C: 2LK without VDEL, but then we would also have 2L positioning

D: ...

 

And on top of that, any non-single line solution will make 1L resolutions for the PF also quite hard (e.g. that thin bright stripe on top of the platform would have to become 2 lines)

 

Any ideas?

You seem to have this well in hand , but since I worked this up already, thought I'd post one more demo w/ screenshot:

 

This displays one sprite onscreen at a time (so multiple sprites would require flicker) with sword, no stripes, PF color can change, and this is the same partially asymmetrical PF that was in my last demo.

pop.zip

[Thomas Jentzsch]

the enemies didn't jump or climb by themselves, but it was possible to drop them down ledges (during fights, when they retreat)

I suppose it wouldn't be a big problem then, if they had some minor glitches while falling down. Or would it?

[Thomas Jentzsch]

You seem to have this well in hand

Oh no, carry on please. I am just playing with the kernel and might loose interest after (or even before) it is finished.

 

Since I want to avoid flicker for the player, the sword might become a problem. It will probably have to share the color with either the player or the enemy.

[Tom]

I suppose it wouldn't be a big problem then, if they had some minor glitches while falling down. Or would it?

 

I don't think so. As somebody else said, vertical movement is usually very fast anyway.

 

I only know the PC version. There the enemies behave just like the prince when they're falling: If they fall high enough, they lose energy, and if they fall even higher they die.

[Thomas Jentzsch]

This displays one sprite onscreen at a time (so multiple sprites would require flicker) with sword, no stripes, PF color can change, and this is the same partially asymmetrical PF that was in my last demo.

Looks good so far.

 

Instead of flickering the players, how about a flickering striped background?

 

One frame would display PF even lines, the other one odd lines. And by not showing the even or odd lines, you could mix the (different) colors of odd and even line frames.

[salstadt]

Both demos look great so far.

 

BTW: Are the enemy objects vertically restricted? Or can they move between platforms?

 

Single-platform. And even beyond that, enemies were usually fought in really basic rooms with few or no platforms. Basically you would enter a room and fight a guy, then move onto the next screen for more platfoming. So screens with enemy battles might not even have any color changes per line.

 

- Adam

[vdub_bobby]

This displays one sprite onscreen at a time (so multiple sprites would require flicker) with sword, no stripes, PF color can change, and this is the same partially asymmetrical PF that was in my last demo.

Looks good so far.

 

Instead of flickering the players, how about a flickering striped background?

 

One frame would display PF even lines, the other one odd lines. And by not showing the even or odd lines, you could mix the (different) colors of odd and even line frames.

Taking a cue from your comments about a 2LK...if I make the sprites with a 2-line resolution, then I can get both players onscreen with no flicker plus PF color changes. For two swords (i.e., during battle) I would have to flicker the swords, since I am using the ball for the sword - on the other hand, using the ball means I can get an independently colored object for the sword, as long as there is no PF on the same scanline(s).

 

Here's my latest and greatest.

 

The huge, huge advantage of yours, Thomas, over mine is that yours uses vastly less ROM space for data - mine reads 4 bytes of data for every scanline. But your version uses a lot more RAM. Tradeoffs...

 

Oh, and as a reminder: the sword won't work if you use PCAE.

pop.zip

[vdub_bobby]

And on top of that, any non-single line solution will make 1L resolutions for the PF also quite hard (e.g. that thin bright stripe on top of the platform would have to become 2 lines)

 

Any ideas?

What I did is write to the PF every line but write to the players every other (alternating) line. Double-line resolution sprites with single line resolution PF.

[Thomas Jentzsch]

What I did is write to the PF every line but write to the players every other (alternating) line.  Double-line resolution sprites with single line resolution PF.

But then you get a little problem with the player alignment. One of them will always fly above the ground.

 

Though maybe this can be compensated by a slight redesign of the PF graphics.

[vdub_bobby]

What I did is write to the PF every line but write to the players every other (alternating) line.  Double-line resolution sprites with single line resolution PF.

But then you get a little problem with the player alignment. One of them will always fly above the ground.

 

Though maybe this can be compensated by a slight redesign of the PF graphics.

Yeah, I noticed the same thing, and I figured that you could have one player stand in the 'floor' (the bright stripe above the platforms) and the other player stand on it.

 

Or you could make the 'floors' bigger, for more of a pseudo-3D look. Like this:

[Thomas Jentzsch]

Or you could make the 'floors' bigger, for more of a pseudo-3D look.  Like this:

Yup, that's what I figured too.

[Thomas Jentzsch]

The huge, huge advantage of yours, Thomas, over mine is that yours uses vastly less ROM space for data - mine reads 4 bytes of data for every scanline.  But your version uses a lot more RAM.  Tradeoffs...

Yup, and wouldn't that be actually 5 bytes every scanline (incl. color)?

 

That would result into about 1000 bytes/screen, thus allowing only 3 screens/bank (+ kernel code and player graphics). Or just less than 50 screens inside a 64K cart.

 

I suppose we have to accept some RAM tradeoffs.

[vdub_bobby]

The huge, huge advantage of yours, Thomas, over mine is that yours uses vastly less ROM space for data - mine reads 4 bytes of data for every scanline.  But your version uses a lot more RAM.  Tradeoffs...

Yup, and wouldn't that be actually 5 bytes every scanline (incl. color)?

 

That would result into about 1000 bytes/screen, thus allowing only 3 screens/bank (+ kernel code and player graphics). Or just less than 50 screens inside a 64K cart.

 

I suppose we have to accept some RAM tradeoffs.

Well, I'm doing 3 PF writes per line (PF1, PF2, PF1 again) plus one color write.

Right now the playing area of my demo is 100 lines tall, so one screen takes 400 bytes.

Figure all overscan/VBLANK in one bank, so just kernel, PF graphics, and sprite graphics in other banks...you could fit almost 10 screens per 4K bank. And if you you could probably make the PF double line resolution which would help things out a bunch. But yeah, it is really data-heavy. Maybe too heavy.

 

On a related subject...

 

Going along with my apparent preference for data-heavy code, I added the ability for the sword to be other than a horizontal line. Unfortunately, the method I came up with requires at least one ~200 byte long table full of mostly zeros (since I am writing to HMBL every other line and HMOVEing every *other* line).

 

But it looks pretty

pop.zip

[StanJr]

yes. Please, Thomas and bobby, team-up on this, kick its ass, and then we'll all celebrate the fruits of your labor. With both of you wokring on this, it is guaranteed to be one amazing game!

[Out_of_Gas]

This is turning into an incredible project. If this gets made into a cart, I will DEFINATELY get this one!

[Thomas Jentzsch]

Well, I'm doing 3 PF writes per line (PF1, PF2, PF1 again) plus one color write.

Oops, my fault. I thought you where doing a completely asymmetrical PF. IMO that's about the only chance for recreating a faithful PoP.

 

Right now the playing area of my demo is 100 lines tall, so one screen takes 400 bytes.  

Figure all overscan/VBLANK in one bank, so just kernel, PF graphics, and sprite graphics in other banks...you could fit almost 10 screens per 4K bank.    And if you you could probably make the PF double line resolution which would help things out a bunch.  But yeah, it is really data-heavy.  Maybe too heavy.

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.

 

But they are repeating, so we might be able to recylce some whole screens or at least stripes of them. 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,

 

Going along with my apparent preference for data-heavy code, I added the ability for the sword to be other than a horizontal line.  Unfortunately, the method I came up with requires at least one ~200 byte long table full of mostly zeros (since I am writing to HMBL every other line and HMOVEing every *other* line).

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.

 

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.

[Thomas Jentzsch]

For reference reasons, maybe we should try coding the very same screen, using salstadt's style.

 

The initial screen as displayed below, already contains a lot of major elements (asymmetry, gates, traps, maybe I'll add an gate opening switch).

[Thomas Jentzsch]

Here is a 1st coarse mockup. Fully asymmetrical using a striped PF.

 

The gate could be done either by the ball or (if possible) by the 2nd player.