FULLSCREEN: Scale up html elements

[liakos1992]

I want to create a game that can go fullscreen and back to normal via options.

The problem is that along with the game sprites, I want the html elements to be scaled up too. I need the html elements to create a hud/ui for my game. I have found some solutions but none is perfect.

I can use the phaser buttons and texts so they can scale up too, but I also need input, scroll elements and checkboxes. Checkboxes are easy to make with phaser. Scrolls are a little harder and creating inputs seems completely impossible. Because I also need a pointer/cursor while writing inside the input, and the user must be able to select the text in a "chat" area.

I have tried to place the html elements in a "%" way like style="left:20%; top:10%; width:30%; height:5%;". Their size scales up, but their font and border size do not.

I have tried to zoom-in elements with css3: element.style.transform = "scale(scaleFactor);" (I can calculate scaleFactor comparing the canvas size between the fullscreen and non-fullscreen mode), but it greatly reduces text quality. Elements positions become inaccurate too.

I tried to search for a javascript canvas gui library and I found zebra but it seems it has a lot of bugs. "zebra.min.js" loads with errors unlike my other files; probably because my project is not on a server and I'm accessing my files locally. (Is it worth trying to fix it?)

I'm asking for your ideas. I don't know what to do.

[Mauricio Fidalgo]

Use view width and view height CSS properties instead of %.

1vh = 1% of the view height.

1vw = 1% of the view width.

for more information about this property https://css-tricks.com/viewport-sized-typography/

i hope this works for you

[mattstyles]

Easiest decision is that there really isn't much difference between a max-width browser and full-screen, usually just a few horizontal px and maybe 100-200px vertically, why do you even need to change font-size? 

If you do want to then you might be best off just using media-queries and specifying em or px and ignoring if it is full-screen or not, just consider the size of the screen. Standard for working with web pages.

14 hours ago, liakos1992 said:

I'm accessing my files locally. (Is it worth trying to fix it?)

By accessing locally, do you mean via file:// protocol? If so then yes it is worth fixing, although it does depend on your project. A few things surrounding loading stuff, like loading anything you might need from a cdn, won't work via file:// so its worth learning how to fire up a quick server. Given you're a JS dev then running a quick node server makes sense (there are about 100 of them! seems to be a popular learning test), I have serve installed globally on a few machines to quickly spin something up but there are plenty for other languages if you're happier with python or whatever.

[liakos1992]

I had to mention it, mattstyles. I am using nwjs.io. It is a tool that converts your javascript project into a binary .exe file, so the non-fullscreen window has 800x600 dimensions, so there is a big difference between the windowed and fullscreen mode. Because of that, I can't host the project on a server. By fixing the "zebra.min.js" I mean changing the code inside. It will be hard because their community is too small and I can't find anything about that problem

[liakos1992]

8 hours ago, Mauricio Fidalgo said:

Use view width and view height CSS properties instead of %.

1vh = 1% of the view height.

1vw = 1% of the view width.

for more information about this property https://css-tricks.com/viewport-sized-typography/

i hope this works for you

Nice idea, but this works only when

game.scale.fullScreenScaleMode = Phaser.ScaleManager.EXACT_FIT;

. I need to use:

scale.fullScreenScaleMode = Phaser.ScaleManager.SHOW_ALL;

then black areas appear at the edge of the screen because the game scales up with the same width/height factor, and "vw" and "vh" calculate black areas too, so the elements scale more

[mattstyles]

It doesnt matter that its done with node webkit, the principles are identical (as the tech is), its the same as viewing a website 800x600 and then in, say, 1440x900, anything applicable to any website is just as applicable to your app.

Find your break points and use media queries to change your styling when the design breaks. If you want your fonts bigger for larger screens then detect the large screen using media queries and increase your font size, dont worry about setting a linear scale (i.e. %) because the difference between 1920 and 1800 (for example) probably wont break the design so a font size of 20px (again, for example) will suffice for both. If the design breaks as the window gets smaller, say, at 1200px, then that is your break point and you set a new font size, maybe 17 or 16 and set whatever other css you need to. 

If your window is not resizable then your task is easier, design for 800x600 and design for larger screens, and thats it.

 

Zebra looks like it contains some sort of XHR, I get no errors using an example from the readme, if you're serving from file then it will probably have a fit, I can't remember how NW handles context with regards to XHR, are those the errors you're getting? you'd probably have to use some sort of XHR shim, which is kinda redundant with NW, although I have no idea why Zebra would be sending requests at start up. From the look of the readme it looks like it does a few 'questionable' things.