In regards to a repeating playfield...

[hendersonn]

Hello all,

From some of the more experienced programmers here, would you say it would be "better" (more efficient/less consuming) to repeat a playfield graphic (vertically) by drawing one big sprite, or repeat the actually process of drawing it?

 

Thanks in advance

[Nukey Shay]

Playfield & sprites are 2 different things. 76 machine cycles per scanline, you can spend them however you want. Certainly less romspace/resources required is better if the end result would still fit your design concept.

[+SpiceWare]

Making a wild guess here, but it seems like you want the left/right sides of the playfield to be different and are proposing drawing the left side by using the playfield registers, while drawing the right side with the player registers? If so I assume you'd be using the players at 4x size so the player's pixels are the same size as the playfield pixels.

 

If that's right, you'd still have to update the playfield pixels on the right side, setting them to zero, otherwise the image on the right would be a merging of the playfield pixels and the player pixels - ie:

 

KernelLoop
  sta WSYNC
  lda (playfield0left),y
  sta PF0
  lda (playfield1left),y
  sta PF1 
  lda (playfield2left),y
  sta PF2
  lda (player0left),y
  sta GRP0
  lda (player1left),y
  sta GRP1
  SLEEP ??
  lda #0
  sta PF0
  sta PF1
  sta PF2

 

The other problem is the players, even at 4x sized, would only replace 16 of the 20 pixels on the right side.

[ZackAttack]

Making a wild guess here, but it seems like you want the left/right sides of the playfield to be different and are proposing drawing the left side by using the playfield registers, while drawing the right side with the player registers? If so I assume you'd be using the players at 4x size so the player's pixels are the same size as the playfield pixels.

 

If that's right, you'd still have to update the playfield pixels on the right side, setting them to zero, otherwise the image on the right would be a merging of the playfield pixels and the player pixels - ie:

 

KernelLoop
  sta WSYNC
  lda (playfield0left),y
  sta PF0
  lda (playfield1left),y
  sta PF1 
  lda (playfield2left),y
  sta PF2
  lda (player0left),y
  sta GRP0
  lda (player1left),y
  sta GRP1
  SLEEP ??
  lda #0
  sta PF0
  sta PF1
  sta PF2

 

The other problem is the players, even at 4x sized, would only replace 16 of the 20 pixels on the right side.

 

If there's going to be a gap in the middle of the scanline, couldn't the COLUPF just be set to match the COLUBK halfway through the scanline to avoid the merging of PF and player graphics? Then you'd only have to update the COLUPF register twice per scanline instead of all the PF registers. (Assuming SpiceWare's assumption is right)

[+SpiceWare]

Changing COLUPF would work. In either case, it's still much simpler to just update each playfield register twice.

[hendersonn]

I guess I shouldn’t have used the word "sprite." I was referring to the bit of data that makes up images used in the game in general. I.e, the following could be an example of what I want to use to draw an image for the playfield:

 

Image1
.byte #%10000001
.byte #%01000010
.byte #%00100100
.byte #%00011000
.byte #%00000000

 

To elaborate further, I'm simply interested in repeating that image vertically. I know there are a few ways to go about it, I'm just looking for what you guys would do (should I actually draw the image multiple times creating one big image, repeat the draw loop in the kernel, etc). Again, I have a grasp on mirroring, but I'm looking for something similar vertically.

 

Sorry for being vague (made sense to me )

 

PS: Thanks spice, I hadn't really had a need to create an asymmetrical playfield, but in the event that I do, I'll refer back to this post.

Edited January 10, 2015 by hendersonn

[Nukey Shay]

Repeating ~n number of bitmap bytes for the entire display? Simplest way would be to use an independent counter that is increased each pass, and reset it to zero whenever it surpasses the number of bytes in the bitmap. There's a LOT of games that do this the other way around (drawing the first bitmap value for a few scanlines, the second value for a few scanlines, and so on). The process is very similar to using a repeated pattern, except that it's trimming down the scanline counter to get the index...instead of constantly resetting the index.

[+SpiceWare]

PS: Thanks spice, I hadn't really had a need to create an asymmetrical playfield, but in the event that I do, I'll refer back to this post.

Please don't refer to that, it's not efficient. This is what you'll be doing:

KernelLoop
  sta WSYNC
  lda (playfield0left),y
  sta PF0
  lda (playfield1left),y
  sta PF1 
  lda (playfield2left),y
  sta PF2
  SLEEP ??
  lda (playfield0right),y
  sta PF0
  lda (playfield1right),y
  sta PF1
  lda (playfield2right),y
  sta PF2
  dey
  bne KernelLoop 

[hendersonn]

Great, thanks for the feedback.

(Also, "bitmap" was the word I was looking for previously.)

[+SpiceWare]

To repeat going down, it'll be most efficient if you repeat a shape that's a power of 2 in size. 4 rows, 8 rows, 16 rows, etc.

KernelLoop:
  tya
  and #3 ; repeats an 4 scanline shape
  tax
  sta WSYNC
  lda playfield0left,x
  sta PF0
  lda playfield1left,x
  sta PF1 
  lda playfield2left,x
  sta PF2
  SLEEP ??
  lda playfield0right,x
  sta PF0
  lda playfield1right,x
  sta PF1
  lda playfield2right,x
  sta PF2
  dey
  bne KernelLoop 

Using X to get the playfield data means you'll read directly from ROM, so you can't change the pattern shown. If you want to use Y, just change it so that X is your scanline countdown.

KernelLoop:
  txa
  and #07 ; repeats a 8 scanline shape
  tay
  sta WSYNC
  lda (playfield0left),y
  sta PF0
  lda (playfield1left),y
  sta PF1 
  lda (playfield2left),y
  sta PF2
  SLEEP ??
  lda (playfield0right),y
  sta PF0
  lda (playfield1right),y
  sta PF1
  lda (playfield2right),y
  sta PF2
  dex
  bne KernelLoop 

Use a #15 for an 16 scanline pattern, #31 for a 32 scanline pattern, etc.

 

 

Hope I didn't type anything wrong, won't be able to check back in until later today.

[hendersonn]

Thanks spice, I'll try it out when I get home tonight.