Can't change layout without having all assets loaded in?

Discussion and feedback on Construct 2

Post » Wed Aug 03, 2016 3:46 pm

Tinimations wrote:@newt I would if I had the time. There can be so many things affecting this, that I would have to put some real effort into the dummy project. I know that rants like this is unhelpful because I don't post concrete evidence, but it's simply because I'm stretched for time, and I won't share Klang's source at this point. It's too complete for it to be shared publicly.


Mechanics aren't the issue, content is.
Just download a bunch of public domain assets, and add them to a dummy project.
Just use the same distribution method you used in your game.

Opengameart.org
Kenney.nl
Image ImageImage
B
169
S
50
G
173
Posts: 8,316
Reputation: 110,276

Post » Wed Aug 03, 2016 4:27 pm

Ashley wrote:In a HTML5 game, the loading bar corresponds to download progress. None of the assets are actually loaded decompressed in to memory at that point. So of course, not all assets are loaded by the 100% mark - that's the point of the layout-by-layout loading system: nothing is loaded, until you go to a layout, at which point only that layout's assets are decompressed in to memory. In NW.js I guess I'm not actually sure what it has to do; if you are using package.nw (i.e. zipped assets) then it will be extracting from the zip, but if you pre-extract the zip it should just figure out there's a resource on disk so it doesn't need to do anything. I guess it might load the asset (compressed) in to RAM so it can be quickly decompressed later, which might be unsuitable for a very large game (although it would help speed up layout loading times). So, are you using package.nw and have you tried pre-extracting it?


I have tried both methods (the pre unzip is a lifesaver btw!), but I don't see any change in memory use. The boot time's way faster though. I'm just trying to get a good understanding of what the massive process in the task manager really is. The only pattern I've seen is that it grows bigger with the project as it gets more assets.

If you have say 4 GB of RAM free, and the system has 1.8 GB of files in RAM it might need later, it may well decide to leave them there. RAM is there to be used.


Which is definately nice in theory, but it's proven to be undynamic, as I've seen 32bit versions of the game crash due to this, and it doesn't seem to scale down when memory use peaks. The game can't boot on setups with less than 2gb. Also I did try turning off the sounds loading on startup, and it only made a few hundred MB of difference, it wasn't the source to the problem.


The sooner you can report issues, the more time we have to do something about them. I think it is unreasonable to expect us or any other developers to make deep changes to the engine in a few weeks. We can look in to issues, but we need time to do that.


Well I have raged about these issues frequently throughout the soon 3 year development. I get it's a risk changing priorities based on one dev who may or may not amount to a finished game (or know what they're doing), but I will stand by that the current solution is hostile towards big projects.

We do design the engine to scale to large projects, but it sounds like you've made one of the biggest projects ever in Construct 2. I definitely intend for Construct 2 to be able to handle such large games, but we might need to make a few tweaks to make it work better


The editor scales pretty well, apart from that the event sheet interaction becomes laggy over time, but that might be that my sheets are too big over that it's weighed down by the full project?

The biggest optimization to iteration I would propose is that the preview can dynamically read an updated sheet (which often is just one value changed) without the need or reloading. This would probably save me up to 2-4 hours daily of just waiting. 1 min for every time I implement a new asset is fair, but just a small value like the spray rate of a particle or a change of variable to debugging the options menu shouldn't have to suffer from this. This one flaw has probably cut Klang's scope by half.

Another potentially big save could be to make a feature to make "reference projects". Lets say I wanna make a new feature. I can make it wicked fast in an empty project, but implementing it in the main project takes ages. I was sort of able to do this with the event sheets when making the final boss. I made assets with identical names and just copied the game logic over. This was a hassle though, and dedicated tools towards this could make a power user work with the efficiency of a clean project even when working on a big project.

This doesn't appear to be related to the main point of this thread, but I'm not aware of any outstanding bug reports for local storage, AFAIK it works fine for the vast majority of users. Also Greenworks has been clearly marked as an experimental plugin for some time, but as it happens, we just released two updates for it this week.


I'll have to check out greenworks then. The local storage thing was more of a rant, as I'm experiencing problems with it without being able to reproduce the issue consistently.

If you're willing to look at the Klang source it would mean a lot to me. I might send a new build by the day's end. Is there any documentation I should prepare ahead?
B
33
S
10
Posts: 376
Reputation: 3,193

Post » Thu Aug 04, 2016 3:18 pm

rosie01 wrote:Since it's not the first time I hear someone complaining about big projects in C2, I'm really interested in what the Scirra Team has to say about this. I'd love to see this engine handle such projects as Klang without problems.


glerikud wrote:Since it's not the first time I hear someone complaining about big projects in C2, I'm really interested in what the Scirra Team has to say about this. I'd love to see this engine handle such projects as Klang without problems.


No way, we wrote the same thing. What are the odds. :o

But seriously, I'm glad that Ashley took the time and looked into this. I hope he can help you @Tinimations and both your project and the engine profits from that.
B
135
S
33
G
17
Posts: 1,557
Reputation: 20,717

Post » Thu Aug 04, 2016 3:27 pm

@glerikud

There are no odds, it's a fake post. Likely to be edited later to set up spam links.
Image ImageImage
B
169
S
50
G
173
Posts: 8,316
Reputation: 110,276

Post » Thu Aug 04, 2016 4:00 pm

newt wrote:@glerikud

There are no odds, it's a fake post. Likely to be edited later to set up spam links.

I was just joking about the odds, but I didn't know that bots use this technique. Thanks for informing me.
B
135
S
33
G
17
Posts: 1,557
Reputation: 20,717

Post » Thu Aug 04, 2016 4:16 pm

It's all nice and cool to receive informing replies from the developer
but are we going to see some actions soon or can we start forgetting about this topic now?
That's usually how it goes right or am I wrong?
(Start topic > Receive unsatisfying reply > Topic gets old with no interactions > New topic complaining about the same problem gets created and so on...)

I feel like this whole discussion is going back to old'n famous "Unload memory" suggestion, which you can pretty much find every month, suggested by different people that are affected by these memory issues. Seeing topics like these fairly often on the forums, is starting to scare me a bit. I'm currently in the middle of a large game, that gets even larger day by day and honestly so far I'm not affected by it so I don't really mind the most of the complaints about memory management.

I don't want to witchhunt but this is slowly getting into EA like levels of support, were we get responses like "That is going to happen soon; We'll be working on it in the future" with next to nothing important being done. I hope you guys understand my concerns and don't start bashing me for complaining about Ashley and his product.
ImageImageImage
B
63
S
23
G
78
Posts: 658
Reputation: 44,929

Post » Fri Aug 05, 2016 12:22 pm

@TheRealDannyyy Yeah... I just confirmed this memory problem for myself again when I prepared the steam demo yesterday. I cut away roughly 600mb of data from the game, and the game now takes 1gb less ram at any given time... I can't fathom this, Construct is such a good and user friendly tool, but it fails on so many of the very basic technical things. I will never stop being baffled by how chromium/construct deals with this.
B
33
S
10
Posts: 376
Reputation: 3,193

Post » Fri Aug 05, 2016 1:34 pm

Tinimations wrote:@TheRealDannyyy Yeah... I just confirmed this memory problem for myself again when I prepared the steam demo yesterday. I cut away roughly 600mb of data from the game, and the game now takes 1gb less ram at any given time... I can't fathom this, Construct is such a good and user friendly tool, but it fails on so many of the very basic technical things. I will never stop being baffled by how chromium/construct deals with this.

Well we can't just sit around and post this over and over again, I'll ask some of my friends that have experience with JS and all the programming stuff to look into this.
Although I highly doubt that they will be able to find any way to add this into the engine.
If they manage to get something done, I'll PM you the details but please don't wait and don't expect too much.
Last edited by TheRealDannyyy on Thu Aug 18, 2016 3:00 pm, edited 2 times in total.
ImageImageImage
B
63
S
23
G
78
Posts: 658
Reputation: 44,929

Post » Fri Aug 05, 2016 3:55 pm

@TheRealDannyyy Appreciated. Yeah I'm not expecting much. There should at the very least be a way for NWjs exports to read that data from disk and not store it in ram though... (like how every game ever made does it).
B
33
S
10
Posts: 376
Reputation: 3,193

Post » Wed Aug 17, 2016 1:47 pm

Removed information from the post by myself, PM's will be send from now on.
Last edited by TheRealDannyyy on Thu Aug 18, 2016 2:47 pm, edited 2 times in total.
ImageImageImage
B
63
S
23
G
78
Posts: 658
Reputation: 44,929

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: AnimH01, Refeuh and 14 guests