Anyone thirsty for some PoP?

[Tom]

How much of the playfield are your kernels using ? PF1 and PF2 ?

You see, a screen in Prince consists of 10*3 tiles, so if you want to use the original level data, you'll probably end up with 3 playfield pixels per tile (or 4, if you use the whole playfield).

[Thomas Jentzsch]

How much of the playfield are your kernels using ? PF1 and PF2 ?

Yup.

 

You see, a screen in Prince consists of 10*3 tiles, so if you want to use the original level data, you'll probably end up with 3 playfield pixels per tile (or 4, if you use the whole playfield).

Yup, 3 tiles/tile, that's what both of our kernels display. Plus one tile each of the left and right screens (which is important to see the gates between screens).

[Tom]

actually this is only necessary on the left side of a screen. there, the rightmost tiles of the screen's left neighbor can be seen. but it's of course also possible on the right side, since you have an additional PF pixel there...

 

i think you also should draw the bottom border of the top screen onto the current screen. there are some places where the upper screen contains a floor with a loose floorplate, which you should see from the screen below (when you hit the ceiling)

[Thomas Jentzsch]

actually this is only necessary on the left side of a screen. there, the rightmost tiles of the screen's left neighbor can be seen. but it's of course also possible on the right side, since you have an additional PF pixel there...

Actually you can see a gate at the right side in the original. It's only a small vertical bar.

 

i think you also should draw the bottom border of the top screen onto the current screen. there are some places where the upper screen contains a floor with a loose floorplate, which you should see from the screen below (when you hit the ceiling)

Yup, we have to draw 3.5 floors.

[Tom]

this depends probably on how you render the image. in the original's fake 3d rendering method, only the rightmost tiles of a screen could be seen on the screen to the right.

 

you mean the situation in the screenshot (from pv3) below.

each cell of the red grid is what can be seen on the computer screen.

from the map data's point of view, the gate is part of the left screen, but only the post can be seen on the left screen. most of the gate can be seen on the right screen only, but the gate is not really part of the right screen.

 

nothing from the right screen is visible on the left screen.

 

[Thomas Jentzsch]

That's what I meant.

 

We could show the post on the right and the (opening) gate on the left. Then the game would offer the same information as the original.

 

But then the gate would not belong to any screen, it would be something in between.

 

Or we could display two tiles of the left screen and the post would be on the rightmost tile of a screen.

[Tom]

Or we could display two tiles of the left screen and the post would be on the rightmost tile of a screen.

 

Something like that would probably be reasonable. We could simply bake the rightmost border of a screen into the map/graphics data of its right neighbor screen.

[Thomas Jentzsch]

Something like that would probably be reasonable. We could simply bake the rightmost border of a screen into the map/graphics data of its right neighbor screen.

I am not sure if that would be the best solution. We would loose symmetry inside the screens, which might help reducing the map size.

 

And IMO it would look a bit odd, to see parts of the left screen, but not of the right screen.

[Thomas Jentzsch]

My latest binary (some messy code also included).

 

I added the ball (gate), and you can now move the players around.

 

The enemy shows some color tearing effect at the right of the screen. I could remove that, but at the cost of the 2nd sword. Maybe I will.

pop010.zip

[Cybergoth]

hi there!

 

The enemy shows some color tearing effect at the right of the screen. I could remove that, but at the cost of the 2nd sword. Maybe I will.

 

Hm... it seems like your loop draws items in this sequence:

 

BALL

PF

P1

P0

PF

 

As the Ball is not moving horizontally, maybe this was a better approach:

 

P0

PF

BALL

P1

PF

 

Greetings,

Manuel

[vdub_bobby]

My latest binary (some messy code also included).

 

I added the ball (gate), and you can now move the players around.  

 

The enemy shows some color tearing effect at the right of the screen. I could remove that, but at the cost of the 2nd sword. Maybe I will.

I thought you mentioned earlier that you were going to use a (flickering) ball for the sword? I still think that's the best idea, mostly cuz I don't think a constant 30 Hz flicker is that bad and cuz an independently colored sword (independent from the players, that is outweighs the flicker. Thoughts from anyone else?

 

I'll try to actually code the flicker so we can see how it looks

[Thomas Jentzsch]

I thought you mentioned earlier that you were going to use a (flickering) ball for the sword?

Yup, that's still the plan. It's still a demo.

 

But since I don't have any Prince graphics which would require the use of a missile, I used them for the swords instead.

 

The gates will most likely be displayed by using the 2nd player. But then I need to implement repositioning first.

[Thomas Jentzsch]

As the Ball is not moving horizontally, maybe this was a better approach:

 

P0

PF

BALL

P1

PF

The problem is, that the players couldn't start or end a the same scanline. And if I use the ball for the sword, one player wouldn't hold it correctly. I suppose that would look quite odd.

[Cybergoth]

Hi there!

 

The problem is, that the players couldn't start or end a the same scanline.

 

Why?

 

Greetings,

Manuel

[Thomas Jentzsch]

Why?

Beause it's a 2LK and, due to the color writes, I cannot VDEL the players.

[vdub_bobby]

I rewrote my kernel again

 

Now we have the ball as sword (flicker) plus two players plus one of the missiles.

 

The missile can only be a single line in height (two scanlines in a 2LK) but it can have an independent color - unless P1 is on the same scanline as it, then P1s color overrides it.

 

The ball is used for the sword in my demo, but it can be any height and can be positioned anywhere on the screen.

 

Also, just to see how it would look, I implemented the flickering sword so you all can see. It doesn't show on the screenshot, obviously, but you can see the glorious flicker if you run the .bin.

pop2lk.zip

[Thomas Jentzsch]

That gives a nice flashing effect when the swords overlap.

[vdub_bobby]

Why?

Beause it's a 2LK and, due to the color writes, I cannot VDEL the players.

What I'm doing is this:

 

VDEL on player 0, then write his color on the same scanline as player 1.

 

If I had time I'd like to do it like this:

cpy P0Top

bpl Switch

lda (),Y

sta GRP0

lda (),Y

sta P0Color

And then 'lda P0Color sta COLUP0' on the next line. But I don't have the extra 6 cycles to spare, so I'm doing this:

cpy P0Top

beq Switch

bpl Wait

lda (),Y

sta GRP0

And then on the next line I do a 'lda (),Y sta COLUP0' - which has its own problems - I have to have buffer bytes on both sides of my color table and it would cause major color issues if I was using missile 0 on different lines than player 0.

The first issue isn't such a big deal since with a 2LK the buffer only needs to be ~64 bytes on either side. The 2nd issue isn't a problem since I don't have time to stick M0 in there anyway!

[Thomas Jentzsch]

The first issue isn't such a big deal since with a 2LK the buffer only needs to be ~64 bytes on either side.

But then you are wasting ~128 Bytes for each animation requireing a different color table, right?

[+Nathan Strum]

Wow. Both of those look pretty amazing. I can only pretend to have the vaguest clue what you're talking about, but either of these would form the basis for an excellent looking 2600 title (whether Prince of Persia, or something else).

 

On the one hand, stuff like this makes me really want to try and learn 2600 programming. On the other hand, actually looking at the code makes me realize it's something way beyond my comprehension.

[vdub_bobby]

The first issue isn't such a big deal since with a 2LK the buffer only needs to be ~64 bytes on either side.

But then you are wasting ~128 Bytes for each animation requireing a different color table, right?

No, you can stick anything in those 128 bytes - I just need that distance from page boundaries so I don't cross them when reading the data during the kernel.

 

That make sense?

 

My tables would look like this:

org $FE40            ;64 bytes past page boundary

.byte COLOR1

.byte COLOR2

etc...



org $FEC0            ;color data ends 64 bytes before page boundary

 

I'll attach my rather sloppy source code, too.

pop2lksource.zip

[Thomas Jentzsch]

That make sense?

Yup, you can put some animations graphics in there.

[vdub_bobby]

Incidentally, one thing I noticed after adding the missile to my demo:

 

A single, oct-width object (missile or ball) is not really wide enough to be a falling platform - falling platforms probably need to be two or three times as wide as the player to look right.

 

Which means that you have to use either the PF for falling platforms or, for screens that had 2 falling platforms, one double-width player and two missiles/missile-ball combo.

 

And that's just for single-width sprites...

[Thomas Jentzsch]

A single, oct-width object (missile or ball) is not really wide enough to be a falling platform - falling platforms probably need to be two or three times as wide as the player to look right.

You could split the platform into pieces which fall down separated. Just like the sword, but with some vertical gaps (e.g. quad width missile, HMM0 +/-1, 4 pixel vertical gap).

[Cybergoth]

Hi there!

 

Why?

Beause it's a 2LK and, due to the color writes, I cannot VDEL the players.

 

I thought you already do? You only need to time the color writes, or?

 

BTW: You can probably optimise this:

 

dey ; 2

tya ; 2

cmp BlockTbl,x ; 4

bne .nextRow ; 2³

dex ; 2

bpl .nextBlock ; 2³= 15

 

with something like:

 

DEY

LDX LargerButFunkierTable,Y

BPL .nextLine

 

Greetings,

Manuel