It is currently Wed Oct 17, 2018 8:24 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 580 posts ]  Go to page Previous  1 ... 29, 30, 31, 32, 33, 34, 35 ... 39  Next
Author Message
 Post subject: Re: Mesen - NES Emulator
PostPosted: Fri Jul 27, 2018 8:25 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6887
Location: Canada
Sour wrote:
Do you have the RAM init option set to random values? (that's the only way I found to reproduce this) If so, that's most likely why - it picks up the random nametable/palette data on the first frames and uses that as the last known palette for any tile that didn't get used after that. I'll add a check to make it ignore frames where rendering is disabled.

Yes, I do have random RAM. That makes sense. Ignoring while disabled should help, thanks.

Sour wrote:
Ideally if a tile's final output (e.g as seen on screen) is a single solid color, it should output it using a grayscale palette instead. That should work for your scenario too, I think? At the very least, it will make it impossible for a non-empty tile to ever show up as a single color in the viewer.

Yeah, I think that would work.

Though TBH maybe this request is overcomplicating it. Greyscale is probably better for debugging in general, and very useful as-is. Maybe there are times where it's worth knowing that a tile really was all-black last time it was rendered too... so I dunno.

Ignoring while rendering off is good, though, since it seems trigger bad recolorations very often during fadeouts in various games.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Sat Jul 28, 2018 12:49 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 524
This build should fix most of the issues: https://www.mesen.ca/MesenJul28.zip

-Added an option to reset all workspace labels to their default when importing DBG/MLB files (in Workspace->Import Settings, enabled by default)
-The "last known palette" data now ignores bg/sprites palette data if bg/sprites are disabled (fixes the random ram init issues as far as I can tell)
-The color picker in the chr viewer now displays the palette index values instead of 0 to 3.
-There's a new option in the CHR viewer to display single-color tiles in grayscale (and I reverted the change I had done to the last known palette display logic)
-Fixed a couple of minor issues when using 8x16 display mode in the chr viewer

Let me know if you find anything else!


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Sat Jul 28, 2018 1:17 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6887
Location: Canada
Ah, trying this out and it actually seems to work really well! "Single colour tile" seems like a weird condition, but it does look like it's a practical one.

Interesting test case 1: in the second level of Sunday Funday you can switch the lights on and off. Pretty neat to watch the tiles go grey when the lights switch off.

Interesting test case 2: in my own game Lizard (or its demo) there's a fade between screens, which will fade the current screen's tiles to black (or now grey), sort of like marking them as inactive, lets me see what's being used in the current scene. :)

Am I correct in seeing that it picks up tile usage colours for the whole nametable space, and not just the onscreen rectangle? It seems to pick up colours for things in the background layer before they come into view. Originally I had assumed it was only doing it for tiles that are used during rendering. (Not sure if either way would be better or worse, just noting the difference.)

Unlike the other CHR viewer options, default palette setting isn't a saved option, always resets to 0 when I restart the program.


I suppose one other thing, since I've been trying a bunch of test versions, it might be good to have a build date in the About menu just so I could have a way of figuring out which build I'm on.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Sun Jul 29, 2018 9:26 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 524
Yea, "Single color tile" isn't exactly clear, but I couldn't really find any better way to describe it.

Your guess is correct - it does use all of the nametable data, rather than what was used during rendering. This is mostly due to not wanting the feature to have too much impact on performance while the debugger is opened (it's a lot easier/faster to check the ~2000 tiles in nametable+sprite ram at the end of the frame, vs adding logic to every single pixel drawn). It does have its downsides though, especially if palette or CHR banks are switched mid frame (in which case the results are wrong for the top half of the split)

I've fixed the palette/highlight type (only for CHR ROM games) dropdowns so that their selection is saved.

The appveyor builds do have a custom build number on each build for this, but they're not optimized with PGO so they are a fair bit (~20-30%) slower than the builds I compile. Still though, having the build date in general is not a bad idea, regardless of whether it's a dev build or an official release, so I've added it to the about window.

There's also a new overlay on the event viewer to show the x,y position (in terms of scanline/cycle) of the mouse cursor (and be able to easily check which events are on the same scanline, etc.). There's no option to disable it at the moment since I don't think there's a need for one, but if you think it gets in the way, let me know and I'll make it optional.

Build: https://www.mesen.ca/MesenJul29.zip


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 01, 2018 5:21 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
I'm attempting to use conditional breakpoints.

I've got a label called "b0" which means "byte zero" and is assigned to $00.

If I put [$b0] in a watchpoint, I can see its value as $0f at this particular point in my program.

If I put [$00] in a watchpoint, I would expect to see the same but I see $00.

For a conditional breakpoint I have tried:

[$00]==15
[b0]==15
$00==15
b0==15

And while I can see b0 take on the value $0f in a watchpoint, the breakpoint never triggers. Not sure what I might be doing wrong? The documentation did seem to be pretty clear about using [ ] to access memory, and the debugger does appear to be seeing my label in the watchpoints but not the breakpoint condition.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 01, 2018 5:40 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6887
Location: Canada
GradualGames wrote:
And while I can see b0 take on the value $0f in a watchpoint, the breakpoint never triggers. Not sure what I might be doing wrong? The documentation did seem to be pretty clear about using [ ] to access memory, and the debugger does appear to be seeing my label in the watchpoints but not the breakpoint condition.

I suspect what you want is a write breakpoint on $00B0 with a condition of Value == $0F.

If you're using an execution breakpoint, the condition will be tested before the instruction executes, so if you're trying to catch the instruction that writes $0F to $00B0, I think the [$B0]==15 condition will only catch an instruction that writes to it once it's already $0F. The Value condition is "value about to be written" for write instructions, or read for read instructions, which is pretty handy in cases like this.

Similarly, you didn't mention, but if it's an execution breakpoint it does need an address range to be active, probably $8000-FFFF. In this case you're looking for a write, not an execution, I think, but that can be an issue as well.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 01, 2018 5:46 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
rainwarrior wrote:
GradualGames wrote:
And while I can see b0 take on the value $0f in a watchpoint, the breakpoint never triggers. Not sure what I might be doing wrong? The documentation did seem to be pretty clear about using [ ] to access memory, and the debugger does appear to be seeing my label in the watchpoints but not the breakpoint condition.

I suspect what you want is a write breakpoint on $00B0 with a condition of Value == $0F.

If you're using an execution breakpoint, the condition will be tested before the instruction executes, so if you're trying to catch the instruction that writes $0F to $00B0, I think the [$B0]==15 condition will only catch an instruction that writes to it once it's already $0F. The Value condition is "value about to be written" for write instructions, or read for read instructions, which is pretty handy in cases like this.

Similarly, you didn't mention, but if it's an execution breakpoint it does need an address range to be active, probably $8000-FFFF. In this case you're looking for a write, not an execution, I think, but that can be an issue as well.


My label is called b0, that isn't a hex number in that case it is actually the name of $00. I have b0,b1,b2, thru b19. Could the fact that b0 is also a hexadecimal number be confusing the debugger? I wonder... it didn't confuse the watchpoint!

I am using an execution breakpoint. b0 would already have been assigned the value, prior to this particular routine being called.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 01, 2018 6:05 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6887
Location: Canada
GradualGames wrote:
My label is called b0, that isn't a hex number in that case it is actually the name of $00. I have b0,b1,b2, thru b19. Could the fact that b0 is also a hexadecimal number be confusing the debugger? I wonder... it didn't confuse the watchpoint!

Hmm, I don't think this can be a problem for conditions, because a hex number without a $ prefix creates a syntax error. It does seem to correctly pick up known labels, for me.

GradualGames wrote:
I am using an execution breakpoint. b0 would already have been assigned the value, prior to this particular routine being called.

If you typed b0 as the address of a write breakpoint, it would have used $00B0. The address fields don't accept expressions, just hex numbers, AFAIK.

Does a write breakpoint work like expected if you put in the correct address of b0 though?


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 01, 2018 6:22 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6887
Location: Canada
Oh! Pardon me! I didn't quite understand what you were reporting, but I am noticing really strange behaviour with that too now that I'm looking at it a little more closely.

At first when I tried creating a b0 label and using it for a conditional execution breakpoint it seemed to work, but I'm getting inconsistent behaviour with it now that I'm trying it after power on.

This is what I'm doing do produce the problem. (Am trying it on tepples' 240pee.nes but it should work on any ROM that clears memory at startup I guess.)

1. create label b0 that points somewhere (I made it go to $35)
2. create execution breakpoint on $8000-FFFF with condition "[b0]==$00"
3. power cycle, and debug... breakpoint is never hit?
4. replace [b0] with its actual address [$35], then power cycle and debug... breakpoint is now hit!
5. replace [$35] with [b0] again, but don't power cycle... resuming in the debugger will keep hitting the breakpoint?

So I apologize, you're right, there is something fishy going on there. (It wasn't failing for me at first, but it is in some cases, like this one.)


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 01, 2018 6:33 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 524
GradualGames wrote:
If I put [$b0] in a watchpoint, I can see its value as $0f at this particular point in my program.
If I put [$00] in a watchpoint, I would expect to see the same but I see $00.
Are you sure about this bit? I can't reproduce this part of the problem - [b0] or [$00] always output the same (and correct) value as far as I can tell. (Also you wrote [$b0] instead of [b0], but I'm assuming that's just a typo)

And you just found a bug with conditional breakpoints when using labels in their conditions. It'll parse the condition properly, but internally there's an issue that's causing it to act as if the condition field was empty when evaluating the breakpoints. This is because expressions that use labels are not "cached" by the expression parser. This was done because some labels are dynamic in nature (e.g a label on a specific PRG ROM offset could potentially point to $8050 now, and then be out of scope due to bank switching), which is not something that the expression cache can handle (because it replaces the label with its current numeric value when converting the expression to reverse polish notation)

Getting this to work properly with PRG/CHR ROM labels might be somewhat tricky (especially in terms of performance), but I'll see what I can do. At the very least, I could fix it for CPU/PPU address labels easily (e.g like your b0 label) without any performance degradation, since those labels aren't dynamic.

There might be a bit more to this based on what rainwarrior just posted. On my end I only got the "breakpoint is always hit" behavior so far, but I didn't try the retro steps yet - I'll test that part too in case it ends up being a different bug.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Aug 01, 2018 6:57 pm 
Offline
User avatar

Joined: Sun Nov 09, 2008 9:18 pm
Posts: 1107
Location: Pennsylvania, USA
Sour wrote:
GradualGames wrote:
If I put [$b0] in a watchpoint, I can see its value as $0f at this particular point in my program.
If I put [$00] in a watchpoint, I would expect to see the same but I see $00.
Are you sure about this bit? I can't reproduce this part of the problem - [b0] or [$00] always output the same (and correct) value as far as I can tell. (Also you wrote [$b0] instead of [b0], but I'm assuming that's just a typo)

And you just found a bug with conditional breakpoints when using labels in their conditions. It'll parse the condition properly, but internally there's an issue that's causing it to act as if the condition field was empty when evaluating the breakpoints. This is because expressions that use labels are not "cached" by the expression parser. This was done because some labels are dynamic in nature (e.g a label on a specific PRG ROM offset could potentially point to $8050 now, and then be out of scope due to bank switching), which is not something that the expression cache can handle (because it replaces the label with its current numeric value when converting the expression to reverse polish notation)

Getting this to work properly with PRG/CHR ROM labels might be somewhat tricky (especially in terms of performance), but I'll see what I can do. At the very least, I could fix it for CPU/PPU address labels easily (e.g like your b0 label) without any performance degradation, since those labels aren't dynamic.

There might be a bit more to this based on what rainwarrior just posted. On my end I only got the "breakpoint is always hit" behavior so far, but I didn't try the retro steps yet - I'll test that part too in case it ends up being a different bug.

Oops, yeah I had a typo with $b0, I meant just b0 because it is a label in my program.

I moved on and was able to find a super gnarly bug in my game by other means of ruling things out and reasoning about my code like usual :D Glad I helped find a bug though!


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu Aug 02, 2018 7:45 am 
Offline
User avatar

Joined: Tue Jun 24, 2008 8:38 pm
Posts: 2004
Location: Fukuoka, Japan
I'm back home this week and I downloaded both sierra/high sierra to test your emulator but... It seems that high sierra disk utility with APFS partition is quite... well.. awful. I never had issues resizing that disk countless time but now I gets error and it just fail to make properly.

Once I figure out the cause, I will give you feedback on the subject. I'm starting to get more scared about the next macOS version.. They are getting bad to worse :lol:


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu Aug 02, 2018 2:43 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 936
Location: cypress, texas
Sour, I just upgraded to MesenDevWin-0.9.5.164 from .139 and the lines that appeared on the screen about a month ago have vanished! Guess that was fixed in your .159 update about 8 days ago. Thank you so much for continuing your improvements to your already spectacular emulator!! :mrgreen: :D It has been a huge blessing to me.

I feel bad for all of the people who don't know about your site on AppVeyor. Are you ever going to release Mesen version 0.9.6 so that many others can benefit from the 164+ fantastic changes you've made to it since March 31st, 2018? :)


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu Aug 02, 2018 7:23 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 524
Using any label in conditional breakpoints should now work properly (as of the latest appveyor build). There is a slight impact on performance when using labels vs hardcoded values in conditions, but considering it's unlikely you're using a large amount of conditional breakpoints at once, this shouldn't be too much of a concern.

@Banshaku
Let me know how it turns out - hopefully we can manage to get it running properly on your computer using the SDL windows build. If we manage to get that much working, it should hopefully not be too hard to fix wine's performance issues with the debugger.

@unregistered
I'm not too sure what you're referring to when you say "lines on the screen"? I don't recall seeing or fixing anything like it, at the very least..
As for 0.9.6, I was initially hoping to get it done over the weekend, but I might have to push it off a few days further still.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Fri Aug 03, 2018 1:33 pm 
Offline
User avatar

Joined: Thu Apr 23, 2009 11:21 pm
Posts: 936
Location: cypress, texas
""Lines on the screen" weren't actual visible extra sprites, but there was like a tic-tac-toe grid of "lines" (like 1 pixel width or height of some background tiles were drawn incorrectly and so it made a visible "line"). Thought it was because I rearranged some data, but the "lines" vanished after installing .164 and guessed that might be due to your scrolling fix in .159. Nevertheless, the "lines" have been eliminated!! :mrgreen: :D Thank you Sour!


edit: From what I remember, the "lines" didn't appear when testing with a powerpack on my NES.

edit2: And all of the text on the screen, from my lua scripts, appears crystal clear now too. You continue to do an excellent service for us. :D

final edit.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 580 posts ]  Go to page Previous  1 ... 29, 30, 31, 32, 33, 34, 35 ... 39  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: *Spitfire_NES* and 3 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