dodraw pointers

[glurk]

Although I've ported some 2600 games to 8bit, I've never actually written one.  So, I'm trying that...  I have code that does an asymmetric playfield, single line.  And I'm trying to integrate "dodraw" and cannot figure out where to place the sprite data, and how to set the pointers.  The draw code is this:

 

 lda #H_PLAYER_0 - 1
 dcp P0_YPos
 bcs .doDraw
 lda #0
 .byte $2c
.doDraw
 lda (sprite0Ptr),y
 sta GRP0

 

And 'Y' is my line counter, which can range 185<->0...  Of course, I don't want the lda(),y to cross a page boundary and be 6 cycles, because it messes up my cycle-45 PF write.  And I'm getting a damn headache trying to figure how to align the sprite data and setup the pointers.  So far, I guess I'm doing it wrong.

 

Can someone explain this to me...  Where in the page do I place my sprite data, and how do I set up the pointers?  And I guess I have to reset P0_YPos every frame, since DCP decrements it.  This offset indexing is making my head hurt.

 

[Thomas Jentzsch]

I am always having a problem with the setup too. But I have old code which I can look up.  

 

The setup code looks like this:

; setting up the temporary counter...:
  sec
  lda #<H_PLAYER_0+186 
  sbc ySprite0              ; vertical sprite position (bottom = 0)
  sta P0_YPos
; ...and the lo pointer: 
  adc #<Sprite0Data-186-3   ; carry = 1!
  sta sprite0Ptr
; the obvious part:
  lda #>Sprite0Data
  sta sprite0Ptr+1

With a 186 bytes kernel, you have to put the sprite data (e.g. Sprite0Data) into the last 70 bytes of a page (185 + 70 = 255).

 

Untested!  

[+SpiceWare]

19 hours ago, glurk said:

And I'm trying to integrate "dodraw" and cannot figure out where to place the sprite data, and how to set the pointers.

 

You might find my tutorial helpful. Specifically in the comments of Step 4 I posted a few replies that breakdown how DoDraw works.

[glurk]

Thanks to you both, I've got 'DoDraw' pretty much figured out and working.

 

If you wanna look, here's my WIP game/demo/thing.  It's a RAM-based 16x14 "programmable" playfield, with two single-line players that can move around it freely.  If you go into the debugger and change the $33 or $CC values to $AA (or whatever) the playfield blocks change onscreen.

 

This was a huge pain to write, I had to unroll the kernel, and displace stuff back and forth to get the timing to work out.  The kernel's HUGE for what it does....

 

WIP.bin

[+SpiceWare]

8 hours ago, glurk said:

This was a huge pain to write, I had to unroll the kernel, and displace stuff back and forth to get the timing to work out.  The kernel's HUGE for what it does....

 

Know how that goes - I unrolled the kernel in my first game, Medieval Mayhem. Looking at this image:

 

The kernel for the top castles is unrolled in 1 bank (there's eight 4K banks in total).

 

The kernel for the middle section is unrolled in 3 banks due to all the graphics needed for the Dragon (68 images, 34 distinct frames of animation with a different graphic for each player), the Marching Knight (8 images).

 

 

The kernel for the bottom castles lives in another bank.

 

 

TIP: Learn how to use macros in dasm. I used macros to write the unrolled kernels in Stay Frosty, which made it significantly easier to do than the kernel in Medieval Mayhem.