Seem to recall the sprite API being young lion's least favorite thing to program & character set API being his most favorite thing to program 40 years ago, even if every effort was just scrap.  Sprites just don't leave much room to be hacked, other than multiplexing.  Sprite multiplexing was actually rarely used in the best looking games.

Another game demo used a scrolling character background purely as eye candy. 

Character sets had all the diabolical algorithms & were manageable from BASIC.  Despite hardware acceleration being seen as increasing over the last 40 years, the C64 really was the most hardware accelerated thing through many more years of later PC's.  Stuff was pretty dictated by the hardware API's & sprites were about the most managed API.  It was like the apollo program before taking a big step back.

Multicolor sprites actually shared 2 global colors.  It's surprising young lion found this more appealing than CGA programming, but the 8086 only had 4 colors & he just didn't have an 8086 assembler or documentation.  The lack of tools was appreciated less than the lack of colors & the lack of hardware acceleration at the time. By age 20, young lion began appreciating software defined graphics more than the hardware accelerated graphics of years earlier because of portability.

8 bit guy had a nugget about retro computing clubs.  Maybe there was a retro computing club which could run these demos on period hardware, but the bay area has become so focused on just getting rich, no-one does this stuff anymore.  

---------------------------------------------------------------------------------------------------------------------------------------------------

It came to pass that a game effort would have to scrap some of the scrolling demo.  In order to solve the flickering, the $d800 color memory would have to be static.  It didn't provide that many more colors.  In order to draw a score panel, the bitmap needs to be 24 rows.  A raster interrupt while accessing the disk would require checking the raster line ($d012) before trying any disk I/O.  This would further slow down the scrolling.

Without the color memory, RLE compression only buys 500 bytes or 2 sectors.  It's probably not worth it.

A maximally enjoyable game would have to go back to character set graphics to speed up the scrolling & offer some sort of obstacle course.  It couldn't justify the disk loading algorithm anymore.  It's not necessary yet.

Because of the page flipping, the sprites have to be copied to 2 VIC banks.  Ideally they would be copied to the same pointer values in both VIC banks but in 1 bank, we have $9000-$a000 hitting the same pointers as $5000-$6000 in the other bank.  $9000 is the character ROM.  That leaves $4e80-$5000 & $8e80-$9000 for 6 sprites.  The $4e80 cuts another 3452 from the program memory.

Another 3 sprites can fit in $7f40-$8000 & $bf40-$c000.  That way it can show all 8 sprites with 1 more sprite as a temporary for copying in new data.

Things would be better if the 2 tile buffers were fragmented.  They could be fragmented by looking up the high bytes in a table instead of doing a straight 16 bit increment but that increment is done in the big unrolled loops so it would be super slow.

  Storing the screen memory separately from the bitmap memory would free up another 1000 bytes for the program, but so far is unnecessary.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------

The difficulty of basing a space fighter game on the scrolling demo & the reality that any real demo using this system wouldn't work on 99% of the 1541 emulators & would quickly wear out any real floppy disks led to an idea to break out the space fighter game into a new program.  This new program would just be a tried & true sprite demo with no background.  It would just have the scoreboard.  Enemies would fly from right to left.  The player would be stationary.  The investment would be low enough to be worth doing & it could be a recaptured experience in sprite programming.  If that worked, a 2nd step could be a simple character based scroller for the background/obstacle course.  Old lion concluded what young lion found: the C64 didn't have enough horsepower to use its own bitmap mode most of the time.