Mikal's Forum Posts

  • Version 1.11.0:

    Expose more Greenworks Steam cloud APIs to nw.js and Electron (1.11.0: supports Greenworks v0.18.0 for NW.js v0.92.0, Steamworks SDK 1.60)

    construct.net/en/make-games/addons/244/greengrinds

  • Ok, I realized that it may be because I am trying to use when refactoring an older SDK V1 addon. Perhaps that's where the issue is, this is meant only for SDK V2.

  • Ashley

    This works for me in preview.

    Does this work for you in export to html5 also? In my case it seems to put the files I want to use as modules into c3runtime.js, so they are no longer available for import using the file descriptor.

  • Use the latest version on itch. Also turn off webgpu.

  • Thanks Ashley, that helped me get it to work. I was over thinking it and using file dependency, etc.

    It is great using modules instead of other methods.

  • Not quite working for me yet (I can get main.js working, but import of another module in instance.js runtime, no so much). I tried various file dependency types. I'll do globalThis for now and wait for the examples that come with the doc updates.

  • Thank you Ashley, appreciate the help and the addition of this feature.

  • I think it is related to: construct.net/en/make-games/releases/beta/r398

    Can C3 addon files (instance.ts) also import modules? Or are the above only for event scripting?

    I know there used to be post on this, but my google-fu is failing me.

  • Try Construct 3

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

    Try Now Construct 3 users don't see these ads

  • Working on improving lighting for 3D Object addon, coming together to make a nice retro 3D style.

    Changing from simple face based lighting to vertex normal based lighting.

    kindeyegames.itch.io/c3-3dobject-alpha

  • Fund raising for large animation improvement and tutorial video for the 3DObject Plugin. Puts animation on GPU and in worker almost completely offloading from the main C3 runtime thread.

    More details and link to contributing here:

    kindeyegames.itch.io/c3-3dobject-alpha/devlog/779636/fund-raising-for-large-animation-improvement-and-tutorial-video

    C = CPU %, G = GPU %, F = FPS

  • It would be great to have the thinner versions of standalone executables, I do hope that this improves. I think someone in thread also mentioned github.com/servo/servo (will start taking a look at this myself.)

    At least webview2 got us a path to publishing to xbox (even though restricted to Creator instead of the main game store, due to MS limitations.)

    In terms of the issue of requiring specific versions of greenworks for specific nw.js versions (and electron versions), I have found that steamworks.js does not have this limitation for both nw.js and electron. One compiled binary works for various recent versions of nw.js and electron. It is also under active development. I have a fix to make it work with nw.js (and will make a PR for rs package that needs the change.)

    It has more features compare to greenworks. Perhaps create an open source version addon for it? I have a start of one that I used for experiments.

    github.com/ceifa/steamworks.js

  • Should C3 refocus the export options for desktop/steamdeck? Webview2 no longer has plans for linux or mac support.

    nw.js and electron support windows, mac fat binary, linux/steam, so seem like good candidates, as far as I know, only nw.js/electron windows really supports overlays

    Other options, Tauri?

    In terms of steamworks support which is somewhat related to export, greenworks has started updating again with later versions of nw.js, which is nice. Greenworks and Greengrinds addons work with this.

    Another option is:

    github.com/ceifa/steamworks.js

    Which works well on electron (and can be compiled for nw.js with a few hacks). It has more features vs greenworks and is actively supported. Electron supports overlay on windows. Another benefit of this build is that it is agnostic in terms of recent nw.js releases, you don't need to update with every new release.

    MS notice on cancelling Mac and Linux dev for webview2:

    github.com/MicrosoftEdge/WebView2Feedback/issues/1314

    Thanks to Salman_Shh for pointing out this post.

  • Another interesting request that may be relevant to this discussion:

    github.com/Scirra/Construct-feature-requests/issues/237

    Request to allow other 3D renderer to render in C3 context, for speed and finer grained integration (similar to what is done on Spine today (though the desire is for Spine to be fully SDK V2 compliant).

    For example, similar to these:

    For three.js - resetState()

    threejs.org/docs

    For babylon.js - wipeCaches()

    doc.babylonjs.com/typedoc/classes/BABYLON.Engine

    It would be difficult to render into the C3 FB directly, but the other engines could render into a texture in the same context that is used by a C3 drawing object would be efficient and fast and can be integrated at a finer grained level than a html layer (this is what I ended up doing for current Spine and it works well.)

    Rendering out of context and sharing with C3 (e.g. via texture download and upload from canvas is slow, I tested this with Spine previously and it was not useable in terms of performance.)

  • Ashley I appreciate this discussion, I had a different understanding about what you meant when you described supporting addons devs for porting to SDK V2. From this discussion, I understand better the limitations to the support you intend to provide. That is helpful. Along these lines I'll close the related world coord for shader and GPU rotate for object requests as discussed and rejected.

    On the other hand, we do already see some SDK V2 suggestions implemented and that does help with showing what may be possible in terms of SDK V2 and addon future development, not just porting (e.g. drawMesh() is appreciated for Spine (and perhaps Sprite2 if that releases)).

    That is helpful guidance for what SDK V2 suggestions to make and what SDK V1 era addons are likely possible to port to SDK V2.

    One other area that I think would help addons devs for the porting work is to know about SDK V1 functionality support in SDK V2:

    • Will SDK V2 be a superset of SDK V1 (all SDK V1 functions + additional V2)
    • If not, can you please let us know what functions will not be supported (in general terms for now, but details later will be needed to evaluate and implement porting)