Pick Axe Pete

[+johnnywc]

I would say that a 2600 port is doable with the following assumptions.

 

1. All game objects flicker at 30 Hz.

2. Rocks colliding to form gold should instead change shape without a color change (a crystal?)

3. No more than 4 rocks are allowed per floor at a time.

4. The kernel supports skewing M0 and M1 every line pair to make pseudo sprites.

 

Object allocations.

 

Even frame

P0 = Pete

P1 = rock (recycled every floor as needed)

M0 = Axe?

M1 = rock 2

 

Odd Frames

P0 = key or spare axe

P1 = rock 3 (recycled every floor as needed)

M0 = Door (recycled on 3 floors)

M1 = rock 4

 

Ladders and floors are all PF graphics.

 

Hi Robert -

 

Thanks for the ideas. This is very similar to what I'm working on. Right now my kernel supports this:

 

P0 - Pete, Key

P1 - Rocks, Axe

M1 - Ladder

BL - Doors

 

I hope to be able to use M0 for falling rocks - not sure if I'll have enough time in the kernel.

 

Right now I'm using a 2LK for the sprites, and I'm using SkipDraw (18 cycles) to draw P0 and P1.

 

- Each 'zone' is 24 lines high, with 3 lines for the floor and 21 for the open space.

- The floor needs 6 PF writes (42 cycles), plus 18 for one of the players = 60, leaving 16 free for other stuff

- The open space need to draw just a player (18), the ladder (14), and 2 PF color changes for the door (13) = 45, leaving 31 free for other stuff

 

I should have enough time to draw a rock using M0 in the open space - I need to get the multiplexing for P0 and P1 working first. My big concern is figuring out where to do the repositioning... In Lady Bug, I could do it in between the rows because the PF was symetrical... this kernel has 6 PF updates that need to be done on each line for the floors leaving no time unless I have a blank line (which would not look good IMO). Another option is to do the repositioning on the first line after the floor - but I'll need two lines to reposition both objects.

 

Anyway - thanks for the ideas.

[cd-w]

I should have enough time to draw a rock using M0 in the open space - I need to get the multiplexing for P0 and P1 working first. My big concern is figuring out where to do the repositioning... In Lady Bug, I could do it in between the rows because the PF was symetrical... this kernel has 6 PF updates that need to be done on each line for the floors leaving no time unless I have a blank line (which would not look good IMO). Another option is to do the repositioning on the first line after the floor - but I'll need two lines to reposition both objects.

Anyway - thanks for the ideas.

 

I personally would avoid multiplexing P0, and just multiplex P1 for all the non-player objects. This means that you will only have one mid-kernel reposition to worry about. Also, it is possible to do repositioning without wasting a whole line, but it requires around 10 different repositioning kernels. I used this approach in Juno First to free up some cycles. The basic idea is to look-up the position in a table and jump to the correct repositioning kernel, e.g:

 

 ; Figure Out Which Repositioning Kernel Is Required (KernelTable has an entry for every X position)
 ldx XPosition
 lda KernelTable,X
; Jump To Correct ReposKernel 
 sta JPTR
 jmp (JPTR)

ReposKernel
; Pad To Correct Position
 sta RESP1
; Set Fine Tune Position (NudgeTable has an entry for every X position)
 lda NudgeTable,X
 sta HMP1
; Reposition Sprite
 sta WSYNC
 sta HMOVE
; Go Back To Regular Kernel
 jmp KernelResume

 

You will need to customise ReposKernel for all of the different positions. This uses quite a bit of ROM, but it frees up lots of cycles round about the write to RESP1.

 

I'm looking forward to seeing how this game develops.

 

Chris

[supercat]

Ladders and floors are all PF graphics.

 

It's been awhile since I've played PAP (need to hook up my O2 again...) but my recollection is that the doors are always in the center of the screen, and there's at most one ladder on screen at once. If my recollection is correct, how about using PF2 for the doors and the Ball for the ladders?

[supercat]

I personally would avoid multiplexing P0, and just multiplex P1 for all the non-player objects.

 

The ability to have multiple rocks in a zone at once is important to the game. I'm not sure if having all five at once in a zone would be critical, but I would think a minimum of four (two per frame).

 

Thinking about it, though, if the O2 had five rocks on screen, a player, an axe or key, and a ladder, assuming the door could be handled with PF graphics, that would be eight sprites total on screen. Since the 2600 can do five sprites per frame, it might not be necessary to multiplex sprites if you don't mind the rocks looking a bit boxy. The space between platforms would allow plenty of CPU time to precalculate the sprite data for the platform scan lines.

 

What am I missing? I'm not sure how to best divvy up the sprites for sensible colors, but if the door and ladder flicker that shouldn't be a problem:

Frame 0:
 P0 -- Human
 M0 -- Unused (gold bar?)
 P1 -- Axe/Key
 M1 -- Rock
 Ball -- Rock
 Playfield -- Unused

 P0 -- Swinging axe
 M0 -- Rock
 P1 -- Rock
 M1 -- Rock
 Ball -- Ladder
 Playfield -- Door

 

Hmm... slight complication if the "ball" rock passes over a playfield row, since COLUPF would have to be set there. Hmm...

 

What registers besides the PF have to be written on those rows... I think just two or three each (GRP0 and ENABL on one row, then GRP1, ENAM0, and ENAM1 on the other). How about using COLUBK to draw the platforms to free up the Ball color. Assuming the platform area is 126 pixels wide and you set up the sprite data in RAM before each platform row, then the platform would be something like:

  lda dat_GRP0
 sta GRP0
 lda dat_ENAXX
 sta ENABL
 lsr
 jsr DRAW_ROW ; RAM routine--31 bytes and 45 cycles, plus 12 for jsr/rts, so 57 total
 SLEEP 5
 sta ENAM0
 lsr
 sta ENAM1
 lda dat_GRP1
 sta GRP1
 jsr DRAW_ROW ; RAM routine--31 bytes and 45 cycles, plus 12 for jsr/rts, so 57 total
 SLEEP 5
 lda dat_GRP0
 sta GRP0
 lda dat_ENAXX
 sta ENABL
 lsr
 jsr DRAW_ROW ; RAM routine--31 bytes and 45 cycles, plus 12 for jsr/rts, so 57 total
 SLEEP 5
 sta ENAM0
 lsr
 sta ENAM1
 lda dat_GRP1
 sta GRP1
 jsr DRAW_ROW ; RAM routine--31 bytes and 45 cycles, plus 12 for jsr/rts, so 57 total
 SLEEP 5

The DRAW_ROW routine in RAM would simply be a mixture of STY COLUBK and STX COLUBK, followed by an RTS. How does that sound?

[+johnnywc]

I personally would avoid multiplexing P0, and just multiplex P1 for all the non-player objects. This means that you will only have one mid-kernel reposition to worry about. Also, it is possible to do repositioning without wasting a whole line, but it requires around 10 different repositioning kernels. I used this approach in Juno First to free up some cycles. The basic idea is to look-up the position in a table and jump to the correct repositioning kernel, e.g:

 

; Figure Out Which Repositioning Kernel Is Required (KernelTable has an entry for every X position)
 ldx XPosition
 lda KernelTable,X
; Jump To Correct ReposKernel 
 sta JPTR
 jmp (JPTR)

ReposKernel
; Pad To Correct Position
 sta RESP1
; Set Fine Tune Position (NudgeTable has an entry for every X position)
 lda NudgeTable,X
 sta HMP1
; Reposition Sprite
 sta WSYNC
 sta HMOVE
; Go Back To Regular Kernel
 jmp KernelResume

 

You will need to customise ReposKernel for all of the different positions. This uses quite a bit of ROM, but it frees up lots of cycles round about the write to RESP1.

 

Thanks for the tip... this is very similar to what I did in CoM, except I didn't need HMP1 set since I was dealing with 6 course positions (didn't need HMOVE). Also, PF0 was constant and depending on what side I was working with, PF1 and PF2 were blank. Since this kernel needs PF0 writes and I can't take advantage of the 'blank PF1/PF2' situation in CoM, I still don't think I'll have time to do the repositioning during the floor kernel (especially with the strict timing of writing to PF2L at cycle 45).

 

Actually, I just blanked out the middle line of the floor to see what it would look like and it's not too bad:

 

 

I'll see what I can come up with.

 

Thanks!

[+johnnywc]

Ladders and floors are all PF graphics.

 

It's been awhile since I've played PAP (need to hook up my O2 again...) but my recollection is that the doors are always in the center of the screen, and there's at most one ladder on screen at once. If my recollection is correct, how about using PF2 for the doors and the Ball for the ladders?

 

Hi supercat -

 

Thanks for the ideas. Right now I'm using M1 for the ladder and the BL for the door. The reason I'm using the BL for the door is that to make it spin when a rock comes out I'm adjusting the size of the BL (and nudging it over using HMBL) between sections depending on the state. I'm also concerned about the colors (the color of the door changes dynamically) and I wanted the ladder to be a constant color (M1 will always be the color of P1 which will always be a rock or pickaxe which were going to be the same color). If I use the BL/PF for the ladder/door, the spinning will be much more course (actually, it would only flash between 8 pixels wide and none). Additionally, I couldn't use independent colors for each as the ladder position can be in one of 9 places, including right over the door.

 

As you mention though, using the BL/PF would free up M1 for a rock sprite which could be more important as far as reducing flicker. We'll see...

 

Thanks again,

Edited November 7, 2008 by johnnywc

[cd-w]

Actually, I just blanked out the middle line of the floor to see what it would look like and it's not too bad:

 

That blank middle line looks good to me.

 

Chris