Added FLI bad line bug processing and misc

[robin-raymond]

In FLI mode, the VIC chip is forced to reload color data per raster line. The issue is that for the first 24 pixels there's no color data available, leaving terrible grey, orange and the background as the only choices available. This code is able to factor this limitation during the dithering process in an attempt to do the best job given a bad scenario.

Alternatively, the settings can be enabled be changed to "fill" the bad line area with background (reducing the draw width by 24 or 48 pixels in the process).

Misc: -reverted logic that stops processing color block after certain iteration count as it can pick colors that it shouldn't instead using the color block (and the new logic does a better job)

• improvement: speed was made faster regarding the recalculation of the color block when the first pixel of the first row of each block is calculated thus ensuring the color blocks are always calculated first
• improvement: The multi and multi FLI code are merged since the logic is cabable or performing both jobs
• fix: the chocie of border and background colors were not being stored and loaded properly in the assembly example
• fix: blanking of an area in FLI was not correctly choosing the background color if any pixel index had the same color chosen (which can happen in FLI mode since color choices are limited)

[robin-raymond]

The reason I removed the short stop of the color block calculations early is because I think it will lead to issues (because false will cause the color block choice to be eliminated instead of chosen). I'm going to re-test that thoroughly, and merge it with Hires graphics (because Hires FLI will need same code), then it will do the same logic you to cut color block calculations after a certain number of iterations (because I agree, it's a good idea).

[robin-raymond]

I just noticed the VIC-20 derives from the VICII multi class. I need to test this!

[robin-raymond]

Hmm, nothing uses that code so I guess I'm safe ignoring it? I suspect this was for the future? I could likely get it working if I read up on the tech specs of the Vic 20 but that's for a future date.

[sehugg]

I don't even remember what I was planning with the VIC-20, I never got the emulator working quite right in 8bitworkshop so I shelved it. I think it relies on redefined characters, nothing as interesting as FLI modes afaik.

[robin-raymond]

Yes, Vic20 doesn't have a bitmap mode but you can redefine the character set and adjust the screen width/height, and it's memory mapping is pretty flexible given it's age. I could add a Vic 20 graphics mode but without an emulator / assembler there's no good way to link to an export + preview + demonstration. That feels disjointed so many that should wait until an emulator exists for it. There are tricks for the Vic 20 for expanding the display.

Good resource here: New Frontiers in VIC-Hires-Graphics-Series and for Changing the screen memory mapping and even Wikipedia has some good descriptive info