improve Color cycling Speed range

[Thomas Bernard]

Color cycling speed can be adjusted from 1 to 64.
1 => 0.2856Hz
35 => 10Hz
64 => 18.2784Hz.

I think that dates back from MS-DOS times where GrafX2 color cycling code was based on the system timer at 18.2784Hz
But on today versions of GrafX2, the color cycling can work much faster, around 50Hz I think (every 20ms).

color cycled pictures are originating mainly from amiga and Atari ST which have 50Hz (or 60Hz) frame rate. Maybe the 70Hz 200/400 lines VGA mode should also be considered.
So I think there is no reason to limit the speed to 18.2784Hz

In fact, I've loaded a file with a color cycle set to 69Hz and everything works well when color cycling, except the slider in the GrafX2 GUI :)
(it's showing 242, but I can only lower it;)

So my proposition is to allow this slider to go from 1 to 255 ...

Or else we could also completely change the range used, but I don't think that would be very useful.

[yrizoud@…]

The ILBM spec didn't specify limits, so I matched the range of values that you can use in Deluxe Paint 2E. IIRC, when I tried going above 64 the image would load, but the cursor in the DP2 window would be outside limits, which I found unsafe.
I never tested with the Amiga versions of Deluxe Paint, so I don't know what limits they have/use.

[PulkoMandy]

The DOS version of GrafX2 did not have colorcycling support, it was added in version 2.3 released in 2011.

According to the original ticket (​https://code.google.com/archive/p/grafx2/issues/365) it seems we just used Deluxe Paint range and speeds so we can properly display existing pictures.

[Thomas Bernard]

Ok so that is DP2E for DOS that is using the IBM BIOS system timer at 18.2784Hz :)

I have added support for IFF CCRT color cycling range (I've found a lot of files with that chunk)
it was found in Commodore's Graphicraft before DeluxePaint introduced CRNG
you should test ​https://gitlab.com/GrafX2/pic-samples/blob/pic-samples/iff/color_cycling/Skier.iff which is set to 14.432ms period (69Hz) and really nice to look ;)

I was wrong the maximum slider value in GrafX2 is 105 which is 30Hz. Skier.iff is still faster than that.
If there is a limit in DeluxePaint, we should explicit this in the documentation, because the file format itself doesn't have this limit :
CRNG stores a word (limited to 32767 if "signed") with 16384 = 60Hz, 1=.0036Hz (1 step every 273 seconds ;), so maximum is 120Hz
CCRT stores microseconds, so theorically 1MHz is achievable ;)
The NEOChrome file format stores VBL periods (60Hz for US and 50Hz for European STs)
Degas File format also stores in VBL periods

[yrizoud@…]

From my older comment on googlecode (thanks for digging this up, it's funny how they anonymized the accounts and I think I got a luckier random nam), the current scale of values in Grafx2 should be the following :
Internally, Grafx2 stores Speed as the "speed slider" value, same as Deluxe Paint.
0 = stopped
1 = IFF 78 = 0.2856 Hz freq = 3501 ms delay
64 = IFF 4991 = 18.28 Hz freq = 55 ms delay
70 = IFF 5461 = 20 Hz freq = 50 ms delay
Above is not usable in Deluxe Paint 3 (?)
105 = IFF 8192 = 30 Hz freq = 33.3 ms delay
Above is not usable in Grafx2, slider only goes up to 105
210 = IFF 16384 = 60 Hz freq = 16.6 ms delay

No matter what scale you want to change to, be careful to provide a "granularity" that ensures things don't get out of sync when the user thinks he has set up exact multiples, such as 3/5. The current (Deluxe Paint) speed slider has the advantage that you can click at pixel 70 for one speed, and click at pixel 7 for a cycle that is exactly ten times faster, or 10 for something that is exactly 7 times faster. Numerically, the user can double-check when all his cycles are synchronized, by finding the smallest multiple of all cycles.

[Thomas Bernard]

hi, Massive Horse ! ;)

My plan is to let the internal working unchanged, but only allow the slider to go beyond 105.

maybe DP3 is capped to 30Hz because of interlaced mode

[yrizoud@…]

This sounds sensible. If you haven't touched sliders yet, be wary of sliders scale in clickable pixels vs how many different values they represent. The engine will work no problem with any values you assign, but the user experience is slightly marred when you displace the cursor by one pixel and it "randomly" modifies by 1 or 2. 1pixel=1value is best, if you don't have the space and want 200% values, it's best to have something like X pixels representing X*2-1 values (one unclickable value is between two clickable values, so one pixel move is ALWAYS +/-2)

If you need to reorganize the screen, can you please see if there can be room to show the corresponding frequency / millisecond duration ? I think both are interesting, depending on situation.

[Thomas Bernard]

I understand what you mean.
I just noticed that today there is 1 missing pixel : value 0 and 1 have the slider shows at the same place, but then from 1 to 105 all values are clickables.

[Thomas Bernard]

Replying to Thomas Bernard:

I understand what you mean.
I just noticed that today there is 1 missing pixel : value 0 and 1 have the slider shows at the same place, but then from 1 to 105 all values are clickables.

nevermind, I broke something while testing ;=)

[Thomas Bernard]

preview

[Thomas Bernard]

​https://gitlab.com/GrafX2/grafX2/merge_requests/147