Please check out my browser-based javascript emulator

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

JRoatch
Formerly 43110
Posts: 422
Joined: Wed Feb 05, 2014 7:01 am
Contact:

Re: Please check out my browser-based javascript emulator

Post by JRoatch »

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Please check out my browser-based javascript emulator

Post by tepples »

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.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Please check out my browser-based javascript emulator

Post by Dwedit »

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.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Please check out my browser-based javascript emulator

Post by tepples »

Has anyone complained to bugzilla.mozilla.org about this slow resizing yet?
Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: Please check out my browser-based javascript emulator

Post by Sik »

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...
peteward44
Posts: 5
Joined: Mon Nov 10, 2014 7:54 am

Re: Please check out my browser-based javascript emulator

Post by peteward44 »

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.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Please check out my browser-based javascript emulator

Post by Dwedit »

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.
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: Please check out my browser-based javascript emulator

Post by Sik »

Dwedit wrote:Texture sizes should be powers of 2, so 256x256 for a NES screen, and pixel format should be 32-bit BGR.
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)
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Please check out my browser-based javascript emulator

Post by tepples »

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.
peteward44
Posts: 5
Joined: Mon Nov 10, 2014 7:54 am

Re: Please check out my browser-based javascript emulator

Post by peteward44 »

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.
User avatar
Dwedit
Posts: 4924
Joined: Fri Nov 19, 2004 7:35 pm
Contact:

Re: Please check out my browser-based javascript emulator

Post by Dwedit »

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!
Gridiron Gamer
Posts: 1
Joined: Wed Jul 13, 2022 5:00 pm

Re: Please check out my browser-based javascript emulator

Post by Gridiron Gamer »

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.
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.
Post Reply