Ah now I see what you mean. Yeah I already do that in my games so I can use expansion port controllers.This won't work in a 4 player game though, and I think it's really unrelated to the emulator inputs that should preferably be separate.

There's one fundamental thing I still can't find anywhere in Mesen. Controller II microphone input. If possible I'd request to make it possible to assign the mic to its own separate input, not like in FCEUX where it replaces the controller II START button when enabled.

You're not blind - there's no microphone support yet. It's been on my list of things to do for a while (along with adding support for all the other types of controllers that Mesen doesn't support yet) - the microphone should be pretty simple to add though, I'll try to get it done over the next few days.

I just released 0.9.2 which adds/improves a number of things in the debugging tools:-Added a "Developer Mode" option in preferences that moves all debugging tools to the "Debug" menu in the main window (and all debug tools can now be opened without opening the main debugger window first)-LUA scripting-Syntax highlighting in the assembler (and some bug fixes)-A few new small features/improvements in the PPU viewer-iNES header editor-Integration with freem's ASM6 fork - ASM6f can now export .mlb & .cdl files which can be imported into Mesen's debugger to get labels/comments and code/data analysis-Changes done to PRG ROM or CHR ROM via the debugging tools (e.g chr editor, assembler or hex editor) can now be saved as an IPS file

And then some non-debugger stuff:-Added a first-run setup configuration dialog to choose between portable mode or store-in-profile mode-Added some options to select paths (and toggle between portable/profile modes)-Some fixes for HD packs and support for replacing background music and sound effects with ogg sound files.-Support for the famicom's 2P microphone-Improved startup performance

Now we're getting somewhere. It asked me whether I wanted to put the settings in the same folder as the executable or in my profile, the latter being ~/Mesen. In GNU/Linux, it's common to put data specific to a particular user and application in a directory whose name begins with a dot so that it doesn't clutter the home directory. One possibility is ~/.config/Mesen.

After all that, it gave me an alert box with the following text, which I had to retype because the alert box did not let me copy its text:

The Microsoft .NET Framework 4.5 could not be found. Please download and install the latest version of the .NET Framework from Microsoft's website and try again.

This gives me no information as to what other libmono-system-*4.0-cil packages I need to install? Is there a verbose option of some sort to see what library isn't being found?

Mesen README states that mono-complete is required. Yet APT says this is a 150 MB install on top of mono-runtime, S.W.F, and S.I.C. Should I just swallow this and be thankful it's smaller than Wine? I have to keep Wine around for FamiTracker anyway even if I do eventually phase out FCEUX debugging version in favor of Mesen. A 100 MB runtime here, a 100 MB runtime there, and pretty soon we're talking real disk space. So to answer your question elsewhere, Mesen is fine if you already have mono-complete installed to run another application. I guess FCEUX might be better if you already have wine installed to run another application but not mono-complete.

I bit the bullet and installed mono-complete, and the main window opened. But that wasn't what I expected to happen, as I typed this command:

Code:

mono ~/Downloads/Mesen.exe --help

The --help, -h, or /? is supposed to print a summary of commands to Console.Out and then exit.

It ran The Curse of Possum Hollow on the first try. NES 2.0 ✓

Time for Zap Ruder. "Light Detection Radius": That's fun

240p Test Suite time. Looking at the circles in "Linearity", I see that the PAR isn't set by default (unlike, say, NO$SNS). In Video > General, I see how to set the PAR, and now they're rounded.

For the application folder, would /home/.mesen be appropriate? Or is it common to use the .config folder and multiple applications do so?

I agree Mesen is not ideal on Linux due to its dependency on Mono. I'd have to take a look at what specific packages from mono it requires - off the top of my head, the runtime + winforms + compression (which you listed) should be the main ones, but it is possible that something else is needed as well. The readme asks for mono-complete because that is the simplest/shortest way to list the requirements.

Not being able to copy the message box is probably a Mono bug - as far as I know, message boxes in WinForms rely on the Win32 API, which always supports Ctrl-C as a way to copy the text?That message box should have showed the actual error, though (most other popups that are the result of an exception do display the exception's details) - that's my bad, I'll fix it.

Good point about --help - I can see if I can fix it, but I vaguely recall trying to implement that and failing because getting a .exe marked as a non-console application to display anything in the command line on Windows is actually hard or impossible (if I am remembering this right). And marking the executable as a console application has its own downsides as well.

Bisqwit's NTSC filter is very slow in comparison to the "NTSC" filter (which is blargg's) - on a dual core processor, this might actually be even worse due to the filter's code attempting to render the picture using 2 different threads + a 3rd thread running the actual emulation.

Mono probably forces Microsoft Sans Serif because that's the default WinForms font, and a lot of programs would likely render incorrectly if the font's size changed from what they expected (e.g if the software is using hardcoded sizes in pixels for layout, etc.) - at least, that's what I would guess.

It's nice to know the precompiled .exe file actually runs on Debian, though! I don't think I had managed to make it run on Debian in my own tests (iirc, only Ubuntu, which I use to compile, and Fedora Core worked for me - but I am far from being a Linux expert).

Putting feature requests on GitHub is fine - that's what it's for, and the best way to ensure I don't forget about it :p

For the application folder, would /home/.mesen be appropriate? Or is it common to use the .config folder and multiple applications do so?

The modern "official"(????) way to to consult the XDG_CONFIG_HOME environment variable (or $HOME/.config, or getpwuid(getuid))/.config), and use a directory under that. Other parts may instead belong .local/share (XDG_DATA_HOME), .cache (XDG_CACHE_HOME)

But ... there are still dozens of brand-new-programs that use the old convention of a single dotdir in your homedir, so don't sweat the complexity-for-the-sake-of-complexity that the FreeDesktop group seem to be overly fond of.

Quote:

Good point about --help - I can see if I can fix it, but I vaguely recall trying to implement that and failing because getting a .exe marked as a non-console application to display anything in the command line on Windows is actually hard or impossible (if I am remembering this right). And marking the executable as a console application has its own downsides as well.

Certainly the windows solution to that problem was to make an alert box containing the help text. Not the worst option...

Something that saves settings into the home folder by default, has no startup wizard, has no updater, no google drive integration, no built in database (so the GoogleDrive folder, MesenUpdater.exe & MesenDB.txt are not created/recreated or even included).

Certainly the windows solution to that problem was to make an alert box containing the help text. Not the worst option...

Some tools definitely do this, Mesen at this point probably has too many command line options for them to fit though. I guess I could just list the main ones, and indicate where the user can find the rest of them in the UI.

B00daW wrote:

Has anyone suggested implementing Kazzo and CopyNES dumping integration into the Mesen debugger?

Nope - but since I do not own either device, that would probably be pretty hard to implement :\

Rahsennor wrote:

181 MB for a NES emulator is just silly.

And I could argue that worrying about 0.06$ worth of SSD disk space (or < 0.01$ worth of HDD space) is also equally as silly :)Either way, it is what it is - the dependency on .NET/Mono is also very much the reason why there is a complete set of debugging tools in the first place. WinForms & its designer in VS trumps any other UI toolkit that I am aware of in terms development speed & simplicity - without it, making the debugger would have probably taken hundreds of hours more of my time, and I quite honestly would not have bothered making one at all.

maseter wrote:

Sour: Have you considered a dedicated portable build?

Most of this would not necessarily be very hard to implement, but it would require a fair amount of compile-time conditions - is there any reason why you would need this? Other than for the sake of it being old school, that is :p

No reason really, except that many people prefer portable stuff playable from flashdrives. [...]puNES (for example) turns portable, if you rename the .exe to puNES_p.exe!

This is exactly what the initial config dialog is there for. e.g if you put Mesen on a USB drive, run it and select "keep data in the same folder as Mesen", it will be portable. Previous versions before 0.9.2 used the same _P.exe shortcut as puNES, but it seemed like the vast majority of people thought that was too hard to find and not a very user-friendly way of handling it.

I'm not sure I see a benefit in making it recognize disksys.rom? The UI will ask for the BIOS a single time and create a copy of the file with the name it expects - you can technically give it a file with any name you want (what Mesen ends up doing with that file, e.g creating a copy called FdsBios.bin in its data folder, shouldn't really be the user's concern?)

What do you mean by "software"? All of the video filters are software filters - "None" just means no filter is applied at all (the PPU's output is converted to RGB and sent to the video card as-is)

Who is online

Users browsing this forum: No registered users and 9 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum