Faster fade out code?

[touko]

Oh, I didn't realize it needed to be a global. That is 2k of ram dedicated just to fadeout then...

Why 2k ??
You really need 1k,but in fact less, because all the palettes are rarelly/never used at the same time .
i think a 6 palettes buffer is enough, it's 192 bytes,and this should speed up a lot your fade routine(because no need to copy/fade unused palettes) .

[Bonknuts]

Some PCE games just have pre-compiled fades for palettes. Sure, it takes up rom (not a whole lot though) but it doesn't need any ram.

[Arkhan]

The trick is to write one fade routine.  It's not a fade in or a fade out.  It's a "fade to this palette" routine.

It will work for fading to black, or for fading to a color.    Just make sure you pay attention to the way PCE lays out a palette, and inc/dec accordingly.    It's a little easier if you work with octal number formatting.  It seems more intuitive that way.

I do this and use a work palette (the current screen palette), and a target palette, and simply fade to it, and copy when ready.

[touko]

The trick is to write one fade routine.  It's not a fade in or a fade out.  It's a "fade to this palette" routine.

Yes i did this too .
You can fade from/to a palette,and for exemple a fade out is concidered as fade to a black palette.

[Bonknuts]

Yeah, a fade "to". Not that anyone probably cares, but there are weighted and unweighted fade methods (as in R/G/B elements as they reach a target value). Obviously weighted takes more time, but looks better for fades to black or from black IMO.

  And if you're ambitious enough, you can even do real time RGB->YUV, make changes, and then back again for additional effects. Though that's probably more fancy than practical - "look what I can do" type effect.

[touko]

Obviously weighted takes more time, but looks better for fades to black or from black IMO.

I fade each RGB values,and not a single inc/dec for the whole color .

[Bonknuts]

Obviously weighted takes more time, but looks better for fades to black or from black IMO.

I fade each RGB values,and not a single inc/dec for the whole color .

Yeah, but do you use a fixed point value (8bit:8bit) for each R/G/B element? That's what I mean by weighted. Otherwise, you'll get to the target value of each R/G/B faster on one element vs the others. I.e. it's not uniform across all elements within a color slot's R/G/B system.

[touko]

Yeah, but do you use a fixed point value (8bit:8bit) for each R/G/B element? That's what I mean by weighted.

No,no mine it's more simple, better than a simple inc/dec,but definitely not as advanced as that you call weighted .

it's not uniform across all elements within a color slot's R/G/B system.

Yes , but very acceptable .
For best result with a RGB fade, you must normalise all the values, before fading .

[Arkhan]

Weighted "looks" better, but in practice is never noticeable to anyone playing a game. 

I put in a weighted one into Inferno and ended up not using it.

[elmer]

Weighted "looks" better, but in practice is never noticeable to anyone playing a game.

That's been my experience, too.

If the fade is running fast-enough that people aren't given the time to stare at and analyze each individual step, then you can actually get away with a really-simple algorithm and find that it still looks good on the screen (as in, I've never, ever, heard anyone complain about it).

[Arkhan]

Atlantean's fades aren't weighted IIRC.   They just do your basic "fade each color til it gets where it needs to be".

People claim it "makes things go grey", but, whatever.

[elmer]

People claim it "makes things go grey", but, whatever.

Yep, that's the simple way of doing it that I got away with for many years (until hardware fades took over). 

If I ever wanted to be "clever" and do it properly, then I'd probably use the classic integer version of the Bresenham line-draw algorithm to decide when to change each RGB component.

[Bonknuts]

That's basically what I was referring to with the fixed point values (a tiny LUT for a bresenham line algo).

 Sometimes you just write stuff.. just because you can. I think most fade to routines don't need to be done in realtime gameplay (i.e. end of stage, or transition into another area, etc - where the action is paused). At least from what I've needed it for, but I can see some situations were it might be needed in game during normal gameplay. I always just used recalculated subpalettes for that, but I guess if you setup a background process system or "thread", you could call such a routine a head of time and have it do the fade steps as needed (kind of like a background timed-sliced decompression process).

 Arkhan, did you use the fade routines while the gameplay was in action, or did you pause the action and use the fade as a transition? Just curious.

[Arkhan]

Atlantean fades while SOME stuff is happening on screen.   I am pretty sure the fades will work mid-game, though.

Most of the fading was for transitioning, though.   No point in fading mid-game in a shootything

Reflectron had a bunch of palette cycling during the entire game.

[DarkKobold]

I think the best way for optimising your routine is doing the fade in a buffer for all palettes and transfer all the buffer after a vsync in asm with a tia bloc transfer .

like that:

/* A 256 bytes buffer is enough for 8 palettes */
int my_buffer[1024];

#asm

   stz $402
   stz $403

   tia _my_buffer , $404 , 1023

#endasm

My fade routine is close to yours, and is very fast,but in ASM .

So, I'm really confused.

First, why the store zero in $402 and $403?

Second, if I want to split this into chunks of 64, how do I tell it $404 plus 64 etc?

This is why I hate assembly. I know, I'm definitely the idiot of the thread.