byuu says:
- bsnes: added video filters from bsnes v082
- bsnes: added ZSNES snow effect option when games paused or unloaded
(no, I'm not joking)
- bsnes: added 7-zip support (LZMA 19.00 SDK)
[Recent higan WIPs have also mentioned bsnes changes, although the higan code
no longer includes the bsnes code. These changes include:
- higan, bsnes: added EXLOROM, EXLOROM-RAM, EXHIROM mappings
- higan, bsnes: focus the viewport after leaving fullscreen exclusive
mode
- bsnes: re-added mightymo's cheat code database
- bsnes: improved make install rules for the game and cheat code
databases
- bsnes: delayed construction of hiro::Window objects to properly show
bsnes window icons
- Ed.]
byuu says:
The Windows port can now run the emulation while navigating menus,
moving windows, and resizing windows. The main window also doesn't try
so hard to constantly clear itself. This may leave a bit of unwelcome
residue behind in some video drivers during resize, but under most
drivers, it lets you resize without a huge amount of flickering.
On all platforms, I now also run the emulation during MessageWindow
modal events, where I didn't before.
I'm thinking we should probably mute the audio during modal periods,
since it can generate a good deal of distortion.
The tooltip timeout was increased to ten seconds.
On Windows, the enter key can now activate buttons, so you can more
quickly dismiss MessageDialog windows. This part may not actually work
... I'm in the middle of trying to get messages out of the global
`Application_windowProc` hook and into the individual `Widget_windowProc`
hooks, so I need to do some testing.
I fixed a bug where changing the input driver wouldn't immediately
reload the input/hotkey settings lists properly.
I also went from disabling the driver "Change" button when the currently
active driver is selected in the list, to instead setting it to say
"Reload", and I also added a tool tip to the input driver reload button,
advising that if you're using DirectInput or SDL, you can hit "Reload"
to rescan for hotplugged gamepads without needing to restart the
emulator. XInput and udev have auto hotswap support. If we can ever get
that into DirectInput and SDL, then I'll remove the tooltip. But
regardless, the reload functionality is nice to have for all drivers.
I'm not sure what should happen when a user changes their driver
selection while a game is loaded, gets the warning dialog, chooses not
to change it, and then closes the emulator. Currently, it will make the
change happen the next time you start the emulator. This feels a bit
unexpected, but when you change the selection without a game loaded, it
takes immediate effect. So I'm not really sure what's best here.
byuu says:
I've added tool tips to hiro for Windows, GTK, and Qt. I'm unsure how to
add them for Cocoa. I wasted am embarrassing ~14 hours implementing tool
tips from scratch on Windows, because the `TOOLTIPS_CLASS` widget just
absolutely refused to show up, no matter what I tried. As such, they're
not quite 100% native, but I would really appreciate any patch
submissions to help improve my implementation.
I added tool tips to all of the confusing settings in bsnes. And of
course, for those of you who don't like them, there's a configuration
file setting to turn them off globally.
I also improved Mega Drive handling of the Game Genie a bit, and
restructured the way the Settings class works in bsnes.
Starting now, I'm feature-freezing bsnes and higan. From this point
forward:
- polishing up and fixing bugs caused by the ruby/hiro changes
- adding DRC to XAudio2, and maybe exclusive mode to WGL
- correcting FEoEZ (English) to load and work again out of the box
Once that's done, a final beta of bsnes will go out, I'll fix any
reported bugs that I'm able to, and then v107 should be ready. This time
with higan being functional, but marked as v107 beta. v108 will restore
higan to production status again, alongside bsnes.
byuu says:
Everything *should* be working again, but of course that won't
actually be the case. Here's where things stand:
- bsnes, higan, icarus, and genius compile and run fine on FreeBSD
with GTK
- ruby video and audio drivers are untested on Windows, macOS, and
Linux
- hiro is untested on macOS
- bsnes' status bar is not showing up properly with hiro/qt
- bsnes and higan's about screen is not showing up properly with
hiro/qt (1x1 window size)
- bsnes on Windows crashes often when saving states, and I'm not sure
why ... it happens inside Encode::RLE
- bsnes on Windows crashes with ruby.input.windows (unsure why)
- bsnes on Windows fails to show the verified emblem on the status bar
properly
- hiro on Windows flickers when changing tabs
To build the Windows bsnes and higan ports, use
ruby="video.gdi audio.directsound"
Compilation error logs for Linux will help me fix the inevitable list of
typos there. I can fix the typos on other platforms, I just haven't
gotten to it yet.
byuu says:
Updated to compile with all of the new hiro changes. My next step is to
write up hiro API documentation, and move the API from alpha (constantly
changing) to beta (rarely changing), in preparation for the first stable
release (backward-compatible changes only.)
Added "--fullscreen" command-line option. I like this over
a configuration file option. Lets you use the emulator in both modes
without having to modify the config file each time.
Also enhanced the command-line game loading. You can now use any of
these methods:
higan /path/to/game-folder.sfc
higan /path/to/game-folder.sfc/
higan /path/to/game-folder.sfc/program.rom
The idea is to support launchers that insist on loading files only.
Technically, the file can be any name (manifest.bml also works); the
only criteria is that the file actually exists and is a file, and not
a directory. This is a requirement to support the first version (a
directory lacking the trailing / identifier), because I don't want my
nall::string class to query the file system to determine if the string
is an actual existing file or directory for its pathname() / dirname()
functions.
Anyway, every game folder I've made so far has program.rom, and that's
very unlikely to change, so this should be fine.
Now, of course, if you drop a regular "game.sfc" file on the emulator,
it won't even try to load it, unless it's in a folder that ends in .fc,
.sfc, etc. In which case, it'll bail out immediately by being unable to
produce a manifest for what is obviously not really a game folder.
byuu says:
Finally!! Compilation works once again on Windows.
However, it's pretty buggy. Modality isn't really working right, you can
still poke at other windows, but when you select ListView items, they
redraw as empty boxes (need to process WM_DRAWITEM before checking
modality.)
The program crashes when you close it (probably a ruby driver's term()
function, that's what it usually is.)
The Layout::setEnabled(false) call isn't working right, so you get that
annoying chiming sound and cursor movement when mapping keyboard keys to
game inputs.
The column sizing seems off a bit on first display for the Hotkeys tab.
And probably lots more.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
byuu