An additional observation: this might finally be an application for the Kaleidoscope?
On 5 April 2012 17:10, Simon Cooke <[email protected]> wrote: > I thought about doing something like this a while back, but as ever didn't > get chance to play with the idea. For me, the trick would have been to say > screw it and randomly/genetically generate the code required to change the > palette. On modern CPUs it shouldn't take more than a few hours to > generate/simulate even if you're brute forcing it. > > Now, of course, once you get to dithering the image and optimizing that, > you're starting to explode the solution space but it's not exactly > insurmountable. > > (I've got a 2 year old daughter and enough work to sink a battleship these > days, so unfortunately as much as I hate to say it, I think my SAM > programming days are done :'( ). > ________________________________ > From: Simon Owen > Sent: 4/3/2012 2:43 > > To: [email protected] > Subject: Re: SAM HAM viewer > > On 2 Apr 2012, at 23:58, Thomas Harte wrote: >> I think that used a tight loop of something like (i) load next palette >> index, >> next colour and next delay length; (ii) push colour to palette index; >> (iii) perform a busy loop of the desired length; (iv) repeat. > > That's closer the approach I was originally aiming for, but the conversion > is far more complicated. For a first attempt I restricted it to changing > the CLUT when the raster was outside the image, which still gives a > noticeable improvement over a static palette. > > My ideal approach would even eliminate steps (i) and (iii), and just use a > huge unrolled loop of OUTI instructions. That would update 1 CLUT entry per > instruction in reverse order, in a continuous loop. The converter would be > tracking a rolling window colours, with knowledge of colours no longer > needed and look-ahead to what can be set up in advance. It also needs to > understand the instruction timing, which varies across the scanline. > Thinking of implementing that still makes my head hurt! > > >> but you could instead, say, change a single palette index several >> times over the course of a single scan line, or anything in between. > > I considered individual CLUT updates for my current viewer, but it took too > much time away from the actual updating — the extra LD B,n needed costs > about the same has half an OUTI. Instead I grouped the dynamic colours > together and updated them with a small unrolled OUTI block. > > >> If you have portions of the image with only four colours (especially >> once the colour aliasing forced by the 128-colour palette is accounted >> for) then switching to mode 3 for a portion of a line could be the smarter >> thing to do, and would presumably cost basically nothing to implement? > > Unless you need the extra resolution, I don't think there's anything to gain > from using mode 3. It uses a subset of the mode 4 CLUT, so it doesn't help > with fast access to an alternative colour set. Or am I missing something? > > Si > > >
