For sprites, the requirement to handle scaling & rotating sprites means that a more flexible sprite system is required than the one used by White Light, which used an unrolled plot routine with fixed size sprites. Obviously this is going to use a _lot_ of sprites, so there needs to be some kind of management system in place.
Tube used realtime texture mapping for all objects incidentally, which is probably why it ran in slow motion on my old 486/25. Not brave enough to attempt this on a Beeb.
Currently the only fully implemented object (diamonds) uses 4 frames for animation, with 4 levels of scaling, and 8 levels of rotation. This takes a mere 128 sprites, which in total takes about 7.5 kB. Each sprite has a header :
Code: Select all
u16 base
u8 x_size (in bytes)
u8 y_size (in lines)
u8 x_offset
u8 y_offset
u16 filler
The offsets mean that the coordinates passed to the sprite plotter can point to any position in the sprite, rather than the top left - this means the main code can just pass the world location to the sprite plotter, and the plotter can adjust for rotation/scaling correctly.
To make life easier for the main game code, there's a routine that will take object number, animation frame, and rotation & distance coordinates, and compute the correct sprite. There's another table with per-object data to help with this, but I won't document it as it's a bit placeholder at the moment. Sprite coordinates are calculated by passing an angle through sine/cosine tables, then multiplying that through a factor derived from distance from camera.
The sprite plotter is column-major, with sprite masks being inferred from colour data via a lookup table. There are variants for X and Y flipping - this helps minimise the number of rotation frames that need to be stored. This does have the quirk that sprites rotated 90 or 270 degrees will appear to be left-right inverted. This hasn't been an enormous issue - yet!
Currently all sprites are pre-rendered. Modelling is done in Blender (which is complete overkill for models this simple!), all required animation & rotation frames are rendered out and fed into a converter, which scales the sprites appropriately, packs them onto a single 160x256 bitmap which is fed into BBC Micro Image Converter, and generates headers which are fed into another converter which packs everything into data to fit into sideways RAM. That all turns frames that look like this :
- diamond.gif (2.16 KiB) Viewed 425 times
into this :
Obviously some manual tweaking is needed at some point!
Currently I'm using 4 distance levels + 32 rotations (8 rotation frames + mirroring). There's some noticeable popping between frames, but I think it's acceptable. I did originally use twice as many frames for rotation, but it currently uses too much memory. I'm toying with using some kind of compression, probably storing all sprites at 2 BPP, which might let me tweak this a bit.
I concluded quickly that having some kind of shadow makes sprites fit in to the world more convincingly. I've done this manually for the main player sprite, as there are only a few of those. I intend to automate this for other objects, due to the sheer number of sprites, but I haven't done this yet.
I should add incidentally that memory usage means there's no way this will run on less than a Master!
What . . . Not even on an Electron - With Turbo 
) but you could draw a 3 colour tube with 9 palette entries and leave 7 colours for sprites perhaps. Changing what 3 colours they are as you descend the tube would give the illusion of a full colour tube (with only 3 on screen at once). Or indeed a two colour 3 frame tube draw with 8 palette entries... tripple frame rate.
- with the tube animation increasing by ~20%...