em-fceux - FCEUX for the web

This is an archive of a topic from NESdev BBS, taken in mid-October 2019 before a server upgrade.
View original topic
em-fceux - FCEUX for the web
by on (#150857)
Ladies and gents!

I'm happy to announce em-fceux, an Emscripten port of FCEUX 2.2.2 for the web.

Play it here: https://tsone.kapsi.fi/em-fceux/

Simply drag and drop a game ROM on the em-fceux window to play. The games and save data is stored locally (using IndexedDB). Keyboard bindings can be customized (defaults to FCEUX SDL driver keys). Gamepads/joysticks should work.

Source code is here: https://bitbucket.org/tsone/em-fceux (also has some in-depth information) License is GPLv2 (as with FCEUX).

Attached are some screenshots of em-fceux running on Google Chrome.

Enjoy! :)
Re: em-fceux - FCEUX for the web
by on (#150859)
Nice one. If you want to include some ROMs besides 2048 in the cart stack by default, feel free to include STREEMERZ there.
Re: em-fceux - FCEUX for the web
by on (#150860)
thefox wrote:
If you want to include some ROMs besides 2048 in the cart stack by default, feel free to include STREEMERZ there.


Thanks for the permission!
Re: em-fceux - FCEUX for the web
by on (#150870)
It requires WebGL won't work on any GPU that supports only OpenGL 1.4. WebGL requires at least OpenGL 2.0, which shuts out the Intel GMA 3100 in my laptop. (My laptop is a Dell Inspiron mini 1012 with an Atom N450 CPU.) From Firefox's error console:
Code:
Error: WebGL: Refused to create native OpenGL context because of blacklisting. fceux.js:1:68822
Error: WebGL: WebGL creation failed. fceux.js:1:68822
TypeError: GLctx is undefined

Could em-fceux give a more visible diagnostic for this situation the way http://get.webgl.org/ does?

Make a 2D Canvas version and I'll grant permission for a couple more games.
Re: em-fceux - FCEUX for the web
by on (#150936)
tepples wrote:
It requires WebGL won't work on any GPU that supports only OpenGL 1.4. WebGL requires at least OpenGL 2.0, which shuts out the Intel GMA 3100 in my laptop. (My laptop is a Dell Inspiron mini 1012 with an Atom N450 CPU.) From Firefox's error console:
Code:
Error: WebGL: Refused to create native OpenGL context because of blacklisting. fceux.js:1:68822
Error: WebGL: WebGL creation failed. fceux.js:1:68822
TypeError: GLctx is undefined

You can try turning off the GPU blacklisting in Firefox. If you have issues after this, try to updating the GL driver (or try another driver). Unfortunately there are issues in both driver and WebGL implementations and not all GPUs may work.

tepples wrote:
Could em-fceux give a more visible diagnostic for this situation the way http://get.webgl.org/ does?

Well, at least there should be an error if a required browser feature is not supported.

tepples wrote:
Make a 2D Canvas version and I'll grant permission for a couple more games.

I have no plans to write support for 2D canvas. The NTSC signal and TV emulation effects use shaders and would not work with software canvas.
Re: em-fceux - FCEUX for the web
by on (#150943)
Fun!
Re: em-fceux - FCEUX for the web
by on (#150978)
This is very cool! I had actually discovered this earlier today while trying to see if someone had already made an emscripten port of FCEUX, and lo and behold, somebody did!

If it's not too hard to get going, I'd be interested in contributing / making a fork with the following features:
- more classic FCEU-style UI for with some menus at the top for familiarity, less collapsing sidebar menus.
- option to reset
- option to change the scale of the emulation, ala windowed FCEUX video settings
- option to use the same possible input types on both controller ports
- when key binding, don't also send the button presses to the game
- remove confirmation for selecting a new ROM.
- reduce prompt when deleting a ROM to a single confirmation.
- a file open window
- import/export tool for saves and save states
- option to use localStorage for battery saves instead of IndexedDB (yes, I know it's much smaller, but these are NES ROMs, and it's supported more widely)
- optional canvas rendering core (disables TV + NTSC emulation)
- debugger support so it's possible to view CHR and nametables, step through code, view RAM, etc
- (low priority) JS tool scripting interface via embind instead of Lua integration. Would definitely need some rewriting to register callbacks instead of doing polling loops in Lua for advancing the emulation state.
- a non-intrusive embedded mode that lets you remove 90% of the UI and just play a specific URL / binary blob with some default controls, an option to trigger fullscreen.

The last option is very important to me. I distribute try-in-browser versions of some of my ROMs... Like Hyper Cat which uses GameBoy-Online and Final Duck which is using Javatari.js. I also would like to make an lightweight HTML5 editor that can assemble 6502 code and run ROMs directly in the browser -- so that's another reason I'd really like debugger support + non-intrusive embedding.

(Looks like Hyper Cat is a little broken, the screen wasn't normally squashed like that... I wonder if a browser update deprecated something or caused a regression.)

Anyway these are just suggestions, I'd do them myself if I find myself motivated and merge if my contributions are wanted. Anyway, I am just rambling, looks cool!
Re: em-fceux - FCEUX for the web
by on (#150979)
Thanks!

Overkill wrote:
If it's not too hard to get going, I'd be interested in contributing / making a fork with the following features:

Certainly! Make a fork, pull request or submit bugs/feature requests in the bitbucket project issue tracker. There is a short guideline for submitting bugs/feature requests. NOTE: The site and the source code are under GPLv2 and modifications must be published.

Overkill wrote:
- option to reset

Press Ctrl+R to reset.
Re: em-fceux - FCEUX for the web
by on (#151456)
Based on tepples and Overkill's feedback, I'm working on 2D canvas renderer support.

Public staging version is here: https://tsone.kapsi.fi/em-fceux-staging/ The 2D canvas/WebGL switch is in the settings tab.

If it doesn't work for you, please shout really loud so I can hear etc. :)

I'm also looking for someone to test this on OS X Safari. Anyone with a Mac?
Re: em-fceux - FCEUX for the web
by on (#151486)
The 2D canvas version is surprisingly playable in Firefox on Linux, even on a dinky little Atom, for games that aren't heavy twitch games. I'm considering replacing the JSNES on my web site with this once it matures. Do you plan on releasing a package I can install to customize the games in the "stack" without having to install all of Emscripten?

Things I found in my first pass, some based on the last time I tried a JavaScript NES emulator:
  • Audio latency gets longer and longer over time. As I type this while running one of my own games, it's up to a second and a half.
  • Zap Ruder, Vaus Test, and Eighty don't do $#!+.
  • The mouse doesn't do anything in Thwaite.
  • Good: Because the Action 53 mapper (iNES #28) is supported, STREEMERZ, LAN Master, and Lawn Mower can be replaced with the first volume of Action 53 if space in the stack becomes limited.
  • The "ARE YOU REALLY SURE YOU WANT TO DELETE" modals are annoying. It'd be better to just have the X immediately move cartridges out of the stack into a trash can. Clicking the trash can would put all "trashed" ROMs back in the stack, and leaving trash alone for 5 minutes would delete them.
  • Same with "Do you want to run".
  • rgb121 is very sensitive to frameskip and can appear to lock up when the frameskip remains even for an extended period.
  • Good: Sprite Cans 2011 had occasional flicker. This is good because it's accurate.
  • BNTest: When a zipfile contains multiple ROMs, only one is added to the stack.
  • Good: DPCM Letterbox and Boing 2007 worked because they work in FCEUX.
Re: em-fceux - FCEUX for the web
by on (#151534)
EDIT: Added mention of Overkill's request on confirm modals when deleting or starting a game.

EDIT: I overlooked the sentences with the thrash can idea for deleted games. I changed my comment to mean easier deletion and starting of games without so many intrusive modals -- not adopting the thrash can itself.

tepples wrote:
Do you plan on releasing a package I can install to customize the games in the "stack" without having to install all of Emscripten?

Extremely good point! I guess Overkill was also requesting this.

tepples wrote:
  • Audio latency gets longer and longer over time. As I type this while running one of my own games, it's up to a second and a half.

You mean on Linux Firefox, right? I know about this issue. Eventually the audio will just stop playing... This may be a bug in Mozilla's Web Audio implementation but I need to check. Webkit-based browsers do not have this problem.

tepples wrote:
  • Zap Ruder, Vaus Test, and Eighty don't do $#!+.

  • em-fceux doesn't use the new PPU in FCEUX as that's more computationally heavy. Do these work without problems with the old PPU in FCEUX 2.2.2?

    tepples wrote:
  • The mouse doesn't do anything in Thwaite.

  • I guess you mean Super NES Mouse, right? It's not supported as I didn't have time to add/enable the peripherals. Currently only Zapper is supported in addition to the regular game controllers.

    tepples wrote:
  • The "ARE YOU REALLY SURE YOU WANT TO DELETE" modals are annoying. It'd be better to just have the X immediately move cartridges out of the stack into a trash can. Clicking the trash can would put all "trashed" ROMs back in the stack, and leaving trash alone for 5 minutes would delete them.
  • Same with "Do you want to run".

  • Noted. I have to think about this -- I mean more direct deleting and starting a game, not the thrash can idea. Overkill requested something similar which now starts to make sense... The modals should be also replaced with something less intrusive to avoid audio stuttering.

    tepples wrote:
  • rgb121 is very sensitive to frameskip and can appear to lock up when the frameskip remains even for an extended period.

  • Browsers can't really guarantee a steady frame rate. Frameskipping happens all the time. Do you think that even-odd frameskipping pattern would be beneficial for other games as well? Is it worth the effort?

    tepples wrote:
  • BNTest: When a zipfile contains multiple ROMs, only one is added to the stack.
  • [/quote]
    In short: one dropped file = one game on stack... The .zip file is not decompressed when dropped on the window. Instead, it's stored in the persistent Emscripten IndexedDB file system in a directory reserved for game files. The game stack essentially lists all files from this directory (plus the built-in games). To load a game, path to a file is passed to the FCEUX game load function, and as FCEUX loads the first game it sees from the .zip, it appears the .zip only has one game while it may indeed have multiple.
    Re: em-fceux - FCEUX for the web
    by on (#151535)
    tepples wrote:
    ...and leaving trash alone for 5 minutes would delete them.

    Not a fan of this idea. Just leave the trash there and have an option to empty the "trash can".
    Re: em-fceux - FCEUX for the web
    by on (#151536)
    Thanks to everyone for the bug reporting and feature requests so far! It's however getting hard to keep track of them, so I want to kindly remind of the project issue tracker. Issues can be added anonymously (doesn't require bitbucket account). When adding an issue, please follow the "no bullshit" guideline. Thanks for understanding! ;)
    Re: em-fceux - FCEUX for the web
    by on (#151552)
    thefox wrote:
    tepples wrote:
    ...and leaving trash alone for 5 minutes would delete them.

    Not a fan of this idea. Just leave the trash there and have an option to empty the "trash can".

    It's a bit bizarre to suggest the user wait for an essentially unpredictable, but relatively short delay for deletion. This really should be put explicitly under the user's control, a deliberate and predictable action.

    Maybe you're thinking about it like real world trash that gets taken away by the municipality on a regular basis? There are a thousand reasons why that is sensible for your real world garbage, but a thousand reasons why it is not sensible for organizing your virtual NES collection.
    Re: em-fceux - FCEUX for the web
    by on (#151555)
    tsone wrote:
    [Increasing latency] may be a bug in Mozilla's Web Audio implementation but I need to check. Webkit-based browsers do not have this problem.

    I wish you luck on this because "best viewed with Chrome; click here to download and install Chrome" is no better than "best viewed with FCEUX; click here to download and install native FCEUX".

    tsone wrote:
    tepples wrote:
    Zap Ruder, Vaus Test, and Eighty don't do $#!+.

    em-fceux doesn't use the new PPU in FCEUX as that's more computationally heavy. Do these work without problems with the old PPU in FCEUX 2.2.2?

    Yes. They just require Zapper, Arkanoid Controller, and Four Score support respectively. It wasn't obvious how to enable the Zapper.

    Quote:
    Do you think that even-odd frameskipping pattern would be beneficial for other games as well? Is it worth the effort?

    I don't know the intricacies of waiting for vblank and presenting the next frame on 2D canvas or WebGL. But given how many NES games use a 30 Hz flicker to indicate mercy invincibility, I'd recommend showing every third frame or every fifth frame if the machine isn't fast enough to show every frame.

    tepples wrote:
    FCEUX loads the first game it sees from the .zip

    Then perhaps one of us should request better handling of multi-ROM zipfiles on FCEUX's bug tracker.

    rainwarrior wrote:
    It's a bit bizarre to suggest the user wait for an essentially unpredictable, but relatively short delay for deletion.

    It's modeled after the "Undo Send" delay that Gmail users can enable on the basis that undo is better than confirmation.
    Re: em-fceux - FCEUX for the web
    by on (#151608)
    tepples wrote:
    I wish you luck on this because "best viewed with Chrome; click here to download and install Chrome"

    Not just Chrome. Webkit is the reason. Safari and Opera use it as well, and Safari is pre-installed on Macs. Later on Microsoft Edge will be also pre-installed on Windows 10 and will probably run em-fceux as well... Currently however, em-fceux seems to work best with webkit-based browsers... Don't get me wrong. I'm not dissing Firefox. I love it.

    tepples wrote:
    tsone wrote:
    tepples wrote:
    Zap Ruder, Vaus Test, and Eighty don't do $#!+.

    em-fceux doesn't use the new PPU in FCEUX as that's more computationally heavy. Do these work without problems with the old PPU in FCEUX 2.2.2?

    Yes. They just require Zapper, Arkanoid Controller, and Four Score support respectively. It wasn't obvious how to enable the Zapper.

    I tried Zap Ruder and at least pong and the music thingy works fine. Also the Y coordinate seems to be registered correctly (as I'd expect from FCEUX old PPU)... Can you be more clear on what is not working with Zap Ruder (not counting FCEUX 2.2.2 old PPU issues)?

    Sorry, but Arkanoid controller and FourScore are not supported ATM. I had to focus on basic features first. I'll continue improve the emulator incrementally when I have time.

    tepples wrote:
    I don't know the intricacies of waiting for vblank and presenting the next frame on 2D canvas or WebGL. But given how many NES games use a 30 Hz flicker to indicate mercy invincibility, I'd recommend showing every third frame or every fifth frame if the machine isn't fast enough to show every frame.

    There is no standard way to set canvas rendering frame rate or enabling/disabling vblank from browser javascript. The "proper" way to redraw canvas is to do it in a callback registered to requestAnimationFrame(). Problem is, the callback will be called rather erratically (however, 60 fps at max), and there's no way to predict when next frame will land... But I got what you meant by rendering every 3,5,7.. frames when frameskipping. Thanks! I've added a feature request so I remember this later :)
    Re: em-fceux - FCEUX for the web
    by on (#151611)
    tsone wrote:
    submit bugs/feature requests in the bitbucket project issue tracker.

    I'm trying to use your time wisely up front so that I don't waste it later, and I have three issue reports saved on my computer that I will post once these two issues are clarified:

    If I'm still seeing an issue in both Firefox and Chrome on my machine, even though it's been marked as "RESOLVED", should I add a comment, create another issue, or do something else?

    Should I try to report issues against the normal URL or against whatever's at the staging URL? Or do I need to reproduce the problem in all four environments (Chrome at normal URL, Firefox at normal URL, Chrome at staging URL, and Firefox at staging URL) before reporting anything?
    Re: em-fceux - FCEUX for the web
    by on (#151791)
    tepples wrote:
    rainwarrior wrote:
    It's a bit bizarre to suggest the user wait for an essentially unpredictable, but relatively short delay for deletion.

    It's modeled after the "Undo Send" delay that Gmail users can enable on the basis that undo is better than confirmation.

    I wrote an angry reply to this earlier, but I was ashamed of myself and deleted it. Now that the moment has passed I think I can respond reasonably.

    The trash can itself is the "undo" step for removing a game. That's the important use case. It's already fine with just the trash can.

    Emptying the trash is not something that needs to be made more convenient, and having it take two clicks to do is essentially a "confirmation". This is a "confirmation" on whether you want to eliminate your ability to "undo" trashing a game.

    Your suggestion was that emptying the trash should not have a confirmation, but instead be automatic with a specific 5 minute delay. This works against the usefulness of the trash can as an "undo" feature, which is why I think it is a bad idea. When the trash can is automatically emptied, its undo functionality is defeated at that moment.

    If it was real files on a hard drive, there would be space to recover by automatic deletion, but these are just symbolic links, totally insignificant. The only thing automatically emptying the trash does is inconvenience the user who might take more than 5 minutes to decide they want to "undo" a game out of the trash (plausible situation, since they're probably busy playing games). Even a predictable empty-trash (like when you close the browser) would be a ton better than a 5 minute auto-delete.

    Actually, in my opinion, the most practical thing to do would probably be no trash can at all. No implementation cost, and since removing a game wouldn't destroy the ROM on your hard drive anyway, it's easy to undo by just re-opening the file.


    Anyhow, the part that made me mad was the article link. The article itself is annoying and arrogant enough; I absolutely despise "one size fits all" rules about programming or usability design. Good design responds to the specifics of the situation, always. You stating "undo is better than confirmation" irks me a lot just by itself, as it would be obviously ludicrious to apply to all situations. There is a time and place for both undo and confirmation in design, very often in tandem with each other. Saying it and linking to the article, instead of actually addressing its merit as applied to this specific situation is what set me off. So this author had some bad experiences with a particular kind of design, and maybe he's right that they should have been done differently in those cases, but to offer it as some generic design rule is awful. Design requires critical thinking, not dogma.

    In Google's e-mail undo case, they were applying an incremental change to a send button with no undo. A hidden delay on e-mail was already practical for them (e.g. as part of an anti-spam measure), but they figured out a nice user-facing feature that could be implemented on top of it. It seems like a fine decision on their part, but only in the context in which that decision was made.
    Re: em-fceux - FCEUX for the web
    by on (#151802)
    IMPORTANT NOTICE:

    If em-fceux doesn't start after loader bar is full, please disable (or clear) the browser cache and reload the page. I'll fix this issue ASAP!

    tepples wrote:
    If I'm still seeing an issue in both Firefox and Chrome on my machine, even though it's been marked as "RESOLVED", should I add a comment, create another issue, or do something else?

    Thanks for bringing this up! :beer: :D I found this bug (Zapper not working) and it's now fixed in staging. No need to add this bug. I simply forgot to attach a mousedown callback to the 2D canvas... :roll:

    tepples wrote:
    Should I try to report issues against the normal URL or against whatever's at the staging URL? Or do I need to reproduce the problem in all four environments (Chrome at normal URL, Firefox at normal URL, Chrome at staging URL, and Firefox at staging URL) before reporting anything?

    It's entirely up to you which, and you can use any browser you want. However, staging version is preferred for reporting bugs as it has the latest changes. Idea with staging is to provide a "live" testable version for you guys to test (like a development build). Staging will gradually improve as bugs get fixed and features added, and finally it is deployed as the official version. My plan is that next official version is released when most of the current issues with >= major priority are resolved.
    Re: em-fceux - FCEUX for the web
    by on (#151809)
    rainwarrior wrote:
    tepples wrote:
    rainwarrior wrote:
    It's a bit bizarre to suggest the user wait for an essentially unpredictable, but relatively short delay for deletion.

    It's modeled after the "Undo Send" delay that Gmail users can enable on the basis that undo is better than confirmation.

    I wrote an angry reply to this earlier, but I was ashamed of myself and deleted it. Now that the moment has passed I think I can respond reasonably.

    The trash can itself is the "undo" step for removing a game. That's the important use case. It's already fine with just the trash can.

    Emptying the trash is not something that needs to be made more convenient, and having it take two clicks to do is essentially a "confirmation". This is a "confirmation" on whether you want to eliminate your ability to "undo" trashing a game.

    ...

    Gentlemen! :) It's great to see your excitement, but IMO "trash can" feature doesn't fully justify the effort and added complexity. Also, browser local data storage can be quite small (5MB and up). The limited space shouldn't be used for trash. The Emscripten IndexedDB sync will also get slower with more files... But most importantly, think about the game stack metaphor -- you wouldn't throw valuable game carts in the trash, right? :D

    I agree it's overkill to have double confirmation for simply deleting a game. I added the second one because the start and delete game confirmations look almost exactly the same. As the 'X' icon is over the game cart, it's easy to accidentally click it and quickly select 'Ok', only to find the game you wanted to play is gone... Second confirmation was the simplest way to solve this problem... I know this must be changed, so I have created a feature request for this.