Danwood's Recent Forum Activity

  • I just figured out it's caused by the DPI, and multiplying ScreenW/H x PixelRatio fixes it.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • I'm trying to determine screen size in pixel using platforminfo -> ScreenWidth/Height. I have a 1920x1200 display and windows uses that res, but ScreenWidth only reports 1536x960 instead, for some odd reason.

    Due to this discrepancy, i can't properly set the game events to scale resolution according to display res. I'm not looking for the canvas size, which varies when resizing the game window, but for the actual screen res. I was expecting ScreenW/H to show the actual resolution. is there another way? And why ScreenW/H shows a resolution tha tis not correct?

  • Hierarchies is the right answer. Fundamentally there is no way to completely stop the lag with the pin behavior, such as scenarios where you pin A to B and also B to A. If you don't want to use hierarchies, you will probably end up with lag.

    Alright. The temporary solution is to put all the entities in the same project folder, that fixes it for now. I will switch to hierarchies after the next regular update on my steam game, since doing that will break savegame compatibility (DinoSystem is quite complex).

  • Use hierarchies instead of pin.

    I know pin is a superseeded feature, but i got reasons for using it in this instance.

  • I noticed there's a lag when an object is pinned to another object which is pinned to a third one, if you move it.

    I've put the 3 objects in the same folder in the projects bar, and that fixed it.

    Question1: is there another better solution?

    Question2: which is the best folder structure organization, considering this issue? I previously organized my folders based on type (player, vegetation, items, plugins, tiledbackgorund, etc) but apparently this is not the best way if i pin an arrow to a quiver which is pinned to the player...

  • Most bugs happen when people use this condition with objects that have multiple instances. Like "Enemy HP=0, Trigger once"

    Hehe, that's part of the natural learning process of C2/3 -> Trigger once for multiple instances -> bug -> learning For Each -> for each related bugs -> and so on...

  • The issue with NW.js not using the GPU on gaming laptops has been longstanding, but tools like Skymen's nvPatchUI seem to offer a practical fix for enabling the discrete GPU. It's great to see updates like r417 addressing this directly for WebView2, though real-world testing feedback from dual-GPU laptops would be valuable to confirm if it's solving the problem comprehensively.

    r417 doesn't work for me, because the exe that should be patched is msedgewebview2.exe, not the exported game's exe.

  • I know that scenario, although I've never left off my project for more than 2 weeks, it is huge and complex, and every time i return to it i feel the same you described.

    I would suggest to give the project some time: play it, find some smaller things you want to change/improve, and attempt to do that. Trial and error, familiarize, and you'll slowly grasp it again. Given enough time, it could work even with projects you did not create in the first place.

  • Since NW is going to be phased out, I'm exploring a possible temporary solution for sticking with WebView2 and allow usage of discrete GPU.

    I'm using the Fixed WV2 export, patching msedgewebview2.exe with the NVPatch. It works (as expected) but the antivirus doesn't like it.

    I'm out of ideas...

  • Ashley

    I tried the patcher, it doesn't work for WV2 (but does for NW), i suspect the exe that should be patched is not the exported game's exe, but msedgewebview2.exe in program files/microsoft. That's probably why the changes in r417 don't work either.

  • The patcher doesn't work for WV2, i suspect the exe that should be patch is not the exported game's exe, but msedgewebview2.exe in program files/microsoft

  • In that post, I mentioned an update in r417 that may help, but nobody has responded to that yet - it'd be interesting to know if it made a difference for anyone.

    WV2 export still doesn't use the discrete GPU, unless i export with --force_high_performance_gpu arg, which, as i mentioned in the post, seems to add an odd janking/stuttering, which is hard to notice but i can guarantee is there for me.

    The only way to fully and properly use the GPU on WV2 for me is to mess with the Nvidia settings and set the WV2 exe (the one in programs/microsoft, not the exported one) to "use full power".

    Still like that after 417.

    On NW.js i can just rename the exe to "run_game", now i can try the tool dop2000 post mentions, which is probably even better.. i'll report back.

Danwood's avatar

Danwood

Member since 2 Jan, 2014

None one is following Danwood yet!

Trophy Case

  • 11-Year Club
  • Forum Contributor Made 100 posts in the forums
  • Regular Visitor Visited Construct.net 7 days in a row
  • Steady Visitor Visited Construct.net 30 days in a row
  • RTFM Read the fabulous manual
  • x6
    Great Comment One of your comments gets 3 upvotes
  • Email Verified

Progress

17/44
How to earn trophies