Software sprites?

Basic and Machine Language

Moderator: Moderators

User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post 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.
User avatar
beamrider
Vic 20 Scientist
Posts: 1447
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Post 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?
User avatar
Mike
Herr VC
Posts: 4816
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Post 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.
User avatar
darkatx
Vic 20 Afficionado
Posts: 470
Joined: Wed Feb 04, 2009 2:17 pm
Location: Canada

Re: Software sprites?

Post 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. :)
Learning all the time... :)
User avatar
beamrider
Vic 20 Scientist
Posts: 1447
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Software sprites?

Post 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....
rhurst
Omega Star Commander
Posts: 1369
Joined: Thu Jan 31, 2008 2:12 pm
Website: https://robert.hurst-ri.us
Location: Providence, RI
Occupation: Tech & Innovation

Re: Software sprites?

Post 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
Any technology distinguishable from magic is insufficiently advanced.
https://robert.hurst-ri.us/rob/retrocomputing
User avatar
beamrider
Vic 20 Scientist
Posts: 1447
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Software sprites?

Post 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
rhurst
Omega Star Commander
Posts: 1369
Joined: Thu Jan 31, 2008 2:12 pm
Website: https://robert.hurst-ri.us
Location: Providence, RI
Occupation: Tech & Innovation

Re: Software sprites?

Post 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.
Any technology distinguishable from magic is insufficiently advanced.
https://robert.hurst-ri.us/rob/retrocomputing
User avatar
beamrider
Vic 20 Scientist
Posts: 1447
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Software sprites?

Post 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
Attachments
MCMergeIng2.PNG
MCMergeIng2.PNG (150.16 KiB) Viewed 9762 times
MCMergeIng.PNG
MCMergeIng.PNG (52.98 KiB) Viewed 9763 times
ORing.PNG
ORing.PNG (8.04 KiB) Viewed 9763 times
User avatar
beamrider
Vic 20 Scientist
Posts: 1447
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Software sprites?

Post by beamrider »

I've uploaded a new version of Pooyan with this and other minor changes.

http://sleepingelephant.com/ipw-web/bul ... 642#p73642
User avatar
beamrider
Vic 20 Scientist
Posts: 1447
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Software sprites?

Post by beamrider »

As well as improved multicolor handling, I have now modified this library to support tall 3 character height sprites.
User avatar
darkatx
Vic 20 Afficionado
Posts: 470
Joined: Wed Feb 04, 2009 2:17 pm
Location: Canada

Re: Software sprites?

Post by darkatx »

:::Thumbs way up::: Good stuff!
Learning all the time... :)
DrVeryEvil
Vic 20 Amateur
Posts: 69
Joined: Thu Jul 23, 2015 5:11 pm
Location: Lansing, MI, USA
Occupation: Data Analyst

Re: Software sprites?

Post by DrVeryEvil »

Has anyone put the Software Sprite Stack in CBMProgStudio? I would hate to convert it if someone has already done it.
User avatar
beamrider
Vic 20 Scientist
Posts: 1447
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Software sprites?

Post 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.
User avatar
hawk
Vic 20 Afficionado
Posts: 342
Joined: Mon Jun 20, 2005 7:32 pm

Re: Software sprites?

Post 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?
Post Reply