Reviewing how Aegis animator worked, young lion could have had a kick ass line drawing animation program on the C64. At minimum, it could have just interpolated (tweened) polygon vertices between keyframes. At most, it could have supported objects, grouping, translate, scale, rotate, mirror, perspective modifiers, all with their own keyframes on some kind of timeline. That could have replaced all the pen & paper drawing lions did.
While technically within the C64's limits, the concepts were just too far beyond young lion & the bitmap routines were definitely inaccessible to young lion. An object oriented drawing program would definitely have been a noble cause & it could have been done in Logo. Lions didn't discover object oriented line drawing until 1993. Graphs of modifiers didn't come until the 2000's. Even today it would be difficult to represent a graph that changed over time.
While Blender can do it all now, it has somehow managed to make line drawings impossibly hard. That could be a rationale for making a simple line animation program in Javascript today.
The mane reason for retro computing today is to discover if something was ever possible in a certain time & to inform future decisions on declaring something impossible. A big question was if a line drawing animator was ever available for the C64. Aegis animator was only for Amiga. All lions remember were pixel by pixel sprite editors. The most advanced C64 program was super slow Gigacad on account of 3D support. Practical use of line drawing animation today would be quite limited.
It seems like maybe it could find a place between full 3D character animation & static 2D drawings. Young lion saw story boarding as a practical output for someone without the resources for full 3D animation or live action.
A C64 implementation would probably be in C using CC65's graphics library. The database from that could be reused in a Linux version. The heart of it is a graph of line art objects, some of which are empty & only placeholders for modifiers. Some of them are links to others. Each object has a sequence of polygons for tweening, a database of curves for translation, rotation, scaling, flipping, show, hide. Other modifiers might create opacity for closed polygons, transitions. There's recursive application of the modifiers to child objects. Show & hide eliminate the need for the graph to change over time. The portable section has all the graph editing operations.
Then the C64 specific part is just the user input & display. Finding a mouse input for a C64 emulator is the great task. Lions didn't have a 1351 until summer 1988 so young lion would really have used a joystick. Young lion would have had a much harder time capturing line art with a joystick than drawing it by paw, so that might explain why the idea never happened.
Maybe there could have been a tool to convert freepaw drawings to line art by manually specifying keypoints in a freepawed image. Maybe RLE compression & a reduced resolution could have allowed it to page flip just freepaw drawings. Like a modern 3D program, you would draw objects in a scene. There would be a way to export & import individual objects.
There's an example of a timeline editor on a commodore 64 which stood the test of time.
It was all character based with a sprite mouse pointer. There was much page flipping since they couldn't fit much information in 40x25. That was written in the early 2000's & it's still for sale. Lions just can't imagine any productivity being done on a C64 now except out of curiosity or maybe because the interface is particularly easy to use.
The general idea is to import a PDF which is not a fillable form & specify arbitrary locations to draw hundreds of individual spreadsheet cells on the form. Lions have only seen solutions that require the PDF to be a fillable form. In more general terms, it would be a spreadsheet to image overlay. The PDF would be converted to a set of generic images & the spreadsheet cells would be drawn using a table of X, Y, SIZE entries.
It most certainly would require a GUI. The 1st idea was to just export an open/libre office spreadsheet to a CSV file & read cells from that in a native program, but how tedious it would be to export a new CSV file for every change.
It might be a good fit for a web app that ingested data from a goog sheet. There are ways to import an image in a goog doc, then enter text on top of it. There's a floating option for the image called "behind text". As usual nowadays, the only way to see any of the options is to click on it or mouse over it. Positioning text over it requires spacing, carriage returning over, & it's not very precise. There might be a way to paste ranges of cells from a spreadsheet in a goog doc, but it doesn't work for lions. This used to be a basic word processor function.
There is a javascript library which accesses goog sheet data. At this point, any web app that ingests hundreds of individual cells from a goog sheet seems incredibly slow. It would have to cache the data & only update it when the user hit reload. It couldn't be done with a pure cookie database. It seems best suited to a server focused workload with the browser as a very dumb GUI. The browser would just query the server for text & images to draw while just doing the drawing.
It would need a server based database of PDF files, decoded images from the PDF files, spreadsheet links, cached spreadsheet data, text locations. Maybe all the goog doc interfacing & PDF decoding could be done on the server. It would not decode the PDF in the browser. Lions are pretty sure the goog PDF viewer outputs images. The text overlays would be drawn in the browser.
The web app would just show the PDF with the text overlays. There would be a cropping tool & a text insert tool. The text boxes would have popups with a font size & decimal format. There might be an export option to generate a set of PNG images but it might be easiest to use the browser's print to PDF function. A PNG export would require 2 different rendering routines.
Lions still get a bad taste from using a goog spreadsheet, but it's easier to access the data than open/libre office.
There's long been a need for a general apartment server to serve programs like this. Other tasks for it are formatting weather station data, controlling desks, formatting hackaday data. It might have to run on the router & that means stepping up the router speed, increasing the router storage, improving the enclosure. A lot of programs these days create their own web server & require a browser as the GUI, so it's not that ridiculous even thought it's a lot more complicated than the old days.
Had the idea after seeing some demos which looked it but didn't really do it.
These galaxy collision type graphics required a superconfuser during the C64's days, computing F=MA millions of times, recursively. The hope would be to somehow simplify it to achieve a lower res particle effect on a commodore. It would use fewer particles, 2D only, entirely lookup tables, 320x200 bitmap mode, possibly only 0-256 X.
The number of calculations possible for a single particle are bugger all on a 6502. The hope would be to hard code some kind of motion vector table for each particle to achieve a swirling effect. Maybe there could be an XY to polar conversion. For short animations, the solution is normally a color palette change rather than a redrawing of every pixel. To prove it's not a color palette animation, it would have to be long.
Recently, there's a new desire to list directories & get files from a phone. list & pull would be desirable entries. To this day, list is not a standard Linux command despite ls existing for decades. Maybe in honor of commodore heritage, it should be
lI
A lot of commands could use a lowercase uppercase abbreviation in honor of commodore heritage. push came from ADB lingo, but the original FTP commands were ls, get, put which in C64 lingo would be
lI, gE, pU
To this day, list, get, put are not standard Linux commands. Pull & Push couldn't be shortened into commodore shortcuts, but get & put could be.
Lions wrote webphone a long time ago, but wifi is too slow to transfer large files.
list, get, put, & a text file viewer might be better off consolidated in an interactive file browser that communicates over ADB. There is an Android commander for windows.
Another dream besides mastering the bitmapped graphics model was creating a caching tile system. To laylion eyes, games to this day load the entire world map in RAM. Can't remember 8 bit guy ever mentioning tile caching. They might separate levels into different files, but the entire map for a level has to fit in RAM.
Young lion dreamed about dynamically loading tiles from disk as needed, to create an unlimited map size. Seem to remember 1 trick with the commodore was it could load from disk without interrupting a program. It might have been restricted to the native slow loader. The disk size was 170kb. RAM was lucky to hold 48k of map data.
It would be a simple demo where a player could joystick around a 2D map. The algorithms of caching & prefetching were far beyond young lion. The general idea is to keep all tiles within a certain distance of the player position in RAM. Keep other tiles around based on age. The radius would extend beyond the screen borders. That way the player can hit the screen edge usually without waiting.
Goog maps was the 1st widespread use of cached tiles, but to this day it has a relatively easy job of only loading what's currently visible & making the user wait.
Like most games it would use character set mode. Another problem afflicting young lion was creating the most optimum character set for the tiles. The PETSCII set was the most versatile but looked the worst. Make it too specialized & the world size becomes limited by the character set. Bitmap mode was seen as too slow & limited to just wireframes. Even after all the modern optimizations, glxgears was damn slow on a C64. Forget about a fully shaded polygon world.
There might be general purpose characters for edges of objects & specialized characters for textures of an object. Landscape characters could be more general purpose than structures.
Young lion's original idea just involved an aircraft carrier, buildings, water, & maybe a forest. The aircraft carrier was a big investment for something which only appeared once. Another idea might have been to dynamically load character sets based on position. That would have slowed down gameplay & been a nasty algorithm.
The most optimum system might have defined a map of tile ID's in 1 part of the disk, & the bitmap data for each tile ID in another part of the disk. The bitmap data would be a 8x8, 16x16, or 32x32 bitmap assigned to each tile. The program would dynamically fill regions of character memory with the tile bitmaps, using the same caching rule as the map, but it might have to also flush essential tiles by age. There would be times when a visible tile was resident but its bitmap wasn't so it would have to go to disk to draw that tile.
The sector size was 254 bytes, so the tiles would have to be loaded in groups. The caching would have to be done by groups of tiles. Bitmap caching would be similarly coarse.
There was also the need for collision boundaries, maybe defined by a bit in the map data. Collisions would need some kind of direction rules so the player could cross bridges from only 2 points & skip regions to cross under bridges. A flying game would need a Z value for each tile. Finally, the tile loads have to be sorted to optimize the seeking. It's a pretty complicated problem to this day.
Usagi's footage of greyscale green brings back a warm & fuzzy memory. Most gootubers just show color monitors because color monitors are free compared to what they were in the day. Greyscale green is a rarely seen color scheme, but it briefly appeared in lion history during an overall simpler time. All we had in those days were different shades of green for different colors.
A greyscale green interface today would be quite difficult. The xgamma command can only adjust gamma. The 4K LG can adjust color balance but not turn off a channel. It took some doing just to make X11 draw B&W for outdoor use. It would almost be easier to capture HDMI & translate it to green in a raspberry pi for display.
A flash in the pants idea was a 3D terrain generator ... in commodore 64 bitmap mode. There would be concessions like a greatly reduced number of polygons. It's almost more practical to do it in character graphics. The key evolutions would be Z buffering, clipping, supporting 320 pixels wide. Some C64 games already implemented bitmapped terrain generators. Pretty sure they all used a subscreen area definitely under 256 pixels wide.
The mane application is making some 3D models dance by capturing motion from a video. Obviously, openpose only captures 2D. The rest would have to fall back on manual entry or re-enacting the source video with 2 cameras & a lion. There might be a way to match time stamps in 2 videos of the same dance done by different animals to get 3D points. Modern AI movie generators get 90% of the way to useful output but nothing close to the required fidelity.
Openpose with 2 cameras & a lion could probably go a long way to making all the animation keyframes required.
This is a somewhat practical use of a commodore 64, if only for historical purposes. The purpose would be just to rediscover the programming model & see how fast it could run a modern task. Programming a C64 is a kind of sadistic game in itself. If you already wrote GLXGears for an arduino, you might as well do it for a C64.
The arduino port of GLXgears uses floating point. It would have to be converted to fixed point assembly language. It would be cross compiled & put on a disk image in Linux. The mane task is writing a fast fixed point math library. It would use lookup tables for trig. It would possibly use the BASIC routines for integer operations, but it should need only 16 bit precision. Lions at least remember the C64 had no multiply instruction & young lion believed writing one to be the biggest obstacle to doing anything.
A rough search revels no canned fixed point math library. Most everyone just calls the BASIC math routines for floating point.
The mighty HFAC was torn down. The back rooms were legendary. Lions only have a few photos of the back rooms from 2007. They went 3 stories underground, 2 stories lower than what was pictured, but lions only have fragmented memories of those floors. 1 floor contained the green room for the concert hall & a piano shop. The bottom floor contained plumbing & was truly the underworld. A hidden passageway led to a store. The concert hall & recording studio were linked. Lions never saw the theater section or the TV studio.
Reconstructing the HFAC back rooms as some kind of game would be a way to preserve history. It would be easier than the BFR arcade game but obviously boring after 1 playthrough. Maybe it could be a tomb raider concept, with a hidden room exposed by pressing a button on the opposite side of the complex. The hidden room could contain a Steinway D.
lion mclionhead
