Software sprites?

[BigJinge]

Thanks Michael for the welcome and for clarifying the symbolic assembler parts.

Reading through this whole thread, it looks like AndyH (HEWCO) has already gotten VIC-SSS to work with CBM prg Studio. I'll get in touch to see if he has any instructions / pointers for doing the same.

Best wishes

BigJinge

[beamrider]

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.

btw, I made a start writing a new version of Blue-Meanies as a demo using this wrapper but I always got some detritus on the bottom row of the screen that I could never get rid of.

It appeared to be affected randomly by seemingly unrelated changes to the code.

http://www.fox-ts.co.uk/shared/BlueMeaniesRevenge.zip

[rhurst]

It amazes me still this thread is followed. Good luck with your assembler pursuits -- it can be a kind of grind, but in the end, it's fun.

@beamrider, back in that day, I had started a new sprite stack using a new approach that would offer some interesting new features. The motivation behind that was the Ultimem announcement, because I was intrigued with its IO2 and IO3 memory option to exploit -- allowing for an extensive cache if it was 'detected' to bolster performance, but also allow it to run without having to rely upon it.

If I can ever get back to it, I'll definitely give you a heads-up. Oh, and start a new thread!

[beamrider]

@Robert

Yeah, would be interested in seeing that..

I also started creating a sprite library that works on large and/or scrolling screens but haven't been motivated to finish it. I have a few other started Vic-20 projects as well - maybe when I retire I'll find time to complete them.

[thegg]

If you need some extra motivation, I (and I am sure quite a few others) would be very interested in such a library.

[davervw1]

I have a software sprite solution as part of my HIRES-20 basic extension I developed last year. I call them "shapes".
https://github.com/davervw/hires-vic-20

There is only low level support for drawing and/or erasing, not specific support for moving them. A sample in BASIC bounces a spacewar/asteroids/omegarace style ship around the screen.


Another example bounces 9 identical 32x40 shapes including some whitespace that helps with erasing them by simply redrawing at a new close location. Most of the time is looking for collisions between the shapes (9x8 = 72 checks). Dropping to 5 shapes would decrease collision processing by more than a third. Programmed in 6502 assembly, probably need a better algorithm to optimize the checks to only the adjacent shapes.

https://github.com/davervw/angular-vic20

[MrSterlingBS]

Dear all,

during the easter brake i had a little time to play around with the SoftwareSpriteStack API from Robert.
But, If i move a sprite in horizontal direction i get some glitches on the sprite.
Is there another call i have to do it before i draw the sprite?

Left, the sprite without movement.
On the right side after a horizontal movement.

Best regards
Sven

Code: Select all

DEMO7           LDA #$1B
                STA $900F
                LDA #%10001111          ; 16x16 sprite floats X-Y and uses Ghosting (bit 5)
                LDY #$10                ; height
                JSR SSSCREATE
               
                LDA #$0a                ; red
                LDX #<cBIGRED1          ;create a new sprite coloured red
                LDY #>CBIGRED1
                ;LDX #<BITMAP    ;create a new sprite coloured red
                ;LDY #>BITMAP
                JSR SSSANIM
                LDX #0          ;X position for sprite
                LDA SSSCLIPY    ;use Y clip value to form Y position for sprite
                LSR
                TAY
                JSR SSSMOVEXY  
               
                LDX #30
                STX SPRITEX
                STX SPRITEY

loopd8          LDX #0
                JSR SSSUSE
                
                lda #%01111111
                sta $9122       ;Set Data Direction of port B to READ (0=read)
        
                lda $9120       ;Port B (R------- Switch)
                sta R0;z_as
        
                lda $911F       ;Port A (--FLDU-- Switches)
                rol R0;z_as
                rol 
                sta R1;z_h         ;-FLDU--R
        
                lda R1;z_h
                cmp #%11111111
                beq JoyNotRight;loopd8             ;See if no keys are pressed
     
                sta R1;z_h
                and #%00001000  ;-FLDU--R
                bne JoyNotUp    ;Jump if UP not presesd
                dec SPRITEY                         ;Move Y Up the screen
JoyNotUp
                lda R1;z_h
                and #%00010000  ;-FLDU--R
                bne JoyNotDown  ;Jump if DOWN not presesd
                inc SPRITEY                     ;Move Y Down the screen
JoyNotDown
                lda R1;z_h
                and #%00100000  ;-FLDU--R
                bne JoyNotLeft  ;Move X Left 
                dec SPRITEX
JoyNotLeft
                lda R1;z_h
                and #%00000001  ;-FLDU--R
                bne JoyNotRight ;Move X Right
                inc SPRITEX
JoyNotRight
               

                LDX SPRITEX
                LDY SPRITEY
                JSR SSSMOVEXY  ;move the BigRed sprite across the screen
                
              

                JSR ANYKEY     ;until a key press
                BEQ loopd8

[AndyH]

If they're multicolour you have to move in increments of 2 on the horizontal otherwise you are changing the bit pairs (that make the colour of a pixel) between odd and even x positions. I can't remember if SSS has any attribute or flag to handle multicolour specifically, but that is what it looks like from your screenshot.

[thegg]

AndyH is exactly right. Look at the demo I've just posted and on the Repeat Sprites screen you will see the multicolour sprites moving twice as fast as the single colour sprites. That is because I increment the X parameter by 2 at each update of the multicolour sprites and by 1 for the single colour sprites.

There is no automation of this in the SSS. It is the programer's responibility to keep the multicolour sprites on an even value in the X coordinate.

[MrSterlingBS]

Hello,

thank you for the answer.

Is it theoratically possible to move multicolored sprites by one pixel?

[AndyH]

Short answer is no.

You could attempt to create 8 pre shifted images in multicolour to give the impression of moving 8 steps, but your pixels will still be fat (double witdth) and restricted to the one of four colours available in the character cell, while bit 3 is set in the corresponding colour memory cell. So this is just animation and still falls under the rules of how multicolour is achieved.

Another simpler thing you can do is store the x position outside of sss and when you pass it in mask out (clear) bit 0 so the sprite routine is always positioned on on even boundary but your actual x position can be odd and even values. Your sprite will still move on the multicolour 2 pixel boundaries but you'll avoid the colour changes you observed and the time it takes to move horizontally will be consistent if it was moving 1 pixel at a time.