Batari DPC+ Sprite Masking?

[jrok]

Would it be possible in the batari DPC+ kernel to mask-wrap the multiplexed P1 sprite similar to Demo 4 of the Harmony DPC+ programming thread?

 

Demo 4 - Data Writer Demo

 

* Unlike the DPC cartridge, the DPC+ Display Data ends up in RAM and can be modified at run time.

* Joystick to move snowman - notice when he moves on/off screen he is masked to smoothly enter/exit the display. (compare with Demo 0)

* Fire to flip snowman - this shows the difference between DFxWRITE and DFxPUSH.

* Attached Image: DPC+ demo.bin_4.png

 

Thanks,

J

[ScumSoft]

The demo manually masks the sprite data based on sprite location, so I don't think bB can do this right now without loading prefab'd masked sprites.

 

I would also love to dynamically alter sprite data such as X = player sprite data index:

 

player0[X] = $FF

 

But I don't think anything like this is implemented right now.

Edited July 20, 2011 by ScumSoft

[jrok]

The demo manually masks the sprite data based on sprite location...

 

Hmmm. So do you mean that it manually loads and repositions shapes at positions 0 and 160 to simulate a smooth exit/entry? It just surprises me a little, since I assumed that its inclusion in the demo was demonstrating a dynamic mask of some sort. In other words, since we could do this manually sans the chip, why is it part of the demo? What's the advantage being shown?

Edited July 20, 2011 by jrok

[ScumSoft]

I'll post the meaningful parts, but essentially what's being done is the data-fetchers are manually altering the bank 6 graphic data.

 

;----------------------------------------
; Bank 4 - Data Writer Demo
;----------------------------------------
; - this demo writes sprite data into the 4K Display Data Bank
; - the sprite data is masked to cause the sprite to smoothly
;   go on/off screen.  Normally the Atari sprites would wrap
;   around and show on both sides of the display
; - use joystick to move sprite around screen
; - hit FIRE to use DFxPUSH instead of DFxWRITE to udate
;   the Display Data. This causes the sprite to be upside down.
; - use LEFT DIFFICULT to control how fast the sprite moves
;----------------------------------------

 

; Mask Values for smooth on-off scrolling,
; 153 = 1 pixel off the right edge
; 154 = 2
; 155 = 3
; 156 = 4
; 157 = 5
; 158 = 6
; 159 = 7
; 160 = 8 pixels off the right edge
;
; 255 = 1 pixel off the left edge
; 254 = 2
; 253 = 3
; 252 = 4
; 251 = 5
; 250 = 6
; 249 = 7
; 248 - change to 160

MaskDataR:
.byte zzXXXXXXX_
.byte zzXXXXXX__
.byte zzXXXXX___
.byte zzXXXX____
.byte zzXXX_____
.byte zzXX______
.byte zzX_______
.byte zz________

MaskDataL:
.byte zz_XXXXXXX
.byte zz__XXXXXX
.byte zz___XXXXX
.byte zz____XXXX
.byte zz_____XXX
.byte zz______XX
.byte zz_______X
.byte zz________

 

SetMask4:
lda #$FF
sta OnOffMask
lda FrostyX
cmp #153 ; 152
bcc CopyFrostyData4
cmp #161
bcc OffRightEdge4

OffLeftEdge4: ; Frosty's off the left edge so mask him
eor #$ff	; converts -1 thru -8 to +0 thru +7
tay
ldx FrostyDirection
bne FacingRight4
FacingLeft4:	
lda MaskDataL,y
sta OnOffMask
jmp CopyFrostyData4

OffRightEdge4: ; Frosty's off the right edge, so mask him
sec
sbc #153
tay
ldx FrostyDirection
bne FacingLeft4
FacingRight4:	
lda MaskDataR,y
sta OnOffMask	

 

; copy Frosty data, masking for smooth on/off if required and flipping
; image if firebutton was down
CopyFrostyData4:	
; read graphics from 0
lda #<FrostyGraphic0
sta DF0LOW
lda #>FrostyGraphic0
sta DF0HI
; read colors from 2
lda #<FrostyColors
sta DF2LOW
lda #>FrostyColors
sta DF2HI

lda FireDown
bne PrepPush4

PrepPush4:
; Fire button held down so we're prepping for PUSH
; push graphics via 1
lda #<(FrostyWrite + FrostyGraphic0Height)
sta DF1LOW
lda #>(FrostyWrite + FrostyGraphic0Height)
sta DF1HI

; push colors via 3
lda #<(ColorWrite + FrostyGraphic0Height)
sta DF3LOW
lda #>(ColorWrite + FrostyGraphic0Height)
sta DF3HI

Write4:	
ldx #FrostyGraphic0Height
WriteLoop4:
lda DF0DATA
and OnOffMask
pha
lda DF2DATA
ldy FireDown
bne PushData4
sta DF3WRITE	; fire button not down so using WRITE
pla
sta DF1WRITE
jmp EndOfLoop4
PushData4:
sta DF3PUSH	; fire button down so using PUSH
pla
sta DF1PUSH
EndOfLoop4:	
dex
bne WriteLoop4

 

 

So what is happening is the pointers are pointed to where frosty resides in Bank6 ram, and then updated as needed, then rewritten from a non-altered frosty when he needs to be shown again.

 

This can be done if we could access bank6 in ASM from bB, though I haven't tried doing such a thing yet.

Edited July 22, 2011 by ScumSoft

[+SpiceWare]

It just surprises me a little, since I assumed that its inclusion in the demo was demonstrating a dynamic mask of some sort. In other words, since we could do this manually sans the chip, why is it part of the demo? What's the advantage being shown?

You're posting this in the bB forms - are you overlooking that my DPC+ demo was not a demo for bB?

 

The name for that part of the demo is Data Writer Demo. As such, it's whole purpose is to show how to write data into the DD(Display Data) bank at run time. The masking was just a way to visually show that the data changed, along with being a potential reason as to why you'd want to manipulate the DD in the first place. I have some updated masking routines, run by the ARM chip, in Chun Li that handle all 3 sizes of the player.

 

 

So what is happening is the pointers are pointed to where frosty resides in Bank6 ram, and then updated as needed, then rewritten from a non-altered frosty when he needs to be shown again.

 

This can be done if we could access bank6 in ASM from bB, though I haven't tried doing such a thing yet.

Using the Copy Data to Fetcher feature, and the fact that "bank 6" for it is the original DD ROM, you could do this:

1) Copy the original, unmasked sprite image from DD ROM to DD RAM

2) point 2 DataFetchers at the sprite in DD RAM

3) Do a loop that reads using one of those DataFetchers, masks the value it read, and finally writes the masked value back out using the other DataFetcher.

Edited July 20, 2011 by SpiceWare

[jrok]

You're posting this in the bB forms - are you overlooking that my DPC+ demo was not a demo for bB?

 

Um... no. That's why I specified the "Batari DPC+" kernel in the topic title. I was just wondering if a similar runtime write could be done to mask sprites in that kernel.

[+SpiceWare]

Your text in #3 asked "why is it part of the demo?" - that's what I was responding to.

[jrok]

Your text in #3 asked "why is it part of the demo?" - that's what I was responding to.

 

I suppose I was wondering what the difference was between masking a sprite stored in RAM (as I've done before with sprites stored in Sara RAM) and the technique being shown in the demo. Although I gess I wasn't really 'wondering' that aloud, so fair enough.

 

It wasn't meant as an offense or anything. I was asking Scumsoft to elaborate on his reply a little, so I could understand the difference. Moreover, I posted this in the bB section, and explained I was trying to understand whether the technique could be appropriated for batari's kernel, and did everything except write "Please don't come over here and yell at me, Darrell!"

 

But, alas...

Edited July 20, 2011 by jrok

[+SpiceWare]

I'm not yelling - just was explaining the why

 

Batari has access to Chun Li's source, and he's free to add the masking routines to bB. It's possible he's waiting for Chun Li to be officially released as the routines could be revised before then, or possibly the routines won't work as they need to know the NUSIZ for the sprite(I don't know if the bB multi-sprite DPC+ kernel supports setting that per multiplexed sprite or not).

[+batari]

The sprite data for P1 is copied every frame, so it should be possible to optionally mask the data every frame as well. It looks like NUSIZ bits 6-7 are unused so maybe these could enable the feature - D6 could enable/disable masking, and D7 would mask on the left or right edge of the screen. I'm not sure how feasible it is to handle single, double, and quad-width sprites as the code could get a little convoluted.

[ScumSoft]

Using the Copy Data to Fetcher feature, and the fact that "bank 6" for it is the original DD ROM, you could do this:

1) Copy the original, unmasked sprite image from DD ROM to DD RAM

2) point 2 DataFetchers at the sprite in DD RAM

3) Do a loop that reads using one of those DataFetchers, masks the value it read, and finally writes the masked value back out using the other DataFetcher.

Good idea, this calls for some tests!

I'll see if I can get something similar working.

 

[edit]

I've tried a few things, but during compile it names the player0 objects as player(randomID)_0 so I lose my pointer references.

Otherwise this would update the player0 objects as needed:

 

 
Mask_P0
rem MASK PLAYER0
if player0x <= 17 then goto maskL
if player0x >= 153 then goto maskR
return

maskL
asm
lda #<(pointerplayer0)
sta DF0LOW
lda #>(pointerplayer0)
sta DF0HI
lda player0x
and #7
tay
ldx MaskDataL,y
.applymaskL
sax DF0WRITE
dec player0height
bne .applymaskL
end
return

maskR
asm
lda #<(pointerplayer0)
sta DF0LOW
lda #>(pointerplayer0)
sta DF0HI
lda player0x
and #7
tay
ldx MaskDataR,y
.applymaskR
sax DF0WRITE
dec player0height
bne .applymaskR
end
return

data MaskDataR
       %11111110
       %11111100
       %11111000
       %11110000
       %11100000
       %11000000
       %10000000
       %00000000
end

data MaskDataL 
       %01111111
       %00111111
       %00011111
       %00001111
       %00000111
       %00000011
       %00000001
       %00000000
end

Edited July 21, 2011 by ScumSoft

[+SpiceWare]

I'm not sure how feasible it is to handle single, double, and quad-width sprites as the code could get a little convoluted.

Chun Li's routines already handle all 3 sizes. Feel free to use them in bB. They work by using the X position to determine which side to mask, using a range of -7 thru 160 if I recall correctly.

[+batari]

I will take a look. I'm still not sure about double and quad-width sprites as it's impossible to mask them smoothly without using other objects to hide part of them.