Denial

here is the picture . . .

The glitch in the graphic display is happening at the point the SSS switches to the other screen in the double buffered display. I don't yet understand why it switches at that point, but I think it has been deliberately chosen: perhaps to allow enough time to rebuild the whole screen before it appears at the top of the display. The glitch disappears if the vsync occurs a few rasters later. You can see this if you change the raster line value from $76 to $80 in the basic file line 67 (assuming PAL system).

Thanks for pointing the issue out. I hadn't noticed. I'm not sure yet whether or not the issue is a feature of the SSS or the conversion. I have noted it and perhaps the cause will reveal itself when I have a better understanding of how the SSS works.

Nice!

Robert: glad you approve.

Attached is an update to the project that includes much of beamrider's modifications for the handling of multicolour and taller (3x2) sprites and a small addition of my own. The archive contains a Readme giving a bit more detail. There is an executable for the demo as well as the source to build it.

The demo is just an illustration of the SSS functionality. How to use it remains essentially the same except for the creation of a sprite that has a new interface. This is documented in the source files.

Thanks to Robert and beamrider for making their source material available.
Enjoy
Dave

Nice, maybe that what i need.
I realized at the weekend that the multicolor sprites are not 100% correct.

@thegg

It is possible to take a look at my problem @the SoftwareSprite thread?


Best regards
Sven

@ thegg
I see you have the same idea with the BigRedDude.

Your work is amazing.


BR
Sven

Hello,

i take a deeper look at the code and have a question.
There are some "illegal"-opcodes describet in "no more secrets" and i found some interesting optimazion for the sprite stack.
The SSSXYPrintS can be done by the LAX opcode instead of LDA/LDX and saves 9 cycles. The check with the newest SpriteStack version runs normal.

There are some other optimizations possible and i have added this in the code "VIC-SSS-MMX.asm". No huge speed increase, but ...
Another in ... and two times in the code...

MrSterlingBS wrote: ↑Tue Apr 11, 2023 11:44 am There are some "illegal"-opcodes describet in "no more secrets" and i found some interesting optimazion for the sprite stack.
The SSSXYPrintS can be done by the LAX opcode instead of LDA/LDX and saves 9 cycles. The check with the newest SpriteStack version runs normal.

Unless absolutely necessary you should really avoid such "optimizations" with illegal opcodes. Some people are now using newer 65C02 as replacements for a defect 6502 and the new ones do not support illegal opcodes at all. Then for marginal speed increases you just cut your user-base unnecessarily. It is better to do optimizations with normal opcodes.

There are some other optimizations possible and i have added this in the code "VIC-SSS-MMX.asm". No huge speed increase, but ...

Code: Select all

SSSXYPRINTS 
                PLA
                STA VECTORFG
                PLA
                STA VECTORFG+1
                LDY #$01
                byte $B3, $F7           ; opcode LAX 5 (+1) cylces
                ;LDA (VECTORFG),Y       ; 5 (+1) cycles
                ;PHA                    ; 3 cycles
                INY
                LDA (VECTORFG),Y
                TAY
                ;PLA                    ; 4 cycles
                ;TAX                    ; 2 cycles
                JSR SSSPLOT
                LDY #3
                JMP DOSSSPRINTS

With your code you actually change what is in the Accumulator at the end. Since with the PLA the result of the first LDA will be restored in the Accumulator, but just keep the value of the second LDA (VECTORFG),y in it. Using LAX would only save 2 cycles (the TAX).

Code: Select all

SSSUPDATE 
                LDX #0
                STX sssIDX   ;mod: sssnum in original
@do 
                CPX SPRITES
                BCC @cc
                RTS
@cc             
                ; Mod draw sprites in Z_ORDER
                LDA SSSZORDR,X
                byte $8F, sssNUM        ; opcode SAX 
                ;STA sssNUM
                ;TAX

SAX does something different than you think obviously. It does NOT store the value to the X-register, but just applies an AND-operation to the Accumulator and X-register and stores that (ANDed) value.

Golden rule for using illegals in my opinion: only use them If it is not possible to do the task otherwise or the speed-increase is so significant that not using them would seriously affect the final product.

Good morning,

I didn't know that many use a 65c02 these days in real hardware.
The optimization was just an attempt. I enjoy making very small improvements, even if they don't really affect performance.

Unfortunately I haven't owned a real VC-20(+16k) since 1987. I bought an AMIGA 500 then.

Is there a VIC emulator that can also simulate 65C02 or even a 65CE02?

Thank you for your answer and time.

BR Sven

PS: 6502 coding is fun!

Hi,

after my line and flood fill project, I'm currently trying to better understand Robert's software sprite stack. Of course, I'm going to make some improvements here as well.

1.) In the demo, the anykey funktion draws always the text "press any key", this can be skipped and gives a decent speed boost
2.) The LSR3 look up tabe is written like this 8x0, 8x1, 8x2, ..., 8x30, 8x31
If the look up table is structured slightly differently, the subtraction of 16 can be omitted.
8x30, 8x31, 8x0, 8x1, ..., 8x28, 8x29
TXA
SEC
SBC #$10
TAX
can be removed in SSSREAD and SSSPEEKS.
3.) Almost all PHA/PLA or TYA/PHA/PLA/TAY have been replaced by zero page addresses.
4.) Another look up table was implemented, instead of 3 times ASL we can written LDA sssRowsx8,Y in SSSUSE.
sssROWSx8:
byte 8,16,24,0,8,16,24,0
byte 16,24,32,0,16,24,32,0
byte 8,16,24,0,8,16,24,0
byte 16,24,32,0,16,24,32,0
5.) Many zero page entries were used where it was worthwhile, e.g. in INC, DEC or STA, to achieve a small increase in speed. This also leaves more
memory for the main program.
6.) ...

I have to say I admire your tenacity and patience. However, I do wonder if this is the best application of your time and effort. Spending time looking for functional improvements would surely be more interesting and worthwhile.

You say you have replaced almost all stack push/pull operations and many variables with zero page locations. I am interested in how you manage the allocation of the zp space. In particular how you ensure that nothing gets broken by reusing a zp already in use elsewhere in the code. I struggle to avoid conflicts with just indirects and fast variable use.

If you are making changes that range over all the code, how are you testing that your changes are not going to break the existing code functions?

Not a criticism, just interested.

I assume from the 6.... at the end of your post that there is more to follow.

Regards Dave

Thank you for your interest in my optimizations.

At the moment I don't have the ability to write such complex code myself, so I'm trying to make my contribution with small improvements here in the forum. For me it's an interesting hobby to optimize code which has already been written.

The checks for the zero page entries are done directly with the last demo posted here. Since I don't get on well with the CBM prg Studio, I've rewrote the code a bit for my platform. This means that all @ in the code had to be replaced by other characters. My development environment is the VASM assembler http://sun.hasenbraten.de/vasm/ with a batch file from ChibiAkumas https://www.chibiakumas.com/6502/.

The three dots under 6.) mean that there are still a few improvements to come. Among other things, a three-level parallax scrolling that already works on two levels. In the loaded image with the monster, there is grass and mushrooms in the lower part of the screen, and stars in the upper part that move from right to left. Each at different speeds, controlled by the interrupt timer.

It also looks like the code could be rewritten a bit to change the following code snippet LDX #0...INX/CPX maxSprites/BNE to LDX maxSprites...DEX/BPL. But this would be a bigger task that I will tackle later. The speed advantage is also rather marginal. My biggest goal is to rewrite my very first purchased game, Fire Galaxy by KingSoft https://www.youtube.com/watch?v=XQPmRie_9gY. Preferably with soft scrolling and multicolor sprites. It's simply a childhood dream. If you are interested in the current code, I would be happy to send it to you via PM.

Best regards, Sven

I remember trying to further optimise this library myself, including using a few lookup tables. The gains made no visible difference and took up a lot more memory so I just reverted to Robert's original code.

MrSterlingBS wrote: ↑Thu Feb 13, 2025 2:18 am My biggest goal is to rewrite my very first purchased game, Fire Galaxy by KingSoft https://www.youtube.com/watch?v=XQPmRie_9gY. Preferably with soft scrolling and multicolor sprites. It's simply a childhood dream. If you are interested in the current code, I would be happy to send it to you via PM.

I don't think you will be able to use SSS if you want to have scrolling as well. That's a particularly hard nut to crack on the Vic. I'm not aware of any games other than Cheese&Onion on the Vic that combines pixel scrolling and software sprites.

beamrider wrote: ↑Thu Feb 13, 2025 8:10 am I remember trying to further optimise this library myself, including using a few lookup tables. The gains made no visible difference and took up a lot more memory so I just reverted to Robert's original code.

Thank you, that is of course right. The improvements are not really huge. But if you run a improved version beside the normal version via the vice emulator you can see a little more speed of the moving sprites.
And today, with the vice emulator, or memory cardridge, there is a lot of RAM available.