#jsmess 2017-07-13,Thu

↑back Search

Time Nickname Message
00:05 🔗 db48x JohnTalen: that's fun :P
00:08 🔗 db48x JohnTalen: so, you were asking how to add support for Vice.js to Emularity last night
00:09 🔗 db48x JohnTalen: to start with, you can just ignore IALoader
00:09 🔗 db48x it's a separate layer from the rest, and you don't need to use it to test things locally
00:20 🔗 JohnTalen db48x: okay.
00:21 🔗 JohnTalen db48x: I didn't look at the source for emularity that long.
00:22 🔗 JohnTalen 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 🔗 JohnTalen 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 🔗 db48x sockets?
01:19 🔗 JohnTalen Yeah, someone here wanted me to add sockets to Emularity.
01:19 🔗 JohnTalen Smoething about using it to mount disks.
01:19 🔗 JohnTalen which in byitself is extremely strange.
01:25 🔗 db48x ah, yes
01:25 🔗 db48x that has nothing to do with network connections or servers
01:25 🔗 db48x a socket is just a type of file that allows IPC between two processes on the same machine
01:26 🔗 db48x our filesystem library supports them, and PCE.js will listen on the socket at a certain filename
01:27 🔗 db48x when it recieves commands on that socket, it mounts and unmounts disks in the emulator
01:27 🔗 db48x yes, that's a bit of a hack
01:27 🔗 db48x but compared to some of the hacks we use, it's pretty well thought out
01:28 🔗 JohnTalen how can it support them when it isn't written?
01:29 🔗 JohnTalen And how would you call a socket from a browser?
01:30 🔗 db48x PCE opens the file and waits for someone to write to it
01:30 🔗 db48x but Emularity never writes to it
01:30 🔗 db48x 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 🔗 db48x as for how it's implemented, I've never read this part of the BrowserFS library
01:31 🔗 db48x but presumably when you call open on the socket it adds your callback to a list
01:31 🔗 db48x then, whenever someone writes to the socket, it calls all the callbacks
01:35 🔗 JohnTalen Hm, you want to share an emulated disk between multiple clients?
01:39 🔗 db48x that would be cool, but not really
01:40 🔗 db48x 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 🔗 db48x and of course we'd like the user to be able to save the disks to their own machine, etc
01:40 🔗 db48x lots of ideas about that
01:41 🔗 JohnTalen Ok, I suppose ReadFile/WriteFile in BrowserFS can do most of the work for this process?
01:41 🔗 db48x presumably
01:43 🔗 JohnTalen 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 🔗 JohnTalen s/classed/clashes.
01:43 🔗 JohnTalen bah
01:43 🔗 JohnTalen classes=clashes
01:43 🔗 db48x 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 🔗 db48x well, we would use it for PCE because PCE.js has already implemented it
01:44 🔗 db48x MAME and DosBox don't really have anything like it at all
01:44 🔗 JohnTalen What platforms did you want it for?
01:44 🔗 db48x though MAME can be scripted with lua, and we've had some ideas about how to use that
01:45 🔗 db48x naturally, we want to support all of the features for all of the platforms
01:45 🔗 db48x but like I said, these are all just ideas that anyone could work on if they want, at this point
01:48 🔗 JohnTalen Okay. I'll review this further after I'm done with Vice.
01:51 🔗 JohnTalen 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 🔗 JohnTalen A stack in this case being a linked list of sorts.
01:52 🔗 db48x yep
01:52 🔗 db48x the real problem is betting a save-state out of MAME
01:53 🔗 db48x 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 🔗 db48x (DosBox is worse, of course, since I don't think it has any kind of save-state functionality)
01:54 🔗 db48x 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 🔗 db48x 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 🔗 db48x neither idea has really been explored properly
01:55 🔗 db48x 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 🔗 JohnTalen 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 🔗 db48x also, there's no guarantee that MAME supports this for every single machine it can emulate
01:57 🔗 db48x 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 🔗 JohnTalen the idea is to store the high scores?
01:57 🔗 db48x that or just to let the user pause the game
01:58 🔗 db48x 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 🔗 db48x we could also publish save states on IA for various reasons
01:58 🔗 JohnTalen 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 🔗 db48x 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 🔗 db48x SketchCow: that reminds me; one of the screen shots for Dragon's Lair is busted
02:02 🔗 JohnTalen to pause the game sounds like easiest.
02:03 🔗 JohnTalen User could select update interval for saving if you're storing game state.
02:04 🔗 bai db48x: if we export the mame functions for snapshots we could trigger the saving and loading of those from js relatively easily
02:04 🔗 bai I thought we actually already supported persistent save states, maybe I'm misremembering
02:04 🔗 JohnTalen 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 🔗 db48x JohnTalen: not quite; PCE is just one of the emulators we support
02:05 🔗 JohnTalen well, for example.
02:05 🔗 bai 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 🔗 bai 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 🔗 db48x yea
02:08 🔗 bai maybe I'm misremembering, I think what we had set up was for dosbox, the unionfs which would save changes to localstorage
02:09 🔗 db48x yes
02:09 🔗 db48x and it does let people save their games, which is awesome
02:09 🔗 db48x but arcades don't have quite the same functinality :)
02:09 🔗 bai 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 🔗 db48x sure
02:10 🔗 bai 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 🔗 db48x that much is already done
02:11 🔗 db48x we do the OverlayFS for all emulators, not just DosBox
02:12 🔗 bai oh ok
02:13 🔗 db48x but it's all just handwaving until someone figures out which MAME functions to export
02:13 🔗 db48x and then there's still the UI to write
02:14 🔗 db48x while that someone is in there, they could figure out how to pause MAME directly
02:15 🔗 db48x (because while we could implement pausing using save states, it'd be easier just to pause the emulation without stopping MAME entirely)
02:16 🔗 bai 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 🔗 JohnTalen Offhand, what is the name of the listener function in PCE.js?
02:16 🔗 bai I'm trying the state save stuff now, I think it's not currently functional
02:17 🔗 bai but I know I did have save states working at some point
02:17 🔗 db48x bai: heh
02:17 🔗 db48x JohnTalen: I have no idea :D
02:18 🔗 JohnTalen 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 🔗 JohnTalen I'll just search it again possibly referencing BrowseFS api functions.
02:20 🔗 bai https://github.com/mamedev/mame/blob/536b2153d995430def817091867b3cfde71e688a/src/emu/machine.cpp#L657
02:20 🔗 bai https://github.com/mamedev/mame/blob/536b2153d995430def817091867b3cfde71e688a/src/emu/machine.cpp#L620
02:23 🔗 bai 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 🔗 db48x that looks like it could be made to work
02:28 🔗 db48x you'll have to allocate a std::string inside the Emscripten HEAP
02:28 🔗 db48x and find the running_machine instance to call those methods on
02:29 🔗 bai 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 🔗 bai 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 🔗 bai 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 🔗 bai 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 🔗 JohnTalen wow, boring and mindless. i almost want to write a emcc screen scraper.
03:50 🔗 JohnTalen 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 🔗 JohnTalen 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 🔗 DFJustin 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 🔗 DFJustin saving state every second or whatever would have a huge performance hit I think
05:56 🔗 bai DFJustin: ah, that's good to know yeah, we definitely wouldn't want it every second, yeah
05:56 🔗 bai but the main problem is the code to check the save/load schedule just isn't executed in the emscripten codepath
05:56 🔗 bai I'm working on fixing that now
06:02 🔗 bai 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 🔗 bai https://github.com/mamedev/mame/pull/2470
10:10 🔗 bai while I was at it, I poked at the sleep() functions a bit, with promising results
10:12 🔗 bai 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 🔗 bai 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 🔗 bai so it's promising, I just have to account for the actual delay time to smooth out the fps
10:31 🔗 bai for comparison: http://imgur.com/a/w0EqG
10:31 🔗 bai guess it's more like 4-5ms per frame, but still much more time spent just relaxing than there was before
14:09 🔗 DFJustin excellent
14:45 🔗 SketchCow As expected, there is resistance.
14:47 🔗 SketchCow (On you putting a patch in)
14:47 🔗 SketchCow 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 🔗 SketchCow Or it's something we patch the code with for a while, like the good old days.
14:54 🔗 SketchCow 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 🔗 SketchCow bai: Perhaps it's time to make a github project called "mame-emscription-optimize"
16:07 🔗 JohnTalen has joined #jsmess
16:07 🔗 JohnTalen progress, but slow.
16:09 🔗 JohnTalen The initial make works fine for clang. It's the linking process that gives the unibug. Almost always a nameclash.
16:09 🔗 JohnTalen So, plodding through still.
16:54 🔗 azakai has joined #jsmess
17:00 🔗 JohnTalen has quit IRC (Read error: Operation timed out)
17:07 🔗 Vito` 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 🔗 bai I dunno about you but I use save state a lot when playing games in emulators, heh
17:11 🔗 bai it's a bit of a cheat though :D
17:11 🔗 bai like in zelda, quicksave before playing money-making game, quickload if you lose
17:29 🔗 db48x bai: that's a nice graph
17:33 🔗 bai 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 🔗 DFJustin I was curious if it would help with sound crackling on those doing > 100%
17:37 🔗 bai 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 🔗 DFJustin drat
17:37 🔗 bai so if it's either too slow or too fast, you get crackles or lag, respectively
17:37 🔗 db48x heh
17:38 🔗 db48x just introduce a one-frame delay
17:38 🔗 DFJustin 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 🔗 bai yeah you're right
17:39 🔗 DFJustin just 'however much time there is between browser animation callbacks'
17:39 🔗 bai I think I triggered a few people on that pull request by using the term frames :D
17:40 🔗 bai 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 🔗 DFJustin 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 🔗 DFJustin 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 🔗 DFJustin which blows my mind
17:43 🔗 bai yeah that's a good point - never seen a system which drops refresh rate on the fly myself, but makes sense
17:44 🔗 DFJustin 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 🔗 DFJustin at the cost of probably having tearing on scrolling and the like
17:45 🔗 DFJustin well even if the refresh rate doesn't change it's currently hardcoded to assume 60 but some monitors are 120 etc
17:50 🔗 bai 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 🔗 bai but my initial attempt I think I was just getting the scale wrong, fucking attoseconds
17:53 🔗 DFJustin 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 🔗 bai yeah true, maybe cap it at, say, 10fps minimum
17:54 🔗 bai reminds me, pausing doesn't really work either
17:54 🔗 bai it stops updating the screen but the system continues to advance
17:55 🔗 DFJustin yeah the check for that is outside our loop
17:56 🔗 bai 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 🔗 bai but I think there's some other state flag being set somewhere which isn't being used, or something
17:57 🔗 DFJustin this is what I had for measuring the time https://gist.github.com/DopefishJustin/d79b5fce9621c78dca50fdaefe6cc1d0
17:58 🔗 DFJustin plus some audio stuff that didn't seem to help
18:00 🔗 bai 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 🔗 DFJustin iirc it basically seemed to just run the maximum 1/30 every time
18:09 🔗 DFJustin 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 🔗 bai didn't help that my pull request was failing the automated tests because I forgot I was compiling with NOWERROR=1 heh
18:15 🔗 bai 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 🔗 bai 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 🔗 SketchCow as long as you are not dissuaded
20:09 🔗 SketchCow and I realize it is mild bht MAME is legendary fir "bite the newbie"
20:09 🔗 SketchCow as long as bai continues lab work, and I am not against tbe patch cluster I mentioned
20:10 🔗 SketchCow I bet we can have something super spectacular
20:17 🔗 JohnTalen has joined #jsmess
20:20 🔗 bai I hit all the high notes too....wrong indentation style, broke the native build, and failed automated testing :D
20:29 🔗 SketchCow you are scum but I love you
20:50 🔗 balrog 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 🔗 bai shoot, did I miss something?
22:16 🔗 bai you're right XD
22:16 🔗 bai think I just forgot one push
22:16 🔗 bai but I'll follow up with one which does this in a less objectionable way anyway
22:19 🔗 db48x you should attach your profiles (or at least the screenshots you took) to your pull request
22:20 🔗 bai well, those are for a different change
22:20 🔗 bai this change itself doesn't have any performance impact
22:21 🔗 db48x it's not about rendering a frame, it's about not spinning the cpu
22:21 🔗 db48x ah
23:20 🔗 bai 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 🔗 bai 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

irclogger-viewer