mirror of https://github.com/bsnes-emu/bsnes.git
5 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
Tim Allen
|
e39987a3e3 |
Update to v101 release.
byuu says (in the public announcement):
Not a large changelog this time, sorry. This release is mostly to fix
the SA-1 issue, and to get some real-world testing of the new scheduler
model. Most of the work in the past month has gone into writing a 68000
CPU core; yet it's still only about half-way finished.
Changelog (since the previous release):
- fixed SNES SA-1 IRQ regression (fixes Super Mario RPG level-up
screen)
- new scheduler for all emulator cores (precision of 2^-127)
- icarus database adds nine new SNES games
- added Input/Frequency to settings file (allows simulation of
latency)
byuu says (in the WIP forum):
Changelog:
- in 32-bit mode, Thread uses uint64\_t with 2^-63 time units (10^-7
precision in the worst case)
- nearly ten times the precision of an attosecond
- in 64-bit mode, Thread uses uint128\_t with 2^-127 time units
(10^-26 precision in the worst case)
- far more accurate than yoctoseconds; almost closing in on planck
time
Note: a quartz crystal is accurate to 10^-4 or 10^-5. A cesium fountain
atomic clock is accurate to 10^-15. So ... yeah. 2^-63 was perfectly
fine; but there was no speed penalty whatsoever for using uint128\_t in
64-bit mode, so why not?
|
|
|
Tim Allen
|
07995c05a5 |
Update to v100 release.
byuu says:
higan has finally reached v100!
I feel it's important to stress right away that this is not "version
1.00", nor is it a major milestone release. Rather than arbitrary version
numbers, all of my software simply bumps version numbers by one for each
official release. As such, higan v100 is simply higan's 100th release.
That said, the primary focus of this release has been code
clean-ups. These are always somewhat dangerous in that regressions are
possible. We've tested through sixteen WIP revisions, one of which was
open to the public, to try and minimize any regressions. But all the same,
please report any regressions if you discover any.
Changelog (since v099):
FC: render during pixels 1-256 instead of 0-255 [hex_usr]
FC: rewrote controller emulation code
SFC: 8% speedup over the previous release thanks to PPU optimizations
SFC: fixed nasty DB address wrapping regression from v099
SFC: USART developer controller removed; superseded by 21fx
SFC: Super Multitap option removed from controller port 1; ports
renamed 2-5
SFC: hidden option to experiment with 128KB VRAM (strictly for novelty)
higan: audio volume no longer divided by number of audio streams
higan: updated controller polling code to fix possible future mapping
issues
higan: replaced nall/stream with nall/vfs for file-loading subsystem
tomoko: can now load multi-slotted games via command-line
tomoko: synchronize video removed from UI; still available in the
settings file
tomoko, icarus: can navigate to root drive selection on Windows
all: major code cleanups and refactoring (~1MB diff against v099)
Note 1: the audio volume change means that SGB and MSU1 games won't
lose half the volume on the SNES sounds anymore. However, if one goes
overboard and drives the sound all the way to max volume with the MSU1,
clamping may occur. The obvious solution is not to drive volume that high
(it will vastly overpower the SNES audio, which usually never exceeds
25% volume.) Another option is to lower the volume in the audio settings
panel to 50%. In general, neither is likely to ever be necessary.
Note 2: the synchronize video option was hidden from the UI because it
is no longer useful. With the advent of compositors, the loss of the
complicated timing settings panel, support for the WonderSwan and its
75hz display, the need to emulate variable refresh rate behaviors in the
Game Boy, the unfortunate latency spike and audio distortion caused by
long Vsync pauses, and the arrival of adaptive sync technology ... it
no longer makes sense to present this option. However, as stated, you
can edit settings.bml to enable this option anyway if you insist and
understand the aforementioned risks.
Changelog (since v099r16 open beta):
- fixed MSU1 audio sign extension
- fixed compilation with SGB support disabled
- icarus can now navigate to root directory
- fixed compilation issues with OS X port
- (hopefully) fixed label height issue with hiro that affected icarus
import dialog
- (mostly) fixed BS Memory, Sufami Turbo slot loading
Errata:
- forgot to remove the " - Slot A", " - Slot B" suffixes for Sufami
Turbo slot loading
- this means you have to navigate up one folder and then into Sufami
Turbo/ to load games for this system
- moving WonderSwan orientation controls to the device slot is causing
some nastiness
- can now select orientation from the main menu, but it doesn't rotate
the display
|
|
|
Tim Allen
|
4344b916b6 |
Update to v094r40 release.
byuu says: Changelog: - updated to newest hiro API - SFC performance profile builds once again - hiro: Qt port completed Errata 1: the hiro/Qt target won't run tomoko just yet. Starts by crashing inside InputSettings because hiro/Qt isn't forcefully selecting the first item added to a ComboButton just yet. Even with a monkey patch to get around that, the UI is incredibly unstable. Lots of geometry calculation bugs, and a crash when you try and access certain folders in the browser dialog. Lots of work left to be done there, sadly. Errata 2: the hiro/Windows port has black backgrounds on all ListView items. It's because I need to test for unassigned colors and grab the default Windows brush colors in those cases. Note: alternating row colors on multi-column ListView widgets is gone now. Not a bug. May add it back later, but I'm not sure. It doesn't interact nicely with per-cell background colors. Things left to do: First, I have to fix the Windows and Qt target bugs. Next, I need to go through and revise the hiro API even more (nothing too major.) Next, I need to update icarus to use the new hiro API, and add support for the SFC games database. Next, I have to rewrite my TSV->BML cheat code tool. Next, I need to post a final WIP of higan+icarus publicly and wait a few days. Next, I need to fix any bugs reported from the final WIP that I can. Finally, I should be able to release v095. |
|
|
Tim Allen
|
f0c17ffc0d |
Update to v094r24 release.
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. |
|
|
Tim Allen
|
a512d14628 |
Update to v094r09 release.
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. |