It is currently Tue Dec 12, 2017 8:48 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 23 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Mesen - Linux (preview)
PostPosted: Sat Dec 17, 2016 10:04 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 301
I just finished making a build Mesen that runs under Linux and I was wondering if some people would be willing to test it on their end to see if it works (or crashes!).
It runs under Mono (only tested Mono 4.2.1 - I assume any recent version will work) and requires SDL2 to be installed.

Building requires clang or gcc, Mono/XBuild and SDL2. It comes with a very basic makefile - just run "make" and then "make run" to start the emulator.
There's also a prebuilt binary here: [linux preview download] (This was built on Ubuntu 16.04 - if you get a popup asking to download the microsoft C++ runtime, you are missing some dependencies)

The main issues remaining at the moment are:
-Gamepads aren't supported (yet)
-Automatic updates won't work
-Netplay doesn't automatically add port forwarding rules to the router (UPnP)
-Fullscreen mode doesn't hide the taskbar

Beyond that, everything else should work (including debugging, netplay (works cross-platform!), NSF player, etc.)
The code itself is almost identical between the Windows & Linux versions - the only portions that differ being the Video/Audio/Input handling (DirectX vs SDL), so most things should be ok.
There is a bunch of features I haven't had the time to test, so I definitely expect some things to be broken beyond what I just listed, though.

Also, for some reason, performance seems to be worse than the Windows build (e.g ~30% slower).
But I've only tested on a VM, so that may be part of the reason.

If you encounter any issue or crash with the Linux version, please let me know in this thread.


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 12:28 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6512
Location: Seattle
Building from source was super easy, with two small sticking points: for some reason std::sqrt needs #include <cmath> ... and the makefile accidentally uses clang instead of $(CC) to build SevenZip/obj/%.o


Debugger is quite nice, but again two small sticking points, both pertaining to fonts. One: the disassembly and memory viewer both seem to be using some random proportional font instead of a monospaced one, and two: the memory viewer is doing something very odd:
Attachment:
cpumemory.png
cpumemory.png [ 36.76 KiB | Viewed 1607 times ]


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 7:25 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 301
Thanks, I fixed the makefile & missing header in xBRZ's code.

Both of the debugger issues you mentionned are actually the same - it's because the display needs to use a monospaced font to work properly.
At the moment it's hardcoded to use "Ubuntu Mono" in BaseControl.cs since that's what I had available on the VM - if you change it to a font you have, it should work as expected.
Are there any "standard" monospaced fonts that I can reasonably expect all (or at least most) linux distros to have?


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 8:08 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19335
Location: NE Indiana, USA (NTSC)
Sour wrote:
Are there any "standard" monospaced fonts that I can reasonably expect all (or at least most) linux distros to have?

I guess you could query fontconfig for the user's preferred monospace font. If all else fails, you could find a free font, like good old DSM, and bundle it. If that's too big, you could bundle a bitmap font.

I plan to try Mesen after I've upgraded my laptop to Xubuntu 16.04 "Xenial". It currently runs 14.04 "Trusty" because that was the newest when I began my last major paid project, and I didn't want to do a major upgrade right in the middle.


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 10:52 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 301
Thanks for the suggestion - I bundled DroidSansMono (it's pretty small) and automatically install it to ~/.fonts on startup, seems to work pretty well.
Also reduced the default font size for the debugger because DSM looked ridiculously big.

I'm not sure how hard it would be to build on Ubuntu 14, probably just depends on the compiler you have installed.
The code uses the C++17 filesystem api, which apparently is only available in GCC 5.3+ (Dec 2015).


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 11:18 am 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 941
Use the font "fixed" which should be included on all X window systems.

_________________
.


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 11:19 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6512
Location: Seattle
AIUI, the fonts infrastructure on any even remotely modern linux uses FontConfig, and that's by default configured to treat the special name "monospace" to mean 'some random installed monospaced font'


"fixed" will only DTRT if FontConfig is configured to use bitmap fonts, which it isn't by default.


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 1:09 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6512
Location: Seattle
Ok, another minor bug, having to do with partial screen redraws. The memory map visualization at the bottom of the debugger can give me some awfully weird results if I drag another window over it:
Attachment:
memory-map-weirdness.png
memory-map-weirdness.png [ 33.32 KiB | Viewed 1519 times ]



Oh, and, for hilarity's sake, the automatic subroutine finder gets awfully confused by the code that (my) NROM build of Driar puts into RAM.

edit: Another: if I go into the Audio configuration, change anything, quit, and restart, then audio doesn't work. For some reason, having any non-empty value in <AudioDevice> in the configuration file causes sound to stop working.


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 6:46 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 301
Thanks for testing! I'll try and fix these tomorrow.

For the audio issue, what does the "Device" dropdown contain in the audio config window?
I'm thinking it might have multiple devices with the same name and it doesn't pick the right one after you change any other setting.

A bit unrelated, but how is the audio latency? On my VM it's pretty terrible (e.g 300-400ms real latency with the latency set to 50ms), but I think that might just be due to the VM itself as I don't really see any reason why it would be so high based on the code.

Also, I just finished adding gamepad support if you feel like giving it a try.


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 7:41 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6512
Location: Seattle
Sour wrote:
For the audio issue, what does the "Device" dropdown contain in the audio config window?
"HDA Intel PCH, ALC1150 Analog" or the same but ending in "Digital"
Either choice causes no audio on the analog output.

Quote:
how is the audio latency?
31ms scheduled latency → ≈100ms real-world A-V latency but 15ms scheduled latency → ≈60ms real-world A-V latency??

Quote:
Also, I just finished adding gamepad support if you feel like giving it a try.
Only thing I have is a USB Gravis GamePad Pro, and it didn't work


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 8:18 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 301
lidnariq wrote:
"HDA Intel PCH, ALC1150 Analog" or the same but ending in "Digital"
Either choice causes no audio on the analog output.
Odd - it could potentially be a SDL bug (although it's more likely to be my own code's fault). I committed a patch/safety net that will ignore the device name if audio init fails because of it (and log a line in the "message log" with the string it tried to use to initialized the audio system - if it doesn't match the dropdown's content, that's probably what's causing the bug in the first place) - so at the very least you should be able to alter the audio config normally now.

Quote:
31ms scheduled latency → ≈100ms real-world A-V latency but 15ms scheduled latency → ≈60ms real-world A-V latency??
Not quite sure what's going on here :) I would have expected ~85ms, not 60ms. Either way, this is much better than what I am getting.

Quote:
Only thing I have is a USB Gravis GamePad Pro, and it didn't work
That sounds pretty old. Maybe it's not supported by the newer /dev/eventX api and only works via /dev/joyX?


Top
 Profile  
 
PostPosted: Sun Dec 18, 2016 8:53 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6512
Location: Seattle
Sour wrote:
I committed a patch/safety net that will ignore the device name if audio init fails because of it (and log a line in the "message log" with the string it tried to use to initialized the audio system - if it doesn't match the dropdown's content, that's probably what's causing the bug in the first place) - so at the very least you should be able to alter the audio config normally now.
Yup, that works, and yup, the error you'd expect to find shows up in the log ([Audio] Failed opening audio device 'HDA Intel PCH, ALC1150 Analog', will retry with default device.)

Quote:
[a USB Gravis GamePad Pro] sounds pretty old. Maybe it's not supported by the newer /dev/eventX api and only works via /dev/joyX?
No, I can read it both via /dev/input/js0 and /dev/input/event14

And if i install libevemu-tools and try running evemu-describe it certainly seems to find it.


Top
 Profile  
 
PostPosted: Mon Dec 19, 2016 3:31 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 301
lidnariq wrote:
And if i install libevemu-tools and try running evemu-describe it certainly seems to find it.
Could you send me the full output for that device when you use evemu-describe and enter the device's number?
e.g:
# EVEMU 1.2
# Input device name: "Microsoft X-Box 360 pad"
# Input device ID: bus 0x03 vendor 0x45e product 0x28e version 0x114
# Supported events:
# Event type 0 (EV_SYN)
# Event code 0 (SYN_REPORT)
# Event code 1 (SYN_CONFIG)
[...]

The supported events/codes, etc. should help me figure out why it's not working with the code I have.


Top
 Profile  
 
PostPosted: Mon Dec 19, 2016 6:21 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 301
lidnariq wrote:
Ok, another minor bug, having to do with partial screen redraws.
This should be fixed - I couldn't reproduce it on my end in Linux, but actually had some refresh issues visible in Windows under some circumstances, so I fixed those.

lidnariq wrote:
Oh, and, for hilarity's sake, the automatic subroutine finder gets awfully confused by the code that (my) NROM build of Driar puts into RAM.
I took a look and I can't see anything wrong - the function list can only detect functions from PRG ROM (since anything else could be erased at any time). As far as I can tell, it's working as I'd expect. What issue did you have with it?


Unrelated, but I also fixed the code window's mouse over tooltip in the debugger (the tooltip when you mouse over labels/addresses didn't show up correctly on my end - it was too small to fit the content)


Top
 Profile  
 
PostPosted: Mon Dec 19, 2016 7:01 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6512
Location: Seattle
This is what I see (on the left) with Driar—the code keeps moving the RTS around in RAM, so I assume that's why we end up with this fragmented thing:
Attachment:
unroller-blocks.png
unroller-blocks.png [ 2.76 KiB | Viewed 1349 times ]


Redraw issues are fixed.

Other things:
- The nametable portion of the PPU memory map seems to be a misleading with things that use ROM nametables?
(I was testing with my silly N163 demo here as well as After Burner)
- Trying to load a 7z file from the GoodMerged GoodNES distribution elicits some complicated crash
- (wishlist) please let me start Mesen with a path to a NES ROM as the first argument?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 23 posts ]  Go to page 1, 2  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Gilbert, Yahoo [Bot] and 4 guests


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

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group