To resize a window on X11, the window manager tells the X11 server to change the
window size, then the X11 server tells the application to paint itself, and then
(eventually) the application tells the X11 server what to draw. This adds an
arbitrary amount of latency to resizing, so to make things feel more responsive,
the X11 server will paint any newly-exposed parts of the window with a default
background colour. If it happens to be the same colour as the appplication would
paint anyway, this gives resizing a much better user-experience.
Since most of bsnes' window is occupied by the viewport, which is always black,
bsnes accordingly set its window background colour to black for the best
resizing experience. However, this had two additional effects:
- When no game is loaded, bsnes displays the bsnes icon in the main display
area. Black canvas widgets are used as spacers to position the icon
correctly, but the spacers don't cover the entire background, and the window
background shines through.
- GTK+3 draws widget transparent by default, so the background colour of the
parent widget shines through child widgets. In particular, setting the
window background to black makes the menu background black, even if the menu
text is also a dark colour.
In order to get the menu to display properly in GTK+3 builds, we have to stop
bsnes from setting the top-level window background colour, and we also have to
ensure that the spacer widgets around the icon cover the entire surface of the
window.
Fixes#108.
On X11, hiro uses the xdg-screensaver helper tool to disable the screensaver,
which detects the screensaver that is running and uses the appropriate
mechanism to communicate with it. The tool's API expects an X11 window ID,
but at least some screensavers ignore it, so it can be set up however. The
GNOME backend *does* care about the window ID, but its expectations are not
documented anywhere, so byuu spent a frustrating few days trying things
at random to get it working, and failing.
It turns out, GNOME does *not* require the window to be mapped, but it *does*
require the window to have a name. Using XStoreName() to name the window fixes
screensaver suspension for me under GNOME 3.38.
Note: while XStoreName is technically deprecated, it's not going to go away
while X11 is still around, and the reason it's deprecated is because it doesn't
include character encoding data. We don't care — no user should ever see the
window name, and it's plain ASCII so it should be fine.
Fixes#102.
This corrects the reporting bit of HVBJOY to be set during the auto joypad
polling sequence.
This change will fix *SpellCraft - Aspects of Valor*. SpellCraft works by
polling JOY1 nonstop once menus are entered on every scanline, so with incorrect
HVBJOY bit 0 reporting, the game was thinking it was safe to read JOY1 during
the auto joypad polling sequence, so partially shifted in results were being
read back as valid. With this patch, you'll find that the game stops polling
between V:225 H:130 and V:228 H:256, which is the auto polling time range.
Before, it was polling during that time. As a result of this fix, the password
menu can be accessed safely without it closing immediately.
Fixes#86.
- Fixes a bug where the program may crash or display improper buttons
when changing the selected row during assignment.
This appears to just be a mistake, accidentally using the 'batched'
rows instead of the activeMapping row.
- Fixes a bug where starting multiple assignments without finishing
one leads to stale "Assigning..." text in some rows.
This appears to be an oversight. Simply refreshing the mappings
before starting an assignment fixes this.
This commit reworks when the screensaver suppression kicks in.
Previously, bsnes would only engage screensaver suppression once, on
application launch. Now that the option is exposed and can be toggled at
any time, we have to be a little more clever.
Additionally, screensaver suppression is now only engaged while
emulation is active, because it doesn't make much sense otherwise.
The setting already existed and could be changed by manually editing the
configuration file, but wasn't exposed in the UI. This commit adds the
corresponding check box.
As I was doing the research for #51, I figured I should write down what I
learned before I forgot it, and if I was going to do that, I might as well
write it down in Markdown so we can make a website from it.
In f09c45f, we fixed native file picker dialogs, so they would correctly set the
"option" field to Auto when loading games, instead of leaving it set to an empty
string which effectively forced NTSC mode. However, this wouldn't fix up the old
entries in the Recent Games menu, so we will patch them up if we encounter them.
Specifically, we don't know what happens when reading from 4016-4017 or 4218-421f, or when writing to 4016 or 4200, during the auto joypad polling sequence.
Presumably, nothing good.
anomie's notes indicate that polling begins between cycles 32.5-95.5, but his
notes were slightly off. 32.5-95.5 is referring to the PPU dot clock. If you
multiply by 4 you get the cycle count, 130-382. It's pretty clear that in
256-cycle units, that would need to be 130-384 or you'd have no event when it
lands on cycle 384. Jonas Quinn confirmed that with his testing in any case.
I chose to split the cycle range in half and run things every 128 clocks. So
that reduces us to 32.5-64.0, or 130 to 256 + 258-384. The reason I chose 128
over 256 was so I could emulate the time it takes to perform the joypad
latching. I don't believe you can set the controller latch to 1 and then 0
immediately. It needs time to let the controllers see this happening and then
release the latch, and time to let that take effect. Polling the controllers is
only one operation so it makes sense that happens once every 256 cycles, which
is why I have the (counter&1) test for that.
Think about it this way: we know the polling sequence takes 4224 cycles, and
4224/256 is 16.5. Isn't that a little strange to have half a cycle? But if we
consider the latching is actually twice as fast, then it's 2x128 + 16x256. If we
run on a 128-clock counter, it becomes 2x128 + 16x2x128, or 34 total states. But
now since we don't actually poll on the second half of each 16x2x256 states, we
don't need to bother running the event there, so we can stop at 33 instead of 34
and it's the same thing. And by doing that, it turns our polling duration into
4224 cycles, just like we've observed.
Fixes#61.
Previously, we didn't have control of byuu.org and it wasn't obvious what we
should do about hosting. Now we can update byuu.org, though, we should continue
using it as the authoritative source information.
Fixes#2.
hiro has two confusingly-named file-picker dialogs. "BrowserDialog" is the
custom dialog built entirely with hiro widgets, "BrowserWindow" is a wrapper
around the native file-picker. bsnes is built for BrowserDialog, but if you tick
"Use native file picker" in the Emulator options, when it needs a file it will
construct a BrowserDialog, copy the relevant config options across to a new
BrowserWindow and invoke that.
Unfortunately, BrowserDialog and BrowserWindow have different capabilities.
Specifically, BrowserDialog includes an "options" list which bsnes uses to let
the user override region detection when loading a game. BrowserWindow has no
such widget. Thus, when using a BrowserDialog the options list worked as intended,
but when using a BrowserWindow the options list was never initialised and no
option was ever chosen. As a result, when opening a game with the native file-
picker, bsnes always used NTSC emulation mode, instead of auto-detecting.
Previously, constructing a BrowserDialog and calling setOptions would leave the
BrowserDialog in an inconsistent state (with no option selected). This was OK if
you immediately displayed the dialog to the user (this would complete the
initialisation and choose a default), but bsnes also used BrowserDialog as an
*interface* typee, to represent the parameters and results of a file-picker
operation that was implemented elsewhere. For this use-case, the inconsistent
state caused problems.
Therefore, BrowserDialog has been changed:
- setting the list of options always chooses a default, maintaining the
invariant that `.options()` always returns one of the available options.
- The internal BrowserDialogWindow class now takes a reference to a Response
object, instead of constructing one from scratch and having to duplicate
the "set .option to a reasonable value" code.
Fixes#44.
Previously, bsnes would turn the cheat text into a list of cheats by splitting
on '\n', producing an empty "cheat" after the last line of the editor:
"7e0003=00\n".split("\n") -> ["7e0003=00", ""]
That empty "cheat" is not a valid cheat, so the result would be marked invalid.
Teaching bsnes to silently skip empty lines worked, but it would preserve
multiple blank lines between two cheats, which was silly.
Now we iterate over all the lines of the cheat editor, putting valid codes in a
new vector, and setting a flag for invalid codes.
Fixes#63.
This is lightly adapted from the implementation in Higan. For more
information, see that PR in higan-emu/higan#118.
The main difference is that we only compile one binary here, and
packaging is similar to (but adapted from) packaging byuu.
This includes changes to SameBoy (updating the README to be clear about
provenance, and adding a GNUmakefile to integrate with bsnes' build system),
updates the SameBoy version number in the about box, and adds SameBoy to the
list of subtrees updated by update-subtrees.sh.
Tim Allen