Researching Existing Engines
We also spent some time researching existing HTML5 3D renders, which again, did not do everything we needed.
This is nice and fast, but it uses a lot of assumptions, like a fixed camera angle.
Most of the actual HTML5 3D engines are done in WebGL, which is unfortunately not supported in many places, especially Android web browsers.
|Screen from the final game|
Another issue we ran into was handling objects that move and scale beyond the bounds of our screen. Depending on the particular browser, this could cause the entire screen to shift (especially when trying to accommodate negative values), or to simply have parts of the sprite draw off to the side when it should be clipped. After running through a number of solutions, including provide a masking HTML element so we could just hide the overflow, we eventually stumbled on the idea (via random Internet forums) of having the sprites be composed of two elements: an enclosing DIV element and the actual IMG element. We could then move the DIV to the extents of the screen, and if the sprite needed to go further, we could alter the IMG's margins, which would contain its effects inside the DIV and also hide the overflow (with the CSS overflow: hidden property).
For the HTML5 canvas itself that we used for 3D rendering, we confined our actual rendering to flat polygons. The canvas allows for drawing arbitrary paths along a set of points, and then either rendering just the path itself, or filling in the enclosed region. This gave us the flexibility to draw a bunch of arbitrary shapes for the road, but limited us in drawing actual 3D objects, because we did not build in any z-sorting.
Coming up next, architecting the source code and dealing with the game loop and performance.
Good to see the details here about the html 5.ReplyDelete