Arima, you aren't quite understanding which textures would be put in VRAM. Let's say you have a huge game level or world. All your character animations and everything around you is in VRAM. As you walk through the world, everything X distance around you gets put into VRAM and stuff beyond that is dumped. I'm talking about that sort of thing. A lot of 3D games use all sorts of ways to manage their resources. They are big companies and have tons of people to work on this stuff, so I don't think it'll happen in Construct, but it'd still be nice to have some of this. I'm just going to work with what Construct has since it probably won't change.

I only mentioned the definition of "streaming" because I saw it the other day being used for what looked like on-demand loading of character models, though I may have been mistaken. It doesn't really matter.

manontherun - Their engines were made to do those things. The Construct engine is a generic and straightforward engine. It wasn't made to handle those kinds of things. Diablo II for example, doesn't use full color PNGs I hear. They optimize their engines for what they need.

3D boxes are still broken though from another bug. At least in 0.99.82+ and the previous versions have other problems I think.

Construct can't do texture streaming and it has to spawn the objects, it can't just keep the objects "there" without textures. With spawning objects, it is entirely cumbersome and not at all dynamic. I'm not entirely sure about all the different definitions of "streaming" and although I could discuss the wording of it, I'd rather not take the time. There's two different things here: 1) The type of loading when you change outfits in a game. Somtimes there's a tiny pause of the character model though not of the game itself, as it changes the model. 2) Only keeping textures of things in the immediate area of the object in VRAM. I would presume they still exist, just without their normal textures. I'm not sure how much of this sort of the loading is normally scripted and how much is dynamic.

Really, Construct is limited with these kinds of things. I do not know all the details of implementing this for Construct, but I'd like to see something being worked on. Resource management is a must in 2D games as they are more VRAM hampered than 3D games. I'd really like to see loading that doesn't pause the game for one thing.

Edit: What do you mean "unload them when leaving a layout"?

Loading an image at runtime still uses VRAM. In terms of VRAM usage, it's no different than having it stored as an animation frame. Construct loads it once to VRAM the same way all other textures are loaded to VRAM.

The only benefits of loading images at runtime instead of having them as part of the cap is it makes it quicker to preview and save, and if you want to update your game and save bandwidth/download time, the players don't have to re-download all the images they already have.

I know that, I was referring to a sort of "on-demand putting into VRAM." From the other topic which is kind of related to this issue, I've found out that everything is stored in RAM until it's loaded into VRAM when you load the layout. I'd like to be able to decide what gets loaded into/unloaded from VRAM better. My post was a little unclear, sorry.

manontherun - That's sounds like Asset Streaming. 3D games really use it. It loads on-demand what it needs. That's why there can be a little delay before your character model changes.

Unfortunately, Construct is very limited with how it can use resources and a lot of features that 3D game engines use (and can really be in 2D games too!), aren't in Construct. Construct was originally made to just run everything from a single .exe. It is not a good practice and a lot of people don't like it, so the whole encryption thing is a hot topic.

I seem to recall that texture streaming isn't possible with DirectX - might it be possible with OpenGL for C2?

Isn't possible? 3D games (using DirectX of course) can stream textures. It's a VERY useful thing. Call of Duty: Modern Warfare 2 uses it. Also, it may be 3D, but it's still using DirectX and 3D doesn't mean it can't be used in 2D.

Okay, good to know how Construct actually works. I kind of wondered about the transfer time for that stuff. This kind of thing would work for, say, checkpoints in the save level though wouldn't it? Some games load stuff around you as you move through them and compress everything else. That probably couldn't be added to C1, but an interesting idea anyway.

Construct only keeps the current layout in VRAM unless you change that setting. Constantly loading everything off the HDD on-demand doesn't seem to be a good idea as constant HDD use is never good. Storing some stuff in regular RAM would be a great feature IMO if it works like I think it does and there'd be no HDD searching/reading.

I have more to say on this, but I'll wait for your reply. There's a topic in the Construct Discussion about lots of frames and animations and stuff that is directly related to your issue.

I think Construct should be tapping into the vast amount of regular RAM everyone has. What if it stores some stuff in regular RAM then puts it in VRAM when needed? I'm not sure what would help exactly, but VRAM is strained while RAM is hardly touched...

Edit: Things that aren't stored in VRAM would kind of have to be put in RAM so as not to be loading off the HDD constantly.

Also, your only 3 posts are about this. Very suspicious. I would recommend no one just download this. Do some research to see if it is safe.

Is there anyway they can just save it from a cache or something? That wouldn't be desirable.

will construct 2 be construct 1 .cap compatible?

Nope.

Because they should really spawn the correct size, not make me change it every time one spawns. Anyway, I found a way to work around this whole thing.