Guys at one point we just have to give Scirra the benefit of the doubt. I'm with the community in general but He's saying that he knows this is a big task, and they will do their best to expand the API. Extending the runway is easy and we got to let this play out for a few months to see if they deliver.

Currently we are raging without having seen much proof either way.

Create a rectangle sprite, when an object is selected, send it's UID to a global value.

Global value =/= 0, pick the object by UID, set the rectangle sprite position to that object and then resize the height/width and angle.

I had 1070 "browser log" actions in the project. Replaced them all with a function call today. Took me several hours even with a fair bit of hacking.

I have to ask, what are you logging that possibly requires that many events?

Appologies, it was my own calculations. For the moveTo the subtraction of the outer window wasn't needed. removing that made it work. A bit weird that it worked in preview but thats probably just a coincidence.

for reference:

	window.moveTo(((runtime.globalVars.screenWidth)/2), ((runtime.globalVars.screenHeight)/2));

I didn't know players wanted those settings - I'd have thought a fullscreen experience was more immersive than windowed 🤷

I polyfilled window.moveTo() and window.resizeTo() for WebView2 as it didn't look too hard (although DPI settings can prove complicated, but I tried to get it right), so that's in for the next beta - hopefully it works OK.

Big big thank you :)! I will try it when the beta comes out and feedback if needed.

It might be more relevant for us small resolution devs but fantastic that we can use the lightweight webview2 while keeping these type of settings. Looking forward to seeing where c3 takes WebView in general.

Have a great weekend!

I believe Animate can export in video format and c3 cant.

> E.g. player would select scale factor 1, 2, 3, 4 etc and it would resize the window based on that.

Why not use letterbox integer scale? That essentially does that and supports any window size. So then you shouldn't have to be trying to change the window size.

The key aspect is that the player should be able to select this in an option screen instead of having to manually adjust the window size by dragging the corners, which doesn't give a professional impression. Especially for selling games on Steam where it's common to get negative reviews for missing these type of settings.

Attached two screenshots from Celeste and my own previous game for reference (Velocity Noodle).

To add on (can't see an edit button?), I realize now in the screenshot in the OP post I do not multiple the scale which is the idea. E.g. player would select scale factor 1, 2, 3, 4 etc and it would resize the window based on that. Alas, issue is the same :)

I think WebView2 doesn't currently support these window positioning methods out of the box. I filed an issue about it a while back.

Can I ask why you need this though? It seems a weird thing to do. If you're trying to set a specific window size, it should default to the viewport size of your project.

Thanks for taking a look Ashley, appreciated.

I dont think it's weird at all, window scale is a very normal option to have for desktop games (i dont do web games). Especially if you do pixelart, your game is made in a much lower resolution and then scaled up. Letting the player then select the window scale in options (or go fullscreen) is seen as hygiene factor for many. Celeste is a good example of this.

I use this JS method because Construct does not provide a native way to scale the window. Would love if that would change moving forward but until then this is the best way to do it from what I've gathered.

Potential bug, I use JS to scale the game window. It works fine in NWjs and the preview, but exporting to WebView2 (which is much leaner than NWjs) seems to nullify the code that changes the window. This is both resizeTo() and moveTo().

Code in question here:

I've tried window.resizeTo, replacing the variables to hardcoded and removing any flags etc values but nothing works.

Also tried a blank project to see but no luck there either.

It doesn't seem to be all JS, because a simple one like alert() works.

> Now they're in development hell: they can't stay on the current version of Construct because it's got a showstopper bug. But they can't update to the newest version of Construct with the fix, because the hack they used in their project won't work. They have no good options and can't rely on official support.

About this: I've been doing consulting work on many games for a while and from experience, this does happen. It's just that it's never EVER that simple. And it's not only on Construct, this kind of stuff happens all the time, because it's expected when making larger scale games. You WILL write bad code that WILL cause problems. You WILL stop updating your engine (not only due to hacks, but also to avoid regressions, and to make the engine codebase more stable for late development) and you WILL cry because an engine bug was fixed 10 versions later. You WILL learn to deal with it, and you WILL find a way to still release.

I just want to jump in and say this is a really good summary of how game development works, and I want to show my support. I've released two games, and both times we used different libraries and extensions that users had changed to do what the engine couldn't do on its own (not c3 in my case). When you do this, you know there's a risk of these things being discontinued.

I don't know how often this creates company backlash, but I can't imagine serious developers using things like Skymen's experimental add-ons without knowing the risks (maybe it's more common in the C3 community). This isn't a post saying Scirra should do this or that, but it's not often I see someone explain game development as well as in the paragraph above, and I wanted to point that out.