Oh... Yeah I just realized how that's kinda silly... Works fine for everything sub 60 fps though. Didn't think this one through, at least I know what to do now. Thanks!

So I've made more tests with 144hz monitors, and it doesn't look good for my game. Most of the framerate independent event's movement use an expression similar to this "Self.Y + (5*(MonitorHz*dt))". I've made sure the monitorHz works, so in this instance it would report 144 and the dt be 0,006944. It should still all add up to 1, but it doesn't in practice. It's still obviously uses 60 as the reference, breaking my game. I'm wondering if there's any way to lock the game to 60? Some kind of vsync?

So I have this one level in particular that suffers from bad frame skips. It's a huge level with 3000 objects (cavestage_5 Ashley). Far from all of these are present in canvas at any given time, but the only thing I really see excelling on this layout is the object count, cell count, and objects pinned to something. Is any of these a potential CPU hog? In a previous iteration every pin action was performed at the beginning of layout, while a video was loading. I softened this out by removing the video source and being more selective with when the pin actions takes place. This improved it somewhat, but not entirely. I'm still on the fence wether I should cut this layout into several smaller ones. The layouts that performs best in Klang are the ones with a very small object count after all.

Thanks

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).

So at the end of the steam demo I'm preparing for my game, I'm showing clickable links to social media and the composer's portfolio. However when accessing these sites through NWjs, they don't work properly. This is the site I'm linking to: http://music.blindhandicap.com/. Both in preview and export, nothing happens when I click play on the music. Stuck in an endless loading. Is there any way around this, or is NWjs built in with secuirity blocks? (That super metroid album's a good jam btw!)

Thanks!

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.

> Rhythm based jumping and sliding in Klang for screenshotsaturday.

>

>

Why the system requirements are too high?

Because chromium likes to keep every asset in the game in memory at any given time. If only the active assets in any given layout was in memory (like scirra claims), then the recommended memory needed would be like 1-2 GB max.

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.

[quote:3d7lusot]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.

[quote:3d7lusot]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.

[quote:3d7lusot]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.

[quote:3d7lusot]

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?

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.

This is what I'm doing already... a fake loading screen. This is what the Indiecade judge never got past. It's also just unfathomably slow. A game iike witcher loads almost instantly on my computer, but a game that's waaay smaller proves too much for a lot of setups. Construct has loading issues, period. Local storage is also unstable.

So I think I've ranted about this before maybe about 5-10 times or so, but here I go again.

So I've noticed that when my game boots, far from all the assets in the game are loaded in when the loading bar reaches 100% (and why does the whole game need to be loaded in, isn't that what storing the game assets on the HDD is for?!?!). I see disk peaking at 100 % long after, and on some computers it can take several minutes before the game can proceed from the bootup loading game layout (yes two loading screens) to the actually game menu. I just had an indiecade judge reply to me being unable to play the game because of s**t like this. I'm really fed up with how Construct/Chromium/NWjs handles assets in memory. Even when 2gb is dedicated to caching assets, there's still frikkin loading times in-game, nothing can be streamed in the background without lagspikes etc. I need to know if there's any way to work around this? What can I do to make sure 100 % on the loading bar means 100 % loaded and playable? Do I need to optimize my game you say? Every layout in the game has on avarage maybe 200-300mb worth of assets in on avarage, yet they all have to be held back by the weight of the entire game. Not only has that severely limited me in what I can put into every scene, but also hampered the scope of the game. Every slight iteration takes 1min of loading in preview just to see if it worked, making new features a nightmare in practice. It's claimed that construct only loads needed assets into memory, but I've done enough tests on all browsers both in preview and export to verify that it's BULL***T! Blank layout with nothing loaded in with all audio cut from the game... 1.8 gb memory used?! WTF?!

At this rate I'll be forced to port the game to unity or something. I can't believe I've spent 2,5 years of my life on this thing only to have it break down so close to the end... I guess I should've known better when I saw the first signs of trouble few weeks into development. Construct's a prototype tool. It was never made for big projects I get that, but I just can't fathom some of the design decisions behind this engine... Keeping it simple is good for the beginners sure, but taking measures to ensure better stability, iteration times and control over assets also greatly benefits the smaller projects as well. I guess when not even the official plugins can be kept up to date and stable (greenworks, local storage looking at you), this is obviously too much to ask.

I don't mean to sound like that thankless noob that whines over why a 100 buck engine isn't perfect, but I took a chance on it, and have spent thousands of hours making a game, and touring it around the world with my own savings to have a chance at making a name for myself. That the tool I chose is the biggest reason I loose sleep every night is just extremely frustrating, and I need to vent a bit. Every issue I've had with the engine has been gradually fixed over time, but I'm afraid if this specific one isn't fixed reeeeal soon, Klang might never be launched as a C2 game.

http://www.snowcannongames.com/klang-giveaway/ Doing a free giveaway of a Skullcandy headset and free copy of Klang. Signing up wouldn't hurt your chances at scoring it! <img src="{SMILIES_PATH}/icon_e_smile.gif" alt=":)" title="Smile">