How to access reliable screen size via scripting?

I want to resize the main layouts to take up the entire screen, and respond to the screen size changing. I've not found any documentation on the matter :( Is `screen.(width|height)` reliable across devices? It's not reliable in debug mode though - hoping there's something better.

I've yet to find anything to help on the scripting side, but PlatformInfo has some expressions that are available in Event Sheets that do the trick. I don't want to use Event Sheets, but as a workaround I can just set global variables that I can then use in my scripts:

It'd be great if I could stick to pure scripting, so if anybody can figure out how to do that I'd appreciate it!

(Moved to scripting forum) In scripting, maybe you just want the browser's window.innerWidth / window.innerHeight? It's not clear what you're trying to do though, because you shouldn't need to do anything like that to make a layout fill the screen.

So the resizing itself is fine, there are fullscreen options that solve that nicely. However I want to generate content that will be visible on-screen, which depends on the size of the screen. I've found the sizes in PlatformInfo do the trick which is great - but is there any way to access them without having to go through an event sheet?

Which PlatformInfo sizes exactly? And are you sure you're not actually after the viewport size? If you're looking for where to position objects in a layout, you need to do that relative to the viewport, not the screen, otherwise in some cases it will look wrong. This is why it's important to explain clearly what your goal is, rather than what the exact answer to a specific question is.

Sure, thanks. There are two things my game needs to do which depends on size:

1. Procedurally generate tiles around the player - just enough to fill the screen (deleting old ones after the player moves away). To know how many tiles are needed to fill the screen, I need to know the size of the screen.

2. UI stuff, i.e. making the game's title larger (within limits).

I think I saw some anchor point and scaling stuff which seems relevant for point 2, which I've yet to try.

For point 1, I was first trying to obtain a size similar to that seen as system canvas size in the debugger. JS screen.width/height didn't work for that (because they included the debugger), layout size didn't change from the original either, and that's when I stumbled across PlatformInfo. I thought I'd experiment with using either the device or CSS size from PlatformInfo to see which one maps more closely to the problem at hand. I think it'll be CSS from what I've seen so far.

I'm not sure what the difference is between viewport size and PlatformInfo device/CSS size, so I'm honestly not sure if that's what I'm looking for? At the moment, I'm able to solve problem 1 and 2 using PlatformInfo CSS size. 2 can probably be done more conveniently using other engine features, but I'm pretty content with my solution for 1.

It sounds like in both cases you actually want to use the viewport, and not the window or screen size.

The viewport is the visible area of the layout, so if you want to place things to fill the view or relative to the view, you need to position them relative to the viewport.

The viewport sometimes happens to match up with the window or screen size, so sometimes using the wrong values will work by accident. However as soon as you scroll, scale or rotate the view, or use certain fullscreen modes, it won't line up any more and will appear broken.

The viewport system expressions can return the viewport size. I just realised the scripting APIs don't cover the viewport yet, so I'll add something for that.

Aha, I think I've fallen into the "wrong values will work by accident" bucket. Viewport size indeed works a treat, however using the same workaround as above to have those values accessible in script.

And that ticked my last box before buying a Construct license! Awesome :D It's been a lot of fun to work with - I'm quite a JavaScript native, and they seem to be a nice fit for each other. Great work!

Going off-topic a little, but I find it interesting that the scripting API is more limited than the event sheet one, considering there's that "syntax" or mini-language that allows people to type in expressions like "PlatformInfo.CanvasCssSize" in event sheets - a naive impression is that that's not very far away from simply mapping to the scripting API directly? Anyway, I'm probably way off - still having fun, but for us who come from a stronger programming background, it'd be nice to see the scripting API treated more like a first-class-citizen when it comes to support and documentation.