[00:03] *** balrog has quit IRC (Read error: Operation timed out) [00:05] *** taisel has quit IRC (hub.efnet.us irc.Prison.NET) [00:05] *** mta has quit IRC (hub.efnet.us irc.Prison.NET) [00:08] *** balrog has joined #jsmess [00:14] OK, got the mail from John, and I've pinged alon zakai with it. [03:36] *** mta has joined #jsmess [03:38] Hey, I have a MAME make question [03:41] emscripten_sleep_with_yield [03:41] So, John came back with suggestions [03:41] I'm wondering if we think we have these [03:41] cc DFJustin bai Vito` [03:42] http://pastebin.com/qiP9NbMe [03:42] (DFJustin already has this in mail) [03:43] https://github.com/kripken/emscripten/issues/3129 [03:54] I pinged Dreamlayers, why not [04:27] SketchCow: yeah, the sleep_with_yield thing is a tough one. I spent a bit of time trying to figure it out and basically it's like he said, you need to be able to replace the sleep() calls with a way to basically exit, and schedule a function that resumes where it left off. emterpretify is probably the way to go with that, but it's tough because sleep is called from all over the codebase, so you end up having to emterpretify a whole lot more of the codebase, which c [04:27] if I recall, in dosbox the sleeps were confined to a relatively small set of locations, so emterpretifying the stack that leads to those calls wasn't too bad [04:27] but in mame they happen all over the place [04:30] How does one deal with a sleep? [04:31] Like, do you set something, or something else? [04:31] I just don't know if it's something like "write a script that goes through the code and changes all sleep functions" [04:32] A mega-sed [04:33] well...the non-emterpretified way to do it is what we did with the main loop in mame. basically the normal main loop for most games and emulators is something like, while (!shouldQuit) { doGameStuff(); sleepForSomeAmountOfTime(); } [04:34] so the easy fix is, when running in the browser, you just get rid of the while() loop and tell emscripten to call doGameStuff() 60 times a second [04:35] for sleep() it's a bit more difficult, because sleep() says "stop doing something for however many milliseconds, then resume exactly where you left off" [04:35] I guess I'm asking if it's a tedious thing, or a structure thing. [04:35] I like tedious things [04:35] so you can't just say, s/sleep/magicalEmscriptenSleep() because there's no way to reenter into that random part of that random function [04:36] except with emterpreter, which basically runs the whole thing inside of an interpreted uh....sandbox? (I dunno if that's technically correct), which can be paused at any time [04:36] so if it sees sleep() it can just say "ok, I'll just stop executing any instructions for however long, and then pick off right where I left off" [04:37] it's a structure thing [04:37] Is there a way to call the emterpreter? I found Boris/Dreamlayers dealing with this [04:38] Aforementioned https://github.com/kripken/emscripten/issues/3129 [04:39] yeah, basically when you build a project, you can tell emxcripten to use the emterpreter in one of three ways...."emterpretify everything" (slow), "emterpretify everything but exclude functions from this blacklist", or "emterpretify just the functions on this whitelist" [04:39] in order for it to work, the whole stack trace underneath the sleep() call needs to be emterpretified [04:40] so like if main() calls doGameStuff() which calls doMachineEmulationStuff() which calls sleep(), all of those functions need to be ont he whitelist, and all of them will run slightly slower [04:41] which is fine if the heavy number crunching madness happens in some other function which isn't whitelisted [04:41] But in theory, the slightly slower is mitigated by the lack of sleep [04:41] yes [04:42] I hit this at both dreamlayers (long shot) and Alon (slightly less long shot) [04:42] In other theory, Justin has better info now [04:44] In that ticket, it really seems like Dreamlayers works with Alon and gets EM-DOSBOX to go hardcore speed [04:46] I'm just wondering if all the pieces are here. [04:54] John's assessment seems to confirm from a third-party view (albeit a quick glance) that there's a worthwhile result at the end of the pile. [04:54] Naturally, he'd prefer we do a NaCL thing but that would make us run great in Chrome and nowhere else. [04:57] yeah nacl is a dead end [07:39] *** GLaDOS has quit IRC (Oh crap, I died.) [07:40] *** GLaDOS has joined #jsmess [10:23] *** godane has quit IRC (Read error: Operation timed out) [10:26] *** godane has joined #jsmess [18:34] bai: Alon came back with a magic flag, if you can help me find where to shove it in MAME distro. [18:34] --proxy-to-worker [18:38] oh yeah, I did some experiments with that a year and a half or so ago [18:38] at the time it was lacking certain functionality like sound, but that should be implemented now [18:39] Looks like toolchain.lua [18:40] this would probably be where it gets added in the build scripts https://github.com/mamedev/mame/blob/234e91f9fbdd5add24c551048df017573116fb0a/scripts/src/main.lua#L114-L147 [18:40] ah, yeah looks like some stuff is set in toolchain.lua too [18:41] not sure what the difference is there, but the main.lua one looks closer to what we were sending in our own build scripts [18:42] it'll change what files get outputted too though [18:42] there's a main .js file, a worker.js file, and the html is a bit different [18:42] we normally toss the html because we invoke using emularity.js, it'll probably need some minor changes there [18:44] well, I'm going to try it, make the jaguar, see what blarts out the other end [18:44] ok [18:44] We'll make a little dumb home for it on FOS [18:48] Obviously it's only worth polishing off all the crazy edges if this has a noticable jump [18:48] It'll all be a big pain but it'll work! [18:52] *** SketchCow changes topic to: http://github.com/jsmess/jsmess | http://www.emularity.com | faster, faster [18:53] -rw-r--r-- 1 root root 23415 Sep 18 18:53 mamejaguar.js [18:53] -rw-r--r-- 1 root root 20788091 Sep 18 18:53 mamejaguar.worker.js [18:57] it's hard to say it'll lead to increased single-thread performance, but it will be less affected by other stuff on the page [18:59] Well, that's the fundamental question [19:01] http://fos.textfiles.com/dfjustin/jaguar/jaguar-workers/ [19:03] wow, that was easy huh [19:03] looks like some other stuff might need some thought, like how to wire up jsmame_set_mastervolume and some of the other functions we bridge between js and C++ [19:03] virtual keyboard, volume/muting, etc [19:04] Well, the next question is if this did anything. [19:12] it's an almost-playable 65% on this system [19:12] not sure what the non-worker version got [19:12] Try /jaguar [19:12] That's the non-worker version [19:12] yeah, trying now [19:13] Obviously, I took a guess where to shove it. It produced a worker, so that's that [19:14] But maybe there's other settings in the loader needed [19:15] performance counter reads the same but the non-worker version feels a lot more responsive [19:44] *** godane has quit IRC (Quit: Leaving.) [19:44] *** godane has joined #jsmess [20:15] I sent out a vaguely informative e-mail for people to look at