#jsmess 2017-03-01,Wed

↑back Search

Time Nickname Message
01:07 🔗 SketchCow Hey, so, loading at least DOSBOX is broken on Chrome
01:07 🔗 SketchCow db isn't in here, maybe bai or someone else can look at the error.
01:07 🔗 SketchCow 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 🔗 gsathya :(
01:11 🔗 SketchCow So, yeah, this was reported but we were not knowing it was universal.
01:12 🔗 SketchCow Unfortunately, I am in Australia so I can't get my recovery code via SMS so I can't get on github
01:12 🔗 SketchCow So this issue you saw opened can't be upgraded to critical
01:12 🔗 SketchCow It means we've been not working for two weeks
01:12 🔗 SketchCow Always makes me wonder who uses us and how they handle that
01:13 🔗 SketchCow gsathya: If you could do it, it would help
01:16 🔗 SketchCow 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 🔗 Ipggi This is the case for me in Chrome 56 on archive.org and defacto2.net
01:40 🔗 Ipggi 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 🔗 Ipggi https://www.irccloud.com/pastebin/5jN1kybv/
01:56 🔗 Ipggi Also tested this on Windows `58.0.3026.0 (Official Build) canary (64-bit)` and it fails
02:05 🔗 bai ohhh, I had a fix for this I thought....
02:05 🔗 bai something to do with gamepad data....hmmm
02:06 🔗 bai let me dig into my dumb brain and see what I can remember
02:10 🔗 azakai has quit IRC (Quit: Ex-Chat)
02:14 🔗 bai this is the code that fixes it - http://pastebin.com/fEV70cc1
02:15 🔗 bai or I think a less-hacky fix has been incorporated into newer emscripten builds
02:16 🔗 bai so either we can put that at the top of the loader code before we initialize anything, or we can recompile everything
02:23 🔗 DFJustin probably due for a recompile anyway
02:30 🔗 bai 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 🔗 bai but prior to chrome 56, instead of "null" each value would be "undefined"
02:30 🔗 bai and emscripten was checking if (typeof gamepads[0] == 'undefined') or something along those lines
02:49 🔗 SketchCow Chrome why do you do this
02:51 🔗 bai they want us to suffer
02:56 🔗 SketchCow Do you need me to put a compiled item somewhere
02:58 🔗 bai hmm, well I guess the question is whether this is affecting just dosbox, or also affecting arcade games
02:59 🔗 bai 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 🔗 bai 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 🔗 bai if it's just dosbox then we only have to recompile dosbox, otherwise we'll have to recompile everything
03:03 🔗 Ipggi I tried a few randon Internet Arcade games in Chrome 56 win and they work fine for me whereas the DosBox fails
03:05 🔗 bai 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 🔗 bai but maybe it just tickles it slightly differently
03:09 🔗 SketchCow Who is doing the recompile? I am but a simple caveman
03:11 🔗 bai 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 🔗 bai 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 🔗 bai 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 🔗 SketchCow I thought you had it. I can give you access
03:13 🔗 SketchCow If you get it done or soon, that's fine
03:13 🔗 SketchCow We had deady for two weeks plus
03:15 🔗 Ipggi Over a month ? .. Chrome 56 was released on 25th Jan
03:16 🔗 SketchCow I did say plus
03:17 🔗 Ipggi 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 🔗 bai looks like dreamlayers has been hard at work lately
03:17 🔗 bai bunch of commits in the past month, updated to new version of dosbox and everything
03:18 🔗 bai including wasm support
03:23 🔗 SketchCow Yea, he hates it and does it.
03:25 🔗 bai haha, does he hate the whole thing, or just games?
03:25 🔗 bai we just won't remind him we're using it for games. srs business only :D
03:30 🔗 SketchCow Oh, it's complicated
03:30 🔗 SketchCow If you can generate it, that's great
05:30 🔗 DFJustin oh cool I didn't know he was still updating it
05:30 🔗 DFJustin we use two different compiles don't we, sync and async
05:35 🔗 bai yeah, you're right. I ran into the standard disk space problem so I'm enlarging my vm now >:(
05:35 🔗 bai you wouldn't happen to have the compile options we use for each of those builds laying about would you?
05:37 🔗 DFJustin not me
05:39 🔗 bai I know about the sync option, just not sure if we used anything else non-default
05:52 🔗 SketchCow Time to find out
05:52 🔗 SketchCow I can snap things in such that they can be un-snapped
05:53 🔗 bai ok cool. I'm starting over on the build process now with a dedicated virtual drive just for this
05:54 🔗 bai 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 🔗 SketchCow Excellent
07:39 🔗 * SketchCow tucks in bai
07:40 🔗 bai HI I'M UP
07:40 🔗 * bai runs the next command
08:31 🔗 SketchCow Hurrah
19:19 🔗 bai 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 🔗 SketchCow Agreed
20:44 🔗 SketchCow I'm fine with flipping it
20:48 🔗 Ravenloft has quit IRC (Remote host closed the connection)
21:01 🔗 bai SketchCow: 4 u http://baicoianu.com/~bai/em-dosbox-builds-2017_03_01.tar.gz
21:07 🔗 Ravenloft has joined #jsmess
21:18 🔗 SketchCow OK.
21:24 🔗 SketchCow has quit IRC (Read error: Operation timed out)
21:24 🔗 SketchCow has joined #jsmess
21:24 🔗 SketchCow OK, let's do this
21:28 🔗 SketchCow root@teamarchive0:/0/FOF# ls emularity_engine_v1/
21:28 🔗 SketchCow dosbox-alt.js.gz dosbox-sync.js.gz dosbox-sync.mem.gz dosbox.json
21:28 🔗 SketchCow dosbox-alt.json dosbox-sync.json dosbox.js.gz
21:33 🔗 bai no idea what alt is, or what uses it
21:33 🔗 bai I guess that's the other difference between sync and nosync, the memory init file
21:33 🔗 bai so if we're changing all to sync, we'll have to also add the metadata to load that
21:35 🔗 SketchCow 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 🔗 SketchCow So it's broken right now because of that.
21:36 🔗 SketchCow Ideas? Or I have to swap it back.
21:36 🔗 bai hmmm yeah how/why/where is that referenced....
21:37 🔗 bai .html.mem is emscripten's name for what we have as .mem.gz
21:38 🔗 bai 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 🔗 SketchCow Uploading .gz
21:38 🔗 SketchCow I just added .mem
21:39 🔗 bai 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 🔗 bai so hopefully when it has the .gz it'll Just Work(tm)
21:41 🔗 SketchCow Not working.
21:41 🔗 SketchCow Do I rename as dosbox-sync.mem.gz
21:42 🔗 bai oh yeah, probably
21:42 🔗 bai 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 🔗 SketchCow I see what happened
21:43 🔗 SketchCow We did this crazy json hack to allow two sets of dosboxerage to live together
21:43 🔗 SketchCow In harmony
21:43 🔗 SketchCow Everywhere around the world, children not dying of dysentery
21:44 🔗 bai yeah
21:44 🔗 SketchCow Removing dosbox.html.mem.gz from emularity_engine_v1 for later not pain
21:45 🔗 bai good idea :D
21:46 🔗 SketchCow Still doesn't see it.
21:46 🔗 SketchCow Thining
21:46 🔗 bai got a test url I can look at?
21:47 🔗 SketchCow emularity_engine_v1: uploading dosbox-nosync.mem.gz: [################################] 1/1 - 00:00:00
21:47 🔗 SketchCow That may help
21:47 🔗 SketchCow or not
21:47 🔗 bai oh, nosync shouldn't require the external file at all
21:47 🔗 SketchCow https://archive.org/details/msdos_festival_BLOCKOUT is the one I'm using.
21:47 🔗 SketchCow I'm flailing
21:49 🔗 Ravenloft has quit IRC (Remote host closed the connection)
21:49 🔗 bai looking now
21:50 🔗 bai so, when you uploaded it, did you rename sync/dosbox.js to dosbox-sync.js, and nosync/dosbox.js to dosbox.js?
21:50 🔗 bai (and then gzip them)
21:51 🔗 SketchCow I now don't remember.
21:51 🔗 bai 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 🔗 SketchCow root@teamarchive0:/0/FOF/em-dosbox-builds/nosync# ls
21:52 🔗 SketchCow dosbox.html dosbox.js
21:52 🔗 SketchCow root@teamarchive0:/0/FOF/em-dosbox-builds/nosync# mv dosbox.js dosbox-sync.js
21:52 🔗 SketchCow root@teamarchive0:/0/FOF/em-dosbox-builds/nosync# gzip -9 dosbox-sync.js
21:52 🔗 SketchCow root@teamarchive0:/0/FOF/em-dosbox-builds/nosync# ia upload emularity_engine_v1 dosbox-sync.js.gz
21:53 🔗 SketchCow emularity_engine_v1: uploading dosbox-sync.js.gz: [################################] 1/1 - 00:00:00
21:53 🔗 bai ah, yeah I think that's reversed
21:53 🔗 bai you're in the nosync dir there
21:53 🔗 SketchCow Ok...
21:53 🔗 SketchCow ....tis....
21:53 🔗 SketchCow is frustrating.
21:53 🔗 SketchCow A sign we really let this slack
21:54 🔗 bai yeah let me get you one with the files already with the right names
21:56 🔗 bai SketchCow: http://baicoianu.com/~bai/em-dosbox-archive_2017_03_01.tar.gz
22:04 🔗 SketchCow So, it works.....
22:04 🔗 SketchCow .... But it's smaller?
22:04 🔗 bai hmm
22:05 🔗 bai yeah it is. I did notice that boris added some pre.js stuff which fiddles with canvas settings...
22:06 🔗 SketchCow 1. It works on Chrome and Firefox.
22:07 🔗 SketchCow 1a. So that's good.
22:07 🔗 SketchCow 2. It is consistently small on firefox and Chrome
22:10 🔗 bai 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 🔗 bai 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 🔗 SketchCow Let's test a fewmore.
22:14 🔗 SketchCow So, everything does it.
22:16 🔗 SketchCow I wonder if:
22:16 🔗 SketchCow - There's a command line argument we didn't have to do and now we do
22:17 🔗 SketchCow - It needs scaling and we don't have scaling
22:18 🔗 SketchCow I pinged Boris
22:18 🔗 SketchCow There's a non-zero chance we do "something"
22:18 🔗 SketchCow But the DOSBOX Logo splash is the full canvas.
22:19 🔗 bai 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 🔗 bai the css width/height seems to be set to the native resolution for this game, which appears to be 640x400
22:20 🔗 SketchCow There's a chance we have to add scale to the IA side
22:20 🔗 bai but the canvas width/height is 960x600
22:21 🔗 SketchCow But we NEVER did that before
22:21 🔗 Ipggi You can also configure dosbox to scale
22:21 🔗 Ipggi using an external config
22:21 🔗 bai yeah, I'm wondering if he changed default scaling params in an attempt to optimize performance and visual clarity
22:22 🔗 Ipggi https://www.dosbox.com/wiki/dosbox.conf#.5Brender.5D
22:24 🔗 SketchCow I agree, maybe it got bonked.
22:24 🔗 bai 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 🔗 bai lemme see if I can find that
22:37 🔗 Ipggi 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 🔗 bai yeah I suspect we have some scaling function on our end which isn't necessary anymore
22:38 🔗 bai emulator = new Emulator(canvas).setScale(scale)
22:38 🔗 bai .setSplashImage(images.ia)
22:38 🔗 bai .setLoad(loadFiles)
22:38 🔗 bai .setCallbacks(callbacks);
22:39 🔗 SketchCow We can do a loaderlab test
22:39 🔗 bai that's in the IALoader class, I'm not quite sure where we instantiate IALoader() though
22:40 🔗 bai 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 🔗 SketchCow Understood
22:42 🔗 SketchCow If you get an idea, let me know
22:42 🔗 SketchCow I'll try to roust db
22:43 🔗 bai 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 🔗 bai function IALoader(canvas, game, callbacks, scale) {
22:43 🔗 bai so it would be the 4th param
22:44 🔗 SketchCow There's another awesome file in the archive you can't get to that shows scale.
22:46 🔗 bai ah yeah, I see it now, archive.min.js
22:46 🔗 bai it SEEMS like we're passing in a scale of 1
22:51 🔗 SketchCow hank [9:48 AM]
22:51 🔗 SketchCow yes, both dosbox and dosbox-sync override the default of “2” with “1"
22:52 🔗 bai ah, so it SHOULD be 2
22:53 🔗 SketchCow 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 🔗 bai cool
22:54 🔗 bai good to have this fixed before then too, glad we caught it
23:19 🔗 SketchCow It doesn't fix it.
23:20 🔗 SketchCow 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 🔗 SketchCow But that's "good" because we now know we can fix it elsewhere in the set
23:23 🔗 SketchCow And we can do the changes, not requiring IA folks.
23:35 🔗 Ipggi Isn't that the correct size? https://usercontent.irccloud-cdn.com/file/4o78nQGp/2017-03-02_10-28-49.png
23:37 🔗 bai 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 🔗 Ipggi returns 1
23:37 🔗 bai yup, there's the culprit then
23:37 🔗 bai SketchCow: if you do the same, I'm betting you have some value > 1
23:38 🔗 bai which is from font scaling in the OS
irclogger-viewer