So high res and multicolour characters can coexist like C64 and Apple II do.
Yup, if you've a little experience of the C64 it's pretty much the same but each pixel twice as wide really.
I've never found that useful or effective on C64 but on the VIC-20 it seems to look more contiguous instead of clashing in resolution.
On the C64 it's used a lot for things like status displays (having a nice, multicolour surround with clean high res text) or in scrolling games for background parallax so they can be shifted back against the scrolling.
I'm somewhat familiar with bit or pixel constructed sprites from my research into the 2600 but I still don't understand what the process is to make a software sprite. I understand its pixel/colour resolution and its uses plus visual advantages but not how its made.
Basically software sprites are just characters. To start with, they can be as simple as having a shape drawn into a character that is then moved around a cell at a time and you'll see that on quite a few unexpanded VIC games since this is the most memory efficient solution.
More complicated software sprites for something like Jetpac
will probably have a workspace of, as an example, two by two characters; the four characters on screen where the soft sprite is about to sit are stashed for later reference and replaced by the workspace, which then has it's definitions replaced by copies of what was there previously. Then one of the pre-shifted sprite definitions (because having the four or whatever states pre-shifted as an object moves from character cell to character cell is the fastest way, although some engines do the shift "live") are merged into the workspace at whatever pixel height needed. Then the entire lot is undone by recovering the stashed background characters and the process starts again for the next refresh.
And there's variatious on both themes, some games store pre-shifted objects in their main font and cycle through those animations to make something move from character cell to character cell - far quicker than the full on complicated sprites but better looking than just jumping a character at a time.
I see what you did there in ViColumn, you emphasized height without exceeding the character limit.
reduced the play area to a single 256 byte page in memory as well, so i've got a bit of extra memory in the remaining screen RAM that isn't visible to use as label space and moving the game itself is easier because i don't have to use indirect indexed addressing or self mod to access everything. =-)