Tinimations's Forum Posts

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

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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">

  • Subscribe to Construct videos now

    Klang's final trailer's up!

    Also there's the steampage! http://store.steampowered.com/app/412660

  • Subscribe to Construct videos now

    Klang's final trailer's up!

  • Tease of Klang's final trailer!

  • https://youtu.be/o1_ySZW31js?t=14m47s Got featured on Indie Games Searchlight!

    The feature uses footage from many different trailers, so about half the footage looks really outdated. Still can't complain about the endless praise.

  • Eisenhans Thanks for the heads up. Made more dedicated tests and the draw call % definately goes down way faster when I only send assets on screen to the invisible layer. Not much difference when I only send assets outside of the canvas. Guess I'll just have to cut down on amount of objects in the scene.

  • So a little followup on the whole optimizing a big scene thing. My optimizing worked, but not well enough. I need to go further. The debugger reports that draw calls is the biggest performance hog on this specific level with several thousand objects.

    I see two options: Dynamically destroy and create assets as I progress through the level to keep the object count low, or put asset outside the screen on an invisible layer. My question is, will this last option have any effect?

    It's hard for me to tell since I won't notice any performance issues before i export (which takes about 20 min) and try it on my laptop, so I would appreciate some advice before i tackle the potential huge undertaking of the first option.

    Thanks

  • Rhythm based jumping and sliding in Klang for screenshotsaturday.

  • So I got this layout with about 4000 objects in it. Naturally it runs a bit more unstable than other layouts. However far from 4k objects are on the screen at any given time. I'm planning on optimizing the scene, and I'm wondering if I can expect any performance boost by turning off collisions and visibility on objects outside of the screen? I've already done experiments with only making animations play on assets within a certain radius, which have shown good results.

  • Claiming your destiny in Klang for Screenshotsaturday.