"Soft" sprites

[derekwinters]

Hi,

I don't know if anyone can offer any feedback on this, but I was playing 8k jetpac for vic20, and I noticed that the "sprites" seem to be able to overlay each other (I will try attach a picture if it works on here).

I looked at jetpac running in WinVice / xvic.exe and viewed memory and I couldin't even find the screen memory - it all seems to be doing something clever with the character set (I could be wrong), as i checked $1000 and it seems like all char data but spaced out hence my thought its come kind of voodoo. The colour memory seems to be in the right place, just cant find a screen = $9005 hi nibble is %1000 so where would screen memory at %x000 be?

I have (although not anywhere near expert level of any kind) tried my own sprite code using assembler not basic, but I cant get it fast enough in the raster time - the clear data or copy existing char data loop takes too long (but that's me doing things wrong at present).

Does anybody know how the above is achieved in jetpac with the sprites etc - seems like super skilled coder black magic? Voodoo!

D

[bjonte]

It's basically constructing characters on the fly.

I would guess that it uses 16 pixels high characters and then fills the screen completely with unique characters, top to bottom left to right, effectively constructing a bitmap. It then draws directly into the character set (bitmap) to render the moving objects with XOR operations to be able to remove the objects again.

[bjonte]

...or voodoo magic.

[Mike]

If you ...

[...] couldin't even find the screen memory [...]

... (i.e. some kind of byte matrix whose contents at least loosely resemble the visible screen), but instead see a regular pattern that spans a whole page somewhere in $0000..$03FF or $1000..$1FFF, then the program sets up the screen as bitmap.

Then of course it is no rocket science anymore to shift objects pixel-wise and overlap them (with OR- or EXOR-operations). Pre-shifted objects give extra speed for horizontal fine movements. If the characters of the address generating text screen are arranged in columns, fine vertical movement comes for free, utilizing the (ZP),Y address mode of the 6502.

Even with a 'normal' text screen, soft sprites are possible in the sense you are seeing here (i.e. fine movement and overlapping objects). That involves somewhat streamlined code, though. As an example, take a look at Robert Hurst's "Triple-S" Software Sprite Stack. He and beamrider have released several games that use this stack.

[derekwinters]

Hi,

Thanks for your quick response.

Looking at the image I attached/jetpac itself, the graphics don't "seem" to be double height looking closely at it paused, so assuming they aren't using double height chars, then its even more voodoo?

I admit I am not a very good programmer but I am interestde to learn/work out how it was done (maybe there might be someone else too one day asks the same question !??)

D

[Mike]

The screen *is* made of double height characters. You can tell it by the colour clash of the beam below the rightmost green platform.

[derekwinters]

Thanks for your response Mike.

I can't find anything relating to Robert Hurst's "Triple-S" Software Sprite Stack when I search in Google - do you knwo of a link or any links to the info?

Also is there any reference about that goes into how the botmap screen would work - I have tried it myself but couldn't work it out and couldn't find any reference to read up on so wrote it off as a fail.

D

[derekwinters]

Hi again,

I'll ask one more question and if I can't understand then I will leave it, and apologise to all in advance for any inconvenience as it's clearly a very very skilled task.

If the chars are double height, looking at the pixels in the graphics, they don't look double height? they look (to me) like normal height pixels - for example look at the text in the score/hi-score So how does that work then? The colour clash just looks like normal char colour clash?

D

[Mike]

If the chars are double height, looking at the pixels in the graphics, they don't look double height? they look (to me) like normal height pixels - for example look at the text in the score/hi-score So how does that work then? The colour clash just looks like normal char colour clash?

Edit: "double height" in the context here doesn't mean the characters are expanded by doubling their pixels vertically (but still keeping a 8x8 character definition), rather, each character addresses a true 8x16 pixel definition. The VIC chip also re-organises its addressing into the character set so each character has its own 16 bytes, and a full character set of 256 characters spans 4 KB.

Now, just because the underlying structure uses double height characters doesn't mean you're forced to 'fill' them completely with 8x16 pixel contents. You can still put two 8x8 characters stacked on top of each other there.

The colour attributes will follow a 8x16 restriction though. Again, take a sharp look at the beam below the rightmost green platform. The platform occupies the upper half of a 8x16 character, so Jetman can walk on it without colour clash. But here there's a beam going just underneath it, which turns from cyan to green.

Is there any reference about that goes into how the bitmap screen would work?

Take a look here: MINIGRAFIK batch processing suite.

I can't find anything relating to Robert Hurst's "Triple-S" Software Sprite Stack when I search in Google

You find quite some hits when you employ the forum's own search box with "Software Sprite Stack", however as I've found out, many of the links in the project threads that point to download resources are dead now ...

...

... Robert?

[ops]

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

[Mike]

Ops, thanks!

[derekwinters]

Hi,

Thanks to everybody for taking the time to answer. I have a better idea of how it should work now.

D

[chysn]

I've used this simple technique in a few games: I earmark a couple adjacent characters in the character set as a two-character bitmap, with one being the source (starting point) and another being the destination (ending point). I copy the data from the characters on the screen into this little bitmap, and then move it, as appropriate.

I use ASL for west-moving objects, LSR for east-moving objects, and byte shifting between the adjacent characters for north- and south-moving objects. The code is here, and the routine at line 808 moves the bitmap one pixel in the specified direction: https://github.com/Chysn/VIC20-HelixCol ... colony.asm

It's a fairly inexpensive but, in my opinion, high-value technique for games based on custom character sets.

[derekwinters]

Hi,

Sorry to have another question, but I have been trying the bitmap things suggested earlier, and I can set $9005 so $1000 to $1fff is the area for the
character memory / bitmap data, but I can't work out in my head where to point to the actual screen memory so I can set a matrix of double height characters to go with the bitmap.

Maybe I have misunderstood. I have tried finding the answer elsewhere but haven't managed to.

D

[srowe]

Perhaps this table helps you understand the possible combinations. In normal circumstances only those shown in green are available

Given the limited available memory the common choice is that have the screen and character generator both start at $1000.