12 replies to this topic

[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?

Quote

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 by ScumSoft, Tue Jul 19, 2011 7:22 PM.

[jrok]

ScumSoft, on Tue Jul 19, 2011 7:21 PM, said:

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 by jrok, Tue Jul 19, 2011 7:29 PM.

[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.

Spoiler

;----------------------------------------
; 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 by ScumSoft, Fri Jul 22, 2011 4:55 PM.

[SpiceWare]

jrok, on Tue Jul 19, 2011 7:29 PM, said:

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.

ScumSoft, on Tue Jul 19, 2011 7:46 PM, said:

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 by SpiceWare, Wed Jul 20, 2011 9:06 AM.

[jrok]

SpiceWare, on Wed Jul 20, 2011 9:06 AM, said:

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]

SpiceWare, on Wed Jul 20, 2011 10:10 AM, said:

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 by jrok, Wed Jul 20, 2011 10:18 AM.

[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]

SpiceWare, on Wed Jul 20, 2011 9:06 AM, said:

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 by ScumSoft, Thu Jul 21, 2011 4:33 PM.

[SpiceWare]

batari, on Wed Jul 20, 2011 3:25 PM, said:

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.