LukeW's Recent Forum Activity

  • I think that tutorial is out of date. You only need to tick 'Export for Steam' when exporting - you don't need to modify the Chromium arguments as it now automatically configures it.

    Thanks for the response.

    I've been on 317.2 for a while due to the porting process, so never saw that 'export for Steam' button. I'll add those lines manually though and see how things go.

  • I ran this test today on two separate PCs. My scores were:

    PC 1:

    editor: 158,000

    nwjs: 54,000

    PC 2:

    editor: 80,000

    nwjs: 30,000

  • Right, so after a bit of help from Mikal over in the Discord channel, we've been able to find the root cause of all these frame drops.

    I'd been using the Construct-Team provided tutorial for getting our games ready for Steam, and one of the things that is mentioned there is that you need to add '--disable-direct-composition' to the Chromium arg line.

    construct.net/en/tutorials/using-greenworks-steam-2853/page-4

    Once I deleted this from the arguments, the frame stutter issue disappeared entirely.

    Laura_D, sorry to ping you over this, but as the author of the tutorial I thought I'd bring your attention to it. It seems that this line is causing some really nasty performance issues on certain machines. From my testing, I've only seen it on AMD-based gpus, but that's a pretty limited pool.

    It sort of creates a bit of a conundrum for Steam exports though. We can omit that line and have smooth games across different hardware types but that limits certain Steam functionality (though from what I can see, does this only stop the achievement icon from popping up... is there anything else it does?).

    Alternatively, we could have a separate 'beta' build for players who have the issue, that they can then opt into (losing the Steam popups in the process). Of course, that assumes that players who experience this issue will actually go to the appropriate forum and make the change themselves which, honestly, is probably not the best way to handle this.

    Also, I get the feeling that this is a separate issue to the performance differences that I mentioned earlier when comparing full frames between in-editor previews and nwjs exports, which VinniePin just started a thread on. I just noticed that frame difference while trying to chase this issue down.

    Also also, I'm aware that this is now falling out of the scope of Construct in the sense that it appears to be an nwjs specific issue. But it's certainly something that's going to affect the majority of Construct users until a proper fix is in place.

  • Well that wasn't the response I was hoping for...

    Following up on this. I had another user post a screenshot of the main menu and noticed their frame counter was hitting 56fps. Considering there's hardly anything going on in this section (at unlocked I'm seeing over 4,500fps on this screen), the fact that the nwjs build cannot maintain a steady framerate is pretty worrying.

    This also means that it's not isolated to my PC.

    CPU/GPU usage in this area:

  • I'm experiencing a lot of framerate loss when exporting to nwjs and, more concerningly, the project is unable to maintain vsync rates despite hitting well over that target framerate when running in unlimited frame modes for testing performance.

    I've attached some comparison screenshots below. The three shots are different zones in my game with varying levels of stuff going on. The column on the left is running in the editor (Chrome r317.2) with unlimited frames. The middle column is the nwjs export with unlimited frames while the right column is NWJS with vsync (with a target refresh rate of 165hz). I didn't include a screenshot, but running with vsync from within the editor DOES match the target rate.

    As you can see from the pic, even in areas where I'm hitting over 1000 fps, the computer is not able to consistently hit the vsync target, and this only gets worse as the areas get more complex. It becomes really noticeable with camera scrolling, and is causing a jankiness to the camera movement despite the game still running at high frame rates.

    Dropping my monitor refresh rate down to 60 still results in missed frames with vsync on, bouncing down to 56-57ish in a lot of areas. Switching monitors on my main PC had no impact, though interestingly, when I launch the game off my old PC I don't get any frame loss with the nwjs build, despite it being a much older system (Intel i5-4560k). I'm wondering if this is an AMD issue (my main PC is a Ryzen 7 5800x, which should be more than enough to handle this).

    Not sure if it's worth mentioning, but with unlimited frames, the cpu is the clear bottleneck, with gpu only hitting about 10% usage.

    Other things I've tried:

    Rolling back Chromium to earlier builds

    Running it with the NVpatch

    Reinstalling chipset drivers

    Making sure graphics card drivers are up to date

    I'm at a loss as to what else to try. I had a small amount of users mention that the game suffered occasional performance issues during a closed beta, and now I'm wondering if they were experiencing something similar.

    What else can I try?

  • if you targeting consoles, best practice to do your entire game in Javascript, visual and all... that way you can have one streamlined code...JS in this case 100% if possible. and when u go to a 3rd party they just replicate what u did in JS in C++ or C# which is usually used in consoles.

    If you're targeting consoles, you'll want to do the opposite. The porting studios use their own wrapping tools to convert the event sheets into C++. They will actually struggle with any custom JS scripting in your project because of this.

    That ^ only applies though if you're specifically going for a porting studio that focusses on C3. I'm not sure how many porting houses actually write the whole programs from scratch - that sounds expensive!

  • I think there are three porting houses that have ported construct games in the past, maybe there are more that I never heard of, would be cool to have a list

    https://www.seaven-studio.com/

    https://www.ratalaikagames.com/

    https://mp2.dk/

    Looks like Seaven Studio might've finally gotten to the point of being C3 ready (according to their website). 6 months ago or so they were still only doing C2, so that's positive news.

    mp2 are booked out last I checked.

  • But for the time being I think third-party porting services is a pragmatic compromise.

    I was speaking with my publisher about this and apparently they use porting services for all the games they release, whether it's Unity, Unreal, GameMaker (hell, they've even published an RPGMaker game using a porting service). They say that despite most engines claims to support console exports, the reality is that it's a bare minimum sort of thing and not fit for release.

    The real issue with Construct 3 though, and is pretty much my main sticking point in continuing with the engine after this current game, is that there are only two porting studios that support the engine, and one of those isn't taking on new projects... so essentially we have one porting studio to get our games onto console. This is actually a pretty major concern. What happens if they also get too busy to take on new jobs?

    I'm not sure if there's anything that Scirra can actually do about this, but for me moving forward, I consider it a deal breaker.

  • yeah, I'm not too concerned about Linux and Mac atm. If we add that later I can just use platform info to pick it.

    Cheers for the answer :)

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads
  • It's surprisingly difficult to find a clear answer on this, so I thought I'd ask here.

    Ashley, I've been asked by my publisher to store user save data in the AppData/Local folder and am currently using nwjs.username to point to it. This works on the computers I've tested, however, I'm also a tad concerned in case there's a scenario where this might point to a folder that doesn't contain that path as, in that situation, it will fail to create the full path.

    This is what I currently have on starting a new game:

    Thanks

  • Are you using Greenworks? I thought that only goes up to 0.71 (I'm only just looking at integrating Steam now, so I genuinely don't know)?

    +1 for this issue. Getting small lag spikes when using the editor.

    For me, it's mainly noticeable when autofill does it's thing - if I type out an object quickly and hit tab, sometimes it doesn't register all the letters and will pick a different object that starts with the same first letter. For example, I want to compare a condition with a 'bugWorm' object, so I quickly type 'bugW' followed by tab into the field, but it will pick 'bugFly' instead.

    Not the end of the world as I just have to slow down a second (literally just a second) to make sure it's filtered down before hitting tab.

    Though, I did have one lag spike yesterday and the editor never recovered. Had to revert to an autosave.

    Thinking about this though, I think it might be happening more the longer my project is open. It's not unusual for me to have the project open for +12 hours a day. I'll have to pay attention to when this happens in relation to how long I've had the editor open for.

LukeW's avatar

LukeW

Member since 26 Mar, 2017

Twitter
LukeW has 9 followers

Trophy Case

  • 7-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Coach One of your tutorials has over 1,000 readers
  • Regular Visitor Visited Construct.net 7 days in a row
  • RTFM Read the fabulous manual
  • Email Verified

Progress

12/44
How to earn trophies