Mikal's Forum Posts

  • I will do some more testing and then if there's still no workaround/fall back for authorization+overlay, I will post to valve.

    Good point about toast popup, then I start thinking about how to detect that, but in that case you do still want real time and the workaround scenarios start to get convoluted.

    Unless I am missing something, until we get a cleaner webview2 workaround or valve adds support for chromium based overlays (including webview2), the way forward for overlay support (if needed) is still nw.js/electron for windows.

    Thanks for your efforts on this.

  • Adding some more recent experiences, to show impact for game devs.

    It seems that doing micro transactions in game does require an overlay and there is no auto fallback.

    When you initiate a transaction via a request from your purchase server to the steam servers (after a client request), the steam app on the client side opens an overlay for transaction approval. If no overlay support, so far I have found that a fallback method does not appear. So, the transaction cannot be completed.

    The non fall back work around is to have a fully separate web site that you send the user to do the purchases and do a separate process to authorize it. It takes you a bit out of the game experience, and friction for purchasing can certainly create a hit to game income. To make it a little better, you may be able to use an iframe, but you have less control over rendering and UI in that case.

    Note that for mac, I have not yet seen an overlay working on any browser based framework. So, that would require a web based work around. The saving grace here is that Mac (and Linux) are generally a very small part of the market (in terms of user demographics.)

    If I find out other workarounds for overlay or other aspects as I continue work. I will post them.

    (Also I am following the webview2 to texture to D3D issue/feature request, which could help. Ashley, I know you are already familiar with this.)

    An idea for windows overlay though.

    Without overlay on, display webview2 window, only. When the overlay is on, use the slower preview capture API of webview2 and use that as texture to write to a D3D window that is now enabled, the overlay can display on top of that and the alpha should be ok, since they mixing on the same surface. Since overlay is on, the webview2 display does not need to be full realtime, so a more slowly updated display could be ok. After overlay disable d3d window and show webview2.

    Here is a gist that seems to support the slower capture method (have not tried it myself yet):

    gist.github.com/pabloko/5b5bfb71ac52d20dfad714c666a0c428

  • If the above does not work out for you, you can play with an experimental setting, which requires more work on the part of the dev and may not work for all situations.

    Set the above debug variable.

    If you change your display viewport (e.g., zoom, resize, etc.). You must:

    - Set the debug variable to "disable"

    - Wait for a few ticks to render with the new viewport

    - Set the debug variable back to "enable"

    In general, this is caching C3 render state, so if C3 render state ever changes, the above procedure should be rerun.

  • Ah, I took a look at the project and performance. There is a 'wait' time before the spine WebGL can be rendered, and there is a 'wait' time for that. I have found this is not always the limiter for performance.

    In your case, try ignoring the CPU perf counter for now and adding many more spine objects while setting the ACE ticks per render to 4 or so.

    In terms of watching perf, don't look so much at the CPU side, but see when the GPU FPS starts to drop from the refresh rate.

    In my case, I have hundreds of spine objects, and the CPU/GPU perf doesn't increase that much compared to 1 (with ticks per render at 4).

  • Ah, I forgot the name of the ACE. It is 'set object render rate', set to 1,2,3,4 and see if CPU usage changes.

  • If you can share the model, I'll check it out.

  • Did you reduce this on the c3 plugin or the spine 2d editor? It should be updated on the c3 addon.

  • Check out lowering the animation rate first (frames per second).

  • If there are others like me who struggle to find the latest link for the project, as previous one goes 404, it is:

    https://github.com/MikalDev/c3_spine_plugin

    also I wonder if you will support this with new SDK, thanks for your effort Mikal <3

    I probably will update over time, what are the new SDK features and version number you are looking for (so I can think about how to implement in plugin)

  • I worked around it using a bundler and globalThis to share class definitions (similar to what C3 does). I was getting spoiled by using import/modules in runtime and hoped similar was available in the editor.

    Thanks for the reply.

  • I've been using modules for runtime files, and that's been very friendly, based on this update: construct.net/en/make-games/manuals/addon-sdk/guide/runtime-scripts/sdk-v2

    Is it possible to use modules in Editor files also (so far, I have not had any luck trying out different combinations, like including the files in the Editor file addon.json list and then using import with the path?) I want to share modules between runtime and editor if possible also.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • yup it is

  • Have you tried the latest version here: github.com/ConstructFund/proui

  • Use bounding box override

    honk.su/c3_spine_plugin

    "If animation is clipping against the bounds of the C3 object, you can use the property bbox override and values to control the bounding box size and center offset. The values are based on Spine project coordinates."

  • Added Linux CEF export support (Ubuntu 22, Steam Deck testing underway).

    construct.net/en/make-games/addons/1124/steamworks-plus