Software sprites?

Basic and Machine Language

Moderator: Moderators

User avatar
beamrider
Vic 20 Scientist
Posts: 1444
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Software sprites?

Post by beamrider »

No reason, you can't call it from 'c' or BASIC.

Would just need to import the data structures, sprite register locations and calls in the appropriate form. No-one has done this to my knowledge though.

I thought about using it to write an *enhanced version of 'blue-meanies' in 'c' as a example/bootstrap project, but never got around to it :(

* The enhancements I had in mind were:smooth movement, better graphics and not pausing when you fired the lasers.
User avatar
beamrider
Vic 20 Scientist
Posts: 1444
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Software sprites?

Post by beamrider »

I've created a C bridge or wrapper around the SSS by Robert Hurst. It can be downloaded from the following location:

https://drive.google.com/open?id=0BypVx ... DRwVE9BUWM

The link is a .zip file that unpacks to a hello world project....

Image

Everything is setup up to get you up and running quickly - it includes a copy of CC65 and VICSSS (but not VICE).

Inside the folder is a COMPILE.BAT that generates the above .PRG file. You will just need to change the path to the location of VICE on your machine
at the bottom of this file.

e.g.

Code: Select all

"c:\MyViceFolder\xvic.exe" -moncommands %~dp0\obj\%TITLE%.sym  -memory 16k  bin\%TITLE%.prg 
The guts of the program is in the file main.c and should be self explanatory with the //COMENTS and reading the included SSS pdf docs and a smattering of C knowledge.

Code: Select all

void main (void)
{
	BYTE bigDudeSprite = 0;
	BYTE idx = 0;

	// Set the screen colours
	textcolor (COLOR_RED);
	bordercolor (COLOR_BLUE);
	bgcolor (COLOR_BLACK);

	// Init Vic SSS
	SSSINIT();

	// Start IRQ routine for optional frame rate lock	
	IrqSetup();
	
	// Create the sprite
	bigDudeSprite = SSSCREATE(16,SPRITEDEF_HEIGHT_16
								| SPRITEDEF_WIDTH_16
								| SPRITEDEF_FLOATY_FLOAT
								| SPRITEDEF_FLOATX_FLOAT
								| SPRITEDEF_ENABLED);

	// Clear screen
	SSSCLEAR(SSSNULL);
	
	// Hello text..
	SSSPRINTTEXT(4,10,"HELLO SSS-C \0");
	SSSPRINTTEXT(2,12,"(SSS BY R.HURST)\0");

	// Select sprite
	SSSUSE(bigDudeSprite);
	
	// Set sprite bitmap
	SSSANIM(COLOR_RED, BIGDUDEBITS);

	// LOOP forever..
	while(TRUE)
	{
		for (idx = 16; idx < 192; idx++)
		{
			// Move sprite to x,y cords
			SSSUSE(bigDudeSprite);
			SSSMOVEXY(idx, idx);
			SSSFLIP(1);
		}
	}
}

A brief explanation some of the other files that are not documented in SSS:

data.s - you can put sprite data etc in here
RasterSync.s - [Assembler SSS] IRQ handler for flicker free sprites
vis-sss-bridge.s -C compatible assembly wrappers for SSS
vis-sss-bridge.h - C header file for SSS function definitions and SYMBOLS
vic20-16k.cfg - linker configuration file. Describes the memory layout and where to put each code file.

You may find an IDE type environment useful. I use Notepad ++ [with NppExec / Explorer plugins] so I can edit files and save/compile/run with a simple Ctrl+F6. You may wish to use Visual Studio code or similar...

Image

You may find my Screen Designer will be useful for generating sprite data using the bitmap function...

There are plenty of tutorials for C on the web.

This zip file was developed under windows, but should be easy to change to other platforms. If anyone would like to produce and share a unix/mac variant that would be great...


Hoping this will encourage some people to progress from BASIC programming - those that don't want the tedium of writing assembly or writing a sprite library.

[I haven't tested all of the SSS API functions from C, but they should work. Let me know if you find a problem]

If there is enough interest I might extend this Hello World into a small game with some background music etc..

Any questions shout up..
Last edited by beamrider on Tue Aug 15, 2017 6:21 am, edited 1 time in total.
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 »

That's killer ... modern tools and APIs for VIC? Incredible.
Any technology distinguishable from magic is insufficiently advanced.
https://robert.hurst-ri.us/rob/retrocomputing
User avatar
hawk
Vic 20 Afficionado
Posts: 342
Joined: Mon Jun 20, 2005 7:32 pm

Re: Software sprites?

Post by hawk »

This is great. Thanks. I'm looking forward to giving it a go. It might make it possible for me to continue a project a started ages ago but stalled on as I couldn't work out how to implement sprites that didn't tear and flicker.
User avatar
Mike
Herr VC
Posts: 4808
Joined: Wed Dec 01, 2004 1:57 pm
Location: Munich, Germany
Occupation: electrical engineer

Re: Software sprites?

Post by Mike »

beamrider wrote:'c' [...] 'c' [...] 'c' [...] 'c'
Just curious: is there a specific reason you insist on this spelling of C (other than, possibly, that cc65 doesn't implement the full language)?
User avatar
beamrider
Vic 20 Scientist
Posts: 1444
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Software sprites?

Post by beamrider »

nope, you got me there.

I must have seen it written like that somewhere and it stuck.

Post corrected.

[Also noticed that there was a missing \0 after (SSS BY R.HURST) - must have worked by luck.]

Will update the download zip to match.
unebonnevie
Vic 20 Drifter
Posts: 35
Joined: Sat Oct 11, 2014 3:25 pm

Re:

Post by unebonnevie »

rhurst wrote:Ok, first ALPHA release DEMO of these "software sprites" is available. :D
Download it here:

DEMO cartridge @ $A000
... and its assembler source code using cc65 project.

It supports NTSC (default) with a startup override to switch to PAL timing. Press RUN/STOP to pause frame.

Still 8x8 only, and just the "fixed" and "vertical" modes supported -- "horizontal" and "float" modes to follow. Then the double-width, double-height, double-both will follow that.

I am very pleased with its progress. The API is coalescing into something that might be useful for rapid implementation within video games, or even just to add some animated effects. 8)

Feedback is always welcomed. :P
Mr. Hurst, I am a big fan of your work on the VIC. Finally, I found this thread. The above links are not active anymore. The new link is https://robert.hurst-ri.us/files/vic-so ... ite-stack/
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 »

You can fetch/follow these projects on GitHub.
Any technology distinguishable from magic is insufficiently advanced.
https://robert.hurst-ri.us/rob/retrocomputing
User avatar
AndyH
Vic 20 Afficionado
Posts: 352
Joined: Thu Jun 17, 2004 5:51 am
Website: https://www.hewco.uk
Location: UK
Occupation: Developer

Re: Software sprites?

Post by AndyH »

This library is amazing, many thanks for putting it together all that time ago.

I'm working things out along with the documentation and I have a version working nicely with CBM PRG Studio. I've created several sprites for use as missiles and intend them to be 1x1 pixels and using the SPRITEDEF recommended for them. This is how I've got it set up:

LDA #%11000000 ; 1x1 missile
LDY #$01 ; 1 pixels high
JSR SSSCREATE
LDA #YELLOW ;
LDX #<SPRLASER ; points to
LDY #>SPRLASER ; char with one dot at top left
JSR SSSANIM

Can I check I have this right, I have pointed reg x and y to a character that has a single pixel in the top left and this seems to behave correctly. Have tried other patterns while experimenting of course and this works as I'd expect. Is that correct for this SPRITEDEF?

I will need to figure out collision detection next, as I want to detect collisions with other sprites and background graphics. I've un-commented SPRITEDEF6 - $40 and I've set bit 6 on the missiles and the enemy sprites which I assume is the correct first step? Any advice of common gotcha's I need to watch out for when working with collisions?

Anyway, big thanks once again Robert for making this library. :) Here's what I've got so far (minus the missiles):
https://twitter.com/Hewco64/status/1053943735107678208
--
AndyH
HEWCO | Vic 20 blog
User avatar
beamrider
Vic 20 Scientist
Posts: 1444
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Software sprites?

Post by beamrider »

Looking at it, I can't see how you obtained the smooth movement as you haven't enabled FLOATX or FLOATY. I use definitions instead of just putting in the binary values like this:

Code: Select all

; SPRITEDEF constants
SPRITBIT_ENABLE                 = <$80
SPRITBIT_COLLISION              = <$40
SPRITBIT_GHOST                  = <$20
SPRITBIT_REPEAT                 = <$10
SPRITBIT_FLOATX                 = <$08
SPRITBIT_FLOATY                 = <$04
SPRITBIT_WIDTH                  = <$02
SPRITBIT_HEIGHT                 = <$01

; Sprite defines
SPRITEDEF_SMALL_FLOAT_XY  =  SPRITBIT_FLOATX | SPRITBIT_FLOATY
so you could define yours as SPRITEDEF_SMALL_FLOAT_XY above. The rest of the code looks okay to me.

I didn't use the collision detection personally and just tracked the positions of things myself.
User avatar
AndyH
Vic 20 Afficionado
Posts: 352
Joined: Thu Jun 17, 2004 5:51 am
Website: https://www.hewco.uk
Location: UK
Occupation: Developer

Re: Software sprites?

Post by AndyH »

beamrider wrote:Looking at it, I can't see how you obtained the smooth movement as you haven't enabled FLOATX or FLOATY. I use definitions instead of just putting in the binary values like this:

Code: Select all

; SPRITEDEF constants
SPRITBIT_ENABLE                 = <$80
SPRITBIT_COLLISION              = <$40
SPRITBIT_GHOST                  = <$20
SPRITBIT_REPEAT                 = <$10
SPRITBIT_FLOATX                 = <$08
SPRITBIT_FLOATY                 = <$04
SPRITBIT_WIDTH                  = <$02
SPRITBIT_HEIGHT                 = <$01

; Sprite defines
SPRITEDEF_SMALL_FLOAT_XY  =  SPRITBIT_FLOATX | SPRITBIT_FLOATY
so you could define yours as SPRITEDEF_SMALL_FLOAT_XY above. The rest of the code looks okay to me.

I didn't use the collision detection personally and just tracked the positions of things myself.
That looks really helpful. In the case of the Float_XY I believe you only need that if you are creating a sprite that will use 2 columns and/or rows to render it. The documentation states that the SPRITEDEF I have used creates a 1x1 character and is useful for missiles. This is what confused me initially as the docs say no float but after testing with different patterns, if I used anything but %10000000 as the character pattern, I would see it being truncated as it moved from position 8 to 15 before being fully visible at position 16. So was wanting to check I had this correct.

In that GIF animation I included, I am using an 8 x 8 pixel sprite and a spritedef as you describe. I've not captured the version where I am now shooting my missiles but will do that later :)

Thanks again for the tip on the Sprite def constants, that will make it more understandable for sure!

I think perhaps you are right about the collision detection - I don't really need pixel precise collisions in my game and detecting a point within a bounding box is pretty straight forward for my missiles.

Is there a good way (optimised for speed) to detect an overlap of two rectangles in 6502?

Edit: Here's the missiles in action - Twitter video
--
AndyH
HEWCO | Vic 20 blog
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 »

Yup, a single character is used for a 1-pixel high missile sprite, and it still has the net effect of the full pixel coordinate system with any other larger sprite. If that pixel is only moving left-right, you can make it wider, say 2-pixels wide and move it 2-pixels at a time, or 4-pixels wide and move it either 2 or 4-pixels. You can see collision-detection in action with code snippet:

Code: Select all

xvic -memory all -autostart ca65-primer/demos/demo.prg
But assume you're looking to detect if the 1x1 missile hit another sprite's 8x8 matrix?
if abs((objectX) - (missileX)) > 8 nope, move on
if abs((objectY) - (missileY)) > 8 nope, move on
hit!

With collision-detection enabled, it's easier like in Sprite Invaders and in the demo:

Code: Select all

	LDA SPRITEZ
	AND #%1000		; collision?
	BNE @hit
...else keep moving the missile until it reaches firing limit range, off-screen or some other decrementing register.
If the hit-bit was detected, then check which play field character cell it "touched":

Code: Select all

@hit:
	LDA SPRITEBACK	; which character code did it hit?
	CMP #$7A			; matrix codes below this # are any of the enemy ships (score) or their missiles (cancel)
	BCC @invader
	JMP @mothership	; else, it's the bonus mother ship
Omega Fury uses a more complicated bounding box collision detection (not pixel collision), because the objects it can hit can be either 8x8 or 16x16:

Code: Select all

@cont:
	LDX #$00
	STX LOOPX
@loop:
	LDA NME,X
	BNE @ck
	JMP @next
@ck:
	LDA #$01		; adjustment for EOR operation
	STA ACOPY
	LDA #$08
	CMP SPRITEH+8,X
	BEQ @nme
	LDA #$F9		; adjust for carrier collision (-7)
	STA ACOPY
@nme:
	LDA SPRITEX+8,X
	SEC
	SBC SPRITEX+12
	BCS @nov1
	EOR #$FF
	CLC
	ADC ACOPY
@nov1:
	CMP #$08
	BCS @next
	LDA SPRITEY+8,X
	SEC
	SBC SPRITEY+12
	BCS @nov2
	EOR #$FF
	CLC
	ADC ACOPY
@nov2:
	CMP #$08
	BCS @next
	LDX SPRITEX+12
	LDY SPRITEY+12
	JSR NEWHITMARK	; player hit
	LDA #$E0
	STA HIT
	LDX LOOPX
	DEC NMEHP,X		; scratch the enemy's hull paint
	BNE @paint
	; killed enemy by ramming it -- no score
	LDA #$00
	STA NME,X
	LDA SPRITEDEF+8,X
	AND #$7F		; disable sprite
	STA SPRITEDEF+8,X
	DEC OBJECTIVE
@paint:
	LDA SPRITEH+8,X	; bigger the ship, the bigger the hit
	CLC
	ADC SPEED		; and the faster you were going
	LSR				; half
	JSR FURYHIT
	LDA FURYHP
	BEQ @xnme
	LDA #$08
	STA SPEED
	LDA #$38		; 56-frames of immunity
	STA COLLISION
	LDA INERTIA
	EOR #$08		; reverse direction
	STA INERTIA
	LDA #100
	JSR RND
	AND #$0F
	JSR FURYNAVI
	JMP @xnme		; go!
@next:
	INC LOOPX
	LDX LOOPX
	CPX #$04
	BEQ @xnme
	JMP @loop
Any technology distinguishable from magic is insufficiently advanced.
https://robert.hurst-ri.us/rob/retrocomputing
User avatar
AndyH
Vic 20 Afficionado
Posts: 352
Joined: Thu Jun 17, 2004 5:51 am
Website: https://www.hewco.uk
Location: UK
Occupation: Developer

Re: Software sprites?

Post by AndyH »

Hi Robert, many thanks for replying with all of that information. I'm really loving your sprite library (did I say that already?), it is allowing me to relive my childhood ambitions of making something as good as Omega Race on the humble Vic.
rhurst wrote:Yup, a single character is used for a 1-pixel high missile sprite, and it still has the net effect of the full pixel coordinate system with any other larger sprite. If that pixel is only moving left-right, you can make it wider, say 2-pixels wide and move it 2-pixels at a time, or 4-pixels wide and move it either 2 or 4-pixels. You can see collision-detection in action with code snippet:

Code: Select all

xvic -memory all -autostart ca65-primer/demos/demo.prg
I've done exactly that with a 2 pixel wide missile. Works a treat.
rhurst wrote: But assume you're looking to detect if the 1x1 missile hit another sprite's 8x8 matrix?
if abs((objectX) - (missileX)) > 8 nope, move on
if abs((objectY) - (missileY)) > 8 nope, move on
hit!
I've ended up with something similar, although I've just checked the upper and lower bounds.

Code: Select all

                lda gamePlayerX
                clc
                sbc enemyX
                cmp #PLAYER_CLEFT
                bcs @collisionOnX
                cmp #PLAYER_CRIGHT
                bcs @noCollision
@collisionOnX   lda gamePlayerY
                sbc enemyY
                cmp #PLAYER_CTOP
                bcs @collision
                cmp #PLAYER_CBOT
                bcc @collision
                
@noCollision    lda #8                 
                sta VICCOLOR
                rts                
@collision      lda #9                
                sta VICCOLOR
                rts
rhurst wrote: With collision-detection enabled, it's easier like in Sprite Invaders and in the demo:

Code: Select all

	LDA SPRITEZ
	AND #%1000		; collision?
	BNE @hit
...else keep moving the missile until it reaches firing limit range, off-screen or some other decrementing register.
If the hit-bit was detected, then check which play field character cell it "touched":

Code: Select all

@hit:
	LDA SPRITEBACK	; which character code did it hit?
	CMP #$7A			; matrix codes below this # are any of the enemy ships (score) or their missiles (cancel)
	BCC @invader
	JMP @mothership	; else, it's the bonus mother ship
I haven't spent any more time on the collisions part of the library just yet, how much of an overhead do you find it adds to the speed? For my first game I can safely use the bounding box collisions using the code above and a slightly smaller hitbox for the player.
rhurst wrote: Omega Fury uses a more complicated bounding box collision detection (not pixel collision), because the objects it can hit can be either 8x8 or 16x16:

Code: Select all

@cont:
	LDX #$00
	STX LOOPX
@loop:
	LDA NME,X
	BNE @ck
	JMP @next
@ck:
	LDA #$01		; adjustment for EOR operation
	STA ACOPY
	LDA #$08
	CMP SPRITEH+8,X
	BEQ @nme
	LDA #$F9		; adjust for carrier collision (-7)
	STA ACOPY
@nme:
	LDA SPRITEX+8,X
	SEC
	SBC SPRITEX+12
	BCS @nov1
	EOR #$FF
	CLC
	ADC ACOPY
@nov1:
	CMP #$08
	BCS @next
	LDA SPRITEY+8,X
	SEC
	SBC SPRITEY+12
	BCS @nov2
	EOR #$FF
	CLC
	ADC ACOPY
@nov2:
	CMP #$08
	BCS @next
	LDX SPRITEX+12
	LDY SPRITEY+12
	JSR NEWHITMARK	; player hit
	LDA #$E0
	STA HIT
	LDX LOOPX
	DEC NMEHP,X		; scratch the enemy's hull paint
	BNE @paint
	; killed enemy by ramming it -- no score
	LDA #$00
	STA NME,X
	LDA SPRITEDEF+8,X
	AND #$7F		; disable sprite
	STA SPRITEDEF+8,X
	DEC OBJECTIVE
@paint:
	LDA SPRITEH+8,X	; bigger the ship, the bigger the hit
	CLC
	ADC SPEED		; and the faster you were going
	LSR				; half
	JSR FURYHIT
	LDA FURYHP
	BEQ @xnme
	LDA #$08
	STA SPEED
	LDA #$38		; 56-frames of immunity
	STA COLLISION
	LDA INERTIA
	EOR #$08		; reverse direction
	STA INERTIA
	LDA #100
	JSR RND
	AND #$0F
	JSR FURYNAVI
	JMP @xnme		; go!
@next:
	INC LOOPX
	LDX LOOPX
	CPX #$04
	BEQ @xnme
	JMP @loop
Ah, that is really helpful - highlighting some general things I have overlooked (I'm still learning the library and 6502 at the same time :)). One question on this snippet in your example:

Code: Select all

   LDA SPRITEX+8,X
   SEC
   SBC SPRITEX+12
   BCS @nov1
   EOR #$FF
   CLC
   ADC ACOPY
@nov1:
   CMP #$08
   BCS @next
ACOPY is being set to $01 or $F9 for a carrier and is added on to the result before comparing - what is that for?
--
AndyH
HEWCO | Vic 20 blog
BigJinge
Vic 20 Newbie
Posts: 2
Joined: Sun Oct 09, 2022 8:42 pm

Re: Software sprites?

Post by BigJinge »

Forgive me, I'm a noob to assembler...

This is regarding the VIC-SSS API and a question of use within a different assembler.

Whilst I've coded in a number of languages over the years, I wanted to write a game in assembler for the VIC.
Looking through, I realised that I'd need to write routines for software sprite mapping and double buffering. Then I came across VIC-SSS by Robert Hurst / theflyingape which does all that. Rather than reinvent the wheel, I'd go with that.

I want to use CBM prg Studio to write assembler. It's a nice IDE with all built in. The vic-sss documentation says that its code is designed to be used with cc65, I don't want to write in C mind.

Is it possible to take the VIC-SSS-MMX.h and VIC-SSS-MMX.s files, add them into CBM prg Studio as .asm files, changing any assembler directives then build with my code?

https://github.com/theflyingape/vic-sss

Or am I missing something?

Any help would be gratefully received.

TIA

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

Re: Software sprites?

Post by Mike »

Welcome!
BigJinge wrote:I want to use CBM prg Studio to write assembler. It's a nice IDE with all built in. The vic-sss documentation says that its code is designed to be used with cc65, I don't want to write in C mind.
Note the source code of SSS primarily is written for ca65, the symbolic assembler that comes with the cc65 package.

beamrider wrote a wrapper to be able to call functions in the SSS library from C, but use of C isn't mandatory. Originally, the client source code was supposed to be written in assembly language, in the source format of ca65.
Is it possible to take the VIC-SSS-MMX.h and VIC-SSS-MMX.s files, add them into CBM prg Studio as .asm files, changing any assembler directives then build with my code?
That is possible for sure, and adapting source is normal business if someone wants to use source code written for one assembler for another assembler.

Greetings,

Michael
Post Reply