So far we know how the notes are displayed inside the measure but not how the measures are displayed as a whole, the notes position inside the measure is independent from the hi-speed, but the measure size( only height actually) is direct affected by the hi-speed.
On o2jam, the native resolution is 800×600 but not all of those 600 pixels are used for the notes( we got the interface, etc).
I found that the usable space, that is, the area where the notes falls, is 480 pixels and, at 1x hi-speed, each measure is 384 pixels, the hi-speed multipliers are direct applied at the measure size, so at 3x the measure is 1152 = 384*3.
We could stop here already, but I don’t think 800×600 is good enough anymore, but we can’t just use the absolute values, since it wouldn’t be using the extra space at all then, and making the usable space bigger would give some sort of advantage.
We need to maintain the scale of the usable space at any resolution, we need to use the ratio:
480/600 = 0.8, so the usable space is 80% of the screen size !, and..
384/480 = 0.8, coincidence or not, the measure at 1x is also 80%, but of the usable space.
then we can apply the hi-speed multipliers at the ratio instead.
e.g.: at 0.5x each measure is 40% of the usable space, and at 5x it is 400%(4 times) the usable space.
Following this, we can scale the measures at any resolution, example with 1024×768:
768 * 0.8 = 614(.4) pixels of usable space.
0.5x -> 614 * 0.4 = 245(.6) pixels of measure size.
1x -> 614 * 0.8 = 491(.2) idem
2x -> 614 * 1.6 = 982(.4) idem
… and so on.
Note however that depending of the screen size the scale won’t be perfect, since we can only have whole numbers for pixels.
So is it over now ? Nope. There’s still one variable not accounted for. The BPM. Which I’m guessing it isn’t relative to any other thing. That is, a magic number that determines how much of a measure moves in a second. But I think it isn’t a direct mapping, there should be some ratio here.. how much that is the question..