Discussion for March update

details here:

Unfortunate to see feb features pushed back, but also understandable. i'm always excited when Construct gets big upgrades that add significant new features. i'm still very confident in Construct's potential as a very powerful and flexible game making tool.

What i'm hoping for is an intermediate 'unstable' build released as soon as the revamped control system is done -- i'm making a multiplayer game designed around gamepads and have been setting aside progress for key parts of the game as i wait for this revamped control scheme. i'm looking to go public with a playable build by mid april, so i'd like access to this revamped control scheme as soon as possible. i know you guys are busy -- i'm just suggesting having the revamped control scheme as one of the top priorities, as i think gamepad support and multiplayer support are both very fundamental.

They haven't really been pushed back per-se, we didn't anticipate releasing 0.99 in February (barring unforseen amounts of time); the renderer's nearing completion, and object folders too, so we're just looking into the new control system and some other stuff, hopefully it's all done in a couple of weeks.

There probably will be an intermediate build to solve some silly issues with the current build, but whether any of these features will be in it I'm not sure.

New Control system with Multiplayer would really be a big change - can't wait to see that happening

Rich when you say renderer what do you mean?

A rewritten renderer so that we can implement V-RAM controls. It's better explained in the February update.

Ah that i see what you mean, seems like some great additions are coming. I can't wait to try out Terminal Orbit, been so so so long coming!

Indeed V-Ram controls in particular are of vital importance to large scale projects, as are object folders.

It'll be cool to see how the VRam stuff will work. Currently, I imagine it like a container, you set the size of the container (vram of your target audience) and just shuffle stuff in and out of there and setup 'load' times accordingly.

Object Folders and - probably even more important - a better way to organize and handle the layouts and layout event sheets would really help for bigger projects. Like, why not put parenting in there? Every layout comes with an event sheet, so you could immediately organize it that way, like:

"Oh, I wanna find my layout 1 event sheet... where is it... ah, yeah, I just press the 'plus' sign next to layout 1 and - ah, there it is!"

If we could do parenting and also have folders in there, it'd really help keeping larger scale projects organized and readable - especially also important if more than one person is working on the project.

It's not possible to control VRAM how you describe. The runtime has no idea which textures you're going to need shortly. It can only guess, and when it gets it wrong, the game will become noticably choppy as it transfers textures to the GPU (it's a slow process). And if there are X megabytes of textures to show on-screen, you need X megabytes of VRAM, regardless of whatever limit you want.

I haven't fully designed how the system will work yet, I'm still working on it, since it's important to get something which is useful and will work well before I start coding. But it'll probably take the form of:

• Layout settings (load and free the layout's textures on an application or layout lifetime)
• System actions (dump all VRAM, dump currently unused VRAM. or cache certain objects for customisation)
• Object settings (load and free object textures in the layout or object lifetime) although this is not as effective a way to do it

If you have any other suggestions how it could be configured I'm listening (now's the time to get your ideas in), however, in short, the user will have to decide how to load and unload VRAM. The runtime can't second guess what your game is going to do, nor can it magically lower the minimum requirements to less than what they really are.

The most important thing would be an ability to load textures from resource and dump them at will.

I think it should have a few ways of going about it.

1. Load everything at start, like it is now. A lot of games are small enough that pretty much any card could load them, and then you don't have any loading issues.

2. Upon going from one layout to another, dump everything except global objects and load all objects on the new layout into VRAM.

3. Have a checkbox "keep in VRAM" - like for the main character, who's going to be used often, even if they're not global. Can be overridden by:

4. Manual controls. Example: At start of layout, dump everything (except the stuff in #3), delete the objects you don't want to use, then use a "load objects in layout" command. Or the "destroy at startup" attribute will prevent an object from being loaded into VRAM.

There might be a better way of going about it, but those're my thoughts.

Can't that somehow be streamed? I mean, always load the current layout and always already start streaming the previous and the next layout into the vram - and kick out everything else.

I'm sure I'm uber-simplifying it, but isn't that how it's usually being done?

Can't that somehow be streamed? I mean, always load the current layout and always already start streaming the previous and the next layout into the vram - and kick out everything else.

If you jump to a layout that's not the next, you'd get choppyness.

That said, it would be cool to hint a preload.

Like an action: load layout x into VRAM

you could trigger it with enough time and if there's not enough time, well, choppyness.

So what happens right now is that the whole game is loaded into the vram at start, right? Couldn't we just create triggers that'd tell the engine to start streaming what we'd need? Like, it's not too hard to imagine that if you're on layout 2 and got 10 layouts, you probably won't be able to go to more than 3 layouts next. You either go to layout 1, layout 3 or you go to the menu. We could set triggers for that. If player is on layout 2, start streaming layout 2 and 3.

Or: If player overlaps with 'StreamObject', start streaming layout 3.

We could have the menu screen as a global layout always in the ram.

In the case of that not being enough, we could still simply create a "Now Loading" layout that the engine automatically temporarily jumps to when changing layouts.

Again, I'm pretty sure I'm really oversimplifying it, but maybe some input from how a lowly artist sees it will help

Hmm, streaming. Could we potentially load things into VRAM without it pausing, if what's being loaded isn't needed yet? So instead of putting the texture through immediately, it would work like this:

CPU runs events

GPU renders frame

Load textures in time between frames

If it's time to render the next frame and the texture hasn't finished loading, wait for the cpu and gpu to run again before loading the rest of it.

Don't know if it's possible or not, but it would help a lot to keep gameplay smooth and reduce loading times.