Problems in latest experimental version

Monkey Targets Forums/HTML5/Problems in latest experimental version

ziggy(Posted 2014) [#1]
I was externalizing this functions to enable a good, unscalled "full window" app on my Junglegui module:
function EnableAutoSize()
{
	window.onresize = ResizeCanvasFull;
	ResizeCanvasFull();
}

function DisableAutoSize()
{
	window.onresize = null;
}

function ResizeCanvasFull()
{

	var canvas = document.getElementById("GameCanvas");
	if (canvas)
	{
		canvas.width = window.innerWidth;
		canvas.height = window.innerHeight;
	}

}

It is not working any more and it produces mouse coordinates to not correlate to canvas coordinates (and also the resizing does not work).
Any help in solving this would be more than welcome.
Also, I've seen latest html5 template has a function to request fullscreen on the app. Do you think this could be properly externalized anyhow?


MikeHart(Posted 2014) [#2]
Yes, had the same experience with my code. The change fucked up everything. One thing that helped me and now has to be doen with every project of mine is to set this Resize variable in the build project files to 0.
Not sure who the hell motivated this change but I guess that is the nature of Monkey. Someone cries wolf and if Mark is convinced that it is a valid call, he changes Monkey. And these changes can screw up other peoples code. :-/


nikoniko(Posted 2014) [#3]
Looked in new MonkeyGame.html and found 2 things

1.New canvas resize mode var CANVAS_RESIZE_MODE=1; //0=locked, 1=stretch, 2=resize

2. And comment:
//Note! Any resize code that modifies canvas.width/canvas.height/canvas.style.wi
dth/canvas.style.height should call this to update canvas...


Anyway using previous MonkeyGame.html is still possible.

New monkeygame.html is also complex for game release version


ziggy(Posted 2014) [#4]
I'm getting lots of problems with new HTML5 default export. The default html5 canvas size is too small, and the fact that now programatically resizing the canvas is broken, I don't know how to provide JungleGui samples in a reasonable way unless I ask people testing the sample to edit the generated html, which is very far from nice


Saj(Posted 2014) [#5]
Same goes here. The canvas is too tiny to see anything.


slenkar(Posted 2014) [#6]
the ability to not copy hundreds of files
upon every compile
is a very noble goal
Otherwise SSD's it would defile
Of course there will be`problems with anything new
Revert to a previous version if it gives you the blues


ziggy(Posted 2014) [#7]
the ability to not copy hundreds of files upon every compile is a very noble goal Otherwise SSD's it would defile Of course there will be`problems with anything new Revert to a previous version if it gives you the blues
I'm sort of complaining about the small program that comes now attached with the generated html5 template. This program is too encapsulated to be modified later from within Monkey, and it has some arbitrary decisions there that may not fit all scenarios. For me, in my honest opinion, it's a step backwards as a module developer. If I can get a working workaround, I don't care the change, but I think that the html5 export should remain simple, pure, and without encapsulated additions. IF any functionality is about to be added, it should be added in the target specific mojo implementation, the same way resolution changes were added to GLFW. Hardcoding it arbitrary on the template, is not very nice, and it is not very convenient.

EDIT: There's an almost working workaround here, that is pure Monkey code: http://www.monkeycoder.co.nz/Community/posts.php?topic=8088


ziggy(Posted 2014) [#8]
There's a working fix here: http://www.monkeycoder.co.nz/Community/posts.php?topic=8088