Mixing canvas with DOM

[Nicolas]

Hey all,

 

I've got a potential project coming up that's essentially five levels of simple gameplay, interspersed with promotional content from the project's client (screens of product imagery and slugs of copy appear between each level). There's also a high score requirement, so players will submit their scores to us upon completion of the game.

 

Mostly fine, but the mixing of Canvas and DOM is something that's yet to become clear. It seems obvious to use each to its strengths, but what then bridges the gap between the internals of the game and the outside DOM, particularly in terms of something like a form? Is it just a case of having things like onGameOver = function() {htmlModal.show()}, and making calls to the DOM from within the game logic? Are there any implications with this sort of thing (shifting focus away from the canvas, for instance)?

 

... Sorry if that doesn't read well, it's early doors for me. I'm currently trying to scope out the project to see whether or not I'm up to taking it on. It might be a good opportunity to step into HTML5 game development (the game itself is straightforward); though it might also be a step too far (it's everything around the game that appears to require consideration).

 

Cheers,

[d13]

Here's what I suggest:

 

- Use canvas as your game's rendering system. That includes sprites, dynamic text for scores, and title text.

- For anything text heavy, such as instructions or forms, use an HTML <div> above the canvas game. The reason for this is that HTML text is really easy to create, format and position.

 

The above would constitute your "game".

But then you've got a bunch of 3rd party stuff: Just use another HTML <div> layer for that.

 

You don't need to worry about about mixing HTML and canvas rendering.

As long as you design your game so that the data and logic are modular, you should be able to plug in any rendering system, or combination of rendering systems, that you need. 

[mattstyles]

Early specs and implementations for canvas involved interspersing it into the DOM in very small chunks.  There was even several versions of icon rendering using a canvas for each icon—it worked really well, if a little fiddly.  So, no, there arent any problems mixing DOM and canvas, or even multiple overlapping canvasses for that matter (keeping an eye on perf of course).

 

Infact, depending on your game the DOM makes a good choice for many UI elements.  Use CSS3 transitions (or some hacks exist) to make sure that if you are moving DOM elements around you're using the GPU and be careful about repainting the DOM too often, its easy to get trapped into repainting far far too much or even mixing CPU and GPU calcs for presentation layer and things can quickly get 'flashy' on devices.

[Gio]

It's all well and good until you need to scale your game to work with different resolutions.

 

It's fairly simple to, say, create a canvas-based game that works at a fixed resolution, then scale the canvas via CSS to fill the whole screen... but doing so with canvas and DOM elements at the same time can be quite challenging.