stricky's Recent Forum Activity

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

stricky's avatar

stricky

Member since 28 Jul, 2014

None one is following stricky yet!

Trophy Case

  • 10-Year Club
  • Email Verified

Progress

11/44
How to earn trophies