[00:05] JohnTalen: that's fun :P [00:08] JohnTalen: so, you were asking how to add support for Vice.js to Emularity last night [00:09] JohnTalen: to start with, you can just ignore IALoader [00:09] it's a separate layer from the rest, and you don't need to use it to test things locally [00:20] db48x: okay. [00:21] db48x: I didn't look at the source for emularity that long. [00:22] db48x: My take was that I use the loader as a fundemental understanding of how to go through it but I can make my own to suit my needs. [00:24] My gripe was adding sockets. Which is strange, because you would only do this to two servers otherwise you'd use HttpRequest via AJAX. [00:31] sockets? [01:19] Yeah, someone here wanted me to add sockets to Emularity. [01:19] Smoething about using it to mount disks. [01:19] which in byitself is extremely strange. [01:25] ah, yes [01:25] that has nothing to do with network connections or servers [01:25] a socket is just a type of file that allows IPC between two processes on the same machine [01:26] our filesystem library supports them, and PCE.js will listen on the socket at a certain filename [01:27] when it recieves commands on that socket, it mounts and unmounts disks in the emulator [01:27] yes, that's a bit of a hack [01:27] but compared to some of the hacks we use, it's pretty well thought out [01:28] how can it support them when it isn't written? [01:29] And how would you call a socket from a browser? [01:30] PCE opens the file and waits for someone to write to it [01:30] but Emularity never writes to it [01:30] so that part of PCE just waits quietly and never has to do anything (the rest of PCE works just fine, of course) [01:31] as for how it's implemented, I've never read this part of the BrowserFS library [01:31] but presumably when you call open on the socket it adds your callback to a list [01:31] then, whenever someone writes to the socket, it calls all the callbacks [01:35] Hm, you want to share an emulated disk between multiple clients? [01:39] that would be cool, but not really [01:40] we'd like to be able to show the user the status of all the disks in the item (sometimes there are more than one), to eject and reinsert them, to be able to add blank disks, etc [01:40] and of course we'd like the user to be able to save the disks to their own machine, etc [01:40] lots of ideas about that [01:41] Ok, I suppose ReadFile/WriteFile in BrowserFS can do most of the work for this process? [01:41] presumably [01:43] okay understood. So you used this because of native support and didn't want to write a file name which classes with another opened file? [01:43] s/classed/clashes. [01:43] bah [01:43] classes=clashes [01:43] of course, a lot of this is pie-in-the sky dreaming, along side ideas like using save states to implement pausing, rewinding, and replaying, or listening on the emulated serial or parrallel ports to support printer emulation, etc [01:44] well, we would use it for PCE because PCE.js has already implemented it [01:44] MAME and DosBox don't really have anything like it at all [01:44] What platforms did you want it for? [01:44] though MAME can be scripted with lua, and we've had some ideas about how to use that [01:45] naturally, we want to support all of the features for all of the platforms [01:45] but like I said, these are all just ideas that anyone could work on if they want, at this point [01:48] Okay. I'll review this further after I'm done with Vice. [01:51] As far as pausing, rewinding etc. In those cases you're just bound by memory. You could probably hold a stack inside a compressed state file. [01:52] A stack in this case being a linked list of sorts. [01:52] yep [01:52] the real problem is betting a save-state out of MAME [01:53] the user can press a sequence of hot-keys to make it dump one out to disk, but this is not exactly an intuitive interface [01:53] (DosBox is worse, of course, since I don't think it has any kind of save-state functionality) [01:54] one option we thought of was to tell emcc to export enough functions from MAME that we could call in and initiate the dump ourselves [01:54] or to export the Lua interpreter's functions so that we could call in and tell it to run some lua which would make MAME dump the save-state to disk [01:55] neither idea has really been explored properly [01:55] and we have no idea how long it takes MAME to do this; if it slows down MAME at all that rather limits what we can do with it [01:55] hm,as far as MAME how about a write/update online RAM guardaian that acts like a trigger in a sql database? linear arrays would be compressed and be written to a compressed diff file as addr/value keys. [01:56] also, there's no guarantee that MAME supports this for every single machine it can emulate [01:57] hmm. if I understood correctly, that would let you save the state of MAME, but disentangling MAME's state from the state of the machine that MAME is emulating would be ridiculously annoying [01:57] the idea is to store the high scores? [01:57] that or just to let the user pause the game [01:58] or, if saving the state is fast enough, we could silently dump the state every second and give the user a way to rewind to previous states [01:58] we could also publish save states on IA for various reasons [01:58] if so, if there was a way to know the Insert Coin state screen to the next whenever you get there just write out the diff between the entry Insert Coin and the current Insert Coin. otherwise you're saving game state as well. [01:58] speeding up the startup process of certain games would be nice (take a look at https://archive.org/details/msdos_Dragons_Lair_1993_1993 if you need a laugh) [01:59] SketchCow: that reminds me; one of the screen shots for Dragon's Lair is busted [02:02] to pause the game sounds like easiest. [02:03] User could select update interval for saving if you're storing game state. [02:04] db48x: if we export the mame functions for snapshots we could trigger the saving and loading of those from js relatively easily [02:04] I thought we actually already supported persistent save states, maybe I'm misremembering [02:04] So a driver has to be created for each emulator that writes out to a PCE kernel that accepts sokets. This is exactly like writing an operating system. [02:05] JohnTalen: not quite; PCE is just one of the emulators we support [02:05] well, for example. [02:05] yeah some systems would be nice to boot off of a running state....like joust, and many other arcade games, when you first turned them on they expected the operator to press a button to step through the booting process, then it would enter play mode [02:06] most people have no idea when they see the test screens during boot-up that they're supposed to be hitting a key [02:06] yea [02:08] maybe I'm misremembering, I think what we had set up was for dosbox, the unionfs which would save changes to localstorage [02:09] yes [02:09] and it does let people save their games, which is awesome [02:09] but arcades don't have quite the same functinality :) [02:09] but it should be possible to do the same thing with mame, whatever directory mame is saving states to, we just need to map that to a browserfs filesystem in the config [02:10] sure [02:10] then users could save and restore using mame's state management keys, or we could export the functions which tell mame to save or load, and trigger them programatically [02:10] that much is already done [02:11] we do the OverlayFS for all emulators, not just DosBox [02:12] oh ok [02:13] but it's all just handwaving until someone figures out which MAME functions to export [02:13] and then there's still the UI to write [02:14] while that someone is in there, they could figure out how to pause MAME directly [02:15] (because while we could implement pausing using save states, it'd be easier just to pause the emulation without stopping MAME entirely) [02:16] I actually did the work to figure that all out like a year or more ago...actually there may be some patches which never made their way into mame as well [02:16] Offhand, what is the name of the listener function in PCE.js? [02:16] I'm trying the state save stuff now, I think it's not currently functional [02:17] but I know I did have save states working at some point [02:17] bai: heh [02:17] JohnTalen: I have no idea :D [02:18] okay. I remember going through the code two weeks ago. I saw some comments about sockets but I was in a state of General Disarray. [02:19] I'll just search it again possibly referencing BrowseFS api functions. [02:20] https://github.com/mamedev/mame/blob/536b2153d995430def817091867b3cfde71e688a/src/emu/machine.cpp#L657 [02:20] https://github.com/mamedev/mame/blob/536b2153d995430def817091867b3cfde71e688a/src/emu/machine.cpp#L620 [02:23] and I think the changes necessary are just to duplicate these lines in the emscripten loop https://github.com/mamedev/mame/blob/536b2153d995430def817091867b3cfde71e688a/src/emu/machine.cpp#L365-L367 [02:27] that looks like it could be made to work [02:28] you'll have to allocate a std::string inside the Emscripten HEAP [02:28] and find the running_machine instance to call those methods on [02:29] the emscripten code stores a reference to the running machine as a static global, https://github.com/mamedev/mame/blob/536b2153d995430def817091867b3cfde71e688a/src/emu/machine.cpp#L1321 [02:30] basically emscripten busts out of that first loop I linked, lets that part of the app exit, and sets up the async handler which calls js_main_loop() in response to the browser's requestAnimationFrame() event [02:32] so we'd need that same save state handling in that loop...and that's work I did somewhere, I should dig it back up [02:57] I've been through too many laptops and too many VMs in the past few years. where the hell did I put all that code [03:32] wow, boring and mindless. i almost want to write a emcc screen scraper. [03:50] hm, machine_name. i can't seem to find the duplicate. There are 11 instances and each one seems to be unique or needed where they are. tomorrow. have to be up early. [03:51] bbt [03:51] *** JohnTalen has quit IRC (Quit: leaving) [05:07] *** i0npulse has quit IRC (Ping timeout: 268 seconds) [05:07] *** i0npulse has joined #jsmess [05:54] mame has an -autosave setting that saves/loads the save state on exit, if that's enabled it might be enough to have an on quit callback that calls mame's exit code [05:55] saving state every second or whatever would have a huge performance hit I think [05:56] DFJustin: ah, that's good to know yeah, we definitely wouldn't want it every second, yeah [05:56] but the main problem is the code to check the save/load schedule just isn't executed in the emscripten codepath [05:56] I'm working on fixing that now [06:02] cool, got save states working....pausing is still not quite right though [07:33] *** bwn has quit IRC (Read error: Operation timed out) [08:10] *** bwn has joined #jsmess [08:16] *** bwn has quit IRC (Ping timeout: 260 seconds) [08:22] *** bwn has joined #jsmess [08:54] *** SketchCow has quit IRC (Read error: Connection reset by peer) [09:00] *** SketchCow has joined #jsmess [09:40] *** bwn has quit IRC (Read error: Operation timed out) [09:52] *** bwn has joined #jsmess [10:09] https://github.com/mamedev/mame/pull/2470 [10:10] while I was at it, I poked at the sleep() functions a bit, with promising results [10:12] I was able to eliminate the spinlock when osd_sleep() is called, by overriding the behavior for throttle_until_ticks() to bail when called under emscripten, and moving a bit of that logic into the emscripten main loop, so if the emulator is told to throttle it just waits until the next frame instead of spinlocking to use up wall time [10:15] that lead to inconsistent framerates because the delays weren't always correct when I do that, but for pacman it went from the cpu being busy for 100% of the frametime (~16.7ms) to only being used for about 2ms per frame, and idling for the rest [10:15] so it's promising, I just have to account for the actual delay time to smooth out the fps [10:31] for comparison: http://imgur.com/a/w0EqG [10:31] guess it's more like 4-5ms per frame, but still much more time spent just relaxing than there was before [14:09] excellent [14:45] As expected, there is resistance. [14:47] (On you putting a patch in) [14:47] But please, can you continue down this road and explore the benefits you're finding, and maybe eventually it will express itself as a patch. [14:47] Or it's something we patch the code with for a while, like the good old days. [14:54] I'd jump into the github thread, but as has been told to me countless times, I don't make things better in there when I show up. [14:55] *** arkiver sets mode: +o SketchCow [16:05] bai: Perhaps it's time to make a github project called "mame-emscription-optimize" [16:07] *** JohnTalen has joined #jsmess [16:07] progress, but slow. [16:09] The initial make works fine for clang. It's the linking process that gives the unibug. Almost always a nameclash. [16:09] So, plodding through still. [16:54] *** azakai has joined #jsmess [17:00] *** JohnTalen has quit IRC (Read error: Operation timed out) [17:07] I think even being able to load previously saved save states, even if they had to be made in the native version, would be a big win. Roll back at the user level is cool but not a common use case. I think even a button to save a state locally would be more likely to see real use than onexit, people are trying a bunch of different games but don't care about their saves in most. [17:11] I dunno about you but I use save state a lot when playing games in emulators, heh [17:11] it's a bit of a cheat though :D [17:11] like in zelda, quicksave before playing money-making game, quickload if you lose [17:29] bai: that's a nice graph [17:33] yeah, if I can get the timing stuff worked out that could help....not sure if it'll necessarily increase speed for things like jaguar that are running < 100%, but for those doing > 100% it means less pegging of the cpu, lower battery usage / heat generation, in theory better interactivity with the rest of the page, etc [17:34] I was curious if it would help with sound crackling on those doing > 100% [17:37] actually as it is now it's introducing more lag on the sound, I think the sound system is coded to assume everything runs at exactly 60 frames per second [17:37] drat [17:37] so if it's either too slow or too fast, you get crackles or lag, respectively [17:37] heh [17:38] just introduce a one-frame delay [17:38] it's worth pointing out that pacman runs at roughly 60fps but there are systems in mame that run e.g. 50fps or 75fps so it really doesn't make much sense to talk about frames [17:38] yeah you're right [17:39] just 'however much time there is between browser animation callbacks' [17:39] I think I triggered a few people on that pull request by using the term frames :D [17:40] do you have any thoughts on addressing the concerns of the people who don't want to "enshrine the run for one frame concept"? [17:41] there's also an issue with the current code where the browser callbacks change based on the host system refresh rate, so for example my laptop goes to 50Hz on battery and that fucks up the speed [17:41] and last time I checked there's no actual web api for what the refresh rate is other than "measure it for a while" [17:42] which blows my mind [17:43] yeah that's a good point - never seen a system which drops refresh rate on the fly myself, but makes sense [17:44] I don't really have time to review the patch until later but I guess it should be as independent from mame's screen objects as possible [17:44] at the cost of probably having tearing on scrolling and the like [17:45] well even if the refresh rate doesn't change it's currently hardcoded to assume 60 but some monitors are 120 etc [17:50] yeah, I started to look into removing the 60hz hardcoded bit, in theory I can just measure the time between when the emscripten main loop was last called and use that as our time to advance the emulator [17:51] but my initial attempt I think I was just getting the scale wrong, fucking attoseconds [17:53] I tried doing that at one point but it's tricky because the gap can be very large if e.g. you switch tabs and come back [17:53] yeah true, maybe cap it at, say, 10fps minimum [17:54] reminds me, pausing doesn't really work either [17:54] it stops updating the screen but the system continues to advance [17:55] yeah the check for that is outside our loop [17:56] actually someone moved it in, and my patch consolidates them so our loop and the native loop are actually running the same codepath now [17:56] but I think there's some other state flag being set somewhere which isn't being used, or something [17:57] this is what I had for measuring the time https://gist.github.com/DopefishJustin/d79b5fce9621c78dca50fdaefe6cc1d0 [17:58] plus some audio stuff that didn't seem to help [18:00] hmm, alright. yeah looks like similar sort of logic as I had...I could get it to run either > 100% or like 1 frame every few secods, but somehow getting the right value just didn't want to work, heh [18:01] iirc it basically seemed to just run the maximum 1/30 every time [18:09] SketchCow: this is pretty mild as pull request pushback goes (there's another one which is a dumpster fire at the moment), I would expect it to get ironed out with some back and forth [18:14] didn't help that my pull request was failing the automated tests because I forgot I was compiling with NOWERROR=1 heh [18:15] fixed now and I addressed all the small concerns, now it's just a matter of ironing out the "web is weird, we shouldn't do it that way" "but web" discussions [18:16] it's also possible for me to split it out a bit more and keep the weirdo stuff in the emscripten define, I suppose [20:08] as long as you are not dissuaded [20:09] and I realize it is mild bht MAME is legendary fir "bite the newbie" [20:09] as long as bai continues lab work, and I am not against tbe patch cluster I mentioned [20:10] I bet we can have something super spectacular [20:17] *** JohnTalen has joined #jsmess [20:20] I hit all the high notes too....wrong indentation style, broke the native build, and failed automated testing :D [20:29] you are scum but I love you [20:50] bai: not sure if the final PR is right, I see a call to jsmess_machine->run_frame() in js_main_loop() but isn't run_frame() renamed to run_timeslices()? [22:15] shoot, did I miss something? [22:16] you're right XD [22:16] think I just forgot one push [22:16] but I'll follow up with one which does this in a less objectionable way anyway [22:19] you should attach your profiles (or at least the screenshots you took) to your pull request [22:20] well, those are for a different change [22:20] this change itself doesn't have any performance impact [22:21] it's not about rendering a frame, it's about not spinning the cpu [22:21] ah [23:20] balrog: just pushed some updates to that pull request, thanks for letting me know about the missing code. that's what happens when I try to work on two separate changes at once :D [23:21] new version is a lot simpler, mostly puts things back how they were before, just moves some code around to make it accessible to the emscripten loop