It is currently Sun Apr 23, 2017 2:44 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 47 posts ]  Go to page 1, 2, 3, 4  Next
Author Message
PostPosted: Sat Dec 03, 2016 9:38 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 190
EDIT (March 2017): See page 3+ for a lot of recent additions to the debugger.

For the past couple of weeks I've been working on Mesen's debugger and added a fair amount of features.
I still have a few features I want to add (e.g editing memory values, displaying APU state, etc.), but I've implemented the vast majority of what I set out to do.
At this point, I think it combines most of the features of other NES debuggers, and probably adds a few features that aren't available in other debuggers.

I'm hoping to get some feedback from people that actually have a use for a debugger (which is why I'm posting this to NESdev instead of NESemdev)
e.g: Is is user-friendly? Are there features that are missing that you'd want/need? etc.

Here's a build containing the latest debug features: download (Still Windows-only, for now)

Screenshots of what it looks like:
Debugger Window: Screenshot #1 #2 #3
PPU Viewer: Screenshot #1 #2 #3
Memory Viewer: Screenshot #1 #2

And here's a mostly complete list of features: feature list

If you decide to give it a try, please let me know what you think! (And if you find anything that looks like a bug, please tell)
Thanks!

P.S: I know a lot of people here seem to be using Linux - at the moment there is no way to run Mesen on it, but I'm hoping to fix that in the next couple of months or so (hopefully.)


Last edited by Sour on Sat Mar 04, 2017 9:54 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Sat Dec 03, 2016 1:50 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 5557
Location: Seattle
Can't test (since linux and even with a VM I can't run ≥DX10), but one question: do the tooltips change according to the emulated machine?
e.g. does the tooltip for $2001 swap the red and green emphasis bits when emulating PAL/Dendy ?


Top
 Profile  
 
PostPosted: Sat Dec 03, 2016 8:35 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 190
Yea, I did the pretty silly choice of using DX11 when I started this a few years ago - probably would have made more sense to use DX9 instead.

The tooltips are based on user-defined labels, so they can be changed at any time. The one in the screenshot is part of the default labels that are automatically added to the debugger.
They're currently hardcoded as is, but I could definitely alter the defaults based on the region to give more accurate info when running in PAL/Dendy mode, etc.


Top
 Profile  
 
PostPosted: Sat Dec 03, 2016 9:14 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Feedback:

Debugger window looks great (warning: it's very hard to impress me with debuggers, I nitpick heavily). Things that caught my attention:

* Uppercase opcodes may annoy some people -- if what's on the left is actual source code (I have a feeling it is), then no problem
* Don't use instruction aliases/mneumonics like cpa (it's cmp) -- but again, if that's actual source code then no problem
* "Draw left Spr" should use the expanded word "Sprite" (it'll fit -- and if it doesn't, you have enough room to shift the other "column" of checkboxes over to the right)
* Be consistent with spelling. Ex: the word is either greyscale or grayscale (e vs. a) (the latter is more common in American English, the former everywhere else). I see "Grayscale" in the UI, while "greyscale" in the tooltips (and while there, just describe bit 0 as "Display type: (0: color, 1: greyscale)
* Column of checkboxes (Vertical Write, NMI on vBlank, etc.) need proper spacing (vertically/space between each one). It's not consistent. If it's difficult to do while keeping alignment with the fields on the left, then split the column into two "sections": Vertical Write, NMI on vBlank, and Large Sprites, followed by some empty space, followed by Grayscale, etc.
* Call stack is two words
* The call stack looks confusing to me. What is the address in parenthesis after the label? (ex: RenderLevel32Wide ($80CA))? It looks like it's the address of the label/function itself, but then there's the "CPU Addr" field that says something different? This could be me not understanding the tool (highly likely!), but I don't find this intuitive at first glance. Hence: take my view on this one with a grain of salt :-)
* Why do the CPU Addr fields start with an @ symbol?
* Why are the ROM Addr fields surrounded in [] brackets?
* It should be "ROM Addr" not "ROM Addr." (note the period)
* It should be "CPU Addr" not "Cpu Addr"
* Labels/checkboxes need to use consistent casing (there are probably other cases than "Cpu Addr" above)
* If this is purely for NES/Famicom/Dendy, then there is no decimal mode CPU flag. I'd suggest "Unused" as a description
* Needs display of RESET, NMI, and IRQ/BRK vectors

Nametable viewer tab needs a grid toggle/checkbox.

Memory viewer needs display of actual (potential) ASCII data on the far right. HOWEVER, before implementing this... well... it's complicated. I can talk at great length about this later on, and it relates to romhacking/translation (as it stands right now, no good debugger offers a feature that's highly sought after). For simplicity/default, you just want to display anything outside of the ASCII 0x20-0x7e range as a dot/period, otherwise show it. Hit me up in a forum post here when you want to tackle the bigger issue (trust me: it's a big undertaking).

Memory viewer needs way to view raw OBJ/OAM memory (not sure if it's in the pulldown). I know the Sprite Viewer tab can display this indirectly, but there are cases where people want to tinker with just OBJ/OAM.


Top
 Profile  
 
PostPosted: Sat Dec 03, 2016 9:36 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5032
Location: Canada
Gave it a bit of a test. Looks pretty good so far. Some thoughts/suggestions:


I like the sprite tool. Sprites don't seem to be drawn in its "Screen Preview" with the correct priority though. (Are they being drawn 0-63 instead of reverse order?)

The memory map with bank numbers is cool.

The palette tool takes up a lot of screen space despite only using a small portion of it.

Is there an option to disable the "default" labels for stuff in the debugger? I find them difficult to read vs just the regular numbers of registers.

The debugger has a lot of important keys that do different things if you are accidentally in the wrong window. E.g. F5 is resume vs stavestate, F11 is step vs fullscreen. The savestate conflict especially bugs me (savestates are very helpful when debugging), and you need to go back to the player window frequently to make player input. I think it would be better if keys were global, maybe add a ctrl/alt/shift modifier to most debugger keys?

F5 only resumes, but wouldn't an execution toggle be more useful? The corresponding break is a 3 key combination Ctrl+Alt+Break, which you have to switch windows to do- couldn't the pause/break key do both break and resume? (Why ctrl+alt as well? There doesn't seem to be any existing thing that uses that key.) I notice the regular emulator already has escape to do pause/unpause, but couldn't this be unified with the debugger? Why is pausing the emulator different from breaking in the debugger? You can't break while the emulator is paused, apparently, and pressing "escape" is the most sensible way to stop the emulator quickly when trying to enter input, so there should be a way to go from "paused" to "break". (At least I can still use the PPU debug windows with the emulator paused.)

Is there an option to not make the debugger break when a ROM is opened? Especially if you only want to look at PPU stuff, I'd want the debugger minimized, and since F5 doesn't work in any window but the debugger I have to switch back to it to resume. If I don't minimize the debugger window it automatically pops up over top of the PPU windows whenever I switch back to the emulator window for some reason.

Finally, this is not a debugging issue, but I have very erratic drops in framerate. The FPS indicator will pretty much always say 60/60 but the actual displayed frames seems to drop down to maybe 15fps about half the time (changing every few seconds). Doesn't seem to be a CPU usage issue (it's not using a full core of the CPU), nor a vsync issue (vsync is off by default).


Top
 Profile  
 
PostPosted: Sat Dec 03, 2016 9:45 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5032
Location: Canada
koitsu wrote:
Memory viewer needs display of actual (potential) ASCII data on the far right. HOWEVER, before implementing this... well... it's complicated. I can talk at great length about this later on, and it relates to romhacking/translation (as it stands right now, no good debugger offers a feature that's highly sought after). For simplicity/default, you just want to display anything outside of the ASCII 0x20-0x7e range as a dot/period, otherwise show it. Hit me up in a forum post here when you want to tackle the bigger issue (trust me: it's a big undertaking).

FCEUX supports hex-to-character mapping through a table file in its hex editor, and has an additonal "text hooker" tool that uses the same for translating text currently in the nametables directly.


Top
 Profile  
 
PostPosted: Sat Dec 03, 2016 9:48 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 18181
Location: NE Indiana, USA (NTSC)
The mention of "Ctrl+Alt+Break" worried me. Make sure it's usable on laptops that lack a full complement of special keys, especially the Print Screen, Scroll Lock, Pause/Break, and number pad, or laptops that make the F keys hard to reach because they default to media keys (such as volume, screen brightness, WLAN enable, external monitor enable) unless Fn is held.

I'd recommend Ctrl+S for quick save state and Ctrl+R for quick load, as those are similar to in word processors (Ctrl+S) and web browsers (Ctrl+R).


Top
 Profile  
 
PostPosted: Sat Dec 03, 2016 9:51 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5032
Location: Canada
It would be useful if the debugger showed hex bytes for everything, to the left of the instruction maybe, or in its own column? It's very helpful to know what the bytes are, especially when the disassembly has misidentified stuff.

With "unknown block", where nothing at all is displayed. Just showing the hex bytes would be much more useful.

What does the debugger show if you're currently executing an illegal opcode? (I don't think the debugger needs to show illegal opcodes, necessarily, but it should show the bytes that are currently being executed at least.)


Top
 Profile  
 
PostPosted: Sat Dec 03, 2016 10:18 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 190
Thanks to the both of you for the feedback!

(Warning: wall of text below)

@koitsu:
The left part is actually a rom's disassembly (+ symbols from a DBG file), not the actual code.
The opcodes are in uppercase because FCEUX/Nintendulator have them in uppercase - is it typical to write them in lowercase when writing the code? Could definitely add an option for this.
Also didn't realize I had a non-standard opcode name in there - but you're right about CMP. I'll fix that and make sure the rest is standard.

Call stack: I'll fix the name, never realized it had a space despite seeing the word all the time!
As for how it works:
RenderLevel32Wide ($80CA) $80CE [$240CE]

$80CA is the sub's entry point
@ $80CE is the current active instruction in that function (so for the top of the stack, it's the PC, for everything else, it will be the address of the JSR instruction)
[$240CE] is the active instruction's location in the PRG ROM - this probably doesn't need brackets (esp. since the function list & label list do not use brackets for the same case)

So it's meant to be read "In function $80CA, at (@) address $80CE" - but I agree it might not be incredibly obvious. Not sure how to make it more intuitive though.

The IRQ/NMI/Reset handlers (and their addresses) are in the Search->Go To menu.
I agree with the points you bring up about labels/layout, so I'll fix those too.

For the NT viewer, you mean a 8x8 grid? Or would 16x16 and 8x8 both make sense due to attributes?

Memory Viewer vs text: This is actually on my list of things to do as well. My original idea was to have a default config that displays ascii like you said, and then be able to customize what value maps to what character. As for the bigger issue, are you referring to how Japanese games like to separate ゛ and ゜ from the actual character and combine them at runtime? (Just a wild guess - I imagine there's also some pretty complex stuff with the Chinese games as well)

The memory viewer lets you view: CPU, PPU, Palette, OAM, Secondary OAM, PRG ROM, CHR ROM, CHR RAM, Work RAM, Save RAM, Internal RAM (the built-in 2k)


@rainwarrior:
You're absolutely right about the sprite preview - I'll fix that.
I agree about the palette tool, but I'm not sure where else I could fit it, there isn't that much space remaining in the other tabs.

I could add an option to disable the default labels - or you can just select all of them in the label list and hit delete too (this could be annoying if you need to do it often though)

The debugger's keys are mostly made to mimic visual studio since this is what I always use.
To be fair, Ctrl+Alt+Break is mostly useless as hitting F11 (step into) will have the exact same effect.
I agree about F5 vs load state though - I end up doing that mistake myself relatively often.
The "pause" screen for the emulator can only be triggered at the end of a frame to avoid the overhead of checking a flag on every single instruction, so it might be tricky to make "break" and "pause" the same - I'll see if I can find anything that makes sense. (for debugger shortcuts in general as well)

I'll add an option to not automatically break when the debugger is opened, good idea. As for the debugger popping over the PPU windows, I actually meant to fix that before posting this morning, but completely forgot about it.

Mesen only disassembles code that has actually been run, or would have been run if the result of a conditional branch had been different (i.e branch taken or not) - so it will never display code that is not nearly 100% sure to be actual code.
Also, if you right-click in the code window, you can turn on "Show byte code" to display the byte code for all instructions below the assembly (makes each line slightly taller).
All the illegal opcodes that Mesen supports are disassembled and are marked with a * next to the opcode. Opcodes that completely crash the CPU will show up as "invalid opcode"

Unknown blocks: If you uncheck "Show only disassembled code" in "Options", they will turn into .db statements.

As for your FPS problem, I'm not quite sure what might be causing it - The first number is the number of frames generated by the emulation, the 2nd is the number of frames sent to the video card.
I haven't had anybody else complain about this before I think, it could be an issue with the directx code (I'm far from being a DX expert) - I'll try to take a look at the code and see if anything looks suspicious.


@tepples:
There are actually laptops that default to not having the keys work as F1-F12? ..That must be a lot of fun to work with.
At the moment some of the keys for Mesen are hardcoded and some can be customized - I plan on allowing users to customize all of them at some point, so this should be fixed eventually.
Thanks for the info, though, I haven't used too many laptops over the years, so I never noticed!


Top
 Profile  
 
PostPosted: Sat Dec 03, 2016 10:21 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5032
Location: Canada
A few more:


A "jump to PC" button would be useful for when you scroll the disassembly view somewhere else and need to get back.

Why is there an "apply state" button? If you're changing register states / etc. it should apply immediately, IMO. However, if you change it into an "undo state" button (grey until you make changes) that resets the state to what it was after the last executed instruction would probably be useful. This is in the category of: let the user undo a mistake rather than require a confirmation every time.

Of the spelling preferences koitsu listed, I definitely agree with CMP (have never seen CPA before).

Being able to set a breakpoint from a right click in the the debugger's disassembly pane would be nice. (You can can do watch but not breakpoints this way, which seems the opposite of which of those two is useful on the disassembly view-- set watch is useful from hex editor, set breakpoint is useful from disassembly.)

A breakpoint seems to hit on the instruction before as well as the instruction it is set on sometimes. (In this case putting a breakpoint on the DEX of ROR, DEX hits on both.)

The watch field needs [] around memory addresses. This was tricky to figure out; not sure what use literals in the watch area is, like if I type $300, what use is it to tell me its value is $300? (Maybe instead of [] for lookup, make all numbers lookup memory, and a # prefix would specify "immediate"? That way the watch could display literals, and they would be entered similar to assembly convention.)

Breakpoint addresses can only be hex. This is fine, I think, but the notation is weirdly inconsistent (no $ in the editor). I don't really like having to type extra $ anyway, maybe a $ to the left of the entry field would make this clear.

Address ranges are extremely important with breakpoint reads and writes. Think of a question like "does this ROM make any writes to WRAM", kind of impossible if each breakpoint only operates on a single byte. (It feels like I should be able to do this with conditional breakpoints, but I couldn't get it to work: see next suggestion...)

It seems like I can type garbage text into the breakpoint condition and it will still hit. There should be some diagnostic here from accidentally using bad syntax.

I love that the breakpoint condition field has a tooltip though. Very good feature!


Top
 Profile  
 
PostPosted: Sat Dec 03, 2016 10:40 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 190
You can jump to the PC with "Show Next Statement" in the code window's right-click menu (Alt-* .. which is a terrible shortcut, I think I also took that from visual studio)

The Apply State vs Undo is a good point.

You can set a breakpoint on any line by clicking on the left end side of the margin (or pressing F9)
The breakpoint hitting on the wrong instruction is odd - are you sure you didn't have a global breakpoint with a condition setup or something akin? Could be a bug though.

The main issue with using # instead of [] is that the watch shares the same expression engine as the breakpoint conditions, so you would have to write "cycle == #$10" for example in the breakpoint conditions - not very user friendly in my opinion. Plus the watch also uses {} to read word values instead of byte values (this is all explained in the "?" popup next to the watch window's title). I agree that # would make sense in the watch window, though.. Not quite sure what solution would work best overall.

Technically you can set ranges with conditions, but it is not that obvious: Set address to "Any" and then set "Address >= $6000 && Address < $8000" as a condition.
Not very ideal, though. Adding ranges to the regular breakpoints would probably be fairly easy and make more sense considering it's a pretty common use case.

I'll add a validation for breakpoint conditions like it does for watch values.


Top
 Profile  
 
PostPosted: Sat Dec 03, 2016 10:47 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5032
Location: Canada
Hmm, well maybe ignore the # suggestion. The ability to fetch 8 vs 16 bit values is a good thing to have. The tooltip does make it clear, I guess, but I didn't notice how to do it right away.

The breakpoint on wrong instruction thing seems to happen any time there is a 1 byte instruction before the breakpointed instruction (e.g. DEX, TAX, etc.).

Question: how to make the emulator do a hard reset (i.e. power off / on) vs soft reset? I see only "reset" and also "stop" which unloads the ROM entirely.


Top
 Profile  
 
PostPosted: Sat Dec 03, 2016 11:02 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5032
Location: Canada
Sour wrote:
if you right-click in the code window, you can turn on "Show byte code" to display the byte code for all instructions below the assembly (makes each line slightly taller).
All the illegal opcodes that Mesen supports are disassembled and are marked with a * next to the opcode. Opcodes that completely crash the CPU will show up as "invalid opcode"

Unknown blocks: If you uncheck "Show only disassembled code" in "Options", they will turn into .db statements.

These are good, though I find the disassembly window gets very cramped by this second line, and the text is small and hard to read (partly because i turned the text size down because the debugger window is so small).

For me the disassembly is the most important thing in the debugger; i want to see lots of it. In this debugger everything else takes up so much space it is crowded away- I can resize the debugger's window to make it bigger, but it's starting from a pretty small space to begin with. If I make the window wider, the instruction bytes and even ROM address could fit on the left easily, though at this point the debugging window is very large on the screen. I don't know what to suggest here; if I could hide/show the "functions/labels" column it might help? That's probably a pain to do though.

Oh wait, I just noticed I can hide those already! Wow. Ha ha. Yeah, so that's really cool.


I really like the automatic code-data logging, finding functions etc. That's really neat. I think I'd rather it show "attempted disassembly", maybe in a special colour, than data bytes, at least where it's not known to be data at this point. (Sometimes data is code, though, so most useful would be an option for all bytes to display an attempted disassembly.)

Since it's already identifying functions etc. maybe it could do profiling too, count the number of times executed, the number of cycles spent in each function, etc. ? (I actually wrote some text parsing tools to do this with FCEUX trace logs, but it's a lot of logs to process-- would be really cool to have a profiler built into an emulator. That's kinda next level stuff though.)


Top
 Profile  
 
PostPosted: Sun Dec 04, 2016 6:48 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Sour wrote:
@koitsu:
The left part is actually a rom's disassembly (+ symbols from a DBG file), not the actual code.

Gotcha. I'm not familiar with .dbg files (are these .deb files FCEUX uses?).

What is turning NES MMIO registers into names? In FCEUX I believe these are accomplished through .nl files. Is this contained within the .dbg? If not (i.e. Mesen is doing the register name conversions itself), then the ability to toggle that would be useful. Most of the time I cannot tools converting such values into arbitrary names which I may/may not recognise.

Sour wrote:
The opcodes are in uppercase because FCEUX/Nintendulator have them in uppercase - is it typical to write them in lowercase when writing the code? Could definitely add an option for this.

It's a matter of programmer style and preference. I've varied over the years in my style, but for quite some time I've resorted to lowercase opcodes, leaving uppercase or mixed-case things for variables, labels, or whatever else. So, to answer your question: yes it's typical, just as it's typical for someone to write opcodes in uppercase. :-) A toggle option would be great (and should be incredibly easy to implement code-wise, assuming you have an uppercase/lowercase string conversion function in the PL you're using).

Sour wrote:
Call stack: I'll fix the name, never realized it had a space despite seeing the word all the time!

Yeah, "callstack" isn't an actual word, it's "call stack". I think some people just like compounding words into a single one to make it sound cool; superHipsterCrapNameWithCamelCase2.0Bro! ;-)

Sour wrote:
As for how it works: {explanation of syntaxes shown in call stack}

Got it -- makes sense. Now that you've described it, it clicks. So here's how you could help clarify the subroutine entry point with very little code: change the field name from "Function" to "Function (Entry Addr)". Bam, clarified. :-) But assuming you're writing documentation for this, yeah, please describe it much like you did to me in the docs. Different debuggers implement call stack syntaxes/conventions differently.

Sour wrote:
The IRQ/NMI/Reset handlers (and their addresses) are in the Search->Go To menu.

Well that's not an intuitive place for it at all. :-) Can they be placed in a small box/section to the left of Labels and below PPU Status?

Sour wrote:
For the NT viewer, you mean a 8x8 grid? Or would 16x16 and 8x8 both make sense due to attributes?

Excellent question (and not something I thought of). I was thinking 8x8, but now that you mention the attribute table, yeah, I think 16x16 would be useful too. Make it a checkbox for toggling the grid on/off, and when the checkbox is enabled, provide a pulldown for Grid Size that's 8x8 or 16x16.

Sour wrote:
Memory Viewer vs text: This is actually on my list of things to do as well. My original idea was to have a default config that displays ascii like you said, and then be able to customize what value maps to what character. As for the bigger issue, are you referring to how Japanese games like to separate ゛ and ゜ from the actual character and combine them at runtime? (Just a wild guess - I imagine there's also some pretty complex stuff with the Chinese games as well)

Sort of. I think rainwarrior touched base on this one, but it's basically that games don't necessarily (bad wording coming up, my apologies) correlate alphabets/text tiles with ASCII location with actual PPU tile offsets. Meaning: "A" in ASCII is at 0x41, but nothing stops a developer from putting their A-Z tiles at PPU address $0020. There are files that are called .tbl (table) files which provide a kind of mapping (e.g. $20 -> "A", etc.). See the FCEUX documentation for "Text Hooker" to get an idea of what I'm talking about. Many Japanese games use offsets that are EUC-JP, but again, you could have $F2 -> "A", $25 -> "B", etc. -- and many games do this too, since for many title or text screens, they only add the CHR for the letters they actually use on-screen (i.e. you don't have an ASCII-compatible full alphabet, because all they show is "CONGRATURATIONS" (note the missing L) which only needs 10 tiles (ACGINORSTU).

I should warn you up front, however. As Walter from The Big Lebowski said: "you're entering a world of pain". The situation is complicated by fonts and character sets. Ideally everyone would use UTF-8, but then you have to deal with that, BOM vs. non-BOM, blah blah, and most of the table-generating tools *do not* use UTF-8. I'm trying very hard right now to avoid the subject, LOL. It's just something you need to keep in mind. That's why I said don't worry about this for now, deal with it down the road.

I've attached a screenshot demonstrating the pain in NO$NES, at least with regards to font usage when printing characters. I've seen this in more programs than I care to count, often in hex editors, but it's never limited to just those.

Sour wrote:
There are actually laptops that default to not having the keys work as F1-F12? ..That must be a lot of fun to work with.

There are actual desktop keyboards like this (they're commonplace too, including some from Microsoft (I use one!)), where the F-keys are either few (F1-F10), or have default scancodes changed to crap like F1=Help, F2=Undo, F3=Redo, F4=New, F10=Spell, etc.. The Microsoft Natural keyboards have an "F-Lock" key (which has no scancode -- it's a modifier key for the keyboard itself (think Fn on a laptop)) that toggles this behaviour, but some older Microsoft and Logitech keyboards did it weirdly -- I could talk for 30 minutes on all that, but will hold off. Laptops are notorious for removing keys though, and I've heard of some which even lack a Fn key. So, in short, I sympathise with tepples -- let's hope he never runs FreeBSD (console framebuffer scrollback requires you to hit Scroll Lock to enter scrollback mode, and again to exit it -- different from Linux console where you use Alt-Arrow or Alt-PUp/PDown (or is it Left Shift?) ;-) ). For keyboards that default to non-classic-F-key mode: this isn't your problem. DO NOT try to solve it in your program: honest! Just stick with standard scancodes/values for function keys and don't worry.

I would, though, suggest trying to limit the F-key usage to F1-F10 if at all possible. Also, some keyboards lack a Pause/Break key entirely, so if you plan on using that key: don't! :-)


Attachments:
screenshot.png
screenshot.png [ 38.64 KiB | Viewed 794 times ]
Top
 Profile  
 
PostPosted: Sun Dec 04, 2016 8:11 am 
Offline
User avatar

Joined: Mon Jan 03, 2005 10:36 am
Posts: 2803
Location: Tampere, Finland
Got this message when loading the DBG file for STREEMERZ, although debugging worked quite well regardless of the errors:
Code:
---------------------------
Mesen
---------------------------
Import completed with 3969 labels importedand 25379 errors - please file a bug report and attach the DBG file you tried to import.
---------------------------
OK   
---------------------------

Unfortunately I don't want to share the DBG file at the moment (maybe later).

The Flip/Priority checkboxes in Sprite Viewer should probably be disabled so that the user doesn't think they can actually switch their state in OAM.

The Sprite Info view could also display the sprite index that the user is currently hovering the mouse over.

_________________
Download STREEMERZ for NES from fauxgame.com! — Some other stuff I've done: kkfos.aspekt.fi


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 47 posts ]  Go to page 1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: AWJ and 8 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