dulsi {l Wrote}:Trophies are not preregistered with the Gamerzilla server. Instead the first time someone connects to a server with a new game, it uploads the trophy list and images.
I see. This is pretty smart actually, thanks for the clearification!
dulsi {l Wrote}:curl and jansson are the only dependencies. I'll update the README to call that out.
Thanks! There's also a ".deps" file.
dulsi {l Wrote}:LibGamerzilla was not designed with WebAssembly in mind. I don't really see how you could design it with WebAssembly. If I use site A for my gamerzilla instance, can the web assembly of site B connect to site A. I don't think that is allowed.
Only if the server sends a special HTTP header allowing cross-site origin. But see my next answer too.
dulsi {l Wrote}:I don't want people entering credentials into site B so it can do the connection. To support that you would want to authorize a token that is limited in what it can do which is not currently available in Gamerzilla.
I agree, that would be an overkill. BTW I was thinking about something simpler, what if the WASM is downloaded from the same server where the Gamerzilla server runs. Then site A is simply the same as site B, no complications (to be honest, I wasn't thinking about separate site A and site B, but you're right, that's a perfectly valid use-case too).
dulsi {l Wrote}:LibGamerzilla expects that you would store a copy of the achievements locally. That is what the second parameter to GamerzillaStart is. Some developers will put it in the game directory. Others prefer a file in the home dot folders. (I prefer the later but LibGamerzilla does not require it.) It could be modified to allow you to not have local copy of achievements but that is not currently implemented.
Ah, I see, makes sense. For that the only solution available for WASM is the LocalStore interface (think about it like huge cookies, certainly not like files, much more like a permanent getenv/setenv interface). BTW I don't think you should implement all, a proper hook interface is more than enough, especially if one can disable the local copy simply by setting those hooks to NULL.
dulsi {l Wrote}:There are hooks to override the reading of trophy list and images. This is used for the Godot implementation so that everything is packaged together. (It should be used for java as well but I haven't implemented that yet so you have the jar plus all the gamerzilla files.) It is the GamerzillaSetRead function.
Nice! This sounds great! Only if there were similar functions for setting the local copy hooks.
dulsi {l Wrote}:getenv("HOME") is only used if you specify "~" in the directory path.
Yes, but on Android there's no such thing. You have to use a special function :-( (Which makes no sense, isn't that supposed to be a Linux under the hood?) Same with mingw (although under Win HOME is usually set, so no probs), but the proper way is to call "SHGetFolderPathW(HWND_DESKTOP, CSIDL_PROFILE, NULL, 0, homedir)" to get the user's home directory.
dulsi {l Wrote}:The non ASCII letters in home path is an interesting issue. I assumed when you get them with getenv you would get UTF-8 and that would work with the file functions.
Yes, that's how it's supposed to be, but unfortunately it isn't (and not just for getenv, with any path). For example "fopen("violá")" works on Linux, but always fail on mingw. You have to convert the path into an array of 16 bit characters, replace directory separators, and use "_wfopen(L"voliá")" (for some reason fopen converts directory separators on its own, but _wfopen doesn't, I have no clue why is that. There are other differences too, for example "remove" removes files and directories as per POSIX, but "_wremove" only works for files, not for directories, you'll need "_wrmdir" for that latter).
dulsi {l Wrote}:Is this something you would use?
Well, yes, there are lots of non-English Windows machines in the wild. Mine happens to be one. (Frankly I never use special characters in filenames, not even spaces, but thanks to MS, the localized version of "Documents and Settings" for example already has some. And people tend to use their own writing system for their usernames, like CJK or Cyrill, in which case localization workarounds with canonized paths do not work either, you have to use UTF-16. For example "C:\Users\Пётр Ильи́ч Чайко́вский", but I have seen paths like "C:¥Users¥宮崎 駿" too.)
dulsi {l Wrote}:Or does it not matter because of the WASM issues? I can look into how to fix it.
Take a look at
my fopen implementation, maybe it helps! As you can see, opening a file with UTF-8 in a portable way isn't trivial sadly. (Note: I couldn't solve this for WASM, there only one file can be open at any given time, the one that the user drag'n'dropped, which is the game file. Hence all my fopen does with emscripten is setting the current offset to 0. Here the problem is, the game file can be several gigabytes in size, and all WASM APIs try to load the entire file into memory, which obviously won't work. I needed a method to only read parts of the file into memory, which adds an extra level of insanity...)
BTW, I was thinking how stable the WebAPI is? Is there a specification for it? What I mean by that, for example, would it be possible to write a drop-in-replacement of libgamerzilla in Javascript using HTTP requests only? I'm guessing if one could reproduce the same HTTP requests like the ones curl does in libgamerzilla, then that should just work, right? (With the server part left untouched.)
Thank you very much for you answers!
bzt
