Page 12 of 12
Re: Software sprites?
Posted: Wed Oct 12, 2022 9:30 pm
by 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
Re: Software sprites?
Posted: Thu Oct 13, 2022 7:14 am
by beamrider
Mike wrote: ↑Wed Oct 12, 2022 4:30 am
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
Re: Software sprites?
Posted: Mon Nov 07, 2022 2:51 pm
by 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!
Re: Software sprites?
Posted: Tue Nov 08, 2022 7:17 am
by 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.
Re: Software sprites?
Posted: Tue Nov 08, 2022 11:10 am
by thegg
If you need some extra motivation, I (and I am sure quite a few others) would be very interested in such a library.
Re: Software sprites?
Posted: Mon Jan 23, 2023 10:40 pm
by 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
Re: Software sprites?
Posted: Tue Apr 11, 2023 7:58 am
by 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
Re: Software sprites?
Posted: Tue Apr 11, 2023 8:05 am
by 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.
Re: Software sprites?
Posted: Tue Apr 11, 2023 8:28 am
by 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.
Re: Software sprites?
Posted: Wed Apr 12, 2023 4:33 am
by MrSterlingBS
Hello,
thank you for the answer.
Is it theoratically possible to move multicolored sprites by one pixel?
Re: Software sprites?
Posted: Wed Apr 12, 2023 5:38 am
by 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.