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.

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! )

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 namecombining mark

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.

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.

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 :pI'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.

Who is online

Users browsing this forum: No registered users and 1 guest

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