Page 2 of 3

Re: We seem to have some new publicity

Posted: Thu Sep 14, 2017 2:22 pm
by Jubatian
nicksen782 wrote: Thu Sep 14, 2017 2:13 pm Here is a (maybe?) simple starting point: I see that the FPS of CUzeBox will vary from 30 to 60. It usually plays at 30 now. What if that FPS was forced for Emscripten builds? Or maybe even some hot key could be pressed? I saw something like that on the CUzeBox documentation, the Frame Limiter. What does that do?
That has not much to do with it, it is already pretty robust. You usually get 30 FPS since the emulator determines that it can't get 60FPS in the long run (switching to 60FPS requires several seconds of steady emulation without lagging). If it tries 60FPS, as soon as there is some lag, it will drop frames long before it would impact the audio. The severe problem with Emscripten and JavaScript is that the host's performance isn't steady (CUzeBox can actually run rather well with a native compile even if the host is unable to run it at full speed, it adapts to its performance running the game slower, the audio at lower frequency). It heavily fluctuates, there are long bursts when emulation can complete all fine, then the browser thinks it has to do something and steals all the CPU. Or the JavaScript garbage collector starts bringing it down to its knees. These can not be foreseen, and even though CUzeBox would start dropping frames on instant, the system hogged by these is too slow to run the emulation even without anything displayed. The browser simply doesn't give it enough CPU time to emulate the AVR, so it is suddenly totally impossible to feed the audio buffer.

Re: We seem to have some new publicity

Posted: Thu Sep 14, 2017 2:44 pm
by nicksen782
I have clearly noticed this when I try to record the emulator with a screen recorder. My computer is actually pretty decent and I've been working mostly in Chrome. Do you encounter the same problems with Firefox?

I wonder if there is some way (probably through Emscripten) to reserve a set of resources?

Re: We seem to have some new publicity

Posted: Thu Sep 14, 2017 3:13 pm
by Jubatian
nicksen782 wrote: Thu Sep 14, 2017 2:44 pm I have clearly noticed this when I try to record the emulator with a screen recorder. My computer is actually pretty decent and I've been working mostly in Chrome. Do you encounter the same problems with Firefox?

I wonder if there is some way (probably through Emscripten) to reserve a set of resources?
Yes, I experience it. I now committed a new version where I toned the aggressivity of the audio frequency scaler down. Now it is less wobbly, and (but) you will also get skips when the performance dips. I don't think it is possible to reserve resources, the browser should already give the JS what it can, and it would be a security issue if any user program on any site could take away the resources it needs for its housekeeping. For me it rather feels like a problem on the browser's end, that it should try to consume CPU resources more evenly (not in occasional bursts of heavy load).

The way CUzeBox interacts with the browser is as far as I know the most recommended one, using requestAnimationFrame, when the browser should really aim to give it what it can for a smooth animation.

Re: We seem to have some new publicity

Posted: Thu Sep 14, 2017 3:27 pm
by nicksen782
Perhaps Emscripten itself will continue to improve over time.

http://kripken.github.io/emscripten-sit ... notes.html

I compile a new CUzeBox for Emscripten when Jubation releases a new version. I'll likely do this tonight.

Re: We seem to have some new publicity

Posted: Thu Sep 14, 2017 4:09 pm
by Artcfox
I don't think it matters if the web browser is not given any CPU for a long time.

Re: We seem to have some new publicity

Posted: Fri Sep 15, 2017 7:39 pm
by Halamix2
Could rewriting in webassembly help with performance?

Re: We seem to have some new publicity

Posted: Fri Sep 15, 2017 7:47 pm
by nicksen782
The Online Player consists of an Emscripten build of CUzeBox with a wrapper for loading files into new instances of the Emscripten FS.

As I understand, Emscripten can output to Webassembly or asm.js.

https://github.com/kripken/emscripten/wiki/WebAssembly

WASM=1 is required (or BINARYEN=1). I don't see that in the CUzeBox make files.

So, Jubation, please correct me if I am wrong, but Halamix2 is suggesting changing the makefile to output something different? There appear to be a couple different ways to build with Emscripten. Perhaps another one is better?

Re: We seem to have some new publicity

Posted: Fri Sep 15, 2017 7:54 pm
by Artcfox
Halamix2 wrote: Fri Sep 15, 2017 7:39 pm Could rewriting in webassembly help with performance?
The web version of the emulator is compiled with Emscripten, which compiles it down to the asm.js strict subset of JavaScript. It's my understanding that all modern browsers are able to convert this "JavaScript asm code" almost directly into native machine instructions. I thought webassembly died when all the major game engine creators (Unreal Engine 4 comes to mind) got on board with Emscripten and asm.js?

It's now possible to run the web version at 100% emulation speed on my cell phone, so I'm pretty sure any performance problems are due to people running it on underpowered (or overloaded) computers.

Edit: It appears that it's also a target, and may be faster. Weird that I hadn't heard anything about webassembly in years. Today I learned! I think it's totally worth a shot to see which is faster.

Re: We seem to have some new publicity

Posted: Fri Sep 15, 2017 8:17 pm
by Jubatian
WebAssembly doesn't have a too wide support yet: http://caniuse.com/#feat=wasm I wouldn't really recommend it for now, later maybe. I could do a successful compile, but right now I only have Firefox ESR which is 52.3.0, the first version which is said to support it. I didn't experience any performance improvement (at least it didn't crash).

Re: We seem to have some new publicity

Posted: Fri Sep 15, 2017 8:24 pm
by nicksen782
No performance improvement? Something must be different. I only need one build of CUzeBox for each game on that site. If in fact some other build method improves things then I could probably make it a choice for the user with what we already have as the default.

What about that? Probably a great way to rapidly test multiple builds actually.

Edit: one build meaning literally one file that is the Emscripten compiled CUzeBox. One file is shared by each game. The site could be told which compiled CUzeBox file to use. Nothing really stopping me from doing that with Uzem as an alternative choice for the user.