[00:30] *** fzzzy has joined #jsmess [03:17] *** DLudwig has quit IRC (Quit: ZNC 1.6.5+deb2build2 - http://znc.in) [03:18] *** binji has quit IRC (Read error: Operation timed out) [03:27] *** DLudwig has joined #jsmess [04:45] *** fzzzy has quit IRC (My MacBook Pro has gone to sleep. ZZZzzz…) [09:05] *** binji has joined #jsmess [13:34] *** binji has quit IRC (Read error: Operation timed out) [15:57] *** fzzzy has joined #jsmess [16:45] *** binji has joined #jsmess [18:44] *** fzzzy has quit IRC (My MacBook Pro has gone to sleep. ZZZzzz…) [19:30] *** fzzzy has joined #jsmess [21:02] *** icculus has joined #jsmess [21:02] Hello, Mr Scott pinged me. [21:02] I’m about to drive home from my in-laws’ house, but tell me what you need and I’ll dive in tonight. [21:06] hey icculus, welcome back. we did a technical write-up of the issue since you were last here, not sure if you've had a chance to check that out yet or not [21:06] https://docs.google.com/document/d/1FHmn1kO3PGYYCRJejZsZMFk_BxWer_pOaTUANRFroM8/edit?usp=sharing [21:08] got some good suggestions from people on how they solved similar problems in the past, I think we have a pretty clear idea of what needs to be done now, just gotta find someone who has the time to knuckle down and get their hands dirty [22:02] bai: was there any code written, or is it just the suggestions so far? [22:04] and if no code was written yet, which approach are people leaning towards? [22:05] no code since the initial prototypes which this analysis is based on. a breakdown of where I think the code changes should be, but some of this stuff is stretching my knowledge of the low-level systems [22:05] (I suspect that the “find some way to disable usleep()” in that doc is the most correct approach, but definitely not the easiest) [22:06] what we're thinking is something along the lines of making usleep() a no-op, and possibly using setjmp() / longjmp() to restore execution state and resume where we left off next time our async handler is called [22:06] there is a chance that mame is architected in such a way that that's not even necessary though [22:07] yeah, in a perfect world, we’re going to want to avoid that setjmp, too [22:07] in this case, its sleeps are, as far as I can tell, entirely for the purposes of frame limiting, which is already being done with rAF [22:08] so as long as disabling the sleep call doesn't mess with MAME's timing, it may be easier than we suspect [22:08] yeah [22:08] Surely it has to deal with PCs that sync-to-vblank already [22:08] or an overloaded windows machine that sleeps too long [22:09] once I retraced my code I did find that there is an allowed_to_sleep boolean that gets set based on various parameters inside of the throttle_until_time function [22:09] ok, I’ll poke at it tonight [22:09] Is there a ROM for some arcade machine that’s useful for testing? Some pirated Pac-Man or something? [22:09] so that's another route to explore, what happens if we change whatever values cause that to be false [22:10] I normally use pirated pacman, SketchCow can probably give you a link to something that's kosher and also a good test of whether our improvements have helped. what do we use for stress testing audio, Mr. Do? [22:11] pacman is fine as a "does this work at all" but it's not pushing the system at all, I can run it at like 500% speed [22:11] it was just an example. :) [22:12] I think this is the one he likes to use for testing https://archive.org/details/arcade_mrdo [22:12] hmm, marked as stream-only :( [22:13] https://cors.archive.org/cors/arcade_mrdo/mrdo.zip [22:13] If you are looking for public domain-ish ROMs them the entire Vectrex library was released as such after they died. [22:15] No idea if anyoine has made items of them or if that was what you meant with "kosher". [22:18] yeah, legally speaking :) [22:20] jaguar is the ultimate stress test, once we prove that the system can run a regular game at 100% speed steady using whatever changes we end up making then we'll see how it helps on the real heavyweight stuff [22:20] jaguar can hit 100% speed in a beast-mode gaming rig, but on anything less we normally see int he range of 60-80% speed [22:21] on* [22:22] it's hard to say whether this change will help much on systems that run < 100% execution speed, but hopefully it'll at least yield a bit more time to the browser to handle things like audio [22:28] ok, I grabbed mrdo.zip [22:28] I have to get in the car now, but I’ll report back. [22:29] *** icculus has quit IRC (icculus) [23:18] *** fzzzy has quit IRC (My MacBook Pro has gone to sleep. ZZZzzz…)