I'm concerned I may have made you fearful of using families from the other thread. Really, there's nothing to worry about as long as you don't delete family variables or try to rename them. It's not as annoying as I thought it would be to have unused variables laying around. Definitely use families instead of recoding the events for every enemy!

4 to 5 MB of VRAM isn't actually that much. Modern, and even not modern graphics cards have tons of VRAM � sometimes into the gigabytes. Even old graphics cards shouldn't have a problem with a 100-150mb VRAM game. A lot of weaker computers use their RAM as VRAM so even though they have weak graphics cards, they actually have gigs of VRAM to work with.

The only thing you really have to be concerned about is textures being unloaded from memory when all instances of that object are deleted from the layout � because then when you create another object of that type, it will reload those textures, which can potentially cause the game to have a slight pause while it sends the textures from RAM to the graphics card. If you want to keep that from happening, simply make sure that there is an instance in the layout somewhere that never gets destroyed. It can be offscreen and invisible, and you can deactivate all its behaviors and use a variable make sure it is unaffected by events.

Did you copy anything from one .cap to another? That's an unfinished feature that screws up caps.

Ashley - Thanks for the info, I'll definitely mention it to ludei. What about audio, though? I imagine that could use a lot of memory. Does c2 unload audio, and if so, what causes it to do so, and how does it know what to unload? Or is that up to the browser makers/ludei as well?

I remember at one point, perhaps in a blog or update log, you mentioned the possibility of writing a blog detailing exactly how the memory management works - I would definitely like to know all the details if you're still thinking about writing about it, and I think it would be quite useful to others making large games as well.

— - thanks!

Joannesalfa - I'm already basically doing that. I'm not keeping instances of all objects in the project in a layout at the same time, it's a problem with the way browsers manage memory ? they currently try to store everything in memory at once even though they don't need to.

I've run into a major problem with the C2 version of loot pursuit � it takes up too much memory. After my iPhone 4S runs out of memory, the frame rate utterly plummets to about 2-3 frames per second. I've confirmed that it's a memory problem because deleting animations and textures is enough to fix it and send the fps back to 60. It's also only happening on my iPhone 4S, which has 512 MB of RAM, and doesn't happen on my iPad, which has one gigabyte of RAM. It's also crashing cocoonjs.

The game doesn't even have anywhere near the amount of animations and graphics that it's going to have, and I haven't even started on sound effects and music yet. This isn't a matter of not taking in cosiderations of designing for mobile - it's a matter of keeping the entire entire game in memory at once when only a part of it is needed.

I know webGL has memory management, but that's useless for mobile because they don't support it yet. Also, isn't that only for VRAM? Doesn't everything still need to be in RAM?

My question is, will there ever be some way of managing memory better, or is this something html5 simply doesn't have the capability to do? Will cocoonjs's eventual implementation of memory management fix this problem (as mentioned, it's currently crashing cocoonjs)? This is an essential feature for larger games like mine. Because if there isn't some way for this to be implemented there's no way larger games like loot pursuit can be delivered on mobile, even though aside from using too much memory it runs fine. It might even be a problem for desktop games as well, that's a lot of memory use! :(

Tommyttk - true about the built-in local file capabilities. There is a plugin someone made that enables local file manipulation via node webkit, though.

I've used both. In my opinion, construct is vastly superior. Sub events alone would be enough to have convinced me, but also objects can have named variables and as many of them as you want, the behaviors aren't useless because they aren't buggy and actually work, none of that spread value nonsense to get multiple instances working, event sheet includes, no broken object references, local variables, updates every week or two, the list goes on and on.

I don't mean to bash MMF, but it was so frustrating to work with. I felt like I was fighting it more than I was making a game with it. C2 in comparison, glides.

Tommyttk - perhaps you missed that C2 can export to exe (and Mac and Linux) via node webkit.

You can also give the object a variable and set it to the platform speed, then you can pick by comparing the variable.

This is an English speaking forum, so please stick to English or provide a translation. Thanks!

Loot pursuit was originally being made in construct classic, it's only very recently I've been letting people know I've switched to c2 for it, so he probably didn't know (I'm not even sure I had announced it publically anywhere when he made the post). Besides, at the speed I work, it's very likely C-7 will finish his first, therefore being the first released rpg with C2.

I don't want to hijack the thread though, so let's get back to talking about courier. Nice to see another rpg being made with C2! :)

Graphics cards do not render anything offscreen automatically.

If by scaled to 50/60% you mean resizing the window, at a guess it sounds like you're hitting the pixel fill rate limits of your graphics card, but that doesn't go along with what you said before in the other thread asking about stuff rendering offscreen. Pixel fill rate, btw, is not a c2 limit, that's a hardware limit, cards can only draw so many pixels per second. Without seeing a screenshot or your capx it's hard to tell, though.