Chester wrote:Hi byuu. So is a debugger on the way?
Hi Chester, thanks for stopping by! :D
I will have to bug you sometime about the feature set you'd be looking for.
Biggest limitation is no savestates for the debugger, but yes, I'd like to re-add something similar to v013's debugger.
So instead of just toggling out, I'm always doing it the long way: hitting Esc and then using the menu to get out. I assume there is no better way, why would I?
And I spent so much time on that layout idea, trying to cover the most common usage scenarios, too :(
For power users / emu loader tools, I allow loading via command-line / file association to hide the menubar automatically.
For general users, when you enter fullscreen with a cart loaded, the menubar disappears. With no cart, you will
have to show the menubar anyway in order to load a cart to play, then hide it again. So it should be shown. It even lets you know there's no cart loaded at the bottom right.
If one insists on loading games in fullscreen mode manually, then one extra key hit after is surely not a big deal.
For idiots, the menubar will stay visible if they go straight into fullscreen mode, allowing them to get out of it.
There is no fool-proof method here that won't hurt one of the three user categories in some way (power/general/idiot)*.
*1 - make 'start in fullscreen' an advanced checkbox, do not save the mode setting on exit, auto-hide the menu when no cart is specified+auto-hide the menu after a cart load from fullscreen.
*1a - maybe add a checkbox to 'hide menu / status bars after cart load'
*2 - keep what I have now, remove fullscreen menu item to enter fullscreen, under the theory that if they get into fullscreen, they can hopefully figure out how to get out. Downside is new people may think the app lacks any kind of fullscreen mode whatsoever. No, nobody stupid is going to read a popup short of making them type the readme text verbatim into a box below to start the app for the first time.
*3 - just don't ever allow starting in fullscreen mode. General user and idiots alike can, in the worst case, hit the power button on their PC and bsnes will be back to safe-old windowed mode on the next run.
(a) removing the fullscreen option from the menu (b) documenting their existence and (c) slapping the documentation in their face on first run?
a) I don't see why we can't have a menu entry as well as a hotkey. We don't remove 'Load Cartridge' because you can do that with a key binding. '[ ] Fullscreen' makes sense under "Video Mode".
b) Should we document the ten other GUI hotkeys? That's what the GUI hotkey window is for. Yeah, there's a problem with people finding that. I don't have a good answer for that ... if we list the GUI keys first, people won't find the joypads. If we list the joypads, people won't find the GUI keys.
Maybe we should pop up an IQ test on first run instead of the documentation that you know idiots won't read if it's over two lines long (assuming they can read) :P
Okay, so knowing which filetypes bsnes supports and generates isn't vitally important to operating the emulator.
The load window tells you the supported types just fine.
But yes, you make a good point about the extensions I suppose. Good enough for me.
I still hold, though, that your unsupported hardware section can be construed as withholding information.
Easy enough,
<h2>Partially supported hardware</h2>
<p>The following hardware support is still considered experimental and has serious known problems. Compatibility and/or playability is not guaranteed.</p>
<b>DSP-3:</b> Coprocessor used by some crappy robot board game
<b>BS-X:</b> Satellite receiver system that streams live audio; flashes physical cartridges with content; and allows users to download games, sound novels, magazines and other such content
Lastly, unemulated hardware is a known limitation
I kind of take issue with that, but we're just splitting hairs here. You can put anything inside an SNES cart. I'm writing a Super NES emulator, not a game cartridge emulator (even if the latter is the end goal.) The cart special chips I add are icing on the cake, and aren't even focused on strict accuracy (due to time constraints, I'd like them all to be timing/bit perfect of course.)
Either that, or rename it as "Popular Unsupported Hardware" and try to gauge which games are worth mentioning
That's what I was going with. I want to list that I don't support SuperFX, SA-1, etc. I know someone who's never heard of the SNES won't know what the hell they are, but I think most people using bsnes would.
I list a few games because that really
is obscure info, and they're also extremely ridiculously popular. I really don't know what people see in Super Mario RPG (I know, blasphemy), but one in three posts I see people mentioning something other than a new bsnes release mention that they can't get that game running. At least we can say "you should read the documentation" when they mention it.
Again, the new popup that says an unsupported chip was detected will probably help a lot, too. We'll have to see.
What bothers me isn't necessarily that the other controllers don't have an equivalent (and can't, due to the sheer size of the scope). It's that some users are going to look at it and be like "wtf, that's not what an snes controller looks like." If Nintendo had used a global design and name for the system, I'd probably leave it in.
