I'll take a look at the new build.
Sour wrote:I guess there must be something with my FCEUX configuration that is causing it to be abnormally slow.
I have to apologize, I made a mistake before, I thought New PPU was on because I almost always have it there, but it got set to old at some point. Sorry! So, you can reduce the severity of the relative comparison a bit, but it's still true that Mesen is too slow when debugging on battery, for me.
With New PPU I get more like 650fps at full speed rather than 1300. When not fast forwarding, about 3% total CPU instead of 2.3%, vs. Mesen kinda jumping from 3-6% but maybe mostly a little over 4%.
When switching to battery mode, there's still enough overhead that I can debug in FCEUX with no slowdown unless I basically open all of its debug viewers at once and turn all their refresh frequencies up to full.
Sour wrote:Opening the debugger in Mesen does impact performance a lot - this is because it turns on a lot of stuff (trace logger, profiling, CDL logging, access counters, etc.). This is why you can open the trace logger and immediately see the execution's history (vs needing to start it beforehand in FCEUX, for example).
Hmm, if you've already got an automated rewind capability, is there really a need to be proactively keeping traces as well? Couldn't you regenerate them on demand from the rewind?
I know you're using the CDL to aid the disassembly, but in my view it's only a little bit helpful, usually very easy to spot "nonsense" data code. If it's consuming significant CPU, I'd definitely turn it off if t was an option. (When starting to use the debugger, showing unidentified data was probably the first option I went looking for and turned on.)
Maybe part of why it's not that much of a problem to me in FCEUX is I can easily control the starting line of the disassembly view. If I see garbage at the top, I just move it up or down a line to find the alignment of the code. Your disassembly I see no easy way to move it one line. Mouse wheel only goes by 3 line increments. (And the desire here is 1-byte increments.) A clickable arrow at the top or bottom of the scroller might help.
Sour wrote:I might also be able to move the processing for some of these to another thread...
If that's possible, it might help making it more usable on battery for me, but it depends whether the stuff that really requires single threading isn't already using the whole core though. (Like I was seeing ~17% in the CPU usage, which I interpret as one maxed thread (12.5%), and another ~40% of another thread on a second core? I think there's a far ways to go before that maxed thread would have any overhead.)
Sour wrote:To go to the PC, you can double-click the top of the callstack or use "Show Next Statement" (Alt+*).
Thanks. The call stack is particularly cool. Since getting to it seems like the same function to me as what "go to" does, I didn't expect to find it in a different menu. I think it would still be worth having as another option in the go to list.
I notice Escape will now unpause the debugger, at least if used from the game window. That's an improvement, though I would much rather if the same key for pause and unpause worked in the debugger window too, similar to how I think having run as F5 be the same as load state as F5 is just asking for mistakes. It is NOT easy to tell which window currently has focus, especially since keys pressed in one often affect the other.
(Also, I am finding myself leaving FPS indicator on just so that I can have a pause indicator that doesn't darken and obscure the whole screen.)
Sour wrote:The code window (and a lot of other things) all use GDI+ (this is what most .NET drawing routines use), maybe GDI+ doesn't respect Windows' own anti-aliasing settings?
Well, the code window looks to me like it's specially rendered, and not using native text stuff. I assume the other uses are the overlay on the game window, where it's totally innocuous to me, but when staring at a big block of disassembly it really sticks out like a sore thumb. With a well hinted font and no anti-aliasing, I'm used to being able to make the text smaller and still have very good legibility, so maybe I'm just a bit fussy about fonts like that. :S
If I could make it smaller and not anti-aliased, I could fit more text in the window and feel more comfortable reading it. As it is, it's OK in the default size, but I can't really make it smaller (mainly because it has 2 sizes of text in it, and the smaller one gets blurry really quick). Like if I could choose the font and specify its size numerically, that would be many times more useful than the increase/decrease size interface where I don't even know a precise number for the size.
Sour wrote:PRG ROM display: I'm not sure what to suggest here - a bank number is vague in a lot of situations. Do you need this information to always be visible? Or would it being shown in a tooltip be sufficient? (e.g on mouse-over on the cpu address?)
The main problem is that the option is either add an extra half-line of small text (reduces amount of code I can see in the window, and hard to read) or replace the CPU address entirely (losing acces to the CPU address). What I was suggesting is that even having it on the left in-line with the CPU address at the same size would be better than either of those options.
Actually, since the CPU and PRG addresses are never going to differ in the bottom 3 nybbles you could even omit those... but a hover tooltip would also do the job. The main meed is just having easy access to the the PRG address, wthout having to give up 50% of the vertical for it, or have to go into the menu and toggle options every time i want to see it.
I am noticing now you have a nice bank display along the bottom, though! That's really good. That's a pretty decent way to see what bank I'm currently in.
Sour wrote:Customizing the default labels: That might be nice, though it might be a pain to edit them in the UI. Maybe allow a simple XML file to be put in Mesen's debugger folder to configure the default workspace on a per-mapper basis?
Well, for me editing them in a text editor would be perfectly good.
Sour wrote:Labels can't start with $ because it would just be confusing when trying to parse what's under the mouse. Ideally, would need to allow the label to be blank (this is possible to define comments in the code) and allow the comment to show in the tooltip for an address that has a comment (it doesn't at the moment).
Well, the blue highlight is nice, since it gives a visual indication that it's a known label and might have a hover tip. If I can't call it $2000 I'd probably just work around with like _2000 or something, not a big deal.
Anyhow, disabling them is the best option for me right now, and if I want custom names I can make them for a specific project, but I really like the tooltip documentation they provide; it's just that the names get in the way for me.
Sour wrote:What CPU does your laptop have? It would at least let me compare with the ~2012 laptop I have.
Intel Core i7-4700MQ @ 2.40 GHz (4 core / 8 thread)