search

greenworksjs / greenworks

Community maintained version of Greenworks - a Steamworks API for Node/Electron/NW.js
MIT License
17 stars 2 forks source link

Kickstart this repo #1

Open insraq opened 2 years ago

insraq commented 2 years ago

Following the discussion here https://github.com/greenheartgames/greenworks/issues/306 , here's the plan to kickstart this repo.

If during the above work, anyone feels that greenheartgames/greenworks is a better base to work on instead of this fork, we can switch to that one as well.

Armaldio commented 2 years ago

I can convert every js file to a typescript file

Spacetech commented 2 years ago

Happy to see things moving forward 👍

My 2 cents regarding which fork to work off of: It really depends on what folks are more comfortable doing.

The main reason to go with mine is that the NAPI conversion is done and it's compatible with Steamworks v1.53a (currently shipping in my games depots on all OS's). However the fork is old so a lot of the changes done in greenworks are missing in it. For example, reorganizing the large api file into separate ones is not in my fork. There's also various apis that are missing.

So the choices are:

  1. Reorganize my fork and get it up to date with the existing greenworks
    1. General file reorganization - split the api file into separate parts, like what was done in the original repo.
    2. Go through greenworks commits and find what apis are missing. To stay organized, we could file issues for each of the missing things.
  2. Migrate the existing greenworks repo to NAPI
    1. This would involve updating bindings in every file, updating how the async workers work, etc.

For option 1 - Once the main api file is split into multiple files, it should involve a bunch of smaller, mostly separate changes, where we re-implement the missing apis. For option 2 - I kinda view this as a single large work item. It takes time and you need to know how NAPI / node bindings work.

My view: I'm not interested in doing the NAPI conversion a second time 😓 , so someone else should take up the mantle for that if option 2 is chosen. I'm happy to code review it though!

Armaldio commented 2 years ago

I think we should also move this issue to discussions and use projets to plan things

Gurigraphics commented 2 years ago

The main reason to go with mine is that the NAPI conversion is done and it's compatible with Steamworks v1.53a (currently shipping in my games depots on all OS's). However the fork is old so a lot of the changes done in greenworks are missing in it.

I generated with your project the "greenworks-win64.node" for Electron and NW.js. But, I couldn't use it. Which version of Electron and NW.js is supported?

Also, I created a repository with a template from NW.js. https://github.com/Gurigraphics/NWjsTemplate You can edit the json and choose any version. And then simply use the command: npm run win, npm run linux, etc, This downloads and generates the executable automatically with custom icons. This makes easier to be able to change versions constantly.

Something like this could be available in this repository for NW.js and Electron. However, NW.js have or had a small problem with Steam Overlay. Maybe better is use Electron.

Spacetech commented 2 years ago

I generated with your project the "greenworks-win64.node" for Electron and NW.js. But, I couldn't use it. Which version of Electron and NW.js is supported?

Can you explain what issues you saw when trying to use it?

My game is running on Electron 16.0.5. Any electron version that supports NAPI should work. I don't know which ones off the top of my head, maybe Electron version 12 and above? I have not tried to use NW.js with the module. Steam overlay with recent Electron versions on Windows has been working well for me. I generally move to new Electron versions quickly as I want to stay up to date with the latest chromium version.

The build command I run is something like node-gyp rebuild --target=$version --arch=x64 --dist-url=https://atom.io/download/electron, where $version is the electron version (16.0.5). It's worth noting that the specific version you build with is not that important because it's NAPI, so it should support multiple Electron versions as long as you build it to some minimum level.

Gurigraphics commented 2 years ago

Can you explain what issues you saw when trying to use it?

Thanks for the answer. The error was this:

Uncaught Error: A dynamic link library (DLL) initialization routine failed

Then, replacing this new greenworks-win64.node by the old greenworks-win64.node, it works again.

Spacetech commented 2 years ago 
Uncaught Error: A dynamic link library (DLL) initialization routine failed

Did you also copy over the steam_api64.dll of Steamworks version that was used in the greenworks build? If it still doesn't work, I would recommend opening a new issue for that. This discussion is getting a bit side tracked 😄

Gurigraphics commented 2 years ago

Did you also copy over the steam_api64.dll of Steamworks version that was used in the greenworks build? If it still doesn't work, I would recommend opening a new issue for that. This discussion is getting a bit side tracked 😄

Probably yes. Steamworks_sdk_153a: sdkencryptedappticket64.dll, steam_api64.dll Anyway, another day I try again. If it doesn't work, I'll open the issue. Thanks

Armaldio commented 2 years ago

@Spacetech @Gurigraphics Please, open a separate issue, thanks

Armaldio commented 2 years ago

So, guys, what are you working on ? I've started working on the CI

Can I have some feedback here

ceifa commented 2 years ago

What do you guys think about add greenworks on npm? So we can have a better version management and add files to be ignored on publish.

sleepingpandagames commented 2 years ago

What do you guys think about add greenworks on npm? So we can have a better version management and add files to be ignored on publish.

I do believe this is a really cool idea, but I'm not sure if Valve will allow that.

I asked on the Steamworks forum if it would be okay to host SDK files on a public repository. Here is the link to the post.

I'll keep an eye on this. If I still have no anwser from Valve after a few days, then I'll contact them directly.

In the meantime, @Armaldio, if you want I can send you the latest SDK versions you need via e-mail.

Armaldio commented 2 years ago

  1. Publishing greenworks on npm mean only publishing .node addons & .js files. SDK will not be available. SDK is only used to build the .node files

  2. Greenworks is already used on npm. We either have to contact the owner to take ownership or to publish to @greenworks/greenwork (prefered for consistency with GH org)

  3. In the meantime, @Armaldio, if you want I can send you the latest SDK versions you need via e-mail.

It seems a regular account (which I have) is able to download the steamworks SDK, so I have the files ;)

insraq commented 2 years ago

Sorry for the lack of updates. I have just had a chance to skim through the whole codebase - it seems that Spacetech's fork is really old and is missing several APIs (and have some extra). I wonder whether it makes sense to move forward with Greenworks's repo instead?

@Armaldio Apart from a newer (and maybe better) API, are there other benefits of using NAPI instead of NAN, especially w.r.t CI setup? For me, I am inclined to add the missing feature onto Greenwork's repo and postpone the migration to NAPI - after all, most game developers won't benefit directly from the API migration and it's a lot of extra work.

Armaldio commented 2 years ago

Isn't the missing APIs are a matter of copy pasting ?

  1. I have already put some time on this repo to migrate and improve CI
  2. I think it's better to add missing APIs directly to NAPI instead of migrating them later
  3. People will not have to worry about compiled addon version with NAPI That's the whole point. With the old nan, I have to compile to multiple versions, the setup is hard and some versions doesn't compile at all or require hacks. Also, only LTS/supported versions of runtimes are supported. With NAPI, wider ranger of versions are supported. Even deprecated runtimes.
insraq commented 2 years ago

I see. So NAPI does provide a much simpler CI setup.

I have compared these two codebases - Spacetech's fork is very dated and these two forks diverge a lot. So trying to reconcile the difference seems to be a lot of work. Adding missing API is not simply "a matter of copy paste" unfortunately. If moving to NAPI is a must, then there are two options:

Both are quite a lot of work and will take time to get there - I was thinking in the meantime, does it make sense to start to add missing features to Greenwork's repo so that game developers would have access to the new Steamworks API in the near future?

Armaldio commented 2 years ago

Adding missing API is not simply "a matter of copy paste" unfortunately.

:disappointed:

I'm not gonna work on c++ parts, so in the end, it's your call

Gurigraphics commented 2 years ago

Both are quite a lot of work and will take time to get there

I'm testing FFI-NAPI. This is 50x simpler https://github.com/Gurigraphics/ffi-napi-steam-js/blob/main/index.js However, getting the "steam callback" and "steam overlay" to work is still a mystery.

Have you guys already tested this?

I've seen in the benchmarks that FFI is a little slower. But not everything requires a lot of performance. And if it worked, it would be a lot less work.