It is currently Wed Nov 22, 2017 4:22 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Gradual color change
PostPosted: Mon Sep 25, 2017 10:27 am 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 211
DRW wrote:
What does the programming language have to do with it?

The math involved is kinda hairy. Though, I guess it comes down to personal opinion and the amount of transitions you're gonna have.

Anyway, here's some example code: http://coliru.stacked-crooked.com/a/7c14ab65a73ca806

If I had to do it in assembly, I would just do a 5-step lerp between the values and call it a day:
Code:
frame1:
lda pal1, y
sta pal_buffer, y
rts

frame2:
lda pal1, y
asl
adc pal1, y
adc pal2, y
ror
lsr
sta pal_buffer, y
rts

frame3:
clc
lda pal1, y
adc pal2, y
ror
sta pal_buffer, y
rts

frame4:
lda pal2, y
asl
adc pal2, y
adc pal1, y
ror
lsr
sta pal_buffer, y
rts

frame5:
lda pal2, y
sta pal_buffer, y
rts


Top
 Profile  
 
 Post subject: Re: Gradual color change
PostPosted: Mon Sep 25, 2017 11:02 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7272
Location: Chexbres, VD, Switzerland
pubby wrote:
If I had to do it in assembly, I would just do a 5-step lerp between the values and call it a day:

But this won't work at all, because the palette is not "linear".


Top
 Profile  
 
 Post subject: Re: Gradual color change
PostPosted: Mon Sep 25, 2017 12:08 pm 
Offline
User avatar

Joined: Thu Mar 31, 2016 11:15 am
Posts: 211
Oh! You're right. This is why I wouldn't do it in assembly :P

The hue would have to be separated from the value and both interploated (which was said in this thread I'm just dumb)


Top
 Profile  
 
 Post subject: Re: Gradual color change
PostPosted: Mon Sep 25, 2017 2:22 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1464
In my opinion, the programming itself is really secondary here. Once I get to actually implementing it, I will write the algorithm and then try to optimize it.

The code that you linked to is not really something that seems to apply to my own attempt. I would not work with any kind of RGB color at all and I wouldn't have any lookup tables.

I would simply do the following:

For all 16 (or 13, depending on what's faster) colors, do the following:

Take the current value.
Take the new value.
Take the high nibble of each.
Calculate the way that has to be walked from one color to the other to reach the other one.
The values in this case go from high nibble 1 to high nibble C (not 0 to F). This has to be taken care of.
Calculate how many scrolling frames we will have and calculate scrollingFrames / colorSteps to find out after how many frames the color needs to be adjusted.

Do a similar thing with low nibble, i.e. brightness.

And then apply the colors during the correct scrolling frames.

This takes 16 x 6 bytes in RAM that have to exist beyond function calls:
For each color:
The current value.
The destination value.
Indicator whether the high nibble is incremented or decremented.
Indicator whether the low nibble is incremented or decremented.
The number of frames until the high nibble is incremented or decremented.
The number of frames until the low nibble is incremented or decremented.

Maybe some more values for special treatment of gray to color and color to gray.

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
 Post subject: Re: Gradual color change
PostPosted: Tue Sep 26, 2017 7:19 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7272
Location: Chexbres, VD, Switzerland
Quote:
The question is just: How could we treat transformation from and to the grayscale values?

Quote:
Maybe some more values for special treatment of gray to color and color to gray.

My $2 : If you want to do it "the NES way", usually simplicity is to be preferred over exactitude. Not that this is a technical limitation or anything, but if there's a way to do something in a simpler way even though it's technically "false", but still does the job, it's common for 80's games to take this path.

This is why I first mentioned cycling hues in a fixed direction, regardless of the values. This also has the advantage of handling the special case of hue=0, as it'll jump to either hue=C or hue=1 without any additional code. The disadvantage is that this does not take the shortest parth, for instance if your preferred direction is increasing hues, and you want to switch from hue=6 to hue=5, you'll rotate through the whole palette instead of going there directly. It's still a gradual change of colour, but the effect is different. Final Fantasy 1 does exactly that when entering in the menu or a shop.

If the shortest path is calculated I'd suggest treat "0" as a normal hue and make it jump to "1" or "C" column, to eventually reach the destination column, is probably closer to the "NES" way to do it, rather than having extra code for that particular case. Extra code does not seem to be avoidable if gray column or black is the target colour, though, but I believe the normal algorithm can extend rather naturally to those colours if used as start colours.


Top
 Profile  
 
 Post subject: Re: Gradual color change
PostPosted: Tue Sep 26, 2017 7:57 am 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1464
Yeah, I really have to see which version I take. I don't know if taking a fixed direction is really something I want to have, even if it's shorter. I'll ave to see what it looks like, which won't happen in the next weeks since I first have to program more important stuff.

I also thought about treating column 0 as a regular column, in the way that the color gray moves through blue and cyan, which might look pretty natural.
Although, in this case, I would still skip column 0 whenever non-gray colors are concerned.


Are there any other NES games that use gradual color changes to switch from one region to another? (Games that simply use this technique to fade out an image to a solid black don't count.)

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
 Post subject: Re: Gradual color change
PostPosted: Tue Sep 26, 2017 8:46 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7272
Location: Chexbres, VD, Switzerland
DRW wrote:
I also thought about treating column 0 as a regular column, in the way that the color gray moves through blue and cyan, which might look pretty natural.
Although, in this case, I would still skip column 0 whenever non-gray colors are concerned.

Yeah, exactly what I meant. Sorry if that wasn't clear.

Quote:
Are there any other NES games that use gradual color changes to switch from one region to another? (Games that simply use this technique to fade out an image to a solid black don't count.)

Ninja Gaiden 3 have this effect on the status bar when you loose a life.

Mega Man's ending have an animation with the sun setting down, however I doubt the palette values are not simply pre-calculated.


Top
 Profile  
 
 Post subject: Re: Gradual color change
PostPosted: Sat Sep 30, 2017 2:59 pm 
Offline
User avatar

Joined: Sat Sep 07, 2013 2:59 pm
Posts: 1464
Bregalad wrote:
Ninja Gaiden 3 have this effect on the status bar when you loose a life.

But the status bar is just an abstract collection of letters and numbers. You can apply any color to it anyway.
But in "Ninja Gaiden", you don't have a source palette and a destination palette and then a bunch of in-between palettes that you can analyze to find out what algorithm they used to turn the dark yellow of screen 1 into light pink of screen 2.

Bregalad wrote:
Mega Man's ending have an animation with the sun setting down, however I doubt the palette values are not simply pre-calculated.

Yeah, that's not the same situation anyway: You have a single scene and this scene is shown in different colors that are all valid scene colors: Every shade really represents a certain time frame of the scene.

But my situation is: You have two different actual color palettes. And now the game gradually switches between both palettes by shortly showing intermediate virtual versions.
These intermediate versions are not supposed to indicate that the scene ever looked like that.
(If I have a green plant in one screen and a purple roof in another screen that simply occupies the same index in the palette, this doesn't mean that the roof was ever brown, just because my scene switch effect cycles through these colors.)

That's not the same as in the "Mega Man" ending where every shade is supposed to be a full representation of the scene at a specific point in time.
So, there's nothing to analyze here, from an algorithm point of view.


And the color change in "Final Fantasy" when entering the menu or a shop is just some general color cycling before the screen completely fades to black. The source colors don't transform into destination colors, they simply blink a bit before everything goes dark and a completely new, unrelated scene is created from scratch.


I would need something like this, but in an NES game:
http://www.youtube.com/watch?v=YzEU19PUVuE&t=13m19s

_________________
Available now: My game "City Trouble".
Website: https://megacatstudios.com/products/city-trouble
Trailer: https://youtu.be/IYXpP59qSxA
Gameplay: https://youtu.be/Eee0yurkIW4
German Retro Gamer article: http://i67.tinypic.com/345o108.jpg


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ]  Go to page Previous  1, 2

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 10 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group