Look-up table with 256 or 128 entries (if you don't need to fade FLASH attribute). Each frame of fading process each attribute must be changed to another. So, you can take current attribute as pointer in look-up table and get new attribute from table.
Look-up table will contain something like (offset, value):
0 0 (black will be black in next frame)
1 0 (dark blue ink will be black next frame)
2 0 (same for dark red ink)
3 1 (dark magenta will be blue next frame)
And so on.
Main loop will looks something like:
;look-up table aligned to 256 bytes, MSB in D
;HL=screen attributes
ld e,(hl)
ld a,(de)
ld (hl),a
inc l
This code must be repeated 32 or so times (depends how much memory for this you have), then loop counter decrement and inc hl (to cross 256 bytes boundaries). This way you'll get very high speed in trade of some memory. If you need even faster code, you can use stack to read or write attributes.
edit: sorry, my bad, I misunderstood 'fade-up' as 'fade-out', not 'fade-in'. Fade-in with smooth transition will require much more memory (I think you mean that by 'prerendering' - 128*steps of fade-up) or will be really slow.
A slight variation on the above might work, but you'd need a look-up table for each frame and a copy of the final image stored elsewhere. What you'd have to do would be to scan through the original image (rather than what is in the screen RAM) and see what a given attribute ought to have changed to for that particular frame.
e.g.
Frame 1:
0 0
1 0
...
6 0
7 0
etc.
Frame 2:
0 0
1 0
...
6 0
7 1
etc.
Frame 3:
0 0
1 0
...
6 1
7 3
etc.
...and so on for the remaining frames.
This isn't going to be nearly as quick as pre-rendering though.
Aha, so pre-rendering probably is the only solution then. Well hopefully I can use compression to reduce the overall size.
Wait a minute, I think my memory is playing tricks on me. Didn't the other thread have a solution in it too?
It depends on how fast you want it. Doing it by table lookup will certainly be fast enough for a normal Spectrum screen; it'll just be a bit sluggish for the TS2068 mode but might still be fast enough for your purposes and you could always consider cutting a frame or two out if it isn't.
That's a fade-out. It decrements the ink and paper for each attribute until it has cycled through enough times to fade to black. but it goes: 7 6 5 4 3 2 1 0, whereas it would look nicer if it went 7 5 6 4 2 3 1 0. A fade up is trickier because if you cycle in the opposite direction you just end up with an all white image, when what you want is to fade only as far as the desired colour for each paper, and ink.
The last posts in that thread are about fade up. Same as described by Shriu here. Notice it was written from top of my head, so no guarantee it works instantly.
Comments
Look-up table will contain something like (offset, value):
0 0 (black will be black in next frame)
1 0 (dark blue ink will be black next frame)
2 0 (same for dark red ink)
3 1 (dark magenta will be blue next frame)
And so on.
Main loop will looks something like: This code must be repeated 32 or so times (depends how much memory for this you have), then loop counter decrement and inc hl (to cross 256 bytes boundaries). This way you'll get very high speed in trade of some memory. If you need even faster code, you can use stack to read or write attributes.
edit: sorry, my bad, I misunderstood 'fade-up' as 'fade-out', not 'fade-in'. Fade-in with smooth transition will require much more memory (I think you mean that by 'prerendering' - 128*steps of fade-up) or will be really slow.
e.g.
Frame 1:
0 0
1 0
...
6 0
7 0
etc.
Frame 2:
0 0
1 0
...
6 0
7 1
etc.
Frame 3:
0 0
1 0
...
6 1
7 3
etc.
...and so on for the remaining frames.
This isn't going to be nearly as quick as pre-rendering though.
It depends on how fast you want it. Doing it by table lookup will certainly be fast enough for a normal Spectrum screen; it'll just be a bit sluggish for the TS2068 mode but might still be fast enough for your purposes and you could always consider cutting a frame or two out if it isn't.