[00:00] I don't have the link to the google doc offhand [00:00] ok no problem [00:02] fzzzy: https://docs.google.com/document/d/1FHmn1kO3PGYYCRJejZsZMFk_BxWer_pOaTUANRFroM8/edit [00:03] basically it's a difference between how many native apps are structured and how webapps generally work - ative apps tend to have a main loop which runs in a blocking fashion, while webapps want everything to be asynchronous and take as little time as possible [00:04] and then, emulators and games fundamentally rely on tings like usleep() to guarantee frame-perfect timing, but in JS there's no equivalent, apart from a blocking loop saying, while (Date.now() < sleeptime) { /* do nothing */ } [00:04] which is a horrible unnecessary waste of cpu :D [00:11] ah, yeah, js can't block. that's definitely An Issue [00:19] am i understanding correctly from this doc that mame's main loop has already been converted into continuation passing style? [00:20] and just the sleep issue needs tackling? [00:21] emterpreter's gotta be way too slow [00:23] hooking a v8 to a blender, haha [00:25] hmm, using a webworker with sharedarraybuffer for output seems like a good option. but i think that just got turned off temporarily because of spectre [00:26] yeah, that was frustrating but at least we hadn't already bet the farm on that solution :D [00:27] yeah the work's already been done to make it run in asynchronous blocks, so in theory yeah, it's just a matter of getting mame to not call sleep() and instead rely on the browser's requestAnimationFrame to keep 60fps timing [00:28] hmm, sharedarraybuffer would be perfect, because high-resolution timers is why they turned it off :) [00:28] *** godane has quit IRC (Quit: Leaving.) [00:29] anyway, we've ot one of the main MAME devs on that issue now, so hopefully he should make short work of it [00:29] got* [00:30] that'll be amazing. [00:31] yeah, that's been a blocker for lots of different stuff [00:32] it is a very hard problem. [00:37] indeed. we're trying to make two very different worlds play together [01:40] wow, i got a normal build of mame compiled no problem :) now to install emscripten [02:25] *** godane has joined #jsmess [02:30] you'll need a full native build anyway in order to determine which drivers to compile when doing per-system asmjs builds [02:30] this isn't true anymore [02:31] Hooray [02:31] Also, db48x is back from vacation, he said hi to me [02:31] Hopefully, he'll be in here WASMing it up and so on [02:31] DFJustin: oh yeah? that's good news, how is it done now? [02:32] mame now uses a build system called genie which generates the actual makefiles and is smart enough / has enough information in the build files to work out the dependencies for a single driver build [02:33] re: am i understanding correctly from this doc that mame's main loop has already been converted into continuation passing style? [02:33] "converted" is a strong word [02:33] it's been monkey-patched to sort of work but not properly rearchitected [02:34] heh fair enough :) [02:36] that doc doesn't mention how to build mame with emscripten -- i guessed that it was `emmake make` and it seems to be working [02:38] i found the docs on the main mame site now [02:40] `emmake make` with no SOURCES parameter will probably blow up because the object file is too gigantic [02:47] oh ok, didn't know genie could do this directly now. so what's the command to build, say, pacman now? [02:54] emmake make SUBTARGET=pacman SOURCES=src/mame/drivers/pacman.cpp [02:55] so that hasn't changed, but then how do you use genie to get the proper source file? [03:00] oh that's what you meant [03:01] genie doesn't do that no [03:08] you can pull it from the xml download at http://mamedev.org/release.html though [03:15] ah ok [03:54] wow, I was able to get the exidy driver compiled with emscripten and run targ with emularity. I thought it would be a lot harder! [03:54] this is always great to hear :D [03:54] the process has streamlined so much since we startd [03:56] emscripten is way more mature and stable now, and mame has fully incorporated all our work and cleaned it up even further [03:56] what are the keybindings though hehe [03:57] depends on the system....for arcade stuff, the important ones are usually 5/6 to insert coin 1/2, and 1/2 for player 1/2 start...f3 to restart system... [03:58] if you hit tab there's a menu and you can view most of the keybindings there [03:58] as well as explore all the system internals [03:58] oh ok i thought 1/2 were insert coin [04:05] i suck at targ [04:49] well i got the mac driver compiling, added macplus.zip and MSBASIC3.image to the emularity example, but I just get exception thrown: 12105992 [04:49] still, satisfied with the progress i made. [05:08] hehe thank you [05:09] whoops [05:35] *** db48x has joined #jsmess [05:37] yeah that's one of the reasons why the archive.org mac isn't mame [06:04] Hey hey db48x has added some new drivers. [06:04] DFJustin: Would like your opinion on their shape [06:04] aa4101 c64 hbf700f ibmpcjr pc8801 snes svi738 tg16 trs80l2 vic20 [06:04] I recall us thinking c64 was too slow, right [06:27] Princess Maker 2 it is. [06:29] I already have to make a second json item to make it a CD [06:41] https://archive.org/details/Nine-princes-in-amber-game [06:52] Firefox froze slightly, but other than that it seems to be working [06:54] 22:52:06.251 325302-01.uab4 NOT FOUND (tried in c64 c1541) [06:54] mamec64.js.gz:1:3016191 [06:54] 22:52:06.251 901229-06 aa.uab5 NOT FOUND (tried in c64 c1541) [06:54] mamec64.js.gz:1:3016191 [06:54] 22:52:06.252 exception thrown: 11475168 [06:58] Yep [06:58] Needed for the disk drive [06:58] Adding [06:59] https://archive.org/details/Nine-princes-in-amber-game works [06:59] Well "works [07:04] I mean, it boots! [07:04] That's something [07:25] :) [07:43] *** godane has quit IRC (Read error: Operation timed out) [07:55] those should be fine except snes and c64 are on the slow side [07:59] I don't think the aa4101 is fully working and it's probably also slow but worth a try I guess [08:00] pc8801 is a big one as far as major platforms missing currently, a lot of the library is x-rated though [08:04] mame's c64 sid emulation is still pretty dire so the enthusiasts would probably be disappointed [08:04] we should try porting vice, that would help [14:11] *** bwn has quit IRC (Read error: Operation timed out) [14:31] the mame codebase is the cleanest code i have ever seen. mad props. also very stable, which is really refreshing after working on js frontends for the last few years where there are breaking library changes every few weeks [14:39] *** bwn has joined #jsmess [20:11] *** godane has joined #jsmess [20:40] I heard when you port vice, your programmer goes fucking insane [20:42] porting whatever the good sid engine is these days to mame would be better [20:43] that used to not be possible because license issues but now it's just nobody has bothered