More scale fixes.

[MattiasBuelens]

I was testing how the tool reacts to bigger screens, and found some issues.

• Transforming mouse coordinates was wrong. It just happened to work out for Black and Black 2, but no such luck for X. It turns out it was right after all, reverted. :stuck_out_tongue:
• Scale calculation should not be rounded. For example in X, main_scale will be 3.2 (1024 canvas width / 320 screen width), rounding to 3 here causes the rendering to be too small. Proper rounding is already implemented in scale(), so no worries about decimals suddenly showing up.

[hftf]

Instead of “reverse-engineering” the scale factor from the canvas dimensions and bounds, I would like to set the scale (to 4) and calculate the canvas dimensions from scale × bounds.

P.S. We should consider the implications of the wider screen (at 640 px instead of 512 px) on page layout/accessibility.

[MattiasBuelens]

4886038 uses the main_scale and mouse_scale values to configure the canvas sizes (coordinate space and screen space). I tried this out on my WIP for X, and I must say 640 by 480 is indeed fairly big.

[hftf]

Obviously this also affects all the small canvases (160 px instead of 128 px). I wonder if it's better to dynamically create two CSS rules (small and large) instead of looping through all the elements. Either that or “hardcode” the rules in a standalone stylesheet so CSS can be cached.

[MattiasBuelens]

Well, the canvas coordinate space cannot be modified through CSS (the canvas.width and canvas.height attributes). We still need JS code to do that.

We could dynamically create and add CSS rules to control the on-screen size of the canvases, yes. An alternative would be to add game-specific CSS stylesheets (e.g. data/x/style.css). (Bonus: that would also allow for game-themed styling of the tool with fancy backgrounds and colors. :stuck_out_tongue: )

[hftf]

If you're rebasing this anyway, why not squash out the revert? :put_litter_in_its_place:

[MattiasBuelens]

Good point, I'll cover up my mistakes. :stuck_out_tongue:

[MattiasBuelens]

Okay, it turns out the menu canvases are a bit more annoying than I expected. The width of .menu-heading .layers controls the width of .menu-heading, and that's what keeps all the .menu-lists properly aligned. Thus, we can't just set the width and height of the menu canvas, we also need to change the .layers and the .layers img...

I'll have a look at the CSS thing. :stuck_out_tongue: If we can dynamically configure 2 CSS classes for small and large, we can use those throughout the DOM where we need it.

[MattiasBuelens]

b8a1344 implements the dynamically generated CSS rules for .size-small and .size-large. Simply add that class to whatever element that needs sizing.

[hftf]

Obviously I haven't tried, but why not this?

var foo = document.createElement('style');
foo.innerHTML = '.size-small { width: …; height: …; } .size-large { width: …; height: …; }';
document.head.appendChild(foo);

[MattiasBuelens]

That'll work too. I kind of like using the DOM / CSSOM, but I guess it's kind of overkill to throw in an extra script for working with the CSSOM if you can do it with 3 lines with innerHTML. :stuck_out_tongue:

[MattiasBuelens]

There you go, e8a3fac uses innerHTML instead.