stricky's Forum Posts

  • frayt, yes I did. The problem turned out to be a command line switch of "--disable-gpu" set on Chrome. No idea how that was set as I don't recall ever setting it manually.

    Chrome performance is back to normal. I still maintain that Edge and Brave give noticeably better performance with less stuttering/ FPS dips but that's a topic for another time once I've better optimised my game.

    Thanks all for the help.

  • I have both "Use hardware acceleration when available" and "Override software rendering list" enabled in Chrome. Running on a high spec PC with latest graphics card drivers. Don't have any extensions installed or anything else that might impact Chrome performance. Still getting very poor performance in Chrome.

    I tested using Brave and I'm getting 50-60 FPS so the issue is definitely with Chrome. Not sure if it's a GPU issue in my case as CPU usage won't go above 10% according to C3 cpuutilisation.

  • Migrated a large C2 project to C3 (5000+ events, large number of animations in Spriter). For some reason, CPU usage won't go above 10% and as a result the game runs at 5 FPS in Chrome. Project also crashes frequently - probably because a large number of sprites are created and positioned when the layouts are started.

    The project runs fine in C2 at 60 FPS on Edge Chromium without crashing. Switching to Chrome with C2, I get the same performance issues as C3 (CPU at 10%, 5 FPS). Unable to preview my project using C3 on Edge, so not sure where the issue lies.

    The only addon I'm using is Spriter. Even though the C3 Spriter addon hasn't been updated in a while I haven't seen any reports of performance issues with Spriter on C3.

    When exporting in C3 using node.js, CPU use is no longer limited and performance is improved but the game frequently crashes when switching layouts which doesn't happen in C2.

    Running latest browser, C3 and Spriter addon versions. Other than CPU not being utilised when running in browser, the debugger is not giving me any clues as to what the issue could be.

    The events and layout loading can be improved but I assumed if everything ran fine on C2 it would run on C3. Any suggestions appreciated as to where I should look to identify the problem and get the game running in a stable fashion on C3 using Chrome.

  • Great news.

    lucid, , please keep the community updated on when work will start on porting Spriter to C3.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • Ashley, any update on when this will be addressed? Even just a rough ETA. Would be nice if you could share a high level roadmap of when major features are planned for C3. As it stands, anyone making anything remotely ambitious has to stick to C2 for the foreseeable future.

    I really hope v1.0 of C3 provides the necessary SDK support otherwise I don't see many C2 customers migrating to C3, and that can't be good for the company.

  • Ashley, can we get an ETA on when the SDK will support drawing to screen. The Spriter team are waiting on this so they can get started on C3 support.

    Without Spriter support C3 is a complete no-go for me and I'm sure many other developers.

    Can this be bumped up the priority list?

    Cheers.

  • BBaller1337, I came across the exact issue you describe and many others because I was applying my logic to directly to C2 sprites or SCML objects. I made the painful decision to redo everything and pin my sprite/spriter objects to a C2 sprite first and it makes everything much cleaner and eliminates many, many issues like this.

    Trust me, the further you go down this route the more painful it will become.

  • Thanks for the new update lucid, it has reduced my sprite initialization time from 10 seconds to 1 second when starting layouts, and I'm seeing a 20-30% improvement in FPS. Excellent work.

  • lucid, I've emailed you the CAPX files requested and some further details on the issue. Thanks for looking into this.

  • [quote:u08oq807]Let me know if I've answered your question correctly, but you should:

    Import the old way by dragging and dropping into C2.

    Then double click the scml object and follow the steps as if importing it the new way. Then inside C2, you can delete all of the sprites it created (except the collision box sprites if you need those), and it should still run everything you didn't delete as well as direct draw.

    OK, so using this method I only have one SCML object which contains the direct draw and the collision objects (this is then pinned to my player sprite in C2). This approach works but I am finding that performance is very poor, as in 10-20 FPS. When I have two separate SCML objects one for collision and one for directdraw pinned to my player sprite in C2 I get much better performance (around 40 FPS), but there is still significant room for improvement. With just direct draw alone I get a solid 60 FPS. My collision sprites are very simple (just one rectangle sprite).

    So either I'm doing something very wrong or the hybrid method has some issues.

  • +1 for this. Using Spriter for animations and I have to constantly delete a large number of sprite objects whenever animations are updated in Spriter. Selecting one at a time in the Projects Panel is incredibly frustrating. Hopefully implementing multi select is a minor issue and can be addressed in a near future C2 patch.

    Ashley, please don't make us wait for Construct 3 to have multi-select!!!

  • lucid, I'm a little confused about the Hybrid method you describe. If I understood the steps correctly it will result in two separate (and differently named) SCML objects in C2? One using the spritesheet for direct draw and one containing the individual objects for collision purposes. If yes, I assume we then need to associate the two separate SCML objects to our player objects in C2 to get everything working as you describe?

    EDIT:

    From page 157, appreciate it if someone who has successfully got the hybrid method working help clarify the instructions lucid provided:

    "First, save your project normally, and then save a spritesheeted project. Import your non-spritesheeted project the old way."

    Does this mean import the non-spritesheeted SCML into C2 by dragging and dropping the file?

    "Follow the old to new style project conversion steps, but this time only delete everything except collision boxes, and other sprites you want to test for collisions."

    So convert the SCML/Spriter project to spritesheet format and then delete everything but the collision boxes? Not following this. If we delete everything except the collision sprites, when do we import the spritesheeted version into C2?

  • Sethmaster, so does the method you describe result in a different SCML file/Spriter object for each enemy type in C2?

    Or do I end up with one SCML file and somehow point to a different atlas spritesheet in C2 to change the enemy type?

    Would appreciate some guidance on how to implement if it's the latter.

  • lucid, a few questions. Apologies if these have been covered before:

    1. First time starting a layout, spriter objects intitialise fine and I can set character maps using the "on initialised" trigger, but when restarting layouts or moving to another layout the trigger doesn't fire. So not sure how to set character maps when moving to another layout.

    2. Does the new directdraw mode significantly reduce CPU usage? My CPU usage is very high. Each enemy has 40+ animations of 10 frames each and there are upto 10 enemies on screen at once. Enemy variations are managed via character maps so there is only one SCML object.

    3. If the individual sprites are no longer separate objects in directdraw mode how would I go about setting frame specific hit boxes? I would like to avoid having to set hit boxes outside of spriter (i.e. in C2) for specific animation frames.

    Thanks,

  • lucid, not sure if this is right place to post, but is there any way using Spriter to replicate the following action:

    Wait PlayerSprite.AnimationFrameCount/PlayerSprite.AnimationSpeed

    I can't use the on animation finished trigger as the wait takes place inside a for loop between a series of actions