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

Ah, I see what you meant now - thought you were talking about the function list. For code in ram, Mesen keeps a cache of what instructions were run, and then invalidates that cache on subsequent writes to RAM, which would result in this if you're constantly altering only portions of it (i.e replacing NOPs with RTS and the like). And unrelated, but I think the green background maybe actually be a bug in this case, will have to check that.

PPU/CPU memory map:They are not perfectly accurate (i.e the "work ram" segment is hardcoded) and some mappers (which require "lower-level" functionalities in the code) do not play nice with it (MMC5 and N163 are good examples of this). Most common mappers (and the vast majority of supported mappers) do not use these though, and should display accurate info for the 0x8000-0xFFFF CPU banks and the entire PPU memory.

7zip crash: Thanks, this is fixed (I just learned the hard way that wchar_t is not 2-bytes in Linux!)

Loading from command line: This is already supported - it's how the file associations options work. ("make run" is just an easy way to run it)e.g from the bin/x64/Release folder:./Mesen.exe ~/Desktop/DriarNROM\(UE\)2.7z mono Mesen.exe ~/Desktop/DriarNROM\(UE\)2.7z

Both correctly load up Mesen w/ the ROM.

Edit: About fontconfig - I kinda feel like shipping a small default font (e.g DSM like is the case at the moment) might be a better option? It helps ensure that the controls display as I'd expect (they are all custom drawn controls) so it may reduce bugs. Arguably I could also allow the user to select a font, but that seems like going a bit too far on customizations (and again, adds the possibility of some fonts not working as expected, etc.)

Edit #2: About 32-bit support - do people actually still run Linux on 32-bits environments? At the moment Mesen ships with both 32-bit & 64-bit DLLs bundled for the Windows version since a lot of people still have 32-bit OSes (no thanks to Windows 10 still shipping with a 32-bit version - despite likely not supporting any 32-bit-only processors). I could do the same for Linux, but I was hoping x64 might be good enough for just about everybody.

Loading from command line: This is already supported - it's how the file associations options work. ("make run" is just an easy way to run it)e.g from the bin/x64/Release folder:./Mesen.exe ~/Desktop/DriarNROM\(UE\)2.7z mono Mesen.exe ~/Desktop/DriarNROM\(UE\)2.7z

Both correctly load up Mesen w/ the ROM.

... Ah-hah. It requires an absolute path, relative paths won't work.

Sour wrote:

For code in ram, Mesen keeps a cache of what instructions were run, and then invalidates that cache on subsequent writes to RAM, which would result in this if you're constantly altering only portions of it

It's been so long I'd forgotten, but the only thing I'm doing is changing the argument in LDA #imm. And alternating between whether the very first instruction in the unrolled loop (at $04E0) is LDA #imm or RTS ... no moving the RTS around.

Ah, nice catch. Actually, it does support relative paths, but since Mesen changes the working folder to ~/Mesen at startup, they're paths relative to that location (not very useful). It shouldn't be too hard to fix though.

Like lidnariq said, you'll need gcc 5.3+ (not sure about clang's version, but 3.8 works fine for me)It actually also uses some features planned for C++17 (filesystem api) - I go for standard & cross-platform APIs whenever possible, since this reduces the odds of platform-specific bugs (at the cost of not working on older compilers)

Who is online

Users browsing this forum: No registered users and 3 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