Someone pointed out recently that Never Gives Up Her Dead makes iplayif freeze up and choke.
It’s a large game file, and even the free version contains graphics (they’re just locked), so it makes sense if it were passing some kind of limit.
This is the url IFDB gives:
Any suggestions? I actually don’t recommend online play for this game anyway as it would get messed up if I released a new version, so I might just remove online play altogether, but it might be nice to find a way to fix this.
Edit: These are the errors it throws that it doesn’t throw for other games:
It doesn’t look like the game is exceeding any limits, it’s just calling glk_current_time and there’s a bug in RemGlk-rs or its dependencies that breaks that Glk function. The stack trace includes a function called <chrono::offset::local::Local as chrono::offset::TimeZone>::offset_from_utc_datetime so it seems like the date-time library used tries to do something wrong.
Yeah there shouldn’t be any wasm-bindgen code in Parchment (except for the new glkaudio library). I’m confused how it got there because I don’t remember it ever being there in the build logs. I guess I missed it one time.
The “weird thing” is calling Glk date/time functions, I don’t know why NGUHD calls them (especially during startup) but many other games don’t and that’s most likely why they’re fine. This really doesn’t look like there’s a way to invoke this Glk function that wouldn’t crash in the same way.
I just rebuild Parchment. There’s no wasm-bindgen or js-sys in the dependencies, but there was also no changes at the end - it was byte for byte identical to what is already on iplayif.com.
Could Chrono have vendored some other crates maybe? That’s the only thing I can think of. Well the wasm-bindgen is just a text message, so that makes sense. It’s just js-sys that shouldn’t be there.
I thought this must have been a recent breakage, but actually I haven’t been running the full Glk tests in Emglken, only for RemGlk-rs on Linux, so I guess it’s never worked since I switched to RemGlk-rs.
This is probably nothing to do with it, but with WASM something had me going for ages that kept producing weird results;
by default the WASM stack size is only 64k. I imagine this has already been adjusted in your build, but it had me over since for ages i didn’t know how limited it was.
You can easily increase the stack size at build time. If you haven’t already, consider this before it bites.
I ended up replacing the Chrono library with the new Jiff library. Which also doesn’t support getting the local timezone in the browser, but it was at least easier to manually get it and patch it in.
