Canvas Query 1.0

[Rezoner]

CanvasQuery - an extended canvas for gamedevelopers

 

Playground - out of box - mouse, keyboard, scaling, gameloop and a layer to draw on.

 

Documentation and download

 

-- 

 

CanvasQuery is a solution that I've been using since for 2 years to develop my games - some of which has been commercial success featured in bundles and press titles like RockPaperShotgun or PCGamer.

 

It's targeted to developers who like to roll-out their own solutions regarding engine mechanics. It does NOT provide entity systems, sprites, collisions e.t.c - it just takes care of loading assets, drawing surface and user input such as keyboard or mouse.

 

The main focus of the project are native applications (desktop, mobile) and cutting edge browsers - reasonable platforms to deploy "full scale games" - hence it plays well with node-webkit and CocoonJS.

 

It's been around since a while - but I have leveraged the version number to 1.0 which means no API changes are allowed and that I have tested it in real-world applications.

[Felipe]

Cool! I like this. I was working on something similar but your's look more complete than mine.

I was thinking on doing something similar but also supporting WebGL.

Thanks!

[Rezoner]

I would love to see the same API for WebGL - however community familiar with OpenGL told me that the architecture is so different that it would not be beneficial to implement it in such way - but then - CocoonJS is using OpenGL with Canvas API and it works great. Confused

[Felipe]

It wouldn't be a performance boost as PIXI. But I've used a language called monkey-x with a webgl patch that really improves performance of rendering. The mojo API is very similar to your canvasquery's one with functions like:

DrawRect

DrawCircle

DrawImage

DrawImageRect

etc...

 

Here you can see the webgl implementation:

http://source.mungo.io/modules/mojo/blob/master/native/mojo.html5.webgl.js

 

Mojo is property of Blitz Research and this implementation is a fork of Monkey-X called Mungo.

[wagner]

It looks awesome, man! I like this kind of solution, simple as possible.

 

I want to test it with some prototypes that I have in my mind...

 

Thanks for sharing.

[Rezoner]

Thank you,

 

I was a bit struggling isn't it a bit too much of abstraction but I've just added simple game states support

 

.... and gamepad

[chg]

I would love to see the same API for WebGL - however community familiar with OpenGL told me that the architecture is so different that it would not be beneficial to implement it in such way - but then - CocoonJS is using OpenGL with Canvas API and it works great. Confused

 

I suspect there are 3 reasons one might to want to use a library that provides a 2D canvas like emulation with a WebGL/OpenGL/OpenGL ES renderer -

• To make use of hardware accelerated drawing where the browser might not otherwise provide it. I think this applies to some particular versions of the Android 4.x browser where it was broken. Hopefully this will be come less of an issue as time goes on...
• To reduce overhead/optimise for hardware acceleration better than the browser can with it's own acceleration of the canvas eg. with batching, minimizing calls to change the state machine
• Mixing 2D canvas functionality with the benefits of a modern 3D accelerated pipeline. eg. Access to shaders for effects, applying 3D transformations to "sprites", mixing 2D with 3D models in the same scene

CocoonJS, I think, aims to solve the first reason. I think something like Pixi.js aims at the second and third (and hits the first a little, though may create the opposite issue by requesting WebGL and getting a software implementation or low power 3D implementation, when a 2D canvas would be faster) - by having the concept of a sprite it can allow sprite batching and it lets you apply certain shader effects to sprites in realtime at little performance cost.

 

I don't think I library like this should aim to target the first reason as a goal, and I think second is what what the community you asked were thinking of, you would be better off with a different API than that of the 2D canvas if you wanted to make use of tricks like sprite batching I suspect; which is to say you wouldn't want a wrapper over each drawImage() call that tried to add it to a batch and flushed/drew that batch whenever a different source was used... I think it'd be nicer if there was a WebGL accelerated sprite renderer that was smaller and lighter than Pixi.js though.

 

The 3rd reason might interest you given the amount of your library devoted to per pixel colour manipulation in your library - such effects could be implemented as shaders and executed in real time, I suspect.