Software sprite routine and FE3

Basic and Machine Language

Moderator: Moderators

Post Reply
User avatar
majikeyric
Vic 20 Afficionado
Posts: 349
Joined: Fri Oct 24, 2014 2:08 pm
Website: http://majikeyric.free.fr
Location: France

Software sprite routine and FE3

Post by majikeyric »

Hi,

I'm aware of the vic-sss library, but I wanted to create my own routine (and I don't like CA65, I prefer ACME :lol: ),

you can download the prg here : http://majikeyric.free.fr/cbm/sprites.prg

It requires a 24K extension because all the sprites are pre-shifted in memory (at runtime), it takes a lot of memory.

Can you tell me if it eats a lot of raster-time ? (just run it) (there are 8 sprites : 6:1x1, 1:2x2, 1:2x3)
I can't compare it to anything (I'm new to VIC coding and software sprites) this is why I ask you.
I still can optimize it a little but not much.

I will adapt my routine to make use of the extra memory of the FE3 and start coding a game.

I have read a little the FE3 technical documentation but I don't understand it very well yet.
According to you, what mode should I use to store in and retrieve data (graphics) from the 512k memory ?
any advice is welcome :)
Last edited by majikeyric on Fri Jan 16, 2015 2:37 pm, edited 1 time in total.
User avatar
beamrider
Vic 20 Scientist
Posts: 1447
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Software sprite routine and FE3

Post by beamrider »

Are the large diamond shapes supposed to flicker to vertical bars and distort?

[edit: - it actually requires 24K of memory]
User avatar
majikeyric
Vic 20 Afficionado
Posts: 349
Joined: Fri Oct 24, 2014 2:08 pm
Website: http://majikeyric.free.fr
Location: France

Re: Software sprite routine and FE3

Post by majikeyric »

oops, yes it requires 24k :oops:
3 sprites pre-shifted (horizontally and vertically)= 3*64 = 192 different sprites in memory :shock:

maybe I should try to only shift the sprites horizontally :lol:
User avatar
beamrider
Vic 20 Scientist
Posts: 1447
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: Software sprite routine and FE3

Post by beamrider »

yes, that's what I meant, if you run with only 16K the graphics get "messed up".

Presumably you are setting one border colour at the last raster line of the screen area, then doing the sprite animation and restoring it afterwards, so it seems to take about 3/4 of a refresh cycle to execute?

The performance, seems about right if you are animating in indivdual pixels, when you start to add in game logic, it will slow down of course and you'll need to either reduce the number of objects or increase the stepping.

I can't see any reason to store vertically shifted sprites since you have to copy them bytewise to character RAM you can just start and end your copy at the desired offset depending on the sprites vertical position within an animation cell. This is what I do on Pooyan to animate the basket going up and down (it doesn't use the SSS for that).

Personally, I think it would be a good idea to pool resources and come up with a definitive "open source" sprite library for the Vic rather than each developer reinventing the wheel. Vic SSS is a good start but it doesn't support multicolour masking, and so if I am to make another game I will first need to come up with a new sprite library. Personally, I can't stand colour clash since it produces the kind of unwated effects illustrated below (the outline of the red diamond is completely lost).
Attachments
Capture.PNG
Capture.PNG (4.5 KiB) Viewed 720 times
Post Reply