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.
