Has Babylon ever run on device where window.devicePixelRatio != 1?

[JCPalmer]

I have been working with Ludei support to get BabylonJS to work for Andoid & iOS.  The basic problem is that Babylon ends up thinking the size to draw in is 0 by 0.  For the conversation see: http://support.ludei.com/hc/communities/public/questions/200763155-Trying-to-get-BabylonJS-to-work

 

According to their software my devicePixelRatio must be 2.  There is code in Engine to define hardwareScalingLevel:

this._hardwareScalingLevel = 1.0 / (window.devicePixelRatio || 1.0);

Then client height & width are divided by hardwareScalingLevel to define the size to draw to in Engine.resize().  If no one has ever run Babylon on a device where the devicePixelRatio != 1, we could have a bug on this side as well.  Should the clientWidth & clientHeight be divided or multiplied by hardwareScalingLevel?

 

clientWidth & clientHeight both return 0, which is another problem.  It does not seem that is supported there.  Using a hack they came up with, I built a babylon.js where the sample scene worked fine.  We just to sort this out.

[GameMonetize]

I think someone already tested this and had no issue but I cannot find the discussion anymore

 

Did you try with Chrome or IE with woom set to 150%. This should be the same thing. 
 

[JCPalmer]

No I did not zoom those, but I do not think that zoom is the same thing, if it works the same way as Safari does.  I have a non-Retina MacPro.   When I zoom a babylon canvas the whole page just magnifies and crops.  I do not think it is changing the device pixel ratio or babylon even knows about the change.  I thought device pixel ratio is for tablets and the newer Macs with retina display.  For those, basically the browser clientWidth/height is returned as DIPs not pixels, so stuff like text does not get sized too small to see well. 

 

Thinking about this, Babylon is geared for the dynamic sizing that can occur on a desktop / laptop browser.  This achieved by using CSS styles which specify the canvas's size in percentages.  When the user re-sizes the browser window a resize event occurs.  If a listener is put into the html, babylon will recalculate the new size.  None of this ever occurs on a tablet.  There are no windows.

 

CocoonJS does NOT use CSS for it's accelerated Canvas+, so right off the bat the same html as for a desktop cannot be used.  A good strategy might to limit all differences just to the launch html.

 

The first thing to remove from the html, in addition to the CSS % sizing, should be the isSupported() test.  Ludei said only 1 canvas is ever actually created with the first getContext() call to a previously sized canvas.  I proved that was true by creating a context as '2d' before creating an Engine & the thing just crashed.  isSupported() is a test done by creating a 'webgl' context on an un-size canvas that get thrown away.  You are screwed if you call isSupported().  I also saw Engine has a _workingCanvas & _workingContext.  The things this is used for like video textures & cube textures are unlikely to ever work on CocoonJS as is.

 

CocoonJS also does not look like it even supports clientWidth/height, since after all there are no scrollbars with a canvas.  clientWidth/height result in zeros.  That means even if you called Engine.setHardwareScalingLevel(1), you will still end up with a 0 sized drawing area.

 

Rather than explicitly supporting CocoonJS, maybe this is another job for the 'Rename - Wrapper' trick, like I used to make SceneLoader.Append().  Take the existing Engine.resize(), and change the name to setSize() giving it parameters width & height.  Create a wrapper called resize() which does the same calc as before, then calls setSize() to actually implement.  After you instance Engine, just call setSize() & pass it anything you want. (You need to do this correct for the resize() being called in the Engine constructor).  This takes care or any weird hardware you wish to support, as discussed in this phaser thread.

 

http://www.html5gamedevs.com/topic/3980-common-phaser-cocoonjs-issues/?hl=initial-scale

 

Automaton is definately a higher priority for me.  (Ben from the Ludei thread:  start 'Gulping' your own fork if this is a problem).  If setSize() is put in, I'll probably add a new .html output file to Tower of Babel, xxx_cocoonjs.html.  It would use the inline .js not .babylon.   CocoonJS is the actual reason for TOB.  At the time, a .babylon file would not even load without a web server.  There is also no need to do incremental loading or put up progress bars here.  All downloading occurred when it was gotten from the store.  It might make no difference on fast desktops, but the javascript parser is C++.  There is no way a parser written in javascript is faster than C++.