Denial

This should be my final post on this thread ...

I have posted for your downloading pleasures the latest archive for VIC Software Sprite Stack, MMX edition.

The API has been cleaned up internally allow / disallow the following features via header constants:

- collision-detection
- ghost mode (EOR)
- repeating sprites
- 16-pixel wide sprites

Disabling any uneeded feature removes code and can make for a bit smaller / faster sprite API.

Included as a working example of most features this API can offer is the video game, Sprite Invaders, which requires 8kb memory expansion and a joystick to play. It allows for one or two player, 3 levels of difficulty, with CLASSIC or VIC 20 rendering variations. If you just want to try the game, click here.

I hope you enjoy this latest creation. It has been a blast to do.

Tried out Sprite Invaders in the browser. A great Space Invaders clone!

You never disappoint, rhurst

Ok, not even two weeks and I already broke my prediction ...

I took on the task of back-porting this latest software sprite stack to all my gaming projects. After all, the API has not changed, just the internals and allowances to enable/disable its feature set in the header file. Well, I found some inconsistencies in the back-ports and thus I am posting that ALL sources and binaries for this and those gaming projects have been touched, tested, and I can safely claim working to my heart's content.

Here's a break-down of each gaming project and its VIC-SSS usage:

Quikman+8k uses 5 sprites, 8x8 only, no additional options

Omega Fury uses 15 sprites, up to 16x16, no additional options

Berzerk MMX uses 16 sprites, up to 8x16 (tall), with options collision-detection and ghost-mode

Break-out! uses 2 sprites, up to (wide) 16x4, with options collision-detection and ghost-mode

Sprite Invaders uses 42 sprites, up to (wide) 16x8, with all options enabled: repeating-sprites, collision-detection, and ghost-mode

The changes made to these gaming projects can be reviewed at my subversion repositories.

The VIC SSS MMX archive has been updated to reflect all the latest code changes used in these gaming projects.

The Robert Hurst VIC 20 Collection archive has been updated to include VIC-SSS-MMX with all my gaming projects including source code, documentation, and batch command files to run the game in either Windows or Linux using MESS 0.140.

If you prefer to get just the latest games, please download this convenient D64 image instead of the larger archives mentioned.

Enjoy!

now we need more programmers start using the VIC-SSS! C'mon boys!

This is related to the topic, I promise.

On the average, how many instructions can the VIC-20's CPU process in a scan line?

RJBowman wrote:On the average, how many instructions can the VIC-20's CPU process in a scan line?

PAL VIC-20s have 71 cycles/line, NTSC VIC-20s have 65 cycles/line. Instructions on the 6502 take 2 to 7 cycles depending on addressing mode. Pick any number between 9 and 35.

For code which is synchronised to the raster beam, you'll have to count cycles for each individual instruction. Quoting an 'average number of instructions per scan line' is of no use here. You find the instruction/address mode cycle counts elsewhere.

Been using this stack for for my latest game. Works really well however I am desperately short of character space and the sprite rendering is corrupting my display. I need at least 64 UDC chars for the back drop.

Would like to drop the ROM characters as I only use 12 of these and lower the UDCs in RAM down from $1C00 to $1800 thus giving more space?

I made the following modifications to SSS and the results are encouraging, but doesn't seem to be working 100% so figured I need to modify another part of the code?

1) Relocated SSBUF into RAM1
2) Made the following mods to VIC-SSS-MMX.s

; previous line commented out

;LDA #$CF ; point VIC screen @ $1000 w/ char set @ $1C00
LDA #$CE ; point VIC screen @ $1000 w/ char set @ $1800


;SBC #$1C ; starting page of custom chars
SBC #$18 ; starting page of custom chars


modified SSSIMAGE as follow

SSSIMAGE:

TAY
ASL
ASL
ASL ; x8
TAX ; save image low byte
TYA
ROL ; set carry bit
ROL
ROL
ROL
AND #%00000011
ORA #$18 ; prepend page pointer
TAY ; save image high byte
RTS




This seems to allow more sprites, however now there is slight corruption as the sprites are rendered.

Update: The distortion seems to occur only when sprites overlap/border each other.

Update2: Spent (a lot) more time debugging this, seems the render is incorrect 3 out of 4 times and comes good every 4th time. Sprite->Background is rendered ok.

Any help appreciated.

Thanks

Excellent! I think you are nearly there...

I am referencing the source, and see that there is another hard-coded reference to $1C that needs replacement to $18 inside of SSSUPDATE: Let us know how that works out for you. Feel free to anonymous FTP upload your project to ftp.hurst-ri.us in its incoming directory (write-only) if you'd like me to take a looksee and do any deeper inspection/debugging. Good luck!

rhurst wrote:Excellent! I think you are nearly there...

I am referencing the source, and see that there is another hard-coded reference to $1C that needs replacement to $18 inside of SSSUPDATE:

Code: Select all

@Dchar: STA VECTORFG+1
                SEC
                SBC #$1C                ; starting page of custom chars

Let us know how that works out for you. Feel free to anonymous FTP upload your project to ftp.hurst-ri.us in its incoming directory (write-only) if you'd like me to take a looksee and do any deeper inspection/debugging. Good luck!

I already got that one covered I think.

Thanks for offer of help - I've sent you a PM with a link to the source as I couldn't connect to the FTP site due to required credentials.

Adrian

Yeah, a while ago I got an optimization in SSSIMAGE which works fine for a 128-character set, but not 256, is what you need. Just modify it to look something like this: That way, the background BYTE returned by SSSREAD (which is part of the WOLF sprite) will get the proper memory address pointer loaded in X/Y.

Excellent, thanks so much, that's great

I can now happily create up 128-chars worth of sprites + my 64 UDCs

One thing I noticed and it could be my fault - but if I exceed 128 (64 d.b. x 2) chars worth of sprite images I get char corruption.

Also, another question. I would like to use the frame skip value to adjust the graduation of sprite movement to compensate for slow downs. Should I be using VSYNC2?

Thanks
Adrian

Can you reveal what SPRITEMAX is set at and the enumerate each sprite definition, i.e., each call to SSSCREATE with A and Y registers?

Can your game sustain any repeating sprites?

For auto frameskip, just do LDY #0 followed by JSR SSSFFLIP. If it more than 2 video refreshes occur between invocations, a frameskip will occur - sprite registers are still updated, but SSSUPDATE is skipped.

If no skip, only those sprites needing rendering will get redrawn. So if a sprite does not ANIM, MOVEXY, TOUCH, or REFRESH between FLIP, it need not be rendered that video flip, thus saving many cycles. That technique is used in all my games where I use a SPEED variable per sprite that is calibrated to the video flip counter, i.e., a sprite might move at speed 7 meaning it moves every flip, speed 0 it is stationary, speed 1 = 1 per 8 flips, speed 2 = 1 per 4 flips, etc. You get varying motion in sprites, plus the benefit of saving those cycles on slower moving objects relative to the "hero" which usually is made to react the fastest (or near the fastest).

SPRITEMAX is set to 16.

Sprites created

ldy #16
n x %10000111

ldy #8
2 x %10001100

where n = 8 : OK
n = 10 : corruption occurs

Afraid no, can't do repeating sprites. They're all animated individually.

I tried SSSFFLIP but it gave odd results. Sprites jumped half way down the screen so I need to get my game loop timing working better when the number of active sprites varies so much ....

Thanks, yes I had a look at your bezerk code. I think I am pushing larger sprites around and varies between 2 - 10 big dude + a couple of 1x1 sprites. I need to drop the frame rate for SSFLIP to a value of 4 and then move some sprites 2 pixels per flip and some 1. Later I will have some slower moving and stationery sprites (if I can create more?) that I can use that technique on.

Did you increase SSSBUF? It comes preset as a default of 64*8.

8 x (2x3) = 48
2 x (2x2) = 8
SSSBUF should be set no smaller than 56*8

10 x (2x3) = 60
2 x (2x2) = 8
SSSBUF should be set no smaller than 68*8