[00:24] bai: What's the link the 3d viewer prototype again [00:29] Found it [00:29] http://baicoianu.com/~bai/ia-model-viewer/ [01:10] oops, yeah that's the one [01:10] it's on github too, lemme pull up that for you too [01:11] SketchCow: https://github.com/jbaicoianu/ia-model-viewer [01:35] *** n00b869 has joined #jsmess [01:36] hello [01:37] nobody here but us chickens. move along. [01:41] *** n00b869 has quit IRC (Ping timeout: 268 seconds) [01:41] Thanks [01:45] that server is getting slower and slower, network-wise [01:45] stupid rackspace [04:18] Is anyone having issues with IA emulation and browserfs.js in FF48? All emulation seems to fail in my console throwing an UnknownError at 5:7614. It doesn't occur on my FF49 Dev Ed install. [04:30] Ipggi: which system, Amiga? [04:31] or all systems? [04:32] all systems [04:32] db48x and sketchcow were working through some browserfs-related problems with Amiga, I think they pushed some new versions - maybe that had a negative effect on other systems? [04:34] Ipggi: it's a problem that's cropped up every now and then [04:34] Ipggi: but we don't know how to reproduce it, or what's really going on under the hood [04:35] if you append &external_js=1 to the url of the item you were using, then you'll get a slightly newer version of the code that will print a marginally nicer error message [04:35] db48x: ah ok, is the new stuff only in loaderlab for not? [04:35] for now* [04:35] yes [04:35] ok, good to know [04:36] since it doesn't fix the problem, there didn't seem much point in promoting it [04:36] yeah, makes sense [04:37] https://www.irccloud.com/pastebin/lvVhCT6s/ [04:37] that's the one [04:38] it's a pretty confusing error message too, because it's telling us that OverlayFS isn't initialized, when what we were trying to do at the time is initialize OverlayFS [04:39] the weirdest thing about it is that if you believe SketchCow, his screenshotters will work for a while and then suddenly break [04:39] once broken, every page they load results in this error [04:45] that's really odd. it seems almost like a wild goose chase. [04:52] yes [04:53] although, having said it like that, I do have a suspicion [04:55] something local to the browser? [04:55] yes, IndexedDB [05:02] You maybe right, there is nothing being created in the IndexedDB on my browser with the failure [05:12] So I ran https://html5test.com/index.html with both the broken browser and a fresh download of FF48 (portable) and the results are different .. it seems my IndexedDB is corrupt? [05:13] FF48 working http://imgur.com/sPsPg8M [05:13] FF48 broken http://imgur.com/PexXsFu [05:14] interesting [05:14] so possibly a browser bug? [05:15] yes it maybe [05:19] I wonder if this is a possible issue? 'Reverting to previous version of Firefox makes indexeddb database inaccessible' https://bugzilla.mozilla.org/show_bug.cgi?id=1092090 [05:19] This profile was running 49 beta but I recently reverted it back to 48 [05:20] hmm [05:20] that wouldn't explain SketchCow's issue, but sounds plausible for yours [05:24] okay that was the issue for me [05:25] running this profile in ff 49b1 now fixes the indexdb issue [05:46] Ipggi: do you get any interesting messages in the Browser Console when this happens ? [05:47] (Tools -> Web Developer -> Browser Console, it's different from the Devtools console [05:47] ) [05:57] okay so I reverted my ff profile to use ff48 again and it's failing, so that is my issue. this is the browser console output when it fails [05:57] IndexedDB UnknownErr: ActorsParent.cpp:584(unknown) [05:57] UnknownError browserfs.js:5:7614 [05:59] I get the same 'IndexedDB UnknownErr: ActorsParent.cpp:584' error when I visit https://html5test.com/index.html [06:02] https://dxr.mozilla.org/mozilla-central/source/dom/indexedDB/ActorsParent.cpp#585 [06:03] that's not a lot to go on [06:10] the other thought is that this could be multiple similar problems [06:11] SketchCow's screenshotter machines didn't have two versions of Firefox on them [06:37] Just to be specific, my issue wasn't caused by having 2 different versions of FF on the same machine [06:38] It was upgrading an instance of FF and then downgrading it. So updating FF 48 to 49beta to test something then reverting it to FF 48 release [09:03] Screenshotting continues [09:32] *** i0npulse has quit IRC (Ping timeout: 506 seconds) [15:01] http://www.theverge.com/2016/8/9/12410620/play-amiga-games-online-free-internet-archive [15:01] http://thenextweb.com/shareables/2016/08/09/internet-archive-just-uploaded-thousands-playable-amiga-games/ [15:01] http://www.tomshw.it/news/amiga-ritorna-sui-vostri-browser-con-10-000-titoli-gratuiti-79216 [15:16] *** i0npulse has joined #jsmess [16:07] *** naTmeg has joined #jsmess [16:15] Ipggi: yes, but SketchCow's screenshotter machines weren't running two versions of FF :) [16:19] SCREENSHOTTERS STILL GOING by the way [16:19] good :) [16:19] Crazy, ridiculous [16:22] db48x: Fair enough. But at least we all now know that one cause of that IndexedDB write error is a FF issue [16:23] yes [16:23] although it could be an error that we're supposed to handle gracefully [16:24] naTmeg: You're the story of the day [16:24] Naturally, we're seeing problematic performance issues left and right [16:24] What with... you know... tens of thousands of visitors [16:27] it's everywhere now :) [16:27] db48x: is there much that could be done to handle it better? From an end user point of view the "Failed to download game data!" message seems resonable imo [16:28] Ha ha, someone just e-mailed in .adfs [16:29] https://consumerist.com/2016/08/09/more-than-2000-amiga-games-now-online/ [16:29] naTmeg: So you know: https://archive.org/details/softwarelibrary_amiga_workbench [16:30] SketchCow: ahh good ideo [16:31] So yeah, if you can check them out to see if you have suggestions. [16:31] Otherwise, I'll end up swapping the emulators and re-shooting [16:32] SketchCow: just came home from work. we don't have internet there, so it take some time for me to get up to date :p [16:32] No, no problem [16:33] https://www.rockpapershotgun.com/2016/08/09/2000-amiga-games-to-play-for-free-in-your-browser/ [16:39] Let's see how much screenshotting has cost me [16:40] $84 [16:41] Ok, let's try the trick. [16:42] (Convert to sae-1200, reshoot) [16:43] Doing it now. [16:43] We'll see how well that helps. [16:44] Let's find out!! [16:45] Ipggi: potentially, yes [16:45] Ipggi: if we're getting the error because we're exceeding the quota, then we could delete something from it and try again [16:46] https://archive.org/details/100_Most_Remembered_64_Game-tunes_The_19xx_Per_Hakan_Sundell_Ron_Birk was fixed [16:48] https://archive.org/details/Alien_Breed_demo-slideshow_1991_Team_17 nothing [16:50] The screenshotters just finished!! [16:52] https://archive.org/details/Back_to_the_Future_Part_II_demo-playable_1990_Image_Works crashes [16:56] So, quick check. Did we decide sae-a1200, sae-a500 and sae-a500p should be all the possible amigas? [16:56] Do we need to add more? [17:03] I imagine there may be some specialty configs with different hardware options for specific apps, but I know nothing about amiga software and hardware personally [17:13] I'm sure naTmeg will have some ideas [17:15] whether the three config are enough? [17:15] Well, I suspect we might want another hail mary set of configs. [17:15] Like "elt's try" [17:16] ahm, some games and stuff does require some special settings, liek 'blitter immediate' or they do not like the floppy speed set to turbo [17:18] those which fail to load must be test manually [17:18] there could be many reasons [17:22] on sae.net, i use the flags DBF_* for this special settings. see top of index.js [17:23] I realize a lot of our solutions feel like battlefield surgery, but if we could come up with a "just try it" setting that's the equivalent of "most basic settings", that would be good. [17:25] the most basic a an A2000, the default model after setup. it's a balance between all options [17:25] i i fear they will fail nevertheless [17:26] it's most likely the rom [17:26] i=but [17:27] That's fine. [17:27] We're trying the best we can. I will be adding something in that basically sets a metadata pair in the thing before darking it. [17:31] ok. also many old games/apps are of low code-quality and barely worked on the original machines.. [17:37] maybe what we need is a script that takes a list of the broken ones, and just boots it up and tries to get a screenshot with each machine config we have [17:38] then from there we can identify hopefully just a few classes of failures and add new machine types as necessary [17:49] that could be an idea. there are only two more configs needed. one with floppy-speed set to original and one with were the blitter is in immediate mode [17:52] i would try to reset the floppy first and then the blitter. blitter only if the game actually has started. [17:57] sometime a black image with two eyes can be seen. that's the AROS-bootscrren. it means the disk is not bootable and does require a workbench-disk. once the workbench is loaded, the content can be started via double-click [17:58] so you can drop those completely [18:00] OK [18:01] Now my Chrome is no longer booting amiga stuff. [18:01] This is getting rather frustrating. [18:01] jvilk: jvilk jvilk jvilk jvilk [18:01] I'm mailing him [18:02] naTmeg: With regards to the mouse. [18:02] Can we lock it to the canvas more? [18:03] yeah it's hiding the pointer but not using pointerlock [18:03] bai: safari does not support it [18:03] there's that margin around it which sort of provides a visual border, but you have to move around a bit to "calibrate" the mouse to the window size which is a bit weird [18:04] naTmeg: that's fine, people who use safari are used to things not working :) [18:04] it's a pretty small percentage of users [18:05] heh, this one does work quite well on mac :p [18:05] thanks to my brothers macbook ;) [18:05] yeah, they'll just gget the current behavior, while other browsers get the better experience [18:06] I can take a look at it if you'd like [18:06] i can add pointerlock, but i need a workaround for mac [18:06] it [18:07] Well, let's do that. [18:08] you can check if the browser supports pointerlock by seeing if document.pointerLockElement is undefined [18:08] if it's undefined then the browser doesn't know about it, any other value (including null) means it's supported [18:09] SketchCow: try deleting the content of your IndexedDB for archive.org [18:09] I can show you how to do that for Firefox, but no idea for Chrome [18:10] "my saved games and high scores, nooooo!" [18:10] In Chrome, go to Options > Under the Hood > Content Settings > All cookies and Site Data > find the domain where you created the IndexedDB. [18:10] Hit either the "X" or click "Indexed Database" > Remove. [18:10] bai: yea, i will take a look on this soon [18:10] SketchCow: sounds right to me :) [18:10] naTmeg: awesome. let me know if you need any help [18:12] bai: the mouse-speed also depends on the current resolution of the amiga, hires: speed is sync, lores: half-speed, you may have noticed that already... [18:12] ahh, is that what it is, yeah that makes sense [18:13] bai: thanks. i'm just working on the CAPS-support. maybe i can finish it this weekend but not sure.. [18:23] bai: there is a mousehack-option in winuae which i have not ported yet. iirc it should sync the pointer for every amiga-resolution. [18:25] I can't delete the indexeddb anymore [18:26] Ok, fixed [18:29] bai: just checked the source. mousehack is something else.. [18:29] maybe i can write a own function to sync it, i'll check that [18:30] hmm ok. basically the workflow for activating pointerlock is, whenever the user clicks, you'd do something along the lines of: if (document.pointerLockElement === null) { canvas.requestPointerLock(); } else { /* normal click handling */ } [18:31] then the other difference is, when pointerlock is active you don't get a clientX/clientY property with the event, instead you get relative movements as event.movementX / movementY [18:33] hmm, maybe there should be a extra request-button for this. because the use have to allow it (minimum once) and have to press ESC to exit, which also could confuse the game/app running [18:33] user [18:35] yeah, I think users have to press esc twice to make it pass through to the running app. it's a trade-off, but generally we've found people don't have a problem with it on the other systems [18:35] whereas when the mouse doesn't work as they expect, they quickly decide it doesn't work right [18:36] well that true [18:40] ok i'll implement it on weekend. should'nt take too long.. [18:40] sweet, thanks [18:51] SketchCow: softwarelibrary_amiga does look very clean now. working titles only :) [18:54] ahh there are some 'windows' too. anyway, looks good [18:58] I'm moving as I can. [18:59] np [19:45] *** Coderjoe has quit IRC (Read error: Operation timed out) [19:47] https://archive.org/details/softwarelibrary_amiga_workbench [19:47] It fixed a couple! [19:47] (A couple) [20:00] nice [20:09] *** Coderjoe has joined #jsmess [21:33] *** SketchCow has quit IRC (Remote host closed the connection) [21:43] *** SketchCow has joined #jsmess [21:47] *** naTmeg has quit IRC (Leaving) [23:23] * db48x starves [23:24] also, my favorite italian restaurant is closed for renovations [23:25] oh nice, this emailer seems distraught because I have neglected to document the scripted amiga emulator, and have especially neglected to include a link to the emulator itself [23:25] https://github.com/db48x/emularity/commit/7acd3d89aa2b3a238ca1e2ed89ea50a6bbaa494d#commitcomment-18582818