byuu says:
I've completed moving all the class objects from `unique_pointer<T>` to
just T. The one exception is the Emulator::Interface instance. I can
absolutely make that a global object, but only in bsnes where there's
just the one emulation core.
I also moved all the SettingsWindow and ToolsWindow panels out to their
own global objects, and fixed a very difficult bug with GTK TabFrame
controls.
The configuration settings panel is now the emulator settings panel. And
I added some spacing between bold label sections on both the emulator
and driver settings panels.
I gave fixing ComboButtonItem my best shot, given I can't reproduce the
crash. Probably won't work, though.
Also made a very slight consistency improvement to ruby and renamed
driverName() to driver().
...
An important change ... as a result of moving bsnes to global objects,
this means that the constructors for all windows run before the
presentation window is displayed. Before this change, only the
presentation window was constructed first berore displaying it, followed
by the construction of the rest of the GUI windows.
The upside to this is that as soon as you see the main window, the GUI
is ready to go without a period where it's unresponsive.
The downside to this is it takes about 1.5 seconds to show the main
window, compared to around 0.75 seconds before.
I've no intention of changing that back. So if the startup time becomes
a problem, then we'll just have to work on optimizing hiro, so that it
can construct all the global Window objects quicker. The main way to do
that would be to not do calls to the Layout::setGeometry functions for
every widget added, and instead wait until the window is displayed. But
I don't have an easy way to do that, because you want the widget
geometry values to be sane even before the window is visible to help
size certain things.
byuu says:
These WIPs-within-WIPs are getting more and more broken ... this isn't
going the way I wanted.
But ... this time around, I've revamped the entire ruby API again, to
solve a bunch of tough problems that have always made using ruby really
clunky.
But there are *so many* ruby drivers that it's going to take a long
time to work through them all. This WIP is only going to run bsnes, and
only on FreeBSD, and only with some drivers.
hiro's Application::initialize() now calls hiro::initialize(), which you
define inside of your hiro apps. This lets you call
Application::setName(...) before anything else in hiro runs. This is
essential on Xorg to set program icons, for instance.
With the ruby rewrite and the change to hiro, I can get away from the
need to make everything in bsnes/higan pointers to objects, and can now
just declare them as regular objects.
byuu wrote:
Sigh ...
asio.hpp needs #include <nall/windows/registry.hpp>
[Since the last WIP, byuu also posted the following message. -Ed.]
ruby drivers have all been updated (but not tested outside of BSD), and
I redesigned the settings window. The driver functionality all exists on
a new "Drivers" panel, the emulator/hack settings go to a
"Configuration" panel, and the video/audio panels lose driver settings.
As does the settings menu and its synchronize options.
I want to start pushing toward a v107 release. Critically, I will need
DirectSound and ALSA to support dynamic rate control. I'd also like to
eliminate the other system manifest.bml files. I need to update the
cheat code database format, and bundle at least a few quark shaders --
although I still need to default to Direct3D on Windows.
Turbo keys would be nice, if it's not too much effort. Aside from
netplay, it's the last significant feature I'm missing.
I think for v107, higan is going to be a bit rough around the edges
compared to bsnes. And I don't think it's practical to finish the bsnes
localization support.
I'm thinking we probably want another WIP to iron out any critical
issues, but this time there should be a feature freeze with the next
WIP.
byuu says:
I stand corrected, I managed to create and even larger diff than ever.
This one weighs in at 309KiB `>__>`
I'll have to create a changelog later, I'm too tired right now to go
through all of that.
byuu says:
I failed to complete a WIP, have five of eight cores updated with some
major changes to Emulator::Interface. I'll just post a quick temporary
WIP in the off chance someone wants to look over the new interface and
comment on it.
Also implemented screen saver suppression into hiro/GTK.
I should also add ... a plan of mine is to develop target-bsnes into a
more generic user interface, with the general idea being that
target-higan is for multiple Emulator::Interface cores at the same time,
and target-bsnes is for just one Emulator::Interface core.
The idea being that if one were to compile target-bsnes with the GBA
core, it'd become bgba, for instance.
I don't plan on releasing single-core emulators like this, but ... I don't see any downsides to being more flexible.
byuu says:
The problems with the Windows and Qt4 ports have all been resolved,
although there's a fairly gross hack on a few Qt widgets to not destruct
once Application::quit() is called to avoid a double free crash (I'm
unsure where Qt is destructing the widgets internally.) The Cocoa port
compiles again at least, though it's bound to have endless problems. I
improved the Label painting in the GTK ports, which fixes the background
color on labels inside TabFrame widgets.
I've optimized the Makefile system even further.
I added a "redo state" command to bsnes, which is created whenever you
load the undo state. There are also hotkeys for both now, although I
don't think they're really something you want to map hotkeys to.
I moved the nall::Locale object inside hiro::Application, so that it can
be used to translate the BrowserDialog and MessageDialog window strings.
I improved the Super Game Boy emulation of `MLT_REQ`, fixing Pokemon
Yellow's custom border and probably more stuff.
Lots of other small fixes and improvements. Things are finally stable
once again after the harrowing layout redesign catastrophe.
Errata:
- ICD::joypID should be set to 3 on reset(). joypWrite() may as well
take uint1 instead of bool.
- hiro/Qt: remove pWindow::setMaximumSize() comment; found a
workaround for it
- nall/GNUmakefile: don't set object.path if it's already set (allow
overrides before including the file)
byuu says:
This is probably the largest code-change diff I've done in years.
I spent four days working 10-16 hours a day reworking layouts in hiro
completely.
The result is we now have TableLayout, which will allow for better
horizontal+vertical combined alignment.
Windows, GTK2, and now GTK3 are fully supported.
Windows is getting the initial window geometry wrong by a bit.
GTK2 and GTK3 work perfectly. I basically abandoned trying to detect
resize signals, and instead keep a list of all hiro windows that are
allocated, and every time the main loop runs, it will query all of them
to see if they've been resized. I'm disgusted that I have to do this,
but after fighting with GTK for years, I'm about sick of it. GTK was
doing this crazy thing where it would trigger another size-allocate
inside of a previous size-allocate, and so my layouts would be halfway
through resizing all the widgets, and then the size-allocate would kick
off another one. That would end up leaving the rest of the first layout
loop with bad widget sizes. And if I detected a second re-entry and
blocked it, then the entire window would end up with the older geometry.
I started trying to build a message queue system to allow the second
layout resize to occur after the first one completed, but this was just
too much madness, so I went with the simpler solution.
Qt4 has some geometry problems, and doesn't show tab frame layouts
properly yet.
Qt5 causes an ICE error and tanks my entire Xorg display server, so ...
something is seriously wrong there, and it's not hiro's fault. Creating
a dummy Qt5 application without even using hiro, just int main() {
TestObject object; } with object performing a dynamic\_cast to a derived
type segfaults. Memory is getting corrupted where GCC allocates the
vtables for classes, just by linking in Qt. Could be somehow related to
the -fPIC requirement that only Qt5 has ... could just be that FreeBSD
10.1 has a buggy implementation of Qt5. I don't know. It's beyond my
ability to debug, so this one's going to stay broken.
The Cocoa port is busted. I'll fix it up to compile again, but that's
about all I'm going to do.
Many optimizations mean bsnes and higan open faster. GTK2 and GTK3 both
resize windows very quickly now.
higan crashes when you load a game, so that's not good. bsnes works
though.
bsnes also has the start of a localization engine now. Still a long way
to go.
The makefiles received a rather substantial restructuring. Including the
ruby and hiro makefiles will add the necessary compilation rules for
you, which also means that moc will run for the qt4 and qt5 targets, and
windres will run for the Windows targets.
byuu says:
Changelog:
- emulator: added `Thread::setHandle(cothread_t)`
- icarus: added special heuristics support for the Tengai Maykou Zero
fan translation
- board identifier is: EXSPC7110-RAM-EPSONRTC (match on SPC7110 +
ROM size=56mbit)
- board ROM contents are: 8mbit program, 40mbit data, 8mbit
expansion (sizes are fixed)
- bsnes: show messages on game load, unload, and reset
- bsnes: added support for BS Memory and Sufami Turbo games
- bsnes: added support for region selection (Auto [default], NTSC,
PAL)
- bsnes: correct presentation window size from 223/239 to 224/240
- bsnes: add SA-1 internal RAM on cartridges with BS Memory slot
- bsnes: fixed recovery state to store inside .bsz archive
- bsnes: added support for custom manifests in both game pak and game
ROM modes
- bsnes: added icarus game database support (manifest → database →
heuristics)
- bsnes: added flexible SuperFX overclocking
- bsnes: added IPS and BPS soft-patching support to all ROM types
(sfc,smc,gb,gbc,bs,st)
- can load patches inside of ZIP archives (matches first “.ips” or
“.bps” file)
- bsnes/ppu: cache interlace/overscan/vdisp (277 → 291fps with fast
PPU)
- hiro/Windows: faster painting of Label widget on expose
- hiro/Windows: immediately apply LineEdit::setBackgroundColor changes
- hiro/Qt: inherit Window backgroundColor when one is not assigned to
Label
Errata:
- sfc/ppu-fast: remove `renderMode7Hires()` function (the body isn't in
the codebase)
- bsnes: advanced note label should probably use a lighter text color
and/or smaller font size instead of italics
I didn't test the soft-patching at all, as I don't have any patches on
my dev box. If anyone wants to test, that'd be great. The Tengai Makyou
Zero fan translation would be a great test case.
byuu says:
Changelog:
- nall: merged Path::config() and Path::local() to Path::userData()
- ~/.local/share or %appdata or ~/Library/ApplicationSupport
- higan, bsnes: render main window icon onto viewport instead of
canvas
- should hopefully fix a brief flickering glitch that appears on
Windows
- icarus: improved Super Famicom heuristics for Starfox / Starwing RAM
- ruby/Direct3D: handle viewport size changes in lock() instead of
output()
- fixes icon disappearing when resizing main window
- hiro/Windows: remove WS_DISABLED from StatusBar to fix window
resize grip
- this is experimental: I initially used WS_DISABLED to work
around a focus bug
- yet trying things now, said bug seems(?) to have gone away at
some point ...
- bsnes: added advanced settings panel with real-time driver change
support
I'd like feedback on the real-time driver change, for possible
consideration into adding this to higan as well.
Some drivers just crash, it's a fact of life. The ASIO driver in
particular likes to crash inside the driver itself, without any error
messages ever returned to try and catch.
When you try to change a driver with a game loaded, it gives you a scary
warning, asking if you want to proceed.
When you change a driver, it sets a crash flag, and if the driver
crashes while initializing, then restarting bsnes will disable the
errant driver. If it fails in a recoverable way, then it sets the driver
to “None” and warns you that the driver cannot be used.
What I'm thinking of further adding is to call emulator→save() to
write out the save RAM contents beforehand (although the periodic
auto-saving RAM will handle this anyway when it's enabled), and possibly
it might be wise to capture an emulator save state, although those can't
be taken without advancing the emulator to the next frame, so that might
not be a good idea.
I'm also thinking we should show some kind of message somewhere when a
driver is set to “None”. The status bar can be hidden, so perhaps on the
title bar? Or maybe just a warning on startup that a driver is set to
“None”.
byuu says:
Changelog:
- bsnes: work on the new GUI; can load games now, but no input support
yet
- icarus: heuristics game/label uses filename instead of internal
header name
byuu says:
Changelog:
- created new bsnes target (it currently does nothing)
- Super Famicom: fixed BS Memory pack support in the MCC emulation
- icarus: fixed manifest-free support for BS Memory flash-based
cartridges
- icarus: database improvements
Tim Allen