Colors?

[Glitchfinder]

I'm trying to make a custom transition script, and have run into a problem. Specifically, cycling through every possibly color and changing it to something else. I know that this kind of thing will create impossible amounts of lag for most systems, but I plan to use it on other ways.

So, is there any simple way to cycle through every possible color? Or, if not, how would I go about doing it? I can post the bit I do have for reference, if you guys need it.

Please note that it is not cycling through ever possible color at the same time, but through every possible color between a a range of values, say Color.new(0, 0, 0, 255) and Color.new(30, 30, 30, 255), where it gets ever possible color between those values.

 

[Brewmeister]

You need to be a bit more specific. If the first value is (0,0,0), what is the second value? etc...

If you define the pattern, we can come up with an algorithm.

Be Well

 

[Glitchfinder]

You need to be a bit more specific. If the first value is (0,0,0), what is the second value? etc...

If you define the pattern, we can come up with an algorithm.

Be Well

I think i've got it. Keep in mind, it would be incredibly slow in RPG Maker XP. What I did was take the starting value for red, and test every value for green for that value, while testing every value of blue for that green. (And each value would max out at the high-end of the testing rang of values)

This took over 2 hours to test in RMXP, and I run XP with 4gb of RAM.

  def update_transition

    unless @frames <= 0 

      frames = @frames

      @shade = (@shade * (frames - 1) + 255) / frames

      @previous_shade = @current_shade

      until @current_shade == @shade

        @current_shade += 1

        color = Color.new(@current_shade, @current_shade, @current_shade, 255)

        recolor_c(Color.new(0, 0, 0, 0), color)

      end

      

      Graphics.update

      Input.update

      

      red = @previous_shade

      until red == @shade

        red += 1

        green = 0

        until green == @shade

          blue = 0

          until blue == @shade

            color = Color.new(red, green, blue, 255)

            recolor_c(Color.new(0, 0, 0, 0), color)

            blue += 1

          end

          green += 1

          Graphics.frame_reset

          Graphics.update

          Input.update

        end

        Graphics.frame_reset

        Graphics.update

        Input.update

      end

      

      Graphics.frame_reset

      Graphics.update

      Input.update

      @frames -= 1

    else

      return

    end

  end

Please note that this is intended to be tested with bwdYeti's bitmap.dll file, and is included within his version of the bitmap class. The excessive Graphics.update calls are simply intended to prevent the game to give a script is hanging error while testing, and will be taken out when I compile a version of this test in c++.

 

[Brewmeister]

Hmmmm, by my calculation it should have taken almost 5 days.

16.7 million possible colors / 40 frames per second / 60 seconds per minute / 60 minutes per hour / 24 hours per day = ~4.8 days.
That's assuming a frame rate of 40, and cycling from Color.new(0,0,0,255) to Color.new(255, 255, 255, 255)

It looks like all but one of your Graphics.update statements are redundant. Try just one update at the deepest level loop (blue). This will update after every color change. Then try moving the update up one level (green). This will only update every 256 color changes, or once per green change. ...

The algorithm, in general, that you used (nested loops) is the most efficient way to cycle all 16.7 million colors.

I guess the biggest question is, why in the name of Bob would you want a 16.7 million frame transition?

Try other transition types. Like a direct fade where all 3 colors gradually transition from the starting to ending values simultaneously. Or a stepped transition where each color fades from start to end individually. You could also get creative and use the transparent value as well.

Be Well

 

[Glitchfinder]

Hmmmm, by my calculation it should have taken almost 5 days.

16.7 million possible colors / 40 frames per second / 60 seconds per minute / 60 minutes per hour / 24 hours per day = ~4.8 days.
That's assuming a frame rate of 40, and cycling from Color.new(0,0,0,255) to Color.new(255, 255, 255, 255)

It looks like all but one of your Graphics.update statements are redundant. Try just one update at the deepest level loop (blue). This will update after every color change. Then try moving the update up one level (green). This will only update every 256 color changes, or once per green change. ...

The algorithm, in general, that you used (nested loops) is the most efficient way to cycle all 16.7 million colors.

I guess the biggest question is, why in the name of Bob would you want a 16.7 million frame transition?

Try other transition types. Like a direct fade where all 3 colors gradually transition from the starting to ending values simultaneously. Or a stepped transition where each color fades from start to end individually. You could also get creative and use the transparent value as well.

Be Well

Actually, it took a lot less time because I put it in a loop. The loop supersedes the default framerate, and will run wild for ten seconds until the game shuts down. I added the redundant calls because they avoid shutting the game down automatically by calling Graphics.update within the requisite ten seconds. As to why I'm doing this? I'm trying to figure out how to replicate the default transitions, like theory. I also figured out a much easier way to do this, that is much less time consuming. Since I'm making a .dll file to do this, and am not limited by Yeti's .dll file, I realized that I could easily rewrite the function to only check to see if each pixel had all three colors below a specific level, instead of telling it to change every single color under the rainbow. So, instead of the .dll file resulting in the program giving out a not responding error, I result in a quick, painless, albeit sharp-edged and oddly timed transition.

As to the other methods of doing transitions, I've tried several methods, which were all less efficient or didn't catch every color. And, as for adding alpha transparency? That shifts it from 16 million colors to a total of 4.29 billion colors that I would have to test. I made my .dll file ignore transparency, and instead only look at the actual color values instead.

Also, thanks for the helpful commentary. That really does help people, and not just me, but anybody else with the question.