Give each unit an invisible circle base sprite, give that physics, set it to elliptical and reduce the number of steps to 1.

Simply make your own fps counter. Every tick add 1 to it. Every 1000 ms check it and reset it.

Usually I just scroll up or down a bit, moving what I want to select generally closer to the center of the screen vertically and try again.

Just wanted to mention that layers themselves don't add to vram use. It's the sprites or effects on the layer that use it. You could have a hundred layers, and without anything on them, they won't increase the vram use one bit.

Construct appears to use textures for the black borders, the amount depending on the amount covered. That said, I know people often here talk about keeping vram usage to a minimum, but 14 mb of vram really isn't that much. Any even remotely recent computer should be able to manage that and plenty more no problem.

Also, do you have any full screen canvases or layer effects? That could affect vram usage.

Otherwise, I guess my best recommendation would be to make the layout size always bigger than the screen resolution and make the pillarboxing yourself.

Edit - there are workarounds for is object on screen (check distance) and the UI (have a camera object, set position of ui elements to it + the offset - there's probably a better way than that but I'm not sure of any others atm. You could even make a ui family with xoffset and yoffset variables and set the offset at the beginning of the layout if you don't want to have to hand code the offsets, etc).

The feature I would love most would be for debug mode to be able to watch the xml event sheets at runtime and when they're updated by saving, update the internal events without having to recompile like lua does. That's right, instant editing of the running game while it's running.

That would make the testing process a gazillion times easier and quicker. No more 'tweak, compile, get to the section of the game, test, restart process' - you could simply leave the game running while you worked on it (this would only work while you're working on the code tho, I woudn't expect other edits like inserting new objects to show up as well).

Yep. To make it clear though, construct is not running all 5,000 events each tick.

One of my event sheets has 5,000, and the entire game is somewhere around 10,000. The only problem is that with that many events, the event editor starts getting slower. I have an older processor though, with a newer one the effect is less.

All of the information in sysinfo is obtained by expressions.

You can already do that with sysinfo, system and window.

But doesn't C2 not have dt implemented yet? I guess I'll have to wait to test it until later.

Either way, it's more efficient than I thought, so maybe the features I suggested aren't needed.

...

Uhh...

With 500 objects, before turning off all other code, each pv check causes about a 10fps hit (1: 355 fps, 2: 345 fps, 3: 335 fps).

After turning off all other code, all 3 pv checks take 10fps total. (None: 207 fps, 3: 197 fps).

The fps went UP and the pv check efficiency went down when I have more code running. I am confused. I should try this with C2 instead.