Please check out my browser-based javascript emulator
Moderator: Moderators
Re: Please check out my browser-based javascript emulator
I didn't mean WebGL exclusively. I have not written a NES emulator but I imagine PPU emulation is CPU bound anyway, and that its output is going to be a byte array of indexed pixels. That byte array could either be converted into RGBA pixels by the CPU to load to Canvas, or (if available) take 1/4 the GPU bandwidth by loading the byte array directly via opengl. In any case proper profiling needs to be conducted before making informed optimizing decisions, and the pixel bandwidth may not even be a issue.
Re: Please check out my browser-based javascript emulator
In any case, you can probably skip much of your rendering code if the tab is not visible (Page Visibility API) and the mapper doesn't snoop on PPU reads (like MMC2 and MMC4, and to a lesser extent MMC3 and JY). Only the scanlines containing sprite 0 or containing at least 8 sprites have any effect that the rest of the system can see.
Re: Please check out my browser-based javascript emulator
The bottleneck is in how the browser resizes canvases, not your code.
You can make a little test JS page that fills a canvas red and blue at 60FPS, and even that will run too slowly.
This is such a stunning display of incompetence from the browser makers. In Windows, you can just make a DirectDraw surface in offscreen video memory. Blitting a video ram surface to the primary buffer can run at around 1900FPS, and that's with stretching.
You can make a little test JS page that fills a canvas red and blue at 60FPS, and even that will run too slowly.
This is such a stunning display of incompetence from the browser makers. In Windows, you can just make a DirectDraw surface in offscreen video memory. Blitting a video ram surface to the primary buffer can run at around 1900FPS, and that's with stretching.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Re: Please check out my browser-based javascript emulator
Has anyone complained to bugzilla.mozilla.org about this slow resizing yet?
Re: Please check out my browser-based javascript emulator
I think all browsers are affected though. The problem is that canvas resizing is done through the DOM renderer, and that part of browsers has always been notoriously slow (and the main target of hate of a lot of people working with javascript, and now people doing CSS3 animations and transformations as well).
And of course I assume they don't even care about this issue since they expect you to use WebGL and let the GPU scale it for you...
And of course I assume they don't even care about this issue since they expect you to use WebGL and let the GPU scale it for you...
-
- Posts: 5
- Joined: Mon Nov 10, 2014 7:54 am
Re: Please check out my browser-based javascript emulator
Some really interesting ideas here. I think what i'm going to experiment with is having a WebGL implementation with a canvas fallback if it's not supported properly. Sadly WebGL doesn't support glPutPixels() so i'll have to write to a texture first, but that shouldn't be too bothersome. I'll report back with my results.
@koitsu I never realised that the sprite overflow made that much a difference on some commercial games. I think i'll reinstate my old overflow code in that case, and maybe leave it as an option to turn it off.
@koitsu I never realised that the sprite overflow made that much a difference on some commercial games. I think i'll reinstate my old overflow code in that case, and maybe leave it as an option to turn it off.
Re: Please check out my browser-based javascript emulator
I hear that for opengl, it's best to use glTexSubImage2D, then draw a quad containing the texture. Texture sizes should be powers of 2, so 256x256 for a NES screen, and pixel format should be 32-bit BGR.
If you're trying for dirty rectangles, proper OpenGL lets you update arbitrary rectangular regions from the source image by using glPixelStorei(GL_UNPACK_SKIP_PIXELS, x); glPixelStorei(GL_UNPACK_SKIP_ROWS, y); glPixelStorei(GL_UNPACK_ROW_LENGTH, width); before your call to glTexSubImage2D, but WebGL is based on OpenGL ES 2.0, which does not support those commands for some stupid reason.
If you're trying for dirty rectangles, proper OpenGL lets you update arbitrary rectangular regions from the source image by using glPixelStorei(GL_UNPACK_SKIP_PIXELS, x); glPixelStorei(GL_UNPACK_SKIP_ROWS, y); glPixelStorei(GL_UNPACK_ROW_LENGTH, width); before your call to glTexSubImage2D, but WebGL is based on OpenGL ES 2.0, which does not support those commands for some stupid reason.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Re: Please check out my browser-based javascript emulator
I thought it had to be BGRA for optimal performance (i.e. no internal texture conversion)? Especially since as far as I know now RGB textures aren't used anymore, they always get the alpha channel added by the driver (R and RG are untouched). Just for the sake of remarking, OpenGL's BGRA is Direct3D's ARGB (yeah, they have different endianness)Dwedit wrote:Texture sizes should be powers of 2, so 256x256 for a NES screen, and pixel format should be 32-bit BGR.
Re: Please check out my browser-based javascript emulator
There should be some way to query the driver to find its preferred texture format, such as channel ordering within a texel, whether Z-ordering (interleaving of X and Y coordinate bits, sometimes called "swizzling", or "twiddling" in KGL for Dreamcast) is needed for acceptable cache performance, etc.
-
- Posts: 5
- Joined: Mon Nov 10, 2014 7:54 am
Re: Please check out my browser-based javascript emulator
I've updated the live demo with WebGL compatibility, i've noticed some increase in performance. I'll start work on the key remapper soon.
Re: Please check out my browser-based javascript emulator
It's telling me that every file has an invalid header now. This is when I use the Open button at the bottom. Dragging files works though.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
-
- Posts: 1
- Joined: Wed Jul 13, 2022 5:00 pm
Re: Please check out my browser-based javascript emulator
Revisiting this thread. Was there ever an updated file with the 2nd controller input mapping fixed? Having player 2 active is the last missing piece for this great emu.peteward44 wrote: ↑Fri Nov 14, 2014 9:21 am I've updated the live demo with WebGL compatibility, i've noticed some increase in performance. I'll start work on the key remapper soon.