[00:11] Neohabitat now works in the browser [00:11] (Only on non-https hosts for now, sadly) [00:14] Sgeo: I totally expect it to sound choppy [00:14] What I'd like is if you hit "performance" and said what the percent in the upper right said [00:14] Before and after the fun [00:14] This is our huge speed test [00:40] SketchCow, I don't see any improvement, and I don't know why not [00:40] Well, that's your litmus [00:40] It's why we keep it around. :) [00:41] It runs at 10-30% and so if we get jumps in quality, it'll show [00:43] Build defines 1: LSB_FIRST=1 MAME_NOASM=1 [00:43] Is that MAME_NOASM=1 intentional? [00:44] DFJustin can tell you [01:53] I'm now "finalizing" tons of items, that is, they're screenshot, verified as booting, and then being set to vice-resid as the emulator. [01:53] So that was at 10,500 and is now well past 12,500 [01:53] Screenshotter is now going to the demos because I believe I nailed almost all the games. [01:54] 12,649 [02:22] So, interesting thing: Websockets do NOT follow the web's Same-Origin Policy. This means that in theory, the Internet Archive could host an Internet-enabled C64 game, as long as it's pointed at a websocket. [02:22] Which could be anywhere, anyone who wants to run, say, a websockify endpoint [03:26] What's higher priority, fast warp/autoload or gamepad support? [03:27] Of those two, gamepad [03:28] Thanks [03:28] Also: proof of concept of media swap [03:28] (I just need us to find two sides and put them together in the system) [03:29] Other stuff keeps pulling me away, if you could point out two items that are that, I'll make the changes, we prove it, and I'll write the settings [03:30] https://archive.org/details/10_Years_HVSC_2006-11-28_HVSC_Crew_Side_A and https://archive.org/details/10_Years_HVSC_2006-11-28_HVSC_Crew_Side_B [03:31] (I already uploaded a single item version) [03:32] Gah, Emscripten already has setImmediate support, so I might just get that over with now, then look at gamepad [03:35] https://archive.org/details/10_Years_HVSC_2006-11-28_HVSC_Crew_Side_A [03:36] I absolutely can not press Alt-N and flip any disk. [03:36] Chrome. Windows 10. [03:39] that's a really old compile, I dunno if we enable MAME_NOASM specifically anymore, but it was intentional [03:41] SketchCow, what happens when you press alt-n on this website? https://w3c.github.io/uievents/tools/key-event-viewer.html [03:42] It sees a key. What column info do you need [03:43] Modifiers: getModifierState and alt [03:43] Meta [03:43] Nothing checked in alt. [03:44] so - Meta - - Meta Meta Meta [03:44] Huh. What keyboard layout are you using? [03:44] Tried second keyboard (long story) [03:44] GetModifier is - Alt Alt Alt [03:44] And Alt is X check check check [03:44] Code is AltLeft [03:45] Try that keyboard with Alt-N for flipping disk [03:47] OK [03:47] One moment. [03:54] Nope [03:54] No dice [03:54] I'm sure it's a basic misunderstanding. This is absolutely vice-resid [03:55] Maybe I'm behind you in versions? [03:56] For this demo, you pressed space after alt-n? (Most games do require any key, some don't and magically detect the flipped disk) [03:57] I'm not running any local version stuff [03:57] https://archive.org/details/0007a2091422 [03:58] This might be the miscommunication [03:58] So it doesn't bring up a selection to flip media? [03:59] No, it goes to the next item defined in the fliplist [03:59] Are you able to go to that item and have it work the way I set it? [03:59] yes [03:59] Oh man, without feedback, that's trouble [04:02] Could define another hotkey to go to the drive attach disk menu. Could add a VICE message when disk flipped. [04:03] Yeah, without feedback, it's probably working but I get nothing onscreen [04:17] F12 is more feedback-y [04:18] But more annoying [04:18] Could attach a hotkey anywhere in the menu [04:25] Well, I didn't manage to focus on gamepad first, so now there's a build that autoloads (warps) very quickly [04:27] What does it do to do that [04:29] Uses Emscripten's built-in setImmediatemode shim [04:29] https://github.com/Sgeo/vice32.js/commit/9f6ee0a5739836d60966ae8209c0977bbdda3d52 [04:30] Does it sound better? [04:30] Or does this only affect that autowarp [04:31] Only effects autowarp, haven't tried mixing setImmediate with sound. I do know that setImmediate could fix the problem with the tab being minimized or backgrounded, but that's not in this build. [04:32] I'm constantly paying attention to this stuff... [04:32] I wonder if it affects the MAME build of escripten [04:32] If it's something that would make it run faster [04:33] We didn't see it in the experiments we did in dfjustin... maybe it went in wrong? [04:35] It should only make a difference if the emulator's performant already. setTimeout (which I think is what older Emscripten used) has a minimum delay of 4 or 10 milliseconds, setImmediate can be faster. But only if the main slowness was caused by the setTimeout delay [04:36] It was a sleep [04:38] hm? [04:38] That's the big delay in MAME [04:38] bai can explain [04:46] ...vice32.js had more ability to recognize my gamepad than SDLVICE on my machine did [04:46] (although the former still isn't working) [05:18] ?qybe I should re,ove the French keyboqrd lqyout fro, ,y syste, zhere I cqn eqsily qctivqte it by qccident [05:34] hmm. trying to link the doc about mame timing stuff but google docs just gives me an empty clipboard when I select "copy url" [05:51] 13,073 [05:55] Doing another build which will fix the blur problem (where things just pause and die when the tab loses focus). If sound sounds BETTER while the tab is out of focus, that would be interesting [05:55] This will also speed autowarp, right [05:55] yes [05:56] (Well, that was already built, this is in the same general area and approach) [05:57] Well, let me know - I'm going to be driving to where I'm staying soon [06:01] ....It's random whether or not it works. [06:02] Sometimes switching tabs is fine, sometimes not. And I know why. I don't know how to fix without forcing setImmediate all the time [06:03] The tab thing [06:05] Forcing setImmediate all the time should fix the tab thing a lot better, and it will be less code, but I don't know what it would do to battery life etc [06:12] Your call. I likely have to go now [06:12] Want to do just the autowarp speedup? [06:14] https://raw.githubusercontent.com/Sgeo/sgeo.github.io/77af6bfd67f79a2f9cd627904100308940cd4162/experimental/vice32/x64.js [06:14] Is just autowarp speedup [06:15] (And networking stuff that IA doesn't care about. Hopefully no one gets weirded out by that Network entry in F12) [06:24] Is there a way to tell it kicked in? [06:25] Like a console message or something [06:25] Statusbar, when showing W, should also show a very high percentage, like 999 [06:25] Without this change, it's around 120 [06:26] (Alt-B / F12->status bar) [06:27] Yeah, it's not in yet. [06:28] (When you upload, it goes in, and it takes IA a little while) [06:29] I see the Network menu item, which is new [06:31] Whoops, there was a blow-up [06:31] Repairing [06:44] ? [07:20] Ugh maybe that's the wrong version [07:23] http://sgeo.github.io/experimental/vice32/x64.js is latest, but it also has the only 50% chance "can music play while backgrounded" thing [07:42] VICE uses SDL_InitSubSystem when it decides it wants joystick input. Emscripten SDL1 stubs that out and it does nothing. [07:43] I keep wondering if I should just burn SDL1 to the ground and switch to SDL2 [07:57] I have gamepad working with one caveat: The user has to press a button on the gamepad before starting the emulator [08:23] SDLJoystick: Warning - Axis 0 exceeds threshold, mapping to NONE [08:25] http://sgeo.github.io/experimental/vice32/x64.js now has my current gamepad code. Still requires going to F12 to change from numpad to gamepad. Pressing a button only after the emulator loads works fine. What doesn't work fine is moving the stick: It confuses the init code into thinking that that axis is damaged, and so VICE ignores it [08:27] Ok even the latest build isn't doing the warping right [08:33] Warp problem has something to do with manual vs autoload: The setImmediate is kicking in with Alt-W warp but not autoload warp [08:33] I should sleep a few hours ago [18:24] Huzzah [18:24] So, let me know when that bit works. [18:24] Are you comfortable with x64.js being put in [18:44] Yes [18:47] I still don't know whether I should just give in and force setImmediate mode all the time. It's certainly less code to do so and would be less buggy, but I keep thinking that there's a reason it's recommended against [18:48] bai, can you shed some light on this note? [18:48] "Note that this mode is strongly not recommended to be used when deploying Emscripten output to the web, since it depends on an unstable web extension that is in draft status, browsers other than IE do not currently support it, and its implementation has been considered controversial in review." [18:48] Well, except for the fact that it's not true because in non-IE, Emscripten shims it with postMessage [18:49] https://developer.mozilla.org/en-US/docs/Web/API/Window/setImmediate [18:49] This method is not expected to become standard, and is only implemented by recent builds of Internet Explorer and Node.js 0.10+. It meets resistance both from Gecko (Firefox) and Webkit (Google/Apple). [18:50] Asking about http://sgeo.github.io/experimental/vice32/x64.js [18:50] I'm triple asking just because when we slam this in, 14,000 items change their nature. :) [18:51] SketchCow, it should be safe (assuming no bugs) and will support gamepads [18:52] bai, in the notes it mentions a polyfill. Emscripten already comes with something like that polyfill [18:55] sure, it sounds like it has a workaround for the fact that it doesn't exist in most browsers [18:56] I guess the question is whether setImmediate emulated by postMessage is better that rAF and setTimeout / setInterval [18:56] It's certainly faster. [18:57] interesting [18:57] Faster might not be the point though. Does it kill battery on mobile devices? Does it screw up things that rAF wouldn't? [18:58] Faster is certainly better during warp. So I wanted to use it during warp only, but that has a cost of higher chance of bugs (as with autoload) [19:02] yeah. if I were to hazard a guess, with only a cursory understanding of what setImmediate does, they're probably emulating it by having a tight loop running in a worker, posting messages to the main thread on some very fast interval, which is a way to work around some of the fudge-factor of using the browser's timeout scheduler which starts getting less accurate whwn you try to use intervals less than about [19:02] 5ms [19:03] so that would probably kill battery on mobile and possibly hurt performance in constrained circumstances [19:05] What are the negative consequences of using setTimeout instead of requestAnimationFrame? [19:05] setTimeout isn't as affected by the background tab thing, so that's nice right off the bat [19:18] yeah setTimeout() will drop to 1s minimum interval in a background tab, while rAF goes to 0. rAF is better for graphics, since it gives you a window of time where you can output graphics to the screen in a way that works nicely with vsync - less tearing, etc [19:18] tying emulation speed to the graphics card speed is probably not how we should be doing it, honestly [19:19] the ideal emulator for the web would run the entire emulator in a worker, and graphics would be handled in another worker using OffscreenCanvas [19:21] the emulator running in a worker could then skip the setTimeout/rAF nonsense entirely, and run as a traditional tight loop like your emulator normally would on a native platform [19:22] the difficulty is getting graphics and sound to output, browsers have been dragging their feet with the ability to do those two things from workers [19:22] chrome now ships with OffscreenCanvas, firefox has it behind a flag, and IE support is nowhere to be found [19:23] safari also has no sign of support [19:25] What are WebSid and the like doing? [19:27] not sure, but generally the options are either run your sound and video code in the main thread, or move as much of the number crunching off into a worker as possible and just pipe data from workers into audio contexts on the main thread [20:49] I used the one you said and the percentage doesn't increase. [20:49] Try any item with vice-resid. [21:14] SketchCow, yeah, warp on autostart isn't working, I'm not sure why. Try alt-w twice, that will turn off and on warp manually, which seems to work [21:15] The latest update does support gamepads though [21:47] ...VICE does something odd. I plugged in "Joystick" into both control port 1 and 2. The right stick controls 1 and the left stick controls 2 [21:47] So someone could play a local multiplayer game... if they're willing to share a gamepad [21:48] It also makes things a bit awkward for Neohabitat, which uses control port 1 [21:50] This is different behavior from WinVICE [22:16] yes, in the browser, gamepads need.to have a button pressed in order for them to show up. emscripten should handle hotplugging after the fact though, and ad l9ng as the underlying app handled gamepad hotplugging, it should work [22:16] but yeah, might introduce ordering problemd... [22:21] bai, VICE wasn't handling gamepad hotplugging, I made a small change so that it can [23:32] bai, Emscripten is yelling at me [23:34] how rude [23:34] "Looks like you are rendering without using requestAnimationFrame for the main loop. You should use 0 for the frame rate in emscripten_set_main_loop in order to use requestAnimationFrame, as that can greatly improve your frame rates!" [23:36] Also the logs say I am switching to setImmediate on autostart, which I was attributing to another line I added, but I was still capped at 120% [23:46] *** azakai has joined #jsmess