Sprites had 24x21 resolution.  2 abreast multicolor mode is still 24x21.   A flame costs 2 more,  but isn't always on.  Memory accounting is a difficult problem.  In both bitmap banks, the sprite pointers can access 7168 + 192 bytes.  It takes more memory but is simpler to have a copy of every possible sprite in both banks.  It's a lot more efficient but more complicated to memcopy the sprites to static pointers in realtime.  Disk I/O would pay for the memcpy.  The memcpy option could perform most rotations at runtime.  The dynamic pointer option requires every possible rotation to be stored twice in RAM so it almost has to use memcpy.  It needs 16 sprites or 1024 bytes in each bank since they all have to be page flipped.

Rough concepts were pretty bad.  It's kind of intelligible when zoomed out.  The journey began with screencapping the website animation with rotations.  It was decided to not reverse the lighting when it was upside down to save memory & because it didn't add to the intelligibility.  It is just a matter of mirroring & rotating the 4 base images to get flat spins, landing burns, strafing.  It also needs RUDs.  This stuff is very labor intensive for the result.  It would be easier to not shade it at all & not roll it.  A low fidelity version might be in order for starting.

Young lion was similarly surprised by how bad sprites really looked in 1985.

A lot of the delusion might have been from assuming the C64 ports of these games were faithful to the arcade versions, but they might have also looked a lot better on a CRT.  Young lion also had some idea game programmers were working within budget constraints so they couldn't max out the machine.  Aligning players horizontally was particularly crippling.  There's no way to multiplex horizontal sprites.

Some fake CRT blurring made it slightly more bearable.

The last time a ship flame was photographed was many years ago.  The flame needs to animate faster than the ship.  It's easier to use 2 double height sprites than a single double width.  The only times it can realistically have a flame are the landing flip & the flat spin.

The big problem is developing a sprite engine.  It's mane feature is a table of the desired image address, transformation, x, y, visibility, colors of each sprite.   It needs to compare a table of new sprite states with a table of current sprite states, copy the desired image data into the 2 banks outside the raster interrupt, copy the new state table to the current state table inside the raster interrupt, then use the current state table to update the VIC II registers inside every raster IRQ.

A general purpose sprite engine was another snag encountered by 10 year old lion.  In this case, there's no multiplexing.  It's a memory management & queueing problem.  As much as young lion believed multiplexing was essential in making any game look good, it actually would never have been practical for his ideas.

On top of the sprite engine, it needs a higher state table for the animation frames.  If only real starships didn't do so many flips.

Cinelerra can screencap an emulator & apply blurring, bobbing in realtime, at 60fps.  It definitely improves the photo rendition.  Bobbing is imperceptible unless it's 4x & the colors are high contrast.  The memory is lost of the actual blurriness of a TV.  There is an intermittent sheering problem with the bobbing.  Unfortunately, trying to debug the bobbing effect with a flashing white image damages the monitor.  It now has permanent flashing lines.

The problem isn't temporal. Bobbing works properly when all the rows are a repeating pattern.  It's a spatial problem when the rows are unique.