In my Python module for making multiplayer games that use m.grl, I have a few functions that might be useful in other applications as well. So here's a list, and you can choose if you want to include them in m.grl. It's all in https://github.com/wijnen/python-webgame/blob/master/html/webgame.js; numbers in parenthesis are line numbers in that file.
My main goal with the module is boardgames. One feature is that it is easy to offer a 3-D version and also a 2-D version of the same game, so clients can choose which one to use. The artist just needs to design the 3-D models in Blender and the 2-D models either as images or drawn on a canvas. The setup is different, of course, but after that almost all the logic is backend independent.
For 2-D mode, I let the user define a viewport (I do that in a global variable; m.grl would use a function argument). When the window is resized, the 2-D canvas is scaled so that it remains in the view. (The canvas itself must change width and height, because the beauty of a canvas is that it uses vector drawing, but that is only really useful if the canvas size changes with the window size). (187-190, 429-464)
For 3-D mode, I do something similar, by setting the camera to a distance so that a rectangle the size of the viewport at the the look_at point would be in view. (71-77, 429-452)
I allow users to use the middle mouse button to move the camera around. I allow the application to switch this off, for use when the camera is controlled by the game. For m.grl, I expect the opposite to be a better default: make it available, but leave it off by default. I implemented spherical coordinates myself to work around #200, because I'm not as smart as you. ;-) (78-125)
For 2-D mode, I make canvas and div "sprites", which resize with the underlying viewport. This allows game pieces the same vector-benefits as the background canvas and it allows pixel images to scale with it. I have not made this work with ganis yet. (362-427)
In my Python module for making multiplayer games that use m.grl, I have a few functions that might be useful in other applications as well. So here's a list, and you can choose if you want to include them in m.grl. It's all in https://github.com/wijnen/python-webgame/blob/master/html/webgame.js; numbers in parenthesis are line numbers in that file.
My main goal with the module is boardgames. One feature is that it is easy to offer a 3-D version and also a 2-D version of the same game, so clients can choose which one to use. The artist just needs to design the 3-D models in Blender and the 2-D models either as images or drawn on a canvas. The setup is different, of course, but after that almost all the logic is backend independent.
For 2-D mode, I let the user define a viewport (I do that in a global variable; m.grl would use a function argument). When the window is resized, the 2-D canvas is scaled so that it remains in the view. (The canvas itself must change width and height, because the beauty of a canvas is that it uses vector drawing, but that is only really useful if the canvas size changes with the window size). (187-190, 429-464)
For 3-D mode, I do something similar, by setting the camera to a distance so that a rectangle the size of the viewport at the the look_at point would be in view. (71-77, 429-452)
I allow users to use the middle mouse button to move the camera around. I allow the application to switch this off, for use when the camera is controlled by the game. For m.grl, I expect the opposite to be a better default: make it available, but leave it off by default. I implemented spherical coordinates myself to work around #200, because I'm not as smart as you. ;-) (78-125)
For 2-D mode, I make canvas and div "sprites", which resize with the underlying viewport. This allows game pieces the same vector-benefits as the background canvas and it allows pixel images to scale with it. I have not made this work with ganis yet. (362-427)
For examples of all this (except div sprites) in use, see https://github.com/wijnen/python-webgame/tree/master/example/quarto