Enter frame delay as FPS in addition to ms

[GoogleCodeExporter]

Ideally the frame delay input popup would feature a frames-per-second input box 
alongside the existing ms one.

This way the equivalent of whatever you input in one box would be shown in the 
other one (so say a fps input of 60 would be 1000/60=16.666*, rounded to 16 or 
17). 

Internally it would still work in ms, this would just be user friendlier, as 
both games and animations usually operate with frames per second.

Original issue reported on code.google.com by ilija.melentijevic on 3 May 2012 at 1:59

[GoogleCodeExporter]

I think I should provide a global 'unit' that gets shared for the whole 
animation, and then each frame's duration is an integer multiple of this unit.
ie. If you say your animation is in 1/60s, a single frame can have a duration 
of 1/60s or 2/60s, nothing in-between.

Now I need to find a way to reload this correctly from a GIF file that stores 
durations in 1/100s, it's very imprecise...

Original comment by yrizoud on 3 May 2012 at 9:49

• Changed title: Enter frame delay as FPS in addition to ms

[GoogleCodeExporter]

Wouldn't this be limiting compared to any number of ms that we currently have?

I'm thinking, store everything in ms as you currently do (and as gif does), 
just make this other box that would convert FPS input to ms. You can always 
tweak ms by hand if it rounds it out differently from what you want. It'd be 
simple, and it would work.

Original comment by ilija.melentijevic on 4 May 2012 at 12:59

[GoogleCodeExporter]

It's not limiting since you can always set the unit to 1000 (millisecond)
I'm surprised by your demand, from all I could find in other programs I felt 
the real cases were for example when you have a frame with duration 4/100, you 
can shorten the duration to 3/100 or lenghen it to 5/100. You never have cases 
of mixing frames of 1/60s with frames of 1/40s.

Original comment by yrizoud on 4 May 2012 at 8:50

[GoogleCodeExporter]

It seems there is some confusion...

Let's say I know that the game works at 60fps. I will then enter frame delays 
as 60,30,15,7.5 fps etc. They immediately show as ms as well.
If my game operates at 50fps I will set delays as 50,25,12.5 etc. Simple.

The margin for error is 1 ms, which is negligible.

If I understand your suggestion correctly, it consists of inputting more 
numbers, that is, for having a fps of 50 and then 25 I would input 50 (master 
fps) and then 1 and 2 (individual frame delays measured in master fps).

This method has the disadvantage that it's hard to guess the master value from 
loaded milliseconds. With first method FPS=1000/frame_delay_in_ms.

I would have no problem at all with working with what you suggest, I was just 
trying to keep it simpler to implement

Btw, old Amiga programs only had one value which was FPS, if you wanted a frame 
to stay longer, you would duplicate it! In that regard we are already more 
advanced in GraFX2 :)

Original comment by ilija.melentijevic on 4 May 2012 at 10:39

[GoogleCodeExporter]

More numbers: More data yes, but less typing in the end. With my idea, you'd 
type the time unit "60" once, and never change it. Then for individual images' 
durations, instead of typing numbers like "117" you type single digit "7" (7 
60th of seconds = 116.66 ms)

Original comment by yrizoud on 4 May 2012 at 2:48

[GoogleCodeExporter]

Deal! :D

Original comment by ilija.melentijevic on 5 May 2012 at 2:53

[GoogleCodeExporter]

The "frames per second" unit implies there are multiple frames :).
"milliseconds per frame" can work on a single frame.

So, the idea of setting a global "milliseconds per tick", then a number of 
ticks for each frame, sounds good to me. Ideally the default tick should match 
the vsync frequency, but I think we can't get this one from SDL...

Original comment by pulkoma...@gmail.com on 10 Jun 2012 at 8:06