byuu says:
Changelog:
- hiro: added BrowserDialog::openObject() [match file *or* folder
by filters]
- hiro: BrowserDialog accept button is now disabled when it would
otherwise do nothing
- eg openFile without a folder to enter or file to open selected
- eg saveFile without a file name or with a file name that matches
a folder name
- bsnes: added support for gamepaks (game folders)
- bsnes: store all save states inside per-game .bsz (ZIP) archives
instead of .bst/ folders
- this reduces the number of state files from 10+ to 1; without
having folders sort before files
- hiro: both gtk2 and gtk3 now use cairo to render Canvas; supports
sx,sy [BearOso]
- higan, bsnes: fast PPU/DSP are now run-time options instead of
compile-time options
- bsnes: disable fast PPU when loading Air Strike Patrol / Desert
Fighter
- bsnes: disable fast DSP when loading Koushien 2
- bsnes: added options to advanced panel to disable fast PPU and/or
fast DSP
byuu says:
Changelog:
- ruby/video: implement onUpdate() callback to signal when redraws are
necessary
- ruby/video/GLX,GLX2,XVideo,XShm: implement onUpdate() support
- bsnes: implement Video::onUpdate() support to redraw Viewport icon
as needed
- bsnes: save RAM before ruby driver changes
- sfc/sa1: clip signed multiplication to 32-bit [Jonas Quinn]
- sfc/sa1: handle negative dividends in division [Jonas Quinn]
- hiro/gtk3: a few improvements
- bsnes: added empty stub video and audio settings panels
- bsnes: restructured advanced settings panel
- bsnes: experiment: input/hotkeys name column bolded and colored for
increased visual distinction
- bsnes: added save button to state manager
byuu says:
Changelog:
- hiro: added Qt5 support
- hiro: added GTK3 support (currently runs very poorly)
- bsnes: number of recent games and quick state slots can be changed
programmatically now
- I may expose this as a configuration file setting, but probably
not within the GUI
- nall: use -Wno-everything when compiling with Clang
- sorry, Clang's meaningless warning messages are just endless ...
byuu says:
Changelog:
- bsnes: cheat code “enabled” option changed to “enable”
- bsnes: connected “Cancel” action on add/edit cheat code window
- hiro: improved BrowserDialog::selectFolder() behavior
- can choose “Select” inside of a target folder when no items are
selected
- bsnes: implemented state manager
- bsnes: save a recovery state before loading a state, quitting, or
changing drivers
- bsnes: input settings, hotkey settings, cheat editor, state manager
entries are now batchable
- this allows bulk clearing/deleting of entries
- bsnes: cheat code list now auto-sorts alphabetically instead of
using up/down move arrows
I know most people will probably prefer to order cheat codes the way
they want, but the issue is that the state manager can't really work
this way. Each state is a file on disk. So yes, we could store a
states-manifest.bml to track the order of the states, or try to insert
numbers into the filenames and do bulk filesystem rename operations on
sorting, but then we would run into oddities when users delete state
files manually. And really, manual sorting is just clumsy. If you really
want a specific ordering, you can prefix cheats/states with numeric
indices instead.
byuu says:
Changelog:
- nall: renamed array to adaptive_array; marked it as deprecated
- nall: created new array class; which is properly static (ala
std::array) with optional bounds-checking
- sfc/ppu-fast: converted unmanaged arrays to use nall/array (no speed
penalty)
- bsnes: rewrote the cheat code editor to a new design
- nall: string class can stringify pointer types directly now, so
pointer() was removed
- nall: added array_view and pointer types (still unsure if/how I'll
use pointer)
byuu says:
Changelog:
- sfc/ppu-fast: fixed overscan crash
- sfc/ppu-fast: fixed direct color mode
- sfc: reconnected MSU1 support
- higan: game.sfc/msu1/data.rom, game.sfc/msu1/track-#.pcm
- bsnes: game.msu, game-#.pcm
- bsnes: added cheat code editor
- bsnes: added cheat code database support
- sfc/ppu-fast: clear overscan lines when overscan disabled
- sfc: output 223/239 lines instead of 224/240 lines
- bsnes: fix aspect correction calculation
- bsnes: crop line 224 when overscan masking is enabled
- bsnes: exposed Expansion Port menu; but hid “21fx” from the list of
devices
- bsnes: tools menu is hidden until a game is loaded
- ruby/input/keyboard/quartz: fixed compilation error
So only bsnes the automated overscan cropping option. In higan, you can
crop however many lines you like from the top or bottom of the image.
But for bsnes, it automatically eats sixteen lines. My view right now is
that if bsnes is meant to be the casual gaming emulator, that it should
eat line 224 in this mode. Most games show content here, but because of
the way the SNES PPU works, the very last line ends up on its very own
tile row (line 0 isn't rendered), if the scroll registers don't account
for it. There's a small number of games that will draw junk data to the
very last scanline of the frame as a result of this. So I chose, at
least for now, to hide it. Users can obviously disable overscan cropping
to see this scanline. I'm open to being convinced not to do this, if
someone has a compelling reason.
We're pretty much screwed one way or the other with no overscan masking.
If we output 239 lines, then most games will render 7 blank lines + 224
drawn lines + 8 blank lines, and the black top and bottom aren't
centered. But if we output 240 lines to get 8 + 224 + 8, then games that
do use overscan will have a blank line at the very bottom of the window.
I'm also trying out a modified cheat code file format. It's been forever
since I bothered to look at it, and the “cartridge” parent node doesn't
match what I'm doing with trying to rename “cartridge” to “game” in
manifests. And indeed, the idea of requiring a root node is rather
superfluous for a cheat code file. Current format looks like this:
cheat
description: foo
code: 7e2000=20+7e2001=30?40
enabled
cheat
description: bar
code: 7e4000=80
Open to discussing this, and I'd like to sync up with Snes9X before they
push out a new release, and I'll agree to finalize and never change this
format again.
I chose to use .cht for the extension when using game files (eg
gamename.cht)
Also, since byuu changes the defaults according to what he's working on, let's
be explicit tat higan gets the accuracy core and bsnes gets the performance
core.
byuu says:
Changelog:
- sfc/ppu-fast:
- don't use mosaicSize unless mosaicEnable is set
- fix background tiles that aren't 8x8 in size
- flush (render) queued lines whenever VRAM or OAM are modified
mid-frame
- queue tile outputs to buffer for object rendering final pass
- fix object window mask indexing
- disable color bleed when output width is 256 pixels
- handle reset(bool) events
- implemented save states
- icarus: fixed SPC7110-RAM-EPSONRTC mapping typo [hex_usr]
- bsnes: fixed overscan masking mode when output height is 240
Todo:
- sfc/ppu-fast: should not have deleted the tilecache freeing in
~PPU()
- ruby/input/carbon: change setPath() call to setPathID()
Errata:
- Rendering Ranger R2 crashes at startup, seems to be an issue with
the expansion port device
Bug reports on the new fast SNES PPU are now welcome.
byuu says:
Changelog:
- nall/GNUmakefile: added `openmp=(true,false)` option; can be toggled
when building higan/bsnes
- defaults to disabled on macOS, because Xcode doesn't stupidly
doesn't ship with support for it
- higan/GNUmakefile: forgot to switch target,profile back from
bsnes,fast to higan,accurate
- this is just gonna happen from time to time, sorry
- sfc/dsp: when using the fast profile, the DSP syncs per sample
instead of per clock
- should only negatively impact Koushien 2, but is a fairly
significant speedup otherwise
- sfc/ppc,ppu-fast: optimized the code a bit (ppu 130fps to 133fps)
- sfc/ppu-fast: basic vertical mosaic support (not accurate, but
should look okay hopefully)
- sfc/ppu-fast: added missing mode7 hflip support
- sfc/ppu-fast: added support to render at 256-width and/or 240-height
- gives a decent speed boost, and also allows all of the older
quark shaders to work nicely again
- it does violate the contract of Emulator::Interface, but oh
well, it works fine in the bsnes GUI
- sfc/ppu-fast: use cached CGRAM values for mode7 and sprites
- sfc/ppu-fast: use global range/time over flags in object rendering
- may not actually work as we intended since it's a race condition
even if it's only ORing the flags
- really don't want to have to make those variables atomic if I
don't have to
- sfc/ppu-fast: should fully support interlace and overscan modes now
- hiro/cocoa: updated macOS Gatekeeper disable support to work on
10.13+
- ruby: forgot to fix macOS input driver, sorry
- nall/GNUmakefile: if uname is present, then just default to rm
instead of del (fixes Msys)
Note: blur emulation option will break pretty badly in 256x240 output
mode. I'll fix it later.
byuu says:
Changelog:
- sfc/ppu-fast: everything other than vertical mosaic and interlace
support is in
Games are quite playable now, and you're welcome to try things out, but
please don't report bugs yet. It's still too early for that.
byuu says:
Changelog:
- sfc/ppu-fast: added a barebones background renderer; very incomplete
Right now, the 2bpp Mega Man X2 splash screen is rendering correctly,
but everything else looks really garbled. I'm thinking my tile cache
conversions from 4bpp to bitmap pixels is wrong, but I'm not seeing any
obvious issues.
If anyone wants to take a look at it, I'd appreciate it. The renderer is
mostly modeled after ppu-performance's.
byuu says:
Changelog:
- nall/GNUmakefile: fixed findstring parameter arguments [Screwtape]
- nall/Windows: always include -mthreads -lpthread for all
applications
- nall/memory: code restructuring
I really wanted to work on the new PPU today, but I thought I'd spend a
few minutes making some minor improvements to nall::memory, that was
five and a half hours ago. Now I have a 67KiB diff of changes. Sigh.
byuu says:
Changelog:
- sfc/ppu: collapsed folders to a single directory to match all other
emulated processors
- sfc/ppu-fast: implemented I/O registers
byuu says:
Changelog:
- SNES: started on skeleton of the new parallel PPU core
To build the new PPU core, set profile=fast via GNU make. The old core
is profile=accurate.
The names of the profiles, and the name of the folder for the fast PPU
are subject to change.
The new PPU core doesn't do anything but demonstrate the proof of
concept: every scanline, make a copy of all the PPU registers and CGRAM.
Share the VRAM and OAM. Batch render all scanlines at once using OpenMP
at the end of each frame and blit the result.
With no PPU core at all, bsnes runs 91% faster than with the accuracy
PPU (230fps vs 120fps.) That's the absolute theoretical best-case
scenario. With the skeleton in place, we're already around 220fps. It'll
go down more as the PPU line renderer starts to do real work. I don't
know where things will end up yet. I suppose we'll find out in time.
My own copy of TDM/GCC can't use OpenMP on Windows, so ... it won't
parallelize if you build with that. I'm going to have to switch to a
different MinGW distribution once this is complete, I suppose.
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:
- nall: added -static-libgcc -static-libstdc++ to Windows/GCC link
flags
- bsnes, higan: added program icons to main window when game isn't
loaded
- bsnes: improved recent games menu sorting
- bsnes: fixed multi-game recent game loading on Windows
- bsnes: completed path override support
- bsnes, higan: added screensaver suppression on Windows
- icarus: add 32K volatile RAM to SuperFX boards that report no RAM
(fixes Starfox)
- bsnes, higan: added automatic dependency generation [Talarubi]
- hiro/GTK: appending actions to menus restores enabled() state
- higan: use board node inside manifest.bml if it exists
- bsnes: added blur emulation and color emulation options to view menu
- ruby: upgraded input.sdl to SDL 2.0 (though it makes no functional
difference sadly)
- ruby: removed video.sdl (due to deprecating SDL 1.2)
- nall, ruby: improvements to HID class (generic vendor and product
IDs)
Errata:
- bsnes, higan: on Windows, Application::Windows::onScreenSaver needs
`[&]` lambda capture, not `[]`
- find it in presentation/presentation.cpp
byuu says:
Changelog:
- bsnes:
- added full input mapping support (multi-mapping, digital+analog
inputs, rumble, hotkeys, etc)
- can now load multi-part games (eg Super Game Boy) from the
command-line
- added recent games menu with list clear function; supports
multi-part games (sorting logic incomplete)
- added automatic binding of gamepads on new configuration files
- added view scaling support with aspect correction, overscan
cropping, and integral scaling modes
- added video shader support
- added status bar (can be hidden)
- added save states (both menu and hotkeys)
- added fullscreen mode support
- added support for loading compressed (ZIP) archives for any
supported media type (SNES, GB, etc)
- added frame counter
- added auto-memory saving
- added pause / block-input modes when main window loses focus
- added --fullscreen command-line option to start bsnes in
fullscreen mode
- added input settings panel
- added hotkeys settings panel
- added path settings panel (paths aren't actually used set, but
can be assigned)
- higan: fixed macOS install rule [Sintendo]
- higan: minor UI code cleanups
- nall: renamed Processor to Architecture to fix macOS builds
[Sintendo]
Yeah, you read right: recent games menu, path settings. And dynamic rate
control + screensaver suppression is on the todo list. I'm not fucking
around this time. I really want to make something special here.
byuu says:
Changelog:
* yes.
But seriously, a list of changes on a pre-alpha GUI is going to get annoying.
Basically, work on embedding stuff in the binary, firmware loading (both
appended to the ROM and in a firmware/ subfolder) added, SGB games can be
loaded, config file holds more values for driver settings, added ruby drivers to
other platforms, etc.
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
byuu says:
Changelog:
- higan: target-tomoko has been renamed to target-higan
- Super Famicom: event has been renamed to
processor(architecture=uPD78214)
- Super Famicom: SNES-EVENT supported once more; under board IDs
EVENT-CC92 and EVENT-PF94
- Super Famicom: SNES-EVENT preliminarily set up to use DIP switch
settings ala the Nintendo Super System (incomplete)
- Super Famicom: MCC PSRAM moved inside the MCU, as it is remappable
- Super Famicom: MCC emulation rewritten from scratch; it is now
vastly more accurate than before
- Super Famicom: added BSC-1A5B9P-01 board definition to database;
corrected BS-MCC-RAM board definition
- Super Famicom: moved SHVC-LN3B-01 RAM outside of
processor(identifier=SDD1)
- higan: when selecting a default game to load for a new system entry,
it will change the system option to match the media type
- higan: the load text box on the system entry window is now editable;
can be used to erase entries
- icarus: fixed bug in Famicom importing
- icarus: importing unappended SNES coprocessor firmware will now
rename the firmware properly
- hiro/GTK,Qt: WM_CLASS is now set correctly in `argv[0]`, so
applications should show “higan”, “icarus” instead of “hiro” now
Note: if you wish to run the BS-X town cartridge, the database currently
lists the download RAM as type “PSRAM”. This needs to be changed to
“RAM” in order to load properly. Otherwise, the emulator will bomb
out on the load window, because BSC-1A5B9P-01 expects PSRAM to always be
present, but it won't find it with the wrong memory type. I'll correct
this in the database in a later release. For now, you can copy the game
portion of the manifest to a new manifest.bml file and drop it into the
gamepak folder until I fix the database.
byuu says:
Changelog:
- Super Famicom: fixed loading of BS Memory and Sufami Turbo
cartridges
- Super Famicom: renamed NSS to DIP; as that's really all it is, it's
not true NSS emulation
- Super Famicom: slot loading now happens inside of board parsing
instead of generically in loadCartridge()
- Super Famicom: BS-X cartridges with flash memory now serialize their
data and write it out to disk¹
- icarus: fixed Famicom game importing (hopefully) and set file import
title to “Load ROM File”
¹: there's no emulation of write commands yet, so the data is never
going to change anyway. This is just in preparation for more advanced
emulation of BS Memory cartridges.
byuu says:
Changelog:
- Super Famicom: everything outside of Nintendo Super System, Campus
Challenge '92 and Powerfest '94 should play
- Super Famicom: removed RAM from coprocessor/event (should use global
RAM)
- Super Famicom: removed RAM from SDD1 (should use global RAM)
- icarus: fixed Super Famicom game importing [hex_usr]
Also worth reminding that you'll need to disable database lookup in
order to run the BS-X Town cartridge right now. Plus, Star Ocean's
database entry still has the RAM in the wrong spot. The MSU1 code is not
looking at the right locations for data, so it's not going to work in
this release either.
I need to figure out what to call coprocessor/event and coprocessor/nss,
as neither are slots or processors like everything else.
Outside of those issues, all games for all systems should be playable,
at least to the extent they were in v106.
byuu says:
Changelog:
- major restructuring of board manifests
- cleanup of generic board names
- Super Famicom: updates to SA1, SuperFX, Cx4, SPC7110, EpsonRTC,
SharpRTC load/save code
- Super Famicom: added experimental SuperFX plot dithering fix
[qwertymodo]
- higan, icarus: rename shared folders to lowercase names; put .sys
folders into new subfolder
- Video Shaders/ → shaders/
- Database/ → database/
- Firmware/ → firmware/
- \*.sys/ → systems/\*.sys/
So right now, only standard SNES games, SA-1, SuperFX, and Cx4 games
load. I have not tested SPC7110 or RTC support, because icarus import
seems to be completely broken? It's creating blank folders when I try it
now. I'll have to fix that ...
Since we are now up to thirteen systems, I've put the .sys folders into
a subfolder. This should declutter the main higan-windows release folder
a good deal. Linux users will need to re-run make install, or manually
move things into a new systems/ subfolder.
Same goes for icarus: lowercase the database/ and firmware/ folders or
re-run make install.
I don't know if qwertymodo's SuperFX fix is exactly correct or not.
Hopefully it is, but I didn't write a test ROM or anything to be
certain. Since SuperFX games should run, if people could please play
through some of them and look for any regressions, that'd be very much
appreciated.
byuu says:
Changelog:
- tomoko: the library menu is now called the systems menu (even in
code)
- tomoko: added icons to menus (disambiguates systems menu entries)
- icarus: added missing .ws, .wsc extensions to scan dialog search
list
- higan: added Benesse - Pocket Challenge V2 emulation¹
¹: the Benesse - Pocket Challenge V2 is a WonderSwan (ASWAN) SoC
inside a custom designed shell. Games made for the WonderSwan (mostly)
run on the Pocket Challenge V2 and vice versa. The big difference is
that the Benesse has a different number of input buttons, that are also
named differently. Of course, right now, I don't know what the buttons
are named or where they're mapped on the 16-input keypad matrix I/O
port. It's also possible that the internal EEPROM doesn't exist, it
definitely has a unique (and also undumped) IPLROM, and other things.
The ROMs have their own .pc2 file extension. So it's getting its own
system entry.
What I'm going to do for v107 and above is utilize the new systems
configuration to mark the Benesse as hidden by default from the main
menu. I don't think anyone in the world will actually care or want to
play this, but there was really no reason not to add it.
byuu says:
Changelog:
- main menu renamed again (Library→System→Systems)
- the 'Hidden' checkbox on system properties was moved to the main
list as a 'Show' checkbox instead
- the move up/move down buttons on the systems panel now function
- added icons to indicate 'system' versus 'game boot' entries in the
systems list
I still didn't add ComboEdit to the Windows hiro port, so once again
this will be Linux/BSD only.
I polished the browse button for selecting a boot game. It'll use a list
of all bootable media file extensions, so that if you double-click any
supported game, it'll select it instead of going inside the folder. If
you pick a non-bootable folder, like say a Sufami Turbo cartridge, it
will go inside the folder instead, because it will treat it like any
other regular folder.
Having a checkbox next to text in the same cell doesn't work so well on
lists that have an onActivate action. Say you tried to double-click the
“Name” field on the Systems tab, it would toggle the checkbox twice
before popping open the system properties editor window. So because of
this, I made the show checkbox its own column. And for consistency, I
did the same for the slot# on the cheat editor window.
As a bit of really pedantic polish: if there are no systems enabled,
then the main menu won't show the separator before the “Load ROM Image”
option anymore.
I think something is wrong with the Markup::Node::insert syntax, but I
realized I have Markup::Node::swap, and just used that for the up/down
arrows on the systems panel for now. But we should probably fix insert()
at some point ... sigh.
byuu says:
Changelog:
- Super Game Boy: fixed loading of boot ROM
- hiro: added ComboEdit::setEditable(bool = true);
- tomoko: added new systems settings panel
Note!!: this release will not compile on Windows or macOS due to the
missing ComboEdit control! I'll try to merge in hex's implementation
for the Windows release here soon. macOS users will probably be out of
luck for a while, sorry.
The new systems panel is an idea I've been meaning to implement for
quite a while, but finally got around to starting on it. It's still
fairly unpolished, but the basic idea is there for Linux/BSD users to
try out now.
So imagine the Super Game Boy, BS-X Satellaview, Sufami Turbo, and the
associated BS Memory Pack-slotted SNES cartridges. To play any of those,
you needed to choose Nintendo→Super Famicom, and then select the
relevant cartridge, and then select any slotted cartridges to play with
it.
This was acceptable-ish, if not ideal. But now imagine in the future if
we wanted to support the Famicom Disk System, which is technically a
cartridge that plugs into the Famicom deck. Or the PC Engine CD, which
has one of three special HuCards that must be inserted (ignoring the
Turbo Duo where it's built-in—I'm going to be emulating the Super CD
as if you're using a stock PCE CD.) Or the Mega CD, where there are
probably a half dozen or more BIOS + hardware revisions that are
region-specific, which connect to an expansion port that is identical to
the cartridge port save for the Mega Drive seeing an I/O register bit
toggled here.
In all of these cases, it's going to be a real pain to have to choose
the 'BIOS' every time you want to play a game for them.
I can't distribute these BIOSes with higan due to copyright
restrictions, and trying to ship dummy folders for every possible
combination would become quite odious, and difficult for people to use
(compare to setting up the Game Boy Advance system BIOS.)
And so I've created the new systems settings panel. Here, you can manage
a list of systems that show up under the higan library menu (now renamed
to “System”), where each entry contains name, boot, and hidden
parameters.
The name parameter is what shows up in the system menu. You can call any
system higan emulates whatever you like here. Don't like “Super
Famicom”? Change it to “SNES”, then.
The boot parameter is a combo edit with a dropdown for all of the
systems higan emulates. If you choose one of these, then the higan
system menu option will work exactly like in previous releases, and
prompt you for a cartridge. But if you choose the browse button next to
the combo edit control, you'll get to pick any gamepak from the higan
library of your choosing.
So you could choose the SGB2 BIOS, and name the menu option “Super Game
Boy 2”, and when you choose the menu option, it will load the SFC core,
load the SGB2 BIOS, and only prompt you for the Game Boy game you wish
to play on it. The same deal goes for the FDS, PCE-CD, Mega CD, Mega
Drive Sonic & Knuckles lock-on cartridge, BS-X Satellaview, SD Gundam
G-Next, etc. Whatever you want to be in the menu, you can put in there
by pointing higan at the appropriate 'BIOS' gamepak to load.
Astute readers have probably already noticed, but you can technically
use this on non-slotted games as well, thus creating instant boot
options for your absolute favorite games, if you so wanted. Point it at
Zelda 3, and you can boot it instantly from the main menu, without any
need for file selection.
The hidden option is a way to hide the system entries from the system
menu. Primarily this would be a fast way for users to disable emulation
cores they never use in higan, without having to remove the options.
The major concession with this change is the collapsing of the
per-manufacturer submenus. What this means is you will now have all
twelve higan emulated systems in the main menu by default. This makes
the list rather long, but ... oh well. I may try to offer some form of
grouping in the future, but the grouping defeats the “list order =
display order” design, and I'm not willing to auto-sort the list. I want
people to be able to control the ordering of the system menu, and have
added (as yet non-functional) sorting arrows for that purpose. I also
don't have a combined tree+table view widget in higan to try to and
group things. But ... we'll see how things go in the future.
Another idea is to add a specialty load option that opens up the user's
Emulation library path, and lets you pick a gamepak for any system,
which would boot the same way as when you drop a gamepak onto the higan
executable or main window. So say you almost never play Wonderswan
games, this would be a way to play them without them cluttering your
system menu list.
The “import ROM files” option has been removed. All it does is launch
icarus directly. I would rather users become familiar with using icarus.
The “load ROM file” option remains.
Anyway, this is all still a work in progress, so please give it time and
don't overload me with too many suggested changes right now, thanks :3
byuu says:
Changelog:
- game/memory/type/battery → game/memory/volatile
- (manufacturer.)content.type → (architecture.)content.type
- nall: Markup::find() strips spaces from values in comparisons
- higan: updated game manifest loading/saving code for all cores
- GBA: flash memory ID is internally selected based on the
manufacturer and memory size
- SFC: ST018 (ARM6) frequency can be modified via game manifest now
- WS: EEPROM::name removed (not useful)
- icarus, genius: battery→volatile updates
I did my best to look over the diff between r13 and r14, but it's 84KiB
excluding the game database changes. It's just too much for me. I'd
greatly appreciate if someone could look over it and check for any
errors in this update. But more than likely, I suppose we'll iron out
any issues by determining which games fail to load.
Right now, I know the Super Game Boy support doesn't seem to work. But
all non-SFC cores should work fully, and all normal + NEC DSP SFC games
should work as well. Unsure about the rest.
Also, I'm planning to change the Game Boy “MBC1M” mapper to “MBC1#A” to
indicate it's an alternate wiring configuration of the stock MBC1, and
not a new mapper type.
byuu says:
Changelog:
- game/memory/category → game/memory/content
- game/memory/model → game/memory/architecture
- game/memory/identity → game/memory/identifier
- Super Famicom: memory/content=Bitmap → memory/content=Save
- Super Famicom: memory/architecture=DMG,MGB →
memory/architecture=LR35902
The game manifest field names are now officially set in stone. I won't
change them again, I'll only add new fields if required.
As for the values in the field, I'm still undecided on the manufacturer
of the ST018, and I could be talked into different identifiers for the
Super Game Boy (SGB1/SGB2, DMG/MGB, or just ICD(2)?)
The board manifest format is still in flux, as is the choice of what to
name firmware files (it's between manufacturer and architecture, where
I'm leaning toward the latter currently.)
Board memory to Game memory mappings will require both the manufacturer
and architecture fields to match.
I'll be updating doc.byuu.org soon with the finalized game manifest
format.
Tim Allen