#jsmess 2016-09-18,Sun

↑back Search

Time Nickname Message
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 🔗 SketchCow OK, got the mail from John, and I've pinged alon zakai with it.
03:36 🔗 mta has joined #jsmess
03:38 🔗 SketchCow Hey, I have a MAME make question
03:41 🔗 SketchCow emscripten_sleep_with_yield
03:41 🔗 SketchCow So, John came back with suggestions
03:41 🔗 SketchCow I'm wondering if we think we have these
03:41 🔗 SketchCow cc DFJustin bai Vito`
03:42 🔗 SketchCow http://pastebin.com/qiP9NbMe
03:42 🔗 SketchCow (DFJustin already has this in mail)
03:43 🔗 SketchCow https://github.com/kripken/emscripten/issues/3129
03:54 🔗 SketchCow I pinged Dreamlayers, why not
04:27 🔗 bai 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 🔗 bai 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 🔗 bai but in mame they happen all over the place
04:30 🔗 SketchCow How does one deal with a sleep?
04:31 🔗 SketchCow Like, do you set something, or something else?
04:31 🔗 SketchCow 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 🔗 SketchCow A mega-sed
04:33 🔗 bai 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 🔗 bai 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 🔗 bai 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 🔗 SketchCow I guess I'm asking if it's a tedious thing, or a structure thing.
04:35 🔗 SketchCow I like tedious things
04:35 🔗 bai 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 🔗 bai 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 🔗 bai 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 🔗 bai it's a structure thing
04:37 🔗 SketchCow Is there a way to call the emterpreter? I found Boris/Dreamlayers dealing with this
04:38 🔗 SketchCow Aforementioned https://github.com/kripken/emscripten/issues/3129
04:39 🔗 bai 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 🔗 bai in order for it to work, the whole stack trace underneath the sleep() call needs to be emterpretified
04:40 🔗 bai 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 🔗 bai which is fine if the heavy number crunching madness happens in some other function which isn't whitelisted
04:41 🔗 SketchCow But in theory, the slightly slower is mitigated by the lack of sleep
04:41 🔗 bai yes
04:42 🔗 SketchCow I hit this at both dreamlayers (long shot) and Alon (slightly less long shot)
04:42 🔗 SketchCow In other theory, Justin has better info now
04:44 🔗 SketchCow In that ticket, it really seems like Dreamlayers works with Alon and gets EM-DOSBOX to go hardcore speed
04:46 🔗 SketchCow I'm just wondering if all the pieces are here.
04:54 🔗 SketchCow 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 🔗 SketchCow Naturally, he'd prefer we do a NaCL thing but that would make us run great in Chrome and nowhere else.
04:57 🔗 bai 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 🔗 SketchCow bai: Alon came back with a magic flag, if you can help me find where to shove it in MAME distro.
18:34 🔗 SketchCow --proxy-to-worker
18:38 🔗 bai oh yeah, I did some experiments with that a year and a half or so ago
18:38 🔗 bai at the time it was lacking certain functionality like sound, but that should be implemented now
18:39 🔗 SketchCow Looks like toolchain.lua
18:40 🔗 bai 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 🔗 bai ah, yeah looks like some stuff is set in toolchain.lua too
18:41 🔗 bai 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 🔗 bai it'll change what files get outputted too though
18:42 🔗 bai there's a main .js file, a worker.js file, and the html is a bit different
18:42 🔗 bai we normally toss the html because we invoke using emularity.js, it'll probably need some minor changes there
18:44 🔗 SketchCow well, I'm going to try it, make the jaguar, see what blarts out the other end
18:44 🔗 bai ok
18:44 🔗 SketchCow We'll make a little dumb home for it on FOS
18:48 🔗 SketchCow Obviously it's only worth polishing off all the crazy edges if this has a noticable jump
18:48 🔗 SketchCow 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 🔗 SketchCow -rw-r--r-- 1 root root 23415 Sep 18 18:53 mamejaguar.js
18:53 🔗 SketchCow -rw-r--r-- 1 root root 20788091 Sep 18 18:53 mamejaguar.worker.js
18:57 🔗 bai 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 🔗 SketchCow Well, that's the fundamental question
19:01 🔗 SketchCow http://fos.textfiles.com/dfjustin/jaguar/jaguar-workers/
19:03 🔗 bai wow, that was easy huh
19:03 🔗 bai 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 🔗 bai virtual keyboard, volume/muting, etc
19:04 🔗 SketchCow Well, the next question is if this did anything.
19:12 🔗 bai it's an almost-playable 65% on this system
19:12 🔗 bai not sure what the non-worker version got
19:12 🔗 SketchCow Try /jaguar
19:12 🔗 SketchCow That's the non-worker version
19:12 🔗 bai yeah, trying now
19:13 🔗 SketchCow Obviously, I took a guess where to shove it. It produced a worker, so that's that
19:14 🔗 SketchCow But maybe there's other settings in the loader needed
19:15 🔗 bai 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 🔗 SketchCow I sent out a vaguely informative e-mail for people to look at

irclogger-viewer