Halfgeek's Forum Posts

  • Are all 64x64 px, the animation has four frames in loop and a 2.5 speed and is optimized.

    Even creating five enemy at a time (when the first wave with 5 die, comes another wave with 5), play "stutters" from scratch.

    I ran on the PC with the debug CS2, CPU usage is wavering, I found 80% too much for what was happening on the screen (5 enemies with bullet 90 degrees).

    That's on your PC debug? 83% CPU usage?!

    That's ridiculous and suggests something wrong that's causing way too much CPU overhead.

    For reference, I have many hundreds of Fighters flying around fluidly dog-fighting each other with particles, trails, explosions and all that collision checking and I'm not even above 50% CPU usage.

  • Do you know of any successful platformer in recent times on PC?

    There's only been a few:

    http://store.steampowered.com/app/211820/

    http://store.steampowered.com/app/105600

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Have you got plans for a console port?

    I've noticed a trend for the past year, the PC crowd is really harsh these days whenever they see a platformer. Comments on Steam are outright hostile to newly released platformers.

    This studio recently did a postmortem for their very nice looking platformer which did not do as well as they had hoped:

    http://store.steampowered.com/app/322680/

    http://www.gamasutra.com/blogs/FilipKra ... omenon.php

    Note that they received great coverage from gaming media sites. Giant Bomb & Destructoid giving excellent reviews etc.

    This is what TotalBiscuit (popular Youtuber) had to say about it: "there may not be an audience who wants to play another puzzle platformer".

    I mean compare to a recent indie hit, Kingdom (http://store.steampowered.com/app/368230/), a very simplistic game but it has some major selling points that appeal to the PC gaming crowd: excellent pixel art (there's an expectation that 2d games = pixel art), some form of procedural generated content, re-play-ability.

    Just some food for thought.

  • Except the save issue, how is NW 0.13 ? It is better than the last versions ?

    Even though I'm migrating to Unity, in the meantime I would like to test the market with different games and C2 makes that easy.

    And to be honest if we are waiting a little more, probably will not need NW at all: Edge on Win10 is smoking fast (and probably on WindowsPhone 10), Safari on iPhone/iPad works great... Probably we will need NW only on Android and older systems.

    0.13 is about 20-25% faster on performance, using cpuutilisation as a metric for my own testing.

    It doesn't suffer stutter (minus asset loading, which you can control via loading on start of layout).

    We we still need a wrapper to make stand-alone .exe games for PC/MAC.

  • Grats!

    Now the fun part, getting NW.JS to behave with C2 on Steam.

  • MelVin

    That's what we found right away, cannot export with NWjs object, game wont start, blackscreens.

    So anything that uses that object is a no-go until this bug is fixed. I'm writing a custom save/load using arrays & JSON write/read with NWjs file access, this goes into a set path, output into text files so that it may avoid future save issues. But we'll need the bugs fixed first with the current alpha5 and C2.

  • I'm glad I decided to create my own save/load in my current project by writing/reading file instead of relying on the built-in method.

    Test it for 0.13 alpha 5, see if it works.

    The only difference between using the default save/load to the custom file write/read is that you have better control of what data is saved, but the file still needs to be stored somewhere.

    This is where the bugs are crippling. The new NW.Js ignores your set data path, it sets its own temporary folder so your file isn't there to be retrieved in the next play session.

    I had a Nexus 5 mobile from Google. An Android update broke my mic/earpiece function, the phone would only work to make calls with headphones. This was an official Google product which they charged a lot of $ for and they screwed it up badly. I have NO faith that Google knows what they are doing.

    This is why reliance on them to get Chromium right, for C2 and later C3 to function well, is a mistake.

    Edit: Can't seem to test with the C2 NWjs object (for file control) for the new 0.13.alpha5, project exported with that object fail to start and just hangs, but without the object its fine.

  • > As for the Intel HD graphics situation, in my game test cases, it's not specifically a fill-rate or hardware performance issue. It's a WebGL issue, or rather, Intel's poor performance with many of the shader effects within C2. Removing those effects, game performance is FINE. Same game, with and without a few shader effects, goes from stutter mess to smooth performance on a HD4000.

    >

    That's not WebGL's fault, it's exactly what I was talking about, just weak hardware. You'd see exactly the same performance characteristics with those effects in a native app. You can assume WebGL performance is identical to a native app using OpenGL.

    I'm not saying that it's WebGL's fault.

    I'm saying it's Intel's fault, either hardware or drivers, but its very slow at processing shaders that are based on OpenGL.

    It's nothing to do with fill-rate, it's specifically WebGL shader limited and if people who use C2 knows this, then they should design their game to not use effects or do not target Intel HD graphics at all. It's a limitation regardless of who's at fault.

  • Ashley

    I do agree with your points, most of them.

    However, any focus on a functional export option for the market market of games? ie. Consoles like Xbone/PS4.

    As for the Intel HD graphics situation, in my game test cases, it's not specifically a fill-rate or hardware performance issue. It's a WebGL issue, or rather, Intel's poor performance with many of the shader effects within C2. Removing those effects, game performance is FINE. Same game, with and without a few shader effects, goes from stutter mess to smooth performance on a HD4000.

  • If you set XDK to Android version 5+ it will not include the Crosswalk Runtime ~17MB saved, since it will use the Android's Chromium in 5+.

    Also these things you need to understand BEFORE you embark on a new project, you have to find the limitations of your target platform first and design for that.

    It used to be 50MB not long ago.

  • — - ha - you're right, but only if you use Scirra's nw.js v13 installation. The one from github works just fine for me...

    Edit - "just fine" does not include full screen or kiosk mode. All looks like a rather rushed introduction of an alpha nw.js to the c2 output schedule IMO.

    The one from github 0.13.0 alpha 5 doesn't work for me at all. Only Scirra's version does.

    It's a good sign there though, performance up, no memory leak.. just a few bugs to sort out.

  • Have you made a thread about it in their forum?

    Perhaps like last time, link it so we can upvote it to impress on them the urgency of the problem.

    Waiting to see what Scirra thinks of this whole episode, since only they would know for sure what's going on with the C2 engine <----> NW.Js interaction.

  • —, have you considered creating a ssytem to use nw.js file storage to store your game state inside the user's folder? After — described this to me a couple of days ago I haven't looked back. I presume that it could suffer the same asynchronous challenges that local storage provides, but this works on v13 AFAIK (although I'm using v12 still).

    Well considering the NW.Js object is causing NW 0.13 to crash, we don't know if it works or not. :p

    Nice if it does, it means I can redesign my save game using Dictionary & JSON rather than the default Save/Load. That's fine too, more direct control in the file read/write is good.

    Also, the file write to a set folder with Data Path which is ignored in the 0.13.a5 NW, it reads from a temporary cache folder that's session specific. So it wouldn't work.

  • In terms of save game state, are we totally screwed, or is there a *potential* workaround sometime in the future?

    Looks like a bug, all they would need to do is stop making a new temporary session folder for saved data at each startup. Chromium used to have 2 data paths, UserData and Data. It looks like it's defaulting to using UserData which may be causing this issue. It's also ignoring the args --data-path='./save/' which suggest it is indeed defaulting to UserData.

    Seems easy to fix.

    I just hope they fix it soon.

  • —

    Thanks for the kind words

    Yeah, not really too sure about how to go about that

    Essentially you download card templates (photoshop) and add some pictures to it. Set it up in the app steamworks. Then post on the steam dev forum asking for activation and they will. That's it.