mirror of https://github.com/bsnes-emu/bsnes.git
11 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
Tim Allen
|
cbbf5ec114 |
Update to v103r10 release.
byuu says:
Changelog:
- tomoko: video scaling options are now resolutions in the
configuration file, eg "640x480", "960x720", "1280x960"
- tomoko: main window is now always resizable instead of fixed width
(also supports maximizing)
- tomoko: added support for non-integral scaling in windowed mode
- tomoko: made the quick/managed state messaging more consistent
- tomoko: hide "Find Codes ..." button from the cheat editor window if
the cheat database is not present
- tomoko: per-game cheats.bml file now goes into the higan/ subfolder
instead of the root folder
So the way the new video system works is you have the following options
on the video settings panel:
Windowed mode: { Aspect correction, Integral scaling, Adaptive }
Fullscreen mode: { Aspect correction, Integral scaling } (and one day,
hopefully Exclusive will be added here)
Whenever you adjust the overscan masking, or you change any of the
windowed or fullscreen mode settings, or you choose a different video
scale from the main menu, or you load a new game, or you unload a game,
or you rotate the display of an emulated system, the resizeViewport
logic will be invoked. This logic will remember the last option you
chose for video scale, and base the new window size on that value as an
upper limit of the new window size.
If you are in windowed mode and have adaptive enabled, it will shrink
the window to fit the contents of the emulated system's video output.
Otherwise, if you are not in integral scaling mode, it will scale the
video as large as possible to fit into the video scaled size you have
selected. Otherwise, it will perform an integral scale and center the
video inside of the viewport.
If you are in fullscreen mode, it's much the same, only there is no
adaptive mode.
A major problem with Xorg is that it's basically impossible to change
the resizability attribute of a window post-creation. You can do it, but
all kinds of crazy issues start popping up. Like if you toggle
fullscreen, then you'll find that the window won't grow past a certain
fairly small size that it's already at, and cannot be shrunk. And the
multipliers will stop expanding the window as large as they should. And
sometimes the UI elements won't be placed in the correct position, or
the video will draw over them. It's a big mess. So I have to keep the
main window always resizable. Also, note that this is not a limitation
of hiro. It's just totally broken in Xorg itself. No amount of fiddling
has ever allowed this to work reliably for me on either GTK+ 2 or Qt 4.
So what this means is ... the adaptive mode window is also resizable.
What happens here is, whenever you drag the corners of the main window
to resize it, or toggle the maximize window button, higan will bypass
the video scale resizing code and instead act as though the adaptive
scaling mode were disabled. So if integral scaling is checked, it'll
begin scaling in integral mode. Otherwise, it'll begin scaling in
non-integral mode.
And because of this flexibility, it no longer made sense for the video
scale menu to be a radio box. I know, it sucks to not see what the
active selection is anymore, but ... say you set the scale to small,
then you accidentally resized the window a little, but want it snapped
back to the proper small resolution dimensions. If it were a radio item,
you couldn't reselect the same option again, because it's already active
and events don't propagate in said case. By turning them into regular
menu options, the video scale menu can be used to restore window sizing.
Errata:
On Windows, the main window blinks a few times on first load. The fix
for that is a safeguard in the video settings code, roughly like so ...
but note you'd need to make a few other changes for this to work against
v103r10:
auto VideoSettings::updateViewport(bool firstRun) -> void {
settings["Video/Overscan/Horizontal"].setValue(horizontalMaskSlider.position());
settings["Video/Overscan/Vertical"].setValue(verticalMaskSlider.position());
settings["Video/Windowed/AspectCorrection"].setValue(windowedModeAspectCorrection.checked());
settings["Video/Windowed/IntegralScaling"].setValue(windowedModeIntegralScaling.checked());
settings["Video/Windowed/AdaptiveSizing"].setValue(windowedModeAdaptiveSizing.checked());
settings["Video/Fullscreen/AspectCorrection"].setValue(fullscreenModeAspectCorrection.checked());
settings["Video/Fullscreen/IntegralScaling"].setValue(fullscreenModeIntegralScaling.checked());
horizontalMaskValue.setText({horizontalMaskSlider.position()});
verticalMaskValue.setText({verticalMaskSlider.position()});
if(!firstRun) presentation->resizeViewport();
}
That'll get it down to one blink, as with v103 official. Not sure I can
eliminate that one extra blink.
I forgot to remove the setResizable toggle on fullscreen mode exit. On
Windows, the main window will end up unresizable after toggling
fullscreen. I missed that one because like I said, toggling resizability
is totally broken on Xorg. You can fix that with the below change:
auto Presentation::toggleFullScreen() -> void {
if(!fullScreen()) {
menuBar.setVisible(false);
statusBar.setVisible(false);
//setResizable(true);
setFullScreen(true);
if(!input->acquired()) input->acquire();
} else {
if(input->acquired()) input->release();
setFullScreen(false);
//setResizable(false);
menuBar.setVisible(true);
statusBar.setVisible(settings["UserInterface/ShowStatusBar"].boolean());
}
resizeViewport();
}
Windows is stealing focus on calls to resizeViewport(), so we need to
deal with that somehow ...
I'm not really concerned about the behavior of shrinking the viewport
below the smallest multiplier for a given system. It might make sense to
snap it to the window size and forego all other scaling, but honestly
... meh. I don't really care. Nobody sane is going to play like that.
|
|
|
Tim Allen
|
8d5cc0c35e |
Update to v099r15 release.
byuu says:
Changelog:
- nall::lstring -> nall::string_vector
- added IntegerBitField<type, lo, hi> -- hopefully it works correctly...
- Multitap 1-4 -> Super Multitap 2-5
- fixed SFC PPU CGRAM read regression
- huge amounts of SFC PPU IO register cleanups -- .bits really is lovely
- re-added the read/write(VRAM,OAM,CGRAM) helpers for the SFC PPU
- but they're now optimized to the realities of the PPU (16-bit data
sizes / no address parameter / where appropriate)
- basically used to get the active-display overrides in a unified place;
but also reduces duplicate code in (read,write)IO
|
|
|
Tim Allen
|
3a9c7c6843 |
Update to v099r09 release.
byuu says:
Changelog:
- Emulator::Interface::Medium::bootable removed
- Emulator::Interface::load(bool required) argument removed
[File::Required makes no sense on a folder]
- Super Famicom.sys now has user-configurable properties (CPU,PPU1,PPU2
version; PPU1 VRAM size, Region override)
- old nall/property removed completely
- volatile flags supported on coprocessor RAM files now (still not in
icarus, though)
- (hopefully) fixed SNES Multitap support (needs testing)
- fixed an OAM tiledata range clipping limit in 128KiB VRAM mode (doesn't
fix Yoshi's Island, sadly)
- (hopefully, again) fixed the input polling bug hex_usr reported
- re-added dialog box for when File::Required files are missing
- really cool: if you're missing a boot ROM, BIOS ROM, or IPL ROM,
it warns you immediately
- you don't have to select a game before seeing the error message
anymore
- fixed cheats.bml load/save location
|
|
|
Tim Allen
|
f48b332c83 |
Update to v099r08 release.
byuu says:
Changelog:
- nall/vfs work 100% completed; even SGB games load now
- emulation cores now call load() for the base cartridges as well
- updated port/device handling; portmask is gone; device ID bug should
be resolved now
- SNES controller port 1 multitap option was removed
- added support for 128KiB SNES PPU VRAM (for now, edit sfc/ppu/ppu.hpp
VRAM::size=0x10000; to enable)
Overall, nall/vfs was a huge success!! We've substantially reduced
the amount of boilerplate code everywhere, while still allowing (even
easier than before) support for RAM-based game loading/saving. All of
nall/stream is dead and buried.
I am considering removing Emulator::Interface::Medium::id and/or
bootable flag. Or at least, doing something different with it. The
values for the non-bootable GB/BS/ST entries duplicate the ID that is
supposed to be unique. They are for GB/GBC and WS/WSC. Maybe I'll use
this as the hardware revision selection ID, and then gut non-bootable
options. There's really no reason for that to be there. I think at one
point I was using it to generate library tabs for non-bootable systems,
but we don't do that anymore anyway.
Emulator::Interface::load() may not need the required flag anymore ... it
doesn't really do anything right now anyway.
I have a few reasons for having the cores load the base cartridge. Most
importantly, it is going to enable a special mode for the WonderSwan /
WonderSwan Color in the future. If we ever get the IPLROMs dumped ... it's
possible to boot these systems with no games inserted to set user profile
information and such. There are also other systems that may accept being
booted without a cartridge. To reach this state, you would load a game and
then cancel the load dialog. Right now, this results in games not loading.
The second reason is this prevents nasty crashes when loading fails. So
if you're missing a required manifest, the emulator won't die a violent
death anymore. It's able to back out at any point.
The third reason is consistency: loading the base cartridge works the
same as the slot cartridges.
The fourth reason is Emulator::Interface::open(uint pathID)
values. Before, the GB, SB, GBC modes were IDs 1,2,3 respectively. This
complicated things because you had to pass the correct ID. But now
instead, Emulator::Interface::load() returns maybe<uint> that is nothing
when no game is selected, and a pathID for a valid game. And now open()
can take this ID to access this game's folder contents.
The downside, which is temporary, is that command-line loading is
currently broken. But I do intend on restoring it. In fact, I want to do
better than before and allow multi-cart booting from the command-line by
specifying the base cartridge and then slot cartridges. The idea should
be pretty simple: keep a queue of pending filenames that we fill from
the command-line and/or drag-and-drop operations on the main window,
and then empty out the queue or prompt for load dialogs from the UI
when booting a system. This also might be a bit more unorthodox compared
to the traditional emulator design of "loadGame(filename)", but ... oh
well. It's easy enough still.
The port/device changes are fun. We simplified things quite a bit. The
portmask stuff is gone entirely. While ports and devices keep IDs,
this is really just sugar-coating so UIs can use for(auto& port :
emulator->ports) and access port.id; rather than having to use for(auto
n : range(emulator->ports)) { auto& port = emulator->ports[n]; ... };
but they should otherwise generally be identical to the order they appear
in their respective ranges. Still, don't rely on that.
Input::id is gone. There was no point since we also got rid of the nasty
Input::order vector. Since I was in here, I went ahead and caved on the
pedantics and renamed Input::guid to Input::userData.
I removed the SNES controller port 1 multitap option. Basically, the only
game that uses this is N-warp Daisakusen and, no offense to d4s, it's
not really a good game anyway. It's just a quick demo to show 8-players
on the SNES. But in the UI, all it does is confuse people into wasting
time mapping a controller they're never going to use, and they're going
to wonder which port to use. If more compelling use cases for 8-players
comes about, we can reconsider this. I left all the code to support this
in place, so all you have to do is uncomment one line to enable it again.
We now have dsnes emulation! :D
If you change PPU::VRAM::size to 0x10000 (words), then you should now
have 128KiB of VRAM. Even better, it serializes the used-VRAM size,
so your save states shouldn't crash on you if you swap between the two
(though if you try this, you're nuts.)
Note that this option does break commercial software. Yoshi's Island in
particular. This game is setting A15 on some PPU register writes, but
not on others. The end result of this is things break horribly in-game.
Also, this option is causing a very tiny speed hit for obvious reasons
with the variable masking value (I'm even using size-1 for now.) Given
how niche this is, I may just leave it a compile-time constant to avoid
the overhead cost. Otherwise, if we keep the option, then it'll go into
Super Famicom.sys/manifest.bml ... I'll flesh that out in the near-future.
----
Finally, some fun for my OCD ... my monitor suddenly cut out on me
in the middle of working on this WIP, about six hours in of non-stop
work. Had to hit a bunch of ctrl+alt+fN commands (among other things)
and trying to log in headless on another TTY to do issue commands,
trying to recover the display. Finally power cycled the monitor and it
came back up. So all my typing ended up going to who knows where.
Usually this sort of thing terrifies me enough that I scrap a WIP and
start over to ensure I didn't screw anything up during the crashed screen
when hitting keys randomly.
Obviously, everything compiles and appears to work fine. And I know
it's extremely paranoid, but OCD isn't logical, so ... I'm going
to go over every line of the 100KiB r07->r08 diff looking for any
corruption/errors/whatever.
----
Review finished.
r08 diff review notes:
- fc/controller/gamepad/gamepad.cpp:
use uint device = ID::Device::Gamepad; not id = ...;
- gb/cartridge/cartridge.hpp:
remove redundant uint _pathID; (in Information::pathID already)
- gb/cartridge/cartridge.hpp:
pull sha256 inside Information
- sfc/cartridge/load/cpp:
add " - Slot (A,B)" to interface->load("Sufami Turbo"); to be more
descriptive
- sfc/controller/gamepad/gamepad.cpp:
use uint device = ID::Device::Gamepad; not id = ...;
- sfc/interface/interface.cpp:
remove n variable from the Multitap device input generation loop
(now unused)
- sfc/interface/interface.hpp:
put struct Port above struct Device like the other classes
- ui-tomoko:
cheats.bml is reading from/writing to mediumPaths(0) [system folder
instead of game folder]
- ui-tomoko:
instead of mediumPaths(1) - call emulator->metadataPathID() or something
like that
|
|
|
Tim Allen
|
6ae0abe3d3 |
Update to v098r09 release.
byuu says: Changelog: - fixed major nall/vector/prepend bug - renamed hiro/ListView to hiro/TableView - added new hiro/ListView control which is a simplified abstraction of hiro/TableView - updated higan's cheat database window and icarus' scan dialog to use the new ListView control - compilation works once again on all platforms (Windows, Cocoa, GTK, Qt) - the loki skeleton compiles once again (removed nall/DSP references; updated port/device ID names) Small catch: need to capture layout resize events internally in Windows to call resizeColumns. For now, just resize the icarus window to get it to use the full window width for list view items. |
|
|
Tim Allen
|
ef65bb862a |
Update to 20160215 release.
byuu says: Got it. Wow, that didn't hurt nearly as much as I thought it was going to. Dropped from 127.5fps to 123.5fps to use Natural/Integer for (u)int(8,16,32,64). That's totally worth the cost. |
|
|
Tim Allen
|
344e63d928 |
Update to v097r02 release.
byuu says:
Note: balanced/performance profiles still broken, sorry.
Changelog:
- added nall/GNUmakefile unique() function; used on linking phase of
higan
- added nall/unique_pointer
- target-tomoko and {System}::Video updated to use
unique_pointer<ClassName> instead of ClassName* [1]
- locate() updated to search multiple paths [2]
- GB: pass gekkio's if_ie_registers and boot_hwio-G test ROMs
- FC, GB, GBA: merge video/ into the PPU cores
- ruby: fixed ~AudioXAudio2() typo
[1] I expected this to cause new crashes on exit due to changing the
order of destruction of objects (and deleting things that weren't
deleted before), but ... so far, so good. I guess we'll see what crops
up, especially on OS X (which is already crashing for unknown reasons on
exit.)
[2] right now, the search paths are: programpath(), {configpath(),
"higan/"}, {localpath(), "higan/"}; but we can add as many more as we
want, and we can also add platform-specific versions.
|
|
|
Tim Allen
|
cec33c1d0f |
Update to v096r07 release.
byuu says: Changelog: - configuration files are now stored in localpath() instead of configpath() - Video gamma/saturation/luminance sliders are gone now, sorry - added Video Filter->Blur Emulation [1] - added Video Filter->Scanline Emulation [2] - improvements to GBA audio emulation (fixes Minish Cap) [Jonas Quinn] [1] For the Famicom, this does nothing. For the Super Famicom, this performs horizontal blending for proper pseudo-hires translucency. For the Game Boy, Game Boy Color, and Game Boy Advance, this performs interframe blending (each frame is the average of the current and previous frame), which is important for things like the GBVideoPlayer. [2] Right now, this only applies to the Super Famicom, but it'll come to the Famicom in the future. For the Super Famicom, this option doesn't just add scanlines, it simulates the phosphor decay that's visible in interlace mode. If you observe an interlaced game like RPM Racing on a real SNES, you'll notice that even on perfectly still screens, the image appears to shake. This option emulates that effect. Note 1: the buffering right now is a little sub-optimal, so there will be a slight speed hit with this new support. Since the core is now generating native ARGB8888 colors, it might as well call out to the interface to lock/unlock/refresh the video, that way it can render directly to the screen. Although ... that might not be such a hot idea, since the GBx interframe blending reads from the target buffer, and that tends to be a catastrophic option for performance. Note 2: the balanced and performance profiles for the SNES are completely busted again. This WIP took 6 1/2 hours, and I'm exhausted. Very much not looking forward to working on those, since those two have all kinds of fucked up speedup tricks for non-interlaced and/or non-hires video modes. Note 3: if you're on Windows and you saved your system folders somewhere else, now'd be a good time to move them to %localappdata%/higan |
|
|
Tim Allen
|
653bb378ee |
Update to v096r03 release.
byuu says: Changelog: - fixed icarus to save settings properly - fixed higan's full screen toggle on OS X - increased "Add Codes" button width to avoid text clipping - implemented cocoa/canvas.cpp - added 1s delay after mapping inputs before re-enabling the window (wasn't actually necessary, but already added it) - fixed setEnabled(false) on Cocoa's ListView and TextEdit widgets - updated nall::programpath() to use GetModuleFileName on Windows - GB: system uses open collector logic, so unmapped reads return 0xFF, not 0x00 (passes blargg's cpu_instrs again) [gekkio] |
|
|
Tim Allen
|
0b923489dd |
Update to 20160106 OS X Preview for Developers release.
byuu says: New update. Most of the work today went into eliminating hiro::Image from all objects in all ports, replacing with nall::image. That took an eternity. Changelog: - fixed crashing bug when loading games [thanks endrift!!] - toggling "show status bar" option adjusts window geometry (not supposed to recenter the window, though) - button sizes improved; icon-only button icons no longer being cut off |
|
|
Tim Allen
|
47d4bd4d81 |
Update to v096r01 release.
byuu says: Changelog: - restructured the project and removed a whole bunch of old/dead directives from higan/GNUmakefile - huge amounts of work on hiro/cocoa (compiles but ~70% of the functionality is commented out) - fixed a masking error in my ARM CPU disassembler [Lioncash] - SFC: decided to change board cic=(411,413) back to board region=(ntsc,pal) ... the former was too obtuse If you rename Boolean (it's a problem with an include from ruby, not from hiro) and disable all the ruby drivers, you can compile an OS X binary, but obviously it's not going to do anything. It's a boring WIP, I just wanted to push out the project structure change now at the start of this WIP cycle. |