It is currently Wed Dec 12, 2018 5:17 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 600 posts ]  Go to page Previous  1 ... 28, 29, 30, 31, 32, 33, 34 ... 40  Next
Author Message
 Post subject: Re: Mesen - NES Emulator
PostPosted: Sat Jul 21, 2018 10:21 am 
Online

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 527
I'm pretty sure that's just a combination of the resampling + the fact that Mesen only supports up to 96kHz in its UI. A period of 0 should result in a ~112kHz sound, so it's very likely it wouldn't show up on a 96kHz recording.

Setting the sample rate to 384kHz by hacking up the code a bit gives me this: (Mesen at bottom)
Attachment:
mesen384000hz.png
mesen384000hz.png [ 11.32 KiB | Viewed 785 times ]

Mesen is correctly producing sounds all the way down to period 0, as far as I can tell (and your 96kHz hardware recording seems to be missing some portions, which makes sense).


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Sat Jul 21, 2018 7:54 pm 
Offline

Joined: Thu Aug 20, 2015 3:09 am
Posts: 424
This should go without saying, but NES audio (except the 163 and VRC7) is unipolar. All sounds, including ultrasonic, have a DC component. The triangle halts instead of being silenced to zero, but any other channel, when set to an ultrasonic period, will produce audible clicks on every volume change.

If that's what Mesen is doing, it's 100% correct.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Sat Jul 21, 2018 8:11 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7011
Location: Canada
Those aren't volume changes, the attenuation in steps is due only to a change in frequency vs. the filters that are in place.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Tue Jul 24, 2018 9:02 am 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7011
Location: Canada
One thing about Mesen's debugger:

When stepping through code, the scroll position of the disasembly jumps up and down erratically. This makes it very hard to follow the code, it will not adjust scroll for a few steps then suddenly jump, and I lose my place visually and mentally.

FCEUX and Nintendulator have a very simple approach to this: every step or breakpoint scrolls the current line to the top of the view. Centre of the view would be equally good (or maybe even better), just anything that's consistent.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Tue Jul 24, 2018 11:59 am 
Online

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 527
The logic used for the scroll position is pretty much identical to what visual studio does: if the next instruction isn't visible in the current view, scroll the view so that the line containing the instruction is in the center of it. Otherwise, don't scroll at all. This typically means that it won't scroll until you reach the bottom of the window, and then scroll back to the center of it (except when dealing with jumps/etc). I'm not completely certain whether this is what you're getting or not based on your description, though.

Either way, I could easily add an option to always scroll the current instruction to the middle of the viewport, if that works better for you?


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Tue Jul 24, 2018 12:37 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7011
Location: Canada
Well, from that described intent this is clearly a bug then:
https://www.dropbox.com/s/c9j2jrdbcyeh3g9/mesen_disassembly_stepping.gif?dl=0 (sorry, I can't seem to upload this as an attachment right now)

This happens to me very frequently. Sometimes it does stay in place like you were describing, but it's just as often like this.

One thing that also happens is any branch that goes off the current visible page basically will scroll to a "random" location. It's very hard to follow the execution when I have to look to a new place on the screen every time it branches. I'm not sure if that's related to this bug, or if that's somehow part of the intended scrolling solution.


To have it always scroll to a fixed location for every step/breakpoint reached would be a more ideal solution than a fixed version of this for me, though. It's very easy to follow visually that way.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Tue Jul 24, 2018 12:44 pm 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 518
Location: Central Illinois, USA
rainwarrior wrote:
Well, from that described intent this is clearly a bug then:
https://www.dropbox.com/s/c9j2jrdbcyeh3g9/mesen_disassembly_stepping.gif?dl=0 (sorry, I can't seem to upload this as an attachment right now)

This happens to me very frequently. Sometimes it does stay in place like you were describing, but it's just as often like this.


I've had this happen as well. Until now, I always assumed it was a fluke of mono on linux, and ignored it.

_________________
My games: http://www.bitethechili.com


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Tue Jul 24, 2018 12:57 pm 
Online

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 527
Yea, that's definitely a bug. It should either not scroll at all, or move the highlighted line to the center of the screen - anything else is incorrect. Since this particular section of code is writing to RAM, it's possible that this is somehow altering the way the ram section at the top of the window is displayed, which might offset the rest of the content (but this should only be possible in a limited number of scenarios).

Either way, I'll take a look and try to find a way to reproduce it on my end.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Tue Jul 24, 2018 1:12 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7011
Location: Canada
Might be worth mentioning that I am using a custom font, and also have the option to show unidentified code/data on as well, in case either of those might affect the ability to reproduce the problem. (I don't remember what the default font was, but after trying it the unidentified code option doesn't seem to affect it.)


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Jul 25, 2018 5:54 pm 
Online

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 527
The issue where the position jumps around when stepping through the code should be fixed (at least, I can no longer reproduce it on my end, on neither Windows nor Linux).

I also fixed some debugger-related memory leaks (in particular, there was a relatively bad one when the options to disassemble unidentified data and/or verified data were enabled) and improved the refresh performance for the code window by roughly 40-50% (e.g with the same settings 0.9.5 refreshes my test case about 12-13 times per second, whereas this build goes up to 18-20). Also, the split view mode now has almost no impact on performance (it drops performance by half in 0.9.5).

There's also a new option in the debugger's options menu: "Keep active statement in the center". This makes the code window behave like FCEUX/Nintendulator (except it keeps the active statement in the center, instead of at the top).

There's a fully-optimized windows-only build here: https://www.mesen.ca/MesenJul25.zip
@gauauu, you should be able to use this Appveyor Linux build

Let me know if you still get issues with this build (whether it's with the new option turned on or not).


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Jul 25, 2018 7:14 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7011
Location: Canada
This seems to work very well now. Thanks! (Both modes, centre-following and not, are good.)


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu Jul 26, 2018 4:57 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7011
Location: Canada
Thanks to the nice event viewer, I made a PAL version of my palette test ROM.

Some things I've noticed using it for this and other stuff recently:

1. When working on the ROM, it keeps getting new symbols from the .dbg file but the old ones are not replaced. As code moves around and I continue working I get big piles of duplicate labels in the wrong location. Is there a way to prevent this?

2. When using the event viewer, if I hit a breakpoint, only events since the start of the frame appear. Is it possible to see the previous frame's events here still?

3. Showing CHR tiles with their last known colour can be a bit confusing when their last known colour was all black during a fadeout. It's easy to turn off, but I thought I had a bug that was failing to load some of my font tiles, but it turned out they just had not yet been seen with a non-black colour yet. I don't know what to suggest exactly here... it's a great feature to see them in their current colour, just this consequence of it wasn't obvious to me at first. (I dunno... maybe an option to override with default greyscale if a palette doesn't have 4 distinct colours?)

4. Debugger keys (e.g. F5 to continue) don't work in the event viewer. Have to click back over there to resume, then click back to event viewer, etc.


BTW having scanline as a breakpoint condition is really wonderful. I also love that I can see CHR-RAM data updated byte by byte while stepping.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu Jul 26, 2018 7:18 pm 
Online

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 527
Thanks for the feedback!

1) This was a bug I wasn't aware of - any identical label should now overwrite any older label with the same name. This should work well in most cases, but ideally, I should probably also add an option to reset labels to their default state whenever a DBG file is loaded (e.g otherwise labels that used to exist but were erased from the code will stay in the list, etc.)

2) There's a new option to show the previous frame's events. Up to the current scanline/cycle, it will show the current frame's events, then it will show the previous frame's (e.g for everything below the yellow bar). This only has an impact when execution is stopped. Did you mean that you wanted to see all events from the previous frame, though? (plus the current frame's on top of them?) This would be feasible too, I think, but it would probably make the event viewer itself somewhat confusing to look at?

3) The last known palette option now automatically uses grayscale whenever all 4 colors in the last palette are identical. This isn't perfect, but should take care of most fade out related issues, I think?

4) I'm not too sure what I can do here - each debug window has its own set of shortcut keys (also the number of shortcuts is relatively small in a lot of them). The event viewer is the only one that doesn't have any shortcut keys, though. I might be able to enable the debugger window's shortcut keys on it (only if the debugger window itself is opened), but I'm not sure how simple that would be, I'll have to check.

RE: Breakpoint conditions - let me know if there's anything else that you think would be useful to have in the list of available values. It's only a couple of lines of code to export any additional APU/CPU/PPU state value.

Build with changes/fixes here: https://www.mesen.ca/MesenJul26.zip


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu Jul 26, 2018 8:26 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 7011
Location: Canada
Sour wrote:
1) This was a bug I wasn't aware of - any identical label should now overwrite any older label with the same name. This should work well in most cases, but ideally, I should probably also add an option to reset labels to their default state whenever a DBG file is loaded (e.g otherwise labels that used to exist but were erased from the code will stay in the list, etc.)

Hmm, I think in most cases where I would be using a DBG file, I'd want it to wipe the workspace's labels on every reload and just use what the DBG has. I guess the weird thing is using both of these features at the same time, the workspace and the DBG... actually maybe another idea would be an internal flag for labels that will keep track of whether they came from a DBG, and if they did it could be deleted on every DBG reload?

Sour wrote:
2) There's a new option to show the previous frame's events. Up to the current scanline/cycle, it will show the current frame's events, then it will show the previous frame's (e.g for everything below the yellow bar). This only has an impact when execution is stopped. Did you mean that you wanted to see all events from the previous frame, though? (plus the current frame's on top of them?) This would be feasible too, I think, but it would probably make the event viewer itself somewhat confusing to look at?

Ah, that's great, that's exactly what I wanted. I don't have a need to see two simultaneous frames, I just wanted to be able to see back one full frame from the current position.

Sour wrote:
3) The last known palette option now automatically uses grayscale whenever all 4 colors in the last palette are identical. This isn't perfect, but should take care of most fade out related issues, I think?

Well, the specific case I was trying to debug when I noticed it I was debugging a white on black font, which because it only uses 2 of 4 colours, it'd be invisible if e.g. only one of those colours wasn't the same. That was why my suggestion was if all four colours aren't different use greyscale. (Though to be honest, just turning this feature off and using always greyscale is pretty good anyway, so it's pretty usable without that.)

However, trying this out, I am seeing some really weird stuff:
Attachment:
strange_chr.png
strange_chr.png [ 141.8 KiB | Viewed 489 times ]

This is during a faded out frame of my game, but note how a lot of the font characters are full black (all 4 black), which was what it looked like when I thought my font loading code had a bug in it. (That's kinda why I asked about this... one of the characters being all black intuitively seems like my bug to me.) At the same time, half of these tiles are being displayed with weird random looking palettes that don't actually exist in my game.

(Maybe these tiles haven't been displayed at all yet, and the last used cache is just uninitialized data?)

If there is a default to prevent 4 blacks from being used, though, it isn't working for those missing tiles (those have 4 black palette entries in that screenshot). I didn't see a new option though...?

Another thought: in the tile info there is a palette shown but there is no way to query the NES palette index of these colours. I can hover for RGB, but I can't get like the NES hex code for it?


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Fri Jul 27, 2018 8:16 pm 
Online

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 527
Yea, I agree using a .DBG file would usually mean you're not editing/creating your own labels on top of it (and so resetting makes the most sense). Keeping a flag internally isn't a bad way of taking care of it, either. I'll see what's easiest to implement.

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.

I should probably rewrite the logic I added to check the actual tile rather than the palette indexes. As it is, if the palette uses 2 different black indexes, it'll still end up being shown as all black instead of grayscale. 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.

Good point about the color indexes in the tile info. At the moment it displays 0/1/2/3 because those are also shortcut keys to switch between them when drawing, but I'm not sure there's any real value to this (it's pretty obvious that the left one will be color 0, etc.). I should probably change this to display the indexes in the bottom right, like it does for all the other tabs?


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: smkzi and 4 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