[01:07] Hey, so, loading at least DOSBOX is broken on Chrome [01:07] db isn't in here, maybe bai or someone else can look at the error. [01:07] https://archive.org/details/msdos_shareware_fb_DSWIND&external_js=1 (just to be current, console floods with error messages I don't get) [01:07] :( [01:11] So, yeah, this was reported but we were not knowing it was universal. [01:12] Unfortunately, I am in Australia so I can't get my recovery code via SMS so I can't get on github [01:12] So this issue you saw opened can't be upgraded to critical [01:12] It means we've been not working for two weeks [01:12] Always makes me wonder who uses us and how they handle that [01:13] gsathya: If you could do it, it would help [01:16] ops, please [01:21] *** yipdw sets mode: +o SketchCow [01:21] *** SketchCow sets mode: +oooo azakai DFJustin gsathya logchfoo2 [01:22] *** SketchCow sets mode: +ooo godane Lord_Nigh Vito` [01:40] This is the case for me in Chrome 56 on archive.org and defacto2.net [01:40] Funny enough I have seen these error messages before in this github issue from early Jan https://github.com/db48x/emularity/issues/10 [01:41] https://www.irccloud.com/pastebin/5jN1kybv/ [01:56] Also tested this on Windows `58.0.3026.0 (Official Build) canary (64-bit)` and it fails [02:05] ohhh, I had a fix for this I thought.... [02:05] something to do with gamepad data....hmmm [02:06] let me dig into my dumb brain and see what I can remember [02:10] *** azakai has quit IRC (Quit: Ex-Chat) [02:14] this is the code that fixes it - http://pastebin.com/fEV70cc1 [02:15] or I think a less-hacky fix has been incorporated into newer emscripten builds [02:16] so either we can put that at the top of the loader code before we initialize anything, or we can recompile everything [02:23] probably due for a recompile anyway [02:30] basically the problem is that when you call navigator.getGamepads() in chrome, instead of returning an array it returns a GamepadList object, which looks like an array but is really just an object, GamepadList {0: null, 1: null, 2: null, 3: null, length: 4} [02:30] but prior to chrome 56, instead of "null" each value would be "undefined" [02:30] and emscripten was checking if (typeof gamepads[0] == 'undefined') or something along those lines [02:49] Chrome why do you do this [02:51] they want us to suffer [02:56] Do you need me to put a compiled item somewhere [02:58] hmm, well I guess the question is whether this is affecting just dosbox, or also affecting arcade games [02:59] there's a chance we've recompiled arcade games since the emscripten patch was added, I hit this a few months ago with my dosbox win311 stuff and azakai fixed it pretty quickly [02:59] but I can't find a bug about it in the emscripten github issue tracker, we may have worked it all out over irc [03:00] if it's just dosbox then we only have to recompile dosbox, otherwise we'll have to recompile everything [03:03] I tried a few randon Internet Arcade games in Chrome 56 win and they work fine for me whereas the DosBox fails [03:05] yeah I seem to recall that being the case with my own stuff as well, but I can't recall why, since both systems should be accessing the gamepads via sdl, so in theory the same bug should exist [03:05] but maybe it just tickles it slightly differently [03:09] Who is doing the recompile? I am but a simple caveman [03:11] I'll spin up an instance and compile the latest version of em-dosbox, it'll be a good exercise for me anyway [03:11] but I don't have access to loaderlab or anything, so I'll just fire the compiled files over to you when I'm done I guess [03:12] there's a chance I'll fall asleep during the compile, already exhausted from gdc, but I'll have something for you soon [03:13] I thought you had it. I can give you access [03:13] If you get it done or soon, that's fine [03:13] We had deady for two weeks plus [03:15] Over a month ? .. Chrome 56 was released on 25th Jan [03:16] I did say plus [03:17] Chrome canary https://www.google.com.au/chrome/browser/canary.html might be useful for someone to regularly test with before these issues go mainstream [03:17] looks like dreamlayers has been hard at work lately [03:17] bunch of commits in the past month, updated to new version of dosbox and everything [03:18] including wasm support [03:23] Yea, he hates it and does it. [03:25] haha, does he hate the whole thing, or just games? [03:25] we just won't remind him we're using it for games. srs business only :D [03:30] Oh, it's complicated [03:30] If you can generate it, that's great [05:30] oh cool I didn't know he was still updating it [05:30] we use two different compiles don't we, sync and async [05:35] yeah, you're right. I ran into the standard disk space problem so I'm enlarging my vm now >:( [05:35] you wouldn't happen to have the compile options we use for each of those builds laying about would you? [05:37] not me [05:39] I know about the sync option, just not sure if we used anything else non-default [05:52] Time to find out [05:52] I can snap things in such that they can be un-snapped [05:53] ok cool. I'm starting over on the build process now with a dedicated virtual drive just for this [05:54] maybe we'll get lucky and the stuff ted plus some other guy did on the sdl_net emscripten port will mean we get that out of the box this time too [07:39] Excellent [07:39] * SketchCow tucks in bai [07:40] HI I'M UP [07:40] * bai runs the next command [08:31] Hurrah [19:19] ok I got a working build, this one's with sync. do we actually need the nosync version anymore? I'll build one either way, but I think the reason we split it out was because of performance concerns that turned out to be non-issues [20:23] *** Ravenloft has joined #jsmess [20:44] Agreed [20:44] I'm fine with flipping it [20:48] *** Ravenloft has quit IRC (Remote host closed the connection) [21:01] SketchCow: 4 u http://baicoianu.com/~bai/em-dosbox-builds-2017_03_01.tar.gz [21:07] *** Ravenloft has joined #jsmess [21:18] OK. [21:24] *** SketchCow has quit IRC (Read error: Operation timed out) [21:24] *** SketchCow has joined #jsmess [21:24] OK, let's do this [21:28] root@teamarchive0:/0/FOF# ls emularity_engine_v1/ [21:28] dosbox-alt.js.gz dosbox-sync.js.gz dosbox-sync.mem.gz dosbox.json [21:28] dosbox-alt.json dosbox-sync.json dosbox.js.gz [21:33] no idea what alt is, or what uses it [21:33] I guess that's the other difference between sync and nosync, the memory init file [21:33] so if we're changing all to sync, we'll have to also add the metadata to load that [21:35] loader.js?v=b76c82e:214 Uncaught Error: Don't know how to find file: dosbox.html.mem at Object.locateAdditionalJS [as locateFile] (loader.js?v=b76c82e:214) at cors_get.php?path=%2F7%2Fitems%2Femularity_engine_v1%2Fdosbox.js.gz:24 [21:36] So it's broken right now because of that. [21:36] Ideas? Or I have to swap it back. [21:36] hmmm yeah how/why/where is that referenced.... [21:37] .html.mem is emscripten's name for what we have as .mem.gz [21:38] I did include that file with the sync build, so we can gzip it and rename it to be consistent with what we had before, but maybe the .js file is referencing the emscripten default filename [21:38] Uploading .gz [21:38] I just added .mem [21:39] oh yeah I bet we load the file via a browserfs mapping in the json file, and it maps it into the fs as dosbox.html.mem [21:40] so hopefully when it has the .gz it'll Just Work(tm) [21:41] Not working. [21:41] Do I rename as dosbox-sync.mem.gz [21:42] oh yeah, probably [21:42] sorry I didn't know how they were named on FOS so I just dumped them into directories with emscripten's default filenames [21:43] I see what happened [21:43] We did this crazy json hack to allow two sets of dosboxerage to live together [21:43] In harmony [21:43] Everywhere around the world, children not dying of dysentery [21:44] yeah [21:44] Removing dosbox.html.mem.gz from emularity_engine_v1 for later not pain [21:45] good idea :D [21:46] Still doesn't see it. [21:46] Thining [21:46] got a test url I can look at? [21:47] emularity_engine_v1: uploading dosbox-nosync.mem.gz: [################################] 1/1 - 00:00:00 [21:47] That may help [21:47] or not [21:47] oh, nosync shouldn't require the external file at all [21:47] https://archive.org/details/msdos_festival_BLOCKOUT is the one I'm using. [21:47] I'm flailing [21:49] *** Ravenloft has quit IRC (Remote host closed the connection) [21:49] looking now [21:50] so, when you uploaded it, did you rename sync/dosbox.js to dosbox-sync.js, and nosync/dosbox.js to dosbox.js? [21:50] (and then gzip them) [21:51] I now don't remember. [21:51] I can make a new tarball with them named what I think they should be based on what you had in that dir before [21:52] root@teamarchive0:/0/FOF/em-dosbox-builds/nosync# ls [21:52] dosbox.html dosbox.js [21:52] root@teamarchive0:/0/FOF/em-dosbox-builds/nosync# mv dosbox.js dosbox-sync.js [21:52] root@teamarchive0:/0/FOF/em-dosbox-builds/nosync# gzip -9 dosbox-sync.js [21:52] root@teamarchive0:/0/FOF/em-dosbox-builds/nosync# ia upload emularity_engine_v1 dosbox-sync.js.gz [21:53] emularity_engine_v1: uploading dosbox-sync.js.gz: [################################] 1/1 - 00:00:00 [21:53] ah, yeah I think that's reversed [21:53] you're in the nosync dir there [21:53] Ok... [21:53] ....tis.... [21:53] is frustrating. [21:53] A sign we really let this slack [21:54] yeah let me get you one with the files already with the right names [21:56] SketchCow: http://baicoianu.com/~bai/em-dosbox-archive_2017_03_01.tar.gz [22:04] So, it works..... [22:04] .... But it's smaller? [22:04] hmm [22:05] yeah it is. I did notice that boris added some pre.js stuff which fiddles with canvas settings... [22:06] 1. It works on Chrome and Firefox. [22:07] 1a. So that's good. [22:07] 2. It is consistently small on firefox and Chrome [22:10] hmm, looking at the settings he sets, these are more about how pixel scaling is handled, it doesn't really say anything about the resolution [22:11] but I wonder if he optimized it by picking a different resolution that was more faithful to what the dos systems were running [22:11] Let's test a fewmore. [22:14] So, everything does it. [22:16] I wonder if: [22:16] - There's a command line argument we didn't have to do and now we do [22:17] - It needs scaling and we don't have scaling [22:18] I pinged Boris [22:18] There's a non-zero chance we do "something" [22:18] But the DOSBOX Logo splash is the full canvas. [22:19] yeah, I'm looking at the canvas parameters in the html. there's two pairs of settings, a css width/height and a canvas width/height [22:20] the css width/height seems to be set to the native resolution for this game, which appears to be 640x400 [22:20] There's a chance we have to add scale to the IA side [22:20] but the canvas width/height is 960x600 [22:21] But we NEVER did that before [22:21] You can also configure dosbox to scale [22:21] using an external config [22:21] yeah, I'm wondering if he changed default scaling params in an attempt to optimize performance and visual clarity [22:22] https://www.dosbox.com/wiki/dosbox.conf#.5Brender.5D [22:24] I agree, maybe it got bonked. [22:24] I think we do some form of scaling in the js, that hasn't changed on our end but maybe it's not necessary anymore [22:24] lemme see if I can find that [22:37] So I did an update on a test VM for defacto2 .. literally just replaced `dosbox.html.mem` and `dosbox.js` with bai's new compiles and it worked perfectly in Chrome, with no render issues [22:38] yeah I suspect we have some scaling function on our end which isn't necessary anymore [22:38] emulator = new Emulator(canvas).setScale(scale) [22:38] .setSplashImage(images.ia) [22:38] .setLoad(loadFiles) [22:38] .setCallbacks(callbacks); [22:39] We can do a loaderlab test [22:39] that's in the IALoader class, I'm not quite sure where we instantiate IALoader() though [22:40] I have to run soon, missing gdc right now to get that slide deck going for the talk, but I've got a meeting in a bit so I'll be heading down to the city soon [22:42] Understood [22:42] If you get an idea, let me know [22:42] I'll try to roust db [22:43] well, if you recall / can grep for where we say "new IALoader(...)" and see what we pass for the scale parameter, that might give us a clue [22:43] function IALoader(canvas, game, callbacks, scale) { [22:43] so it would be the 4th param [22:44] There's another awesome file in the archive you can't get to that shows scale. [22:46] ah yeah, I see it now, archive.min.js [22:46] it SEEMS like we're passing in a scale of 1 [22:51] hank [9:48 AM] [22:51] yes, both dosbox and dosbox-sync override the default of “2” with “1" [22:52] ah, so it SHOULD be 2 [22:53] I've asked Hank to do the work. You can move forward and enjoy GDC and not get nervous about your talk at all [22:53] cool [22:54] good to have this fixed before then too, glad we caught it [23:19] It doesn't fix it. [23:20] It does what I feared - the opening splash is twice as big, the initial "welcome to dosbox" text screen is twice as big, and then it drops down. [23:23] But that's "good" because we now know we can fix it elsewhere in the set [23:23] And we can do the changes, not requiring IA folks. [23:35] Isn't that the correct size? https://usercontent.irccloud-cdn.com/file/4o78nQGp/2017-03-02_10-28-49.png [23:37] that seems right yeah. hmm....do me a favor, drop to your js console (ctrl+shift+j in chrome, ctrl+shift_i in ff) and type devicePixelRatio and hit enter [23:37] returns 1 [23:37] yup, there's the culprit then [23:37] SketchCow: if you do the same, I'm betting you have some value > 1 [23:38] which is from font scaling in the OS