Yep! Hence the 20 page thread asking for a native exporter.

(Not that I agree a native exporter is a good idea at all, my thoughts are in that thread somewhere )

Ah, just like the good old days...

Ashley I think you're misunderstanding the events. You're supposed to first shrink the window (it starts at high quality, but it doesn't matter), then 'lock' the canvas size once you start getting consistent 60fps. Then, you *should* be able to enlarge the window without any negative performance implications.

So it's not 1. or 2. in your options, but rather, a canvas smaller than the window, with low quality fullscreen mode, as you'd expect.

I'll copy in the instructions from the capx:

INSTRUCTIONS:

1. Manually enlarge the window (or increase the number of PerformanceKillers spawned) until the fps is 'NOT OK'.

2. Shrink the window until the FPS is consistently 'OK' (60fps).

3. Press 'Set Canvas Size' which will make the current WINDOW size the new CANVAS size, and will also set LOW QUALITY fullscreen scaling to ON.

4. Increase the WINDOW SIZE as far as you can. This should have NO EFFECT on performance, but in all my tests results in a serious FPS drop.

Mamajuano from your description it seems like you might be seeing a problem similar to this one, or it could also be a mistake in your events. Hard to say.

Yeah, I noticed about a 10fps drop, but if I increased the number of fullscreen objects the drop was even more noticeable.

Hey all,

I'm putting this here instead of in the Bugs section because the issue may just be that I misunderstand how the 'low quality' fullscreen scaling option works.

Basically, 'low quality' fullscreen scaling is supposed to render the game at a specific size, then stretch it up to the window size. This has the side effect of the game looking blurry if the screen is too big, however it's very necessary if the game is bottlenecked by GPU fillrate.

Now, my expectation is that, once low quality fullscreen scaling is set, the actual window size should have no effect on performance. However, recently I've been noticing that the opposite is true - having a bigger window size is more costly, even when low quality fullscreen scaling is on.

This happens in all browers I tested - Chrome, Canary, Node-Webkit, Internet Explorer, and Firefox.

I've attached a capx so you can test it for yourself. Instructions are included in the event sheet.

I really, really hope this is a bug, but I can't be sure. Am I just fundamentally misunderstanding something here? Or is there really a problem with C2's implementation of low quality fullscreen scaling?

Yea, the way I so it is with 'set canvas size', and then setting the layout scale to a ratio of the original canvas width vs the new canvas width.

— afaik, 3d games have hardware and software optimizations preventing overdraw.

Let's just say that fillrate is also my enemy

Not much you can do apart from limiting the number of huge/fullscreen sprites drawn and limiting the number of layers that force their own texture (this includes setting layer opacities, and having layer effects). Then of course there's always the option of low quality fullscreen scaling, but then the game will look blurry on big screens. My game has this toggleable, as well as resolution presets.

Is the window the same size? Could be fillrate related.

Oh! I see now! Sorry for being dense.

Yeah, this is actually really cool, provided it had a solid connection with the event system.

I really don't like line linking. It's always sort of unclear which data is going where, and in which direction - this gets confusing really quick - the 'spaghetti problem'.

I really like the event system because it makes a wonderful transition to learning real code. Events are basically real code, just with a few helpful constraints.

Here, that's quite abstracted away.

Just my thoughts, I'm by no means an expert in spaghetti

jayderyu sounds like a C3 suggestion.