nesdev.com

No worries, it's by fixing the nitpicky stuff that you get a polished UI :p I don't actually use the debugging tools all that much myself (other than the times I'm trying to figure out why a particular rom doesn't work properly in Mesen, that is), so it's very helpful to have the opinion of people who actually use it for rom hacks or homebrew dev and the like.

2- I'll try to come up with something for this. At the moment, pondering the idea of adding an icon on the right-hand side of the current code row that could be used to open the memory tools at that location (and potentially other things?). I'd only show the icon for the row below the mouse cursor or such. Not quite sure just yet.

3- I'll keep it like it is for now then, and see if other people ask for the same thing or not.

4- That's mostly due to the fact that I try to make each tool fit in 1024x768 res, maximum. Which leaves about 700ish pixels when you factor in the taskbar. So all that blank space can't actually have anything that's permanently there, otherwise the UI would break on smaller screens. I just added a "Use Vertical Layout" option, though. This will move the label/function lists from the right side to the empty spot, which removes any empty space and makes better use of the available space at larger resolutions.

5- I added a warning/confirmation when changing the font for any tool that warns if the font doesn't appear to be a monospace font.

6- All debugger tools should now remember their last position, and I also made the hex editor remember the memory type setting. Like you said, though, this will conflict with the F1 shortcut, but there isn't too much I can do about that.
In general, all settings should be remembered. If you find anything that doesn't get saved, let me know, it's probably a bug.

Here's a build with the changes: download
Let me know what you think.

Sour, it seems that after creating something like way more than 5 trace log files, Mesen starts creating trace log files with "Additional information (IRQ, NMI, etc.)" disabled, even if it is checked. The only solution I've found to correct this is to close and reopen Mesen.

"Additional information..." is important for me because it provides a nice seperation between frames. (I'm using a condition pc != $c2ad && pc != $c2af to skip all of the frame filler at the end of each frame. So helpful! )

Is this fixable? It has happened like four different times.


p.s. Sorry, but I feel this is important. My Override is:

My Windows Notepad uses the Courier New font and after searching through Windows Character Map the * character is actually Unicode character U+08EF: Undefined in Courier New, but wasn't sure how to print that character here using this tablet. That character is important to me because it is a tiny mark that appears underneath the first character of the PC and that lower mark straightens each line (the ` messed up each line, for me, before adding U+08EF). Note: there's a name for characters that appear below or above other characters, but I don't remember the name combining mark

edit.
final edit.

Thanks for the report! I was only able to reproduce this once, but I'm pretty sure I've fixed it.
You can grab the latest automatic dev build with the fix from appveyor here: https://ci.appveyor.com/project/Sour/me ... /artifacts

Let me know if you still get the bug with this build.

Thanks Sour! I will try using it today and report back with my experience. After downloading it and opening the .exe AVG scanned and reported that I "have discovered a very rare file" and they took it to their offices to run a detailed virus scan. They said it would be around 79 minutes before they could converse futher. I'm sure your file is virus clean, but thought you would enjoy reading their message about your excellent program.

AVG Virus Lab just sent so I'm going to start using it now, but my feedback will probably be tomorrow. : )

Anti-virus software these days are a bit paranoid - executables that aren't signed or haven't been seen/scanned by other computers using the same AV software will often end up being flagged as potentially dangerous (even though the AV actually can't find anything dangerous with the file itself).

Obviously in this case, any Appveyor build will likely end up being flagged. To be honest, I'm surprised the other builds I sent you before didn't get the same treatment.

I feel helpless in my attempts to prevent the newest Mesen from talking about a file for recording movies on startup. I don't want it to create movie files; is this something new?

Your description is a bit vague, so hard to say for sure. The only thing I can think of right now is.. are you pressing the Pause/Break key on your keyboard? If so, you might be triggering the internal "test recording" mode I have for my own use (which appears to be active in the appveyor builds, by mistake - it's usually disabled in any build I release manually)

Yes, just figured out if I use the Esc key pausing works normally! Hope the "test recording" mode goes away sometime because I enjoy using the pause key for pausing the game. Maybe you could make it to disable "test recording" if the pause key is bound in your shortcut keys binding section?

edit: Or, could you add your "test recording" mode to the short cut keys list and then we could unbind the pause button for that if we would like to? Thought maybe that suggestion would be easier on you and Mesen.

If you grab the latest Appveyor build, it should be fixed. The test recording mode is disabled on appveyor builds now (like it was meant to be in the first place)

Sour, so far your newest Mesen graciously allows me to use the pause key and hasn't ever disabled your "Additional information (IRQ, NMI, etc.)" checkbox!

Sorry for my late reply.

Note: I have noticed that your Format: Override code must always write the entire line on every line it affects because lines that don't use the [EffectiveAddress] [MemoryValue,h] have two spaces at their end. The first space must be always added after [Disassembly] and the second space is one I kept from your example. On lines ending with an EffectiveAddress only one space is left at the end. Fix if you want to; just notifying you.

Regarding my previous post, if you decide to fix that maybe you could create three seperate strings and then write the appropriate one. Just more thoughts from me, who is a newbie focusing on one machine, to you, who writes an extreemly excellent emulator that can be used on many different machines.

Is the issue just having extra whitespace at the end of the line? If so, it's not really that much of an issue, but I guess there's no harm in removing the whitespace at the right side of each line. If the tags are used in the middle of a line there isn't much I can do about it, though.

Yeah, it's not really an issue, I agree, but, I just wanted you to be aware of it. And, if those things are in the middle of a line, and you still want to fix this, it seems to me that it would be somewhat fixable if you just built seperate strings and then, for instance, used the string without the space following [Disassembly] for lines that only use [Disassembly] (implying they don't use [EffectiveAddress] [MemoryValue,h]). And you could add a space at the end of [EffectiveAddress], then that extra space we have following it could be removed and that wouldn't be a problem either. Though, then you would have to remove that added space in another string and print that string if the line doesn't have a [MemoryValue,h]. So you would need to have 3 seperate strings to choose from.

That may still be problematic for those who place Disassembly, EffectiveAddress, and MemoryValue in the middle of a line... but it sounds good to me thinking about it. Sorry, I can't test it.

To be honest, I'd rather not needlessly increase the complexity of the trace logger just to fix a couple of whitespace issues, though :p
I'll most likely add some code to trim the whitespace at the end of lines, just to avoid making the logs larger than they need to be, but beyond that, if you're using these in the middle of the line (like the default format), you will want to use [Align] to keep things aligned in a readable manner, anyway, so it shouldn't really matter much at all.