Back under the hood once more

It occurred to me that I had gone more than a week or two without diving back into engine code to crank around at its inner workings, so it was probably time to fix that. Well, more accurately, I decided that I wanted to be able to test things out on my tablet devices and the code that I had wasn’t quite there yet, so I thought I’d tweak it up a little bit.

So I set out on an epic quest to try and make a canvas appear at a position and size of my choosing on an HTML page, hoping that some how, some way, the mystic art of laying out something in a web page had somehow gotten more intuitive. Alas.

This is actually something that I’ve been pondering for a little while now. Back when I wrote the original page template (using Bootstrap) and tested to make sure that things looked more or less correct on all of my devices/browsers/screens, I noticed that the page worked just fine, but the canvas, being specifically sized, was the outlier. Plus that whole thing regarding the phone having no keyboard or mouse.

As time has gone on, I’ve been more interested in doing some testing on tablets (also useful for getting in house guests to test things out!). What really goosed me over the line is how, while testing ts-breakout, I keep moving the mouse outside of the canvas, which stops mouse input and thus gets in the way.

So I set out to modify the code so that the canvas will resize itself to make itself as big as is possible for the constraints of the screen as well as maintaining its aspect ratio. I also thought it would be nice to be able to go fullscreen as well.

For the most part, my goal is now complete, although the code requires a bit more tweaking before I’m happy with its state. By far the easiest thing to do is calculate the size of the window, determine how large the canvas can be while maintaining aspect, and sizing it to that size. What is more difficult is getting the HTML/CSS to cooperate in laying the page out.

I remain amazed at how CSS has advanced to the point where, if I wanted to, I could annoyingly animate things bouncing around the screens, changing their corner radii to be more or less circular, but saying “put this box right in the middle horizontally and vertically” is still some sort of arcane voodoo.

Nevertheless, I was successful, and my tests on various phones and tablets seem to indicate I’ve done something right. I’m hooked into the resize and orientation change events, so that the canvas is dynamic. I’m still working on the fullscreen portion, but I don’t anticipate any problems with that (famous last words!).

I also have some primitive logic in place that captures touch events and converts them to mouse events, so that (except for keyboard controls) things still work. More needs to be done in this regard in order to make the fake mouse events work the same as the originals do (e.g. my mouse handler stops handling mouse movement if the cursor is not inside the canvas, but the touch does not).

What I still need to play with a bit is the manner in which I’m doing the scaling of the canvas. Right now I have the canvas rendering size fixed, and the CSS scales the canvas up or down as appropriate. On one my (admittedly older) android tablets, the result is a very poorly scaled image. I assume I could get better fidelity by not scaling the canvas size and instead changing the scale factor of the rendering, but I don’t know.

I’m not sure how much I really care about that particular aspect, since for most of my use cases, the way I’m doing things works just fine. I feel like going the other way would make me want to dynamically select different image sizes (or just make them higher resolution in general?) to make things look nicer, and then *boom* I’m too far down a road that doesn’t lead anywhere interesting for simple prototypes.

Here’s a simple screenshot showing how things are looking currently on an iPad. Unlike most images on the blog, this one links to a higher resolution image.

iPad collision test screenshot

Collision test code running on an iPad