Zooming, Scaling, Culling and Performance

I don't expect much from this, but since it's a runtime issue I figure it's worth a shot in the dark.

So Construct doesn't use zoom levels to cull what it draws (or so it seems). Running the game at higher resolutions totally kills the frame rate on some systems.

Current implementation for it is to use the 'show more content' and layer zooms and a nice overlay to letterbox or pillar box the game neatly as needed. It's a really nice and functional implementation but apparently it's garbage, performance wise.

Option 1: The easiest option is to just use stretch, make the window snap afterward to whatever the closest multiple is and be done with it, but that really fucks with people trying to full screen the game and stuff. Not great.

Option 2 seems horrible and gross. Allow no resizing (besides menu based resizing which is fine) and then use some directx injection hack to put in a global shader which will magnify that image to the appropriate screensize. I'm not even sure I can legally do that though as it involves distributing hacked DX Dlls?

Option 3: Some sorta horrible manual culling with setting things invisible (Are objects with 0 opacity culled?). Maybe using different layers for different slices of the stage? This is a little messy for a few reasons

Option 4: Hope to god someone doesn't care about noodling with the Construct Source a bit and can change -something-. I don't care if it's a hack or if someone puts in a call for a normal shader at the start of the application so I can at least affect the whole screen. Or if the culling just always assumes a screen size of 640x480 (perhaps exempting certain layer names?). Or really, just any advice with dealing with this might help. What do plugins have access to? Would it be possible to make plugins that toggle vsync and the stretch mode? Could I use a plugin to put in other options? Like, different stretching and resize behaviors?

I have multiple routes for for optimizing the game (all of which I'm exploring) and this is just one of them, but it's one where the things I want to be able to play with seem beyond what construct allows me to do, currently.

Maybe make a launcher that forces the screen resolution instead and then launches the game (eg: if widescreen scale down to a set 16:9 size, otherwise 4:3 1024x768) then when the game is closed it resets the screen size to default. Would this be a possible "Option 5" ? I've seen a few games that work this way, but it is pretty rare.

As far as I can remember, Classic *does* correctly cull everything outside the viewport, even when zooming. I can't remember how its letterbox implementation works, it might just overdraw black bars (FWIW Construct 2 does a proper letterbox and only draws visible content)

If by "some systems" you mean integrated GPUs like Intel HD graphics, then you're probably running in to fillrate limits (i.e. the memory write bandwidth of the hardware), which is especially problematic at high resolutions. I honestly can't remember how Classic works in this regard any more, but if it has an equivalent to C2's 'Low quality fullscreen mode' where it renders the game small then just stretches the result up to the screen, then use that. C2 should soon be getting a front-to-back renderer mode as well which could significantly reduce fillrate and end up making C2's GPU performance better than Classic's! But there is very little hope of Classic getting that.

Weird. I guess it's just multiple things snowballing together (Because it's only a problem on stages with lots of offscreen content which gets exponentially worse when things get zoomed in.

Sadly stretched doesn't preserve aspect ratio so that makes it real hard to do anything neatly scaleable. Wondering if I could do something crazy like use canvas to grab the screen content and then squish it back to the right size, but dealing with low resolution pixel art, I have a feeling if I did that I'd end up with a good bit of distortion.

Sadly the transferring a five year old project to C2 is kinda out of the question unless r0j0 gets the converter in slightly better shape. If that end up happening, I do not look forward to what a nightmare process that conversion will be on the re-coding and bug fixing front.

Ashley, do you have any recollection about how possible it would be to change things like rendermode at runtime through a plug in because I think optimally Id want to use the 'high quality scaling' mode I made which is a bit slow but fine on most systems, but say, switch to stretching as a fall back for weaker systems.

As far as I can recall, I don't think plugins had control over that kind of capability.