Page 10 of 12

Posted: Fri Aug 23, 2013 8:17 am
by Mike
rhurst wrote:Mike, thanks for clarifying, but could you dump how the VIC registers might look to accomplish that >512-byte screen space? I would not mind seeing that in action, and perhaps account for it in macro assembly?
There's nothing special about this. You specify the number of rows and columns to display in the registers $9002 and $9003 as usual. Of course you have to make sure, that there is also RAM in the extra space beyond - with the screen starting at 7680 for example, VIC 'hops' to address 32768 (character ROM base) after 512 bytes, this case for instance wouldn't work as intended. On a VIC-20 with +8K RAM (or more), the screen starts at 4096, here you just have to raise the BASIC start from $1201 to a higher address to make room for the extra characters.

You'll have to keep in mind though, that all this only applies to the display as done by VIC. The screen editor still will assume the standard 22x23 layout.

Posted: Sun Oct 06, 2013 1:15 pm
by beamrider
rhurst wrote:
beamrider wrote:One thing I did want to ask. I'm using all multi color and some of the sprite colors are rendered behind the play field characters. Is there anything that can be done about this? I'm using SSSPRINT to print the background btw.
No, there is no masking phase for multicolor sprites to maintain the integrity of its color.
Hi Robert

Trust you had a good time in Venice?

Just wondering what would be the amount of work involved (and possible performance hits) in improving multi-color support to maintain color integrity?

Posted: Sun Oct 06, 2013 2:20 pm
by Mike
Let me take a guess on it:

Currently Robert's Triple-S System supports OR-ing into the playfield, or XOR-ing. OR-ing does not need to care about sprite priorities, and XOR-ing doesn't even bother that colours are wildly changed over non-blank background. With multi-colour and just OR-ing, colour 3 naturally takes precedence over either colour 1 or 2, while colour 1 and 2 are of lower precedence - and 1 and 2 mix to 3 when overlaid. If you want greater control over what happens, you'd have to employ masking. Parts of the background need to be cleared beforehand if the sprite is supposed to be in foreground, and parts of the sprites need to be cleared when is it supposed to go behind background patterns.

On a bit level, you'd have pattern, mask, and background bits and combine them as follows:

background_new = (background_old AND NOT mask) XOR pattern

mask=0 and pattern=0 keep the background,

mask=1 and pattern=0 force the screen pixel to 0,

mask=1 and pattern=1 force the screen pixel to 1.

The combination mask=0 and pattern=1 reproduces the XOR behaviour.

This also works with multi-colour data. You'll need to shift both mask and pattern data 'in real-time' and combine the shifted data into the background. Finally, as hinted above, you'll normally get different different results depending on order of the processed sprites. Attribute clash will still occur.

Re: Software sprites?

Posted: Mon Apr 14, 2014 8:45 am
by darkatx
From what I'm working on this was the first thing to pop in my head. I just came to the same conclusion...need to AND then XOR to get what I want. Thank god for this thread for me to reference that I'm on the right track here. :)

Re: Software sprites?

Posted: Sat Oct 18, 2014 8:46 am
by beamrider
Hi Robert,

To avoid loathsome color clash Pooyan just uses a single foreground colour (white).

It just popped in to my head that perhaps there might be some performance improvements to be had in the SSS by assembling a version with a conditional directive to omit update of colour RAM when being used for monochrome or 4 color MC programs?

Just a thought....

Re: Software sprites?

Posted: Sun Oct 19, 2014 6:06 am
by rhurst
As you know, there are some conditionals in play already. And there are opportunities, like the one you point out, to add a few more that could further tailor needs; honestly, I felt that any more tweaks on the existing feature set might introduce complexity (aka choices) heavier than the resulting benefit. And I wanted to keep this API friendly to the programmer first.

Thus, I put in a GHOST (XOR) mode to ignore SPRITECOL, so there's no enforced foreground color clash by a sprite with that feature on. Because it is a feature bit setting per sprite, you can minimize color clash without losing opportunity for more onscreen colors -- something of great importance especially back then as noted by game reviewers and enthusiasts alike.

In Berzerk there is only color clash from the hero, because every sprite except its hero is in ghost mode -- and that actually has the same effect as the arcade game which was originally written for B&W. Conversely, Break-Out! and Sprite Invaders put only their "missile" sprites in ghost mode, which means their missile image inherits the foreground color already in play -- in those games when the cell is empty, WHITE. If the cell is occupied by another character/color, only the missile takes on any color clash from that cell and its image bits are inverted (XOR) should any part of it overlap with that cell's image. That helps maintain the missile's image consistency, whereas in most cases when any such overlap occurs, you want a collision-detection event to fire off after the frame is rendered.

If VIC-SSS had a global conditional in place, i.e. SSSMONO=1, it could suppress the SPRITECOL register (times MAXSPRITE) need and eliminate the Accumulator parameter passing to SSSANIM (if that is even used by the game at all). And the "dirty line" rendering process would have a couple of assembly lines of code taken out to write to color ram, but there wouldn't be any big savings in PLAYCOLOR space, because their upper bits are used in conjunction with the lower bits for color.

This tells me the overhead benefit of a global monochrome setting -- with this API -- is small; so instead, I chose to make it a sprite-by-sprite feature. I understand that if this API were rewritten for a 4-color only playing mode, it would perform faster... so it's up to the programmer to gauge the "frenetic game play" value by achieving those extra few frames-per-second.

I did envision of possibly putting in an Atari-like flicker effect for when a sprite overlaps with another sprite, to render those conflicting characters on odd/even frames -- sort of seen in Quikman's demo mode where it renders two even-numbered sprites, then two odd-numbered sprites, and the effect when an even and odd sprite come in contact makes for an interesting coloring effect (i.e., red and yellow monster become orange). If that special mode could be added in without too much overhead, I can see that allowing for some interesting games for VIC, like Popeye. :P

Re: Software sprites?

Posted: Sun Oct 19, 2014 1:04 pm
by beamrider
Ok, thanks for the explanation.

I tried the XOR mode before and it didn't look too good with a busy background.

Image

Re: Software sprites?

Posted: Sun Oct 19, 2014 2:06 pm
by rhurst
No, it doesn't work well there... it think you've done a fine job with VIC's limitations. I hinted that a different rendering scheme altogether could provide for some (minor) graphic enhancements with performance gain, i.e., use of an 8x16 character display, which can also avoid the overhead of ZP indirect-Y addressing.

Re: Software sprites?

Posted: Tue May 19, 2015 3:32 am
by beamrider
Using the subroutine below to replace the simple OR operation in SSS, I have managed to greatly improve the multicolor handling WITHOUT having speed/memory/complexity overhead of maintaing separate masks. I've tested a version of Pooyan and all the graphical glitches in the existing version have gone as illustrated by the attached images. The new routine (MCMerging) doesn't allow the red branches of the tree to bleed through into the balloon. This is especially beneficial on the second level where the balloons now float in front of the rock instead of looking like they went behind it.

The only restriction is that we still can't define areas of the background color to force an override of whatever is underneath, so in the above example, we couldn't force a blue outline around our ballons using the background colour value in the spritedef, but I don't see this as a big issue and can be worked around with graphical design.

Will optimise and maybe release an updated version of Pooyan soon...

Code: Select all

@mcMerge:

		STY YCOPY
		LDY sssXFER		; from ...
		LDA (VECTORBG),Y
		STA R0 ; background pixels
		LDY sssLINENUM	; to ...
		LDA (VECTOR1),Y	;
		STA R1
		LDA #0 ; clear  -
		STA R3 ;      output value
		LDA #%11000000
		STA R4 ; mask
		LDY #4 ; loop index

@mergeLoop:
		LDA R1 ; load sprite pixels
		AND R4 ; consider two bits
		BEQ @stbg1 ; non -zero ? if so output background
		ORA R3; merge to output byte
		STA R3;   ..... 
		jmp @nextPair
@stbg1:
		LDA R0 ; load background pixels
		AND R4 ; consider two bits
		ORA R3; merge to output byte
		STA R3;   ..... 
@nextPair:
		LSR R4
	    LSR R4
		DEY
		BNE @mergeLoop
		
@saveResult:
		LDA R3
		LDY sssLINENUM	; to ...
		STA (VECTORFG),Y
		LDY YCOPY
		RTS

Re: Software sprites?

Posted: Tue May 19, 2015 12:21 pm
by beamrider
I've uploaded a new version of Pooyan with this and other minor changes.

http://sleepingelephant.com/ipw-web/bul ... 642#p73642

Re: Software sprites?

Posted: Mon May 25, 2015 4:05 am
by beamrider
As well as improved multicolor handling, I have now modified this library to support tall 3 character height sprites.

Re: Software sprites?

Posted: Mon May 25, 2015 1:37 pm
by darkatx
:::Thumbs way up::: Good stuff!

Re: Software sprites?

Posted: Tue Aug 08, 2017 5:45 am
by DrVeryEvil
Has anyone put the Software Sprite Stack in CBMProgStudio? I would hate to convert it if someone has already done it.

Re: Software sprites?

Posted: Tue Aug 08, 2017 5:56 am
by beamrider
Don't think anyone other than me and Robert of course, has made any games using the library...

There are prebuilt binaries, but compiling the library itself requires CA65.

Re: Software sprites?

Posted: Wed Aug 09, 2017 6:42 am
by hawk
I was wondering whether anyone had modified it to interface to C via cc65 or do you have to code in ca65 or BASIC?