mirror of https://github.com/bsnes-emu/bsnes.git
37 Commits
| Author | SHA1 | Message | Date |
|---|---|---|---|
Tim Allen
|
0c55796060 |
Update to v106r46 release.
byuu says:
Changelog:
- bsnes, higan: simplified make output; reordered rules
- hiro: added Window::set(Minimum,Maximum)Size() [only implemented in
GTK+ so far]
- bsnes: only allow the window to be shrunk to the 1x multiplier size
- bsnes: refactored Integral Scaling checkbox to {Center, Scale,
Stretch} radio selection
- nall: call fflush() after nall::print() to stdout or stderr [needed
for msys2/bash]
- bsnes, higan: program/interface.cpp renamed to program/platform.cpp
- bsnes: trim ".shader/" from names in Settings→Shader menu
- bsnes: Settings→Shader menu updated on video driver changes
- bsnes: remove missing games from recent files list each time it is
updated
- bsnes: video multiplier menu generated dynamically based on largest
monitor size at program startup
- bsnes: added shrink window and center window function to video
multiplier menu
- bsnes: de-minimize presentation window when exiting fullscreen mode
or changing video multiplier
- bsnes: center the load game dialog against the presentation window
(important for multi-monitor setups)
- bsnes: screenshots are not immediate instead of delayed one frame
- bsnes: added frame advance menu option and hotkey
- bsnes: added enable cheats checkbox and hotkey; can be used to
quickly enable/disable all active cheats
Errata:
- hiro/Windows: `SW_MINIMIZED`, `SW_MAXIMIZED `=> `SW_MINIMIZE`,
`SW_MAXIMIZE`
- hiro/Windows: add pMonitor::workspace()
- hiro/Windows: add setMaximized(), setMinimized() in
pWindow::construct()
- bsnes: call setCentered() after setMaximized(false)
|
|
|
Tim Allen
|
ec960c5172 |
Update to v106r44 release.
byuu says:
Changelog:
- hiro/Windows: use `WS_CLIPSIBLINGS` on Label to prevent resize
drawing issues
- bsnes: correct viewport resizing
- bsnes: speed up window resizing a little bit
- bsnes: fix the cheat editor list enable checkbox
- bsnes: fix the state manager filename display in game ROM mode
- bsnes: fix the state manager save/rename/remove functionality in
game ROM mode
- bsnes: correct path searching for IPS and BPS patches in game ROM
mode
- bsnes: patch BS-X town cartridge to disable play limits
- bsnes: do not load (program,data,expansion).(rom,flash) from disk in
game pak mode
- this is required to support soft-patching and ROM hacks
- bsnes: added speed mode selection (50%, 75%, 100%, 150%, 200%);
maintains proper pitch
- bsnes: added icons to the menubar
- this is particularly useful to tell game ROMs from game paks in
the load recent game menu
- bsnes: added emblem at bottom left of status bar to indicate if a
game is verified or not
- verified means it is in the icarus verified game dump database
- the verified diamond is orange; the unverified diamond is blue
- bsnes: added an option (which defaults to off) to warn when loading
unverified games
- working around a bug in GTK, I have to use the uglier
MessageWindow instead of MessageDialog
- bsnes: added (non-functional) link to <https://doc.byuu.org/bsnes/>
to the help menu
- bsnes: added GUI setting to toggle memory auto-save feature
- bsnes: added GUI setting to toggle capturing a backup save state
when closing the emulator
- bsnes: made auto-saving states on exit an option
- bsnes: added an option to auto-load the auto-saved state on load
- basically, the two combined implements auto-resume
- bsnes: when firmware is missing, offer to take the user to the
online help documentation
- bsnes: added fast PPU option to disable the sprite limit
- increase from 32 items/line + 34 tiles/line to 128 items/line +
128 tiles/line
- technically, 1024 tiles/line are possible with 128 sprites at
64-width
- but this is just a waste of cache locality and worst-case
performance; it'll never happen
Errata:
- hiro/Windows: fallthrough on Canvas `WM_ERASEBKGND` to prevent
startup flicker
|
|
|
Tim Allen
|
f70a20bc42 |
Update to v106r41 release.
byuu says:
Changelog:
- hiro: added Label::set(Background,Foreground)Color (not implemented
on Cocoa backend)
- hiro: added (Horizontal,Vertical)Layout::setPadding()
- setMargin(m) is now an alias to setPadding({m, m, m, m})
- hiro/Windows: update Label rendering to draw to an offscreen canvas
to prevent flickering
- sfc: reverted back to 224/240-line height (from 223/239-line height
in earlier v106 WIPs)
- bsnes: new multi-segment status bar added
- bsnes: exiting fullscreen mode will resize and recenter window
- this is required; the window geometry gets all scrambled when
toggling fullscreen mode
- bsnes: updated to a new logo [Ange Albertini]
Errata:
- hiro/Windows: try to paint Label backgroundColor quicker to avoid
startup flicker
- `WM_ERASEBKGND` fallthrough to `WM_PAINT` seems to work
- hiro/Qt: use Window backgroundColor for Label when no Label
backgroundColor set
- bsnes: update size multipliers in presentation.cpp to 224/240 (main
window size is off in this WIP)
|
|
|
Tim Allen
|
5961ea9c03 |
Update to v106r26 release.
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
|
|
|
Tim Allen
|
0ea17abfea |
Update to v106r15 release.
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 |
|
|
Tim Allen
|
fbc58c70ae |
Update to v104r14 release.
byuu says:
Changelog:
- Emulator::Interface::videoResolution() -\> VideoResolution renamed
to videoInformation() -\> VideoInformation
- added double VideoInformation::refreshRate
- higan: added `binary := (application|library)` — set this to
`library` to produce a dynamic link library
- higan: removed `-march=native` for macOS application builds; and for
all library builds
- higan: removed `console` build flag; uncomment `link += -mwindows`
instead
- nall/GNUmakefile: `macosx` platform renamed `macos`
- still need to do this for nall/intrinsics.hpp
- Game Gear: return region=NTSC as the only option, so that the system
frequency is always set correctly
- hiro/cocoa: fixed typo [Sintendo]
- hiro/Windows: removed GetDpiForMonitor, as it's Windows 8+ only; DPI
is no longer per-monitor aware
- icarus: core Icarus class now has virtual functions for
directory::create, <file::exists>, <file::copy>, <file::write>
- icarus: Sufami Turbo can import save RAM files now
- icarus: setting `ICARUS_LIBRARY` define will compile icarus without
main(), GUI components
- ruby/video/Direct3D: choose the current monitor instead of top-left
monitor for fullscreen exclusive [Cydrak]
- ruby/video/Direct3D: do not set `WS_EX_TOPMOST` on fullscreen
exclusive window [Cydrak]
- this isn't necessary for exclusive mode, and it just makes
getting out of the application more difficult
|
|
|
Tim Allen
|
1ff315838e |
Update to v104r13 release.
byuu says:
Changelog:
- nall/GNUmakefile: build=release changed to -O2, build=optimize is
now -O3
- hiro: added Monitor::dpi(uint index) → Position [returns logical
DPI for x, y]
- Position is a bad name, but dpi(monitor).(x,y)() make more sense
than .(width,height)()
- hiro: Position, Size, Geometry, Font changed from using signed int
to float
- hiro: Alignment changed from using double to float
- hiro: added skeleton (unused) Application::scale(), setScale()
functions
Errata:
- hiro/cocoa's Monitor::dpi() is untested. Probably will cause issues
with macOS' automatic scaling.
- hiro/gtk lacks a way to get both per-monitor and per-axis (x,y) DPI
scaling
- hiro/qt lacks a way to get per-monitor DPI scaling (Qt 5.x has this,
but I still use Qt 4.x)
- and just to get global DPI, hiro/qt's DPI retrieval has to use
undocumented functions ... fun
The goal with this WIP was basically to prepare hiro for potential
automatic scaling. It'll be extremely difficult, but I'm convinced that
it must be possible if macOS can do it.
By moving from signed integers to floats for coordinates, we can now
scale and unscale without losing precision. That of course isn't the
hard part, though. The hard part is where and how to do the scaling. In
the ideal application, hiro/core and hiro/extension will handle 100% of
this, and the per-platform hiro/(cocoa,gtk,qt,windows) will not be aware
of what's going on, but ... to even make that possible, things will need
to change in every per-platform core, eg the per-platform code will have
to call a core function to change geometry, which will know about the
scaling and unscale the values back down again.
Gonna be a lot of work, but ... it's a start.
|
|
|
Tim Allen
|
ed5ec58595 |
Update to v103r13 release.
byuu says:
Changelog:
- gb/interface: fix Game Boy Color extension to be "gbc" and not "gb"
[hex\_usr]
- ms/interface: move Master System hardware controls below controller
ports
- sfc/ppu: improve latching behavior of BGnHOFS registers (not
hardware verified) [AWJ]
- tomoko/input: rework port/device mapping to support non-sequential
ports and devices¹
- todo: should add move() to inputDevice.mappings.append and
inputPort.devices.append
- note: there's a weird GCC 4.9 bug with brace initialization of
InputEmulator; have to assign each field separately
- tomoko: all windows sans the main presentation window can be
dismissed with the escape key
- icarus: the single file selection dialog ("Load ROM Image...") can
be dismissed with the escape key
- tomoko: do not pause emulation when FocusLoss/Pause is set during
exclusive fullscreen mode
- hiro/(windows,gtk,qt): implemented Window::setDismissable() function
(missing from cocoa port, sorry)
- nall/string: fixed printing of largest possible negative numbers (eg
`INT_MIN`) [Sintendo]
- only took eight months! :D
¹: When I tried to move the Master System hardware port below the
controller ports, I ran into a world of pain.
The input settings list expects every item in the
`InputEmulator<InputPort<InputDevice<InputMapping>>>>` arrays to be
populated with valid results. But these would be sparsely populated
based on the port and device IDs from inside higan. And that is done so
that the Interface::inputPoll can have O(1) lookup of ports and devices.
This worked because all the port and device IDs were sequential (they
left no gaps in the maps upon creating the lists.)
Unfortunately by changing the expectation of port ID to how it appears
in the list, inputs would not poll correctly. By leaving them alone and
just moving Hardware to the third position, the Game Gear would be
missing port IDs of 0 and 1 (the controller ports of the Master System).
Even by trying to make separate MasterSystemHardware and
GameGearHardware ports, things still fractured when the devices were no
longer contigious.
I got pretty sick of this and just decided to give up on O(1)
port/device lookup, and moved to O(n) lookup. It only knocked the
framerate down by maybe one frame per second, enough to be in the margin
of error. Inputs aren't polled *that* often for loops that usually
terminate after 1-2 cycles to be too detrimental to performance.
So the new input system now allows non-sequential port and device IDs.
Remember that I killed input IDs a while back. There's never any reason
for those to need IDs ... it was easier to just order the inputs in the
order you want to see them in the user interface. So the input lookup is
still O(1). Only now, everything's safer and I return a
maybe<InputMapping&>, and won't crash out the program trying to use a
mapping that isn't found for some reason.
Errata: the escape key isn't working on the browser/message dialogs on
Windows, because of course nothing can ever just be easy and work for
me. If anyone else wouldn't mind looking into that, I'd greatly
appreciate it.
Having the `WM_KEYDOWN` test inside the main `Application_sharedProc`, it
seems to not respond to the escape key on modal dialogs. If I put the
`WM_KEYDOWN` test in the main window proc, then it doesn't seem to get
called for `VK_ESCAPE` at all, and doesn't get called period for modal
windows. So I'm at a loss and it's past 4AM here >_>
|
|
|
Tim Allen
|
427bac3011 |
Update to v101r06 release.
byuu says:
I reworked the video sizing code. Ended up wasting five fucking hours
fighting GTK. When you call `gtk_widget_set_size_request`, it doesn't
actually happen then. This is kind of a big deal because when I then go
to draw onto the viewport, the actual viewport child window is still the
old size, so the image gets distorted. It recovers in a frame or so with
emulation, but if we were to put a still image on there, it would stay
distorted.
The first thought is, `while(gtk_events_pending())
gtk_main_iteration_do(false);` right after the `set_size_request`. But
nope, it tells you there's no events pending. So then you think, go
deeper, use `XPending()` instead. Same thing, GTK hasn't actually issued
the command to Xlib yet. So then you think, if the widget is realized,
just call a blocking `gtk_main_iteration`. One call does nothing, two
calls results in a deadlock on the second one ... do it before program
startup, and the main window will never appear. Great.
Oh, and it's not just the viewport. It's also the widget container area
of the windows, as well as the window itself, as well as the fullscreen
mode toggle effect. They all do this.
For the latter three, I couldn't find anything that worked, so I just
added 20ms loops of constantly calling `gtk_main_iteration_do(false)`
after each one of those things. The downside here is toggling the status
bar takes 40ms, so you'll see it and it'll feel a tiny bit sluggish.
But I can't have a 20ms wait on each widget resize, that would be
catastrophic to performance on windows with lots of widgets.
I tried hooking configure-event and size-allocate, but they were very
unreliable. So instead I ended up with a loop that waits up to a maximm
of 20ms that inspects the `widget->allocation.(width,height)` values
directly and waits for them to be what we asked for with
`set_size_request`.
There was some extreme ugliness in GTK with calling
`gtk_main_iteration_do` recursively (`hiro::Widget::setGeometry` is
called recursively), so I had to lock it to only happen on the top level
widgets (the child ones should get resized while waiting on the
top-level ones, so it should be fine in practice), and also only run it
on realized widgets.
Even still, I'm getting ~3 timeouts when opening the settings dialog in
higan, but no other windows. But, this is the best I can do for now.
And the reason for all of this pain? Yeah, updated the video code.
So the Emulator::Interface now has this:
struct VideoSize { uint width, height; }; //or requiem for a tuple
auto videoSize() -> VideoSize;
auto videoSize(uint width, uint height, bool arc) -> VideoSize;
The first function, for now, is just returning the literal surface size.
I may remove this ... one thing I want to allow for is cores that send
different texture sizes based on interlace/hires/overscan/etc settings.
The second function is more interesting. Instead of having the UI trying
to figure out sizing, I figure the emulation cores can do a better job
and we can customize it per-core now. So it gets the window's width and
height, and whether the user asked for aspect correction, and then
computes the best width/height ratio possible. For now they're all just
doing multiples of a 1x scale to the UI 2x,3x,4x modes.
We still need a third function, which will probably be what I repurpose
videoSize() for: to return the 'effective' size for pixel shaders, to
then feed into ruby, to then feed into quark, to then feed into our
shaders. Since shaders use normalized coordinates for pixel fetching,
this should work out just fine. The real texture size will be exposed to
quark shaders as well, of course.
Now for the main window ... it's just hard-coded to be 640x480, 960x720,
1280x960 for now. It works nicely for some cores on some modes, not so
much for others. Work in progress I guess.
I also took the opportunity to draw the about dialog box logo on the
main window. Got a bit fancy and used the old spherical gradient and
impose functionality of nall/image on it. Very minor highlight, nothing
garish. Just something nicer than a solid black window.
If you guys want to mess around with sizes, placements, and gradient
styles/colors/shapes ... feel free. If you come up with something nicer,
do share.
That's what led to all the GTK hell ... the logo wasn't drawing right as
you resized the window. But now it is, though I am not at all happy with
the hacking I had to do.
I also had to improve the video update code as a result of this:
- when you unload a game, it blacks out the screen
- if you are not quitting the emulator, it'll draw the logo; if
you are, it won't
- when you load a game, it black out the logo
These options prevent any unsightliness from resizing the viewport with
image data on it already
I need to redraw the logo when toggling fullscreen with no game loaded
as well for Windows, it seems.
|
|
|
Tim Allen
|
f5e5bf1772 |
Update to v100r16 release.
byuu says: (Windows users may need to include <sys/time.h> at the top of nall/chrono.hpp, not sure.) Unchangelog: - forgot to add the Scheduler clock=0 fix because I have the memory of a goldfish Changelog: - new icarus database with nine additional games - hiro(GTK,Qt) won't constantly write its settings.bml file to disk anymore - added latency simulator for fun (settings.bml => Input/Latency in milliseconds) So the last one ... I wanted to test out nall::chrono, and I was also thinking that by polling every emulated frame, it's pretty wasteful when you are using Fast Forward and hitting 200+fps. As I've said before, calls to ruby::input::poll are not cheap. So to get around this, I added a limiter so that if you called the hardware poll function within N milliseconds, it'll return without doing any actual work. And indeed, that increases my framerate of Zelda 3 uncapped from 133fps to 142fps. Yay. But it's not a "real" speedup, as it only helps you when you exceed 100% speed (theoretically, you'd need to crack 300% speed since the game itself will poll at 16ms at 100% speed, but yet it sped up Zelda 3, so who am I to complain?) I threw the latency value into the settings file. It should be 16, but I set it to 5 since that was the lowest before it started negatively impacting uncapped speeds. You're wasting your time and CPU cycles setting it lower than 5, but if people like placebo effects it might work. Maybe I should let it be a signed integer so people can set it to -16 and think it's actually faster :P (I'm only joking. I took out the 96000hz audio placebo effect as well. Not really into psychological tricks anymore.) But yeah seriously, I didn't do this to start this discussion again for the billionth time. Please don't go there. And please don't tell me this WIP has higher/lower latency than before. I don't want to hear it. The only reason I bring it up is for the fun part that is worth discussing: put up or shut up time on how sensitive you are to latency! You can set the value above 5 to see how games feel. I personally can't really tell a difference until about 50. And I can't be 100% confident it's worse until about 75. But ... when I set it to 150, games become "extra difficult" ... the higher it goes, the worse it gets :D For this WIP, I've left no upper limit cap. I'll probably set a cap of something like 500ms or 1000ms for the official release. Need to balance user error/trolling with enjoyability. I'll think about it. [...] Now, what I worry about is stupid people seeing it and thinking it's an "added latency" setting, as if anyone would intentionally make things worse by default. This is a limiter. So if 5ms have passed since the game last polled, and that will be the case 99.9% of the time in games, the next poll will happen just in time, immediately when the game polls the inputs. Thus, a value below 1/<framerate>ms is not only pointless, if you go too low it will ruin your fast forward max speeds. I did say I didn't want to resort to placebo tricks, but I also don't want to spark up public discussion on this again either. So it might be best to default Input/Latency to 0ms, and internally have a max(5, latency) wrapper around the value. |
|
|
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
|
3ebc77c148 |
Update to v098r10 release.
byuu says: Changelog: - synchronized tomoko, loki, icarus with extensive changes to nall (118KiB diff) |
|
|
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
|
0955295475 |
Update to v098r08 release.
byuu says: Changelog: - nall/vector rewritten from scratch - higan/audio uses nall/vector instead of raw pointers - higan/sfc/coprocessor/sdd1 updated with new research information - ruby/video/glx and ruby/video/glx2: fuck salt glXSwapIntervalEXT! The big change here is definitely nall/vector. The Windows, OS X and Qt ports won't compile until you change some first/last strings to left/right, but GTK will compile. I'd be really grateful if anyone could stress-test nall/vector. Pretty much everything I do relies on this class. If we introduce a bug, the worst case scenario is my entire SFC game dump database gets corrupted, or the byuu.org server gets compromised. So it's really critical that we test the hell out of this right now. The S-DD1 changes mean you need to update your installation of icarus again. Also, even though the Lunar FMV never really worked on the accuracy core anyway (it didn't initialize the PPU properly), it really won't work now that we emulate the hard-limit of 16MiB for S-DD1 games. |
|
|
Tim Allen
|
0d0af39b44 |
Update to v097r14 release.
byuu says: This is a few days old, but oh well. This WIP changes nall,hiro,ruby,icarus back to (u)int(8,16,32,64)_t. I'm slowly pushing for (u)int(8,16,32,64) to use my custom Integer<Size>/Natural<Size> classes instead. But it's going to be one hell of a struggle to get that into 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
|
4d193d7d94 |
Update to v096r02 (OS X Preview for Developers) release.
byuu says:
Warning: this is not for the faint of heart. This is a very early,
unpolished, buggy release. But help testing/fixing bugs would be greatly
appreciated for anyone willing.
Requirements:
- Mac OS X 10.7+
- Xcode 7.2+
Installation Commands:
cd higan
gmake -j 4
gmake install
cd ../icarus
gmake -j 4
gmake install
(gmake install is absolutely required, sorry. You'll be missing key
files in key places if you don't run it, and nothing will work.)
(gmake uninstall also exists, or you can just delete the .app bundles
from your Applications folder, and the Dev folder on your desktop.)
If you want to use the GBA emulation, then you need to drop the GBA BIOS
into ~/Emulation/System/Game\ Boy\ Advance.sys\bios.rom
Usage:
You'll now find higan.app and icarus.app in your Applications folders.
First, run icarus.app, navigate to where you keep your game ROMs. Now
click the settings button at the bottom right, and check "Create
Manifests", and click OK. (You'll need to do this every time you run
icarus because there's some sort of bug on OSX saving the settings.) Now
click "Import", and let it bring in your games into ~/Emulation.
Note: "Create Manifests" is required. I don't yet have a pipe
implementation on OS X for higan to invoke icarus yet. If you don't
check this box, it won't create manifest.bml files, and your games won't
run at all.
Now you can run higan.app. The first thing you'll want to do is go to
higan->Preferences... and assign inputs for your gamepads. At the very
least, do it for the default controller for all the systems you want to
emulate.
Now this is very important ... close the application at this point so
that it writes your config file to disk. There's a serious crashing bug,
and if you trigger it, you'll lose your input bindings.
Now the really annoying part ... go to Library->{System} and pick the
game you want to play. Right now, there's a ~50% chance the application
will bomb. It seems the hiro::pListView object is getting destroyed, yet
somehow the internal Cocoa callbacks are being triggered anyway. I don't
know how this is possible, and my attempts to debug with lldb have been
a failure :(
If you're unlucky, the application will crash. Restart and try again. If
it crashes every single time, then you can try launching your game from
the command-line instead. Example:
open /Applications/higan.app \
--args ~/Emulation/Super\ Famicom/Zelda3.sfc/
Help wanted:
I could really, really, really use some help with that crashing on game
loading. There's a lot of rough edges, but they're all cosmetic. This
one thing is pretty much the only major show-stopping issue at the
moment, preventing a wider general audience pre-compiled binary preview.
|
|
|
Tim Allen
|
0253db8685 |
Update to higan and icarus v095r17 release.
byuu says: higan supports Event mapping again. Further, icarus can now detect Event ROMs and MSU1 games. Event ROMs must be named "program.rom", "slot-(1,2,3).rom" MSU1 games must contain "msu1.rom"; and tracks must be named "track-#.pcm" When importing the CC'92, PF'94 ROMs, the program.rom and slot-(1,2,3).rom files must be concatenated. The DSP firmware can optionally be separate, but I'd recommend you go ahead and merge it all to one file. Especially since that common "higan DSP pack" floating around on the web left out the DSP1 ROMs (only has DSP1B) for god knows what reason. There is no support for loading "game.sfc+game.msu+game-*.pcm", because I'm not going to support trying to pull in all of those files through importing. Games will have to be distributed as game folders to use MSU1. The MSU1 icarus support is simply so your game folders won't require an unstable manifest.bml file to be played. So once they're in there, they are good for life. Note: the Event sizes in icarus' SFC heuristics are wrong for appended firmware. Change from 0xXX8000 to 0xXX2000 and it works fine. Will be fixed in r18. Added Sintendo's flickering fixes. The window one's a big help for regular controls, but the ListView double buffering does nothing for me on Windows 7 :( Fairly sure I know why, but too lazy to try and fix that now. Also fixes the mMenu thing. |
|
|
Tim Allen
|
bd628de3cf |
Update to higan and icarus v095r15 release.
r13 and r14 weren't posted as individual releases, but their changelogs
were posted.
byuu says about r13:
I'm not going to be posting WIPs for r13 and above for a while.
The reason is that I'm working on the major manifest overhaul I've
discussed previously on the icarus subforum.
I'm recreating my boards database from scratch using the map files
and the new map analyzer. The only games that will load are ones
I've created board definitions for, and updated
sfc/cartridge/markup.cpp to parse. Once I've finished all the
boards, then I'll update the heuristics.
Then finally, I'll sync the syntax changes over to the fc, gb, gba
cores.
Once that's done, I'll start posting WIPs again, along with a new
build of icarus.
But I'll still post changelogs as I work through things.
Changelog (r13):
- preservation: created new database-builder tool (merges
region-specific databases with boards)
- icarus: support new, external database format
(~/.config/icarus/Database/(Super Famicom.bml, ...)
- added 1A3B-(10,11,12); 1A3B-20
byuu says about r14:
r14 work:
I successfully created mappings for every board used in the US set.
I also updated icarus' heuristics to use the new mappings, and
created ones there for the boards that are only in the JP set.
Then I patched icarus to support pulling games out of the database
when it's used on a game folder to generate a manifest file.
Then I updated a lot of code in higan/sfc to support the new mapping
syntax. sfc/cartridge/markup.cpp is about half the size it used to
be with the new mappings, and I was able to kill off both map/id and
map/select entirely.
Then I updated all four emulated systems (and both subsystems) to
use "board" as the root node, and harmonized their syntax (made them
all more consistent with each other.)
Then I added a manifest viewer to the tools window+menu. It's kind
of an advanced user feature, but oh well. No reason to coddle people
when the feature is very useful for developers. The viewer will show
all manifests in order when you load multi-cart games as well.
Still not going to call any syntax 100% done right now, but
thankfully with the new manifest-free folders, nobody will have to
do anything to use the new format. Just download the new version and
go.
The Super Famicom Event stuff is currently broken (CC92/PF94
boards). That's gonna be fun to support.
byuu says about r15:
EDIT: small bug in icarus with heuristics. Edit
core/super-famicom.cpp line 27:
if(/*auto*/ markup = cartridge.markup) {
Gotta remove that "auto" so that it returns valid markup.
Resolved the final concerns I had with the new manifest format.
Right now there are two things that are definitely broken: MCC (BS-X
Town cart) and Event (CC '92 and PF'94).
And there are a few things that are untested: SPC7110, EpsonRTC,
SharpRTC, SDD1+RAM, SufamiTurbo, BS-X slotted carts.
|
|
|
Tim Allen
|
f2a416aea9 |
Update to v095r11 release.
byuu says: Changelog: - SFC: "uint8 read(uint addr)" -> "uint8 read(uint addr, uint8 data)" - hiro: mHorizontalLayout::setGeometry() return value - hiro/GTK: ListView,TreeView::setFocused() does not grab focus of first item Notes: - nall/windows/utf8.hpp needs using uint = unsigned; at the top to compile - sfc/balanced, sfc/performance won't compile yet Seems Cx4 games broke a while back. Not from this WIP, either. I'll go back and find out what's wrong now. |
|
|
Tim Allen
|
41c478ac4a |
Update to v095r07 release.
byuu says:
Changelog:
- entire GBA core ported to auto function() -> return; syntax
- fixed GBA BLDY bug that was causing flickering in a few games
- replaced nall/config usage with nall/string/markup/node
- this merges all configuration files to a unified settings.bml file
- added "Ignore Manifests" option to the advanced setting tab
- this lets you keep a manifest.bml for an older version of higan; if
you want to do regression testing
Be sure to remap your controller/hotkey inputs, and for SNES, choose
"Gamepad" from "Controller Port 1" in the system menu. Otherwise you
won't get any input. No need to blow away your old config files, unless
you want to.
|
|
|
Tim Allen
|
40f4b91000 |
Update to v095r06 release.
byuu says: Changelog: - fixed I/O register reads; perfect score on endrift's I/O tests now - fixed mouse capture clipping on Windows [Cydrak] - several hours of code maintenance work done on the SFC core All higan/sfc files should now use the auto fn() -> ret; syntax. Haven't converted all unsigned->uint yet. Also, probably won't do sfc/alt as that's mostly just speed hack stuff. Errata: - forgot auto& instead of just auto on SuperFamicom::Video::draw_cursor, which makes Super Scope / Justifier crash. Will be fixed in the next WIP. |
|
|
Tim Allen
|
483fc81356 |
Update to v094r44 release.
byuu says: Changelog: - return open bus instead of mirroring addresses on the bus (fixes Mario&Luigi, Minish Cap, etc) [Jonas Quinn] - add boolean flag to load requests for slotted game carts (fixes slot load prompts) - rename BS-X Town cart from psram to ram - icarus: add support for game database Note: I didn't rename "bsx" to "mcc" in the database for icarus before uploading that. But I just fixed it locally, so it'll be in the next WIP. For now, make it create the manifest for you and then rename it yourself. I did fix the PSRAM size to 256kbit. |
|
|
Tim Allen
|
0c87bdabed |
Update to v094r43 release.
byuu says:
Updated to compile with all of the new hiro changes. My next step is to
write up hiro API documentation, and move the API from alpha (constantly
changing) to beta (rarely changing), in preparation for the first stable
release (backward-compatible changes only.)
Added "--fullscreen" command-line option. I like this over
a configuration file option. Lets you use the emulator in both modes
without having to modify the config file each time.
Also enhanced the command-line game loading. You can now use any of
these methods:
higan /path/to/game-folder.sfc
higan /path/to/game-folder.sfc/
higan /path/to/game-folder.sfc/program.rom
The idea is to support launchers that insist on loading files only.
Technically, the file can be any name (manifest.bml also works); the
only criteria is that the file actually exists and is a file, and not
a directory. This is a requirement to support the first version (a
directory lacking the trailing / identifier), because I don't want my
nall::string class to query the file system to determine if the string
is an actual existing file or directory for its pathname() / dirname()
functions.
Anyway, every game folder I've made so far has program.rom, and that's
very unlikely to change, so this should be fine.
Now, of course, if you drop a regular "game.sfc" file on the emulator,
it won't even try to load it, unless it's in a folder that ends in .fc,
.sfc, etc. In which case, it'll bail out immediately by being unable to
produce a manifest for what is obviously not really a game folder.
|
|
|
Tim Allen
|
c45633550e |
Update to v094r42 release.
byuu says:
I imagine you guys will like this WIP very much.
Changelog:
- ListView check boxes on Windows
- ListView removal of columns on reset (changing input dropdowns)
- DirectSound audio duplication on latency change
- DirectSound crash on 20ms latency
- Fullscreen window sizing in multi-monitor setups
- Allow joypad bindings of hotkeys
- Allow triggers to be mapped (Xbox 360 / XInput / Windows only)
- Support joypad rumble for Game Boy Player
- Video scale settings modified from {1x,2x,3x} to {2x,3x,4x}
- System menu now renames to active emulation core
- Added fast forward hotkey
Not changing for v095:
- not adding input focus settings yet
- not adding shaders yet
Not changing at all:
- not implementing maximize
|
|
|
Tim Allen
|
213879771e |
Update to v094r41 release (open beta).
byuu says: Changelog (since the last open beta): - icarus is now included. icarus is used to import game files/archives into game paks (folders) - SNES: mid-scanline BGMODE changes now emulated correctly (used only by atx2.smc Anthrox Demo) - GBA: fixed a CPU bug that was causing dozens of games to have distorted audio - GBA: fixed default FlashROM ID; should allow much higher compatibility - GBA: now using Cydrak's new, much improved, GBA color emulation filter (still a work-in-progress) - re-added command-line loading support for game paks (not for game files/archives, sorry!) - Qt port now compiles and runs again (may be a little buggy; Windows/GTK+ ports preferred) - SNES performance profile now compiles and runs again - much more |
|
|
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
|
0271d6a12b |
Update to v094r39 release.
byuu says:
Changelog:
- SNES mid-scanline BGMODE fixes finally merged (can run
atx2.zip{mode7.smc}+mtest(2).sfc properly now)
- Makefile now discards all built-in rules and variables
- switch on bool warning disabled for GCC now as well (was already
disabled for Clang)
- when loading a game, if any required files are missing, display
a warning message box (manifest.bml, program.rom, bios.rom, etc)
- when loading a game (or a game slot), if manifest.bml is missing, it
will invoke icarus to try and generate it
- if that fails (icarus is missing or the folder is bad), you will get
a warning telling you that the manifest can't be loaded
The warning prompt on missing files work for both games and the .sys
folders and their files. For some reason, failing to load the DMG/CGB
BIOS is causing a crash before I can display the modal dialog. I have no
idea why, and the stack frame backtrace is junk.
I also can't seem to abort the failed loading process. If I call
Program::unloadMedia(), I get a nasty segfault. Again with a really
nasty stack trace. So for now, it'll just end up sitting there emulating
an empty ROM (solid black screen.) In time, I'd like to fix that too.
Lastly, I need a better method than popen for Windows. popen is kind of
ugly and flashes a console window for a brief second even if the
application launched is linked with -mwindows. Not sure if there even is
one (I need to read the stdout result, so CreateProcess may not work
unless I do something nasty like "> %tmp%/temp") I'm also using the
regular popen instead of _wpopen, so for this WIP, it won't work if your
game folder has non-English letters in the path.
|
|
|
Tim Allen
|
7ff7f64482 |
Update to v094r34 release.
byuu says: Fixes SuperFX fmult, lmult timings; rambr, bramr and clsr assignment masking. Implements true GBA ROM prefetch (buggy, lower test score, but runs Mario & Luigi without crashing on battles anymore.) |
|
|
Tim Allen
|
e0815b55b9 |
Update to v094r28 release.
byuu says: This WIP substantially restructures the ruby API for the first time since that project started. It is my hope that with this restructuring, destruction of the ruby objects should now be deterministic, which should fix the crashing on closing the emulator on Linux. We'll see I guess ... either way, it removed two layers of wrappers from ruby, so it's a pretty nice code cleanup. It won't compile on Windows due to a few issues I didn't see until uploading the WIP, too lazy to upload another. But I fixed all the compilation issues locally, so it'll work on Windows again with the next WIP (unless I break something else.) (Kind of annoying that Linux defines glActiveTexture but Windows doesn't.) |
|
|
Tim Allen
|
20cc6148cb |
Update to v094r27 release.
byuu says: Added AWJ's fixes for alt/cpu (Tetris Attack framelines issue) and alt/dsp (Thread::clock reset) Added fix so that the taskbar entry appears when the application first starts on Windows. Fixed checkbox toggling inside of list views on Windows. Updated nall/image to properly protect variables that should not be written externally. New Object syntax for hiro is in. Fixed the backwards-typing on Windows with the state manager. NOTE: the list view isn't redrawing when you change the description text. It does so on the cheat editor because of the resizeColumns call; but that shouldn't be necessary. I'll try and fix this for the next WIP. |
|
|
Tim Allen
|
bb3c69a30d |
Update to v094r25 release.
byuu says: Windows port should run mostly well now, although exiting fullscreen breaks the application in a really bizarre way. (clicking on the window makes it sink to background rather than come to the foreground o_O) I also need to add the doModalChange => audio.clear() thing for the accursed menu stuttering with DirectSound. I also finished porting all of the ruby drivers over to the newer API changes from nall. Since I can't compile the Linux or OS X drivers, I have no idea if there are any typos that will result in compilation errors. If so, please let me know where they're at and I'll try and fix them. If they're simple, please try and fix them on your end to test further if you can. I'm hopeful the udev crash will be gone now that nall::string checks for null char* values passed to its stringify function. Of course, it's a problem it's getting a null value in the first place, so it may not work at all. If you can compile on Linux (or by some miracle, OS X), please test each video/audio/input driver if you don't mind, to make sure there's no "compiles okay but still typos exist" bugs. |
|
|
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
|
4e0223d590 |
Update to v094r20 release.
byuu says: Main reason for this WIP was because of all the added lines to hiro for selective component disabling. May as well get all the diff-noise apart from code changes. It also merges something I've been talking to Cydrak about ... making nall::string::(integer,decimal) do built-in binary,octal,hex decoding instead of just failing on those. This will have fun little side effects all over the place, like being able to view a topic on my forum via "forum.byuu.org/topic/0b10010110", heh. There are two small changes to higan itself, though. First up, I fixed the resampler ratio when loading non-SNES games. Tested and I can play Game Boy games fine now. Second, I hooked up menu option hiding for reset and controller selection. Right now, this works like higan v094, but I'm thinking I might want to show the "Device -> Controller" even if that's all that's there. It kind of jives nicer with the input settings window to see the labels there, I think. And if we ever do add more stuff, it'll be nice that people already always expect that menu there. Remaining issues: * add slotted cart loader (SGB, BSX, ST) * add DIP switch selection window (NSS) * add timing configuration (video/audio sync) |
|
|
Tim Allen
|
b4ba95242f |
Update to v094r13 release.
byuu says: This version polishes up the input dialogue (reset, erase, disable button when item not focused, split device ID from mapping name), adds color emulation toggle, and add dummy menu items for remaining features (to be filled in later.) Also, it now compiles cleanly on Windows with GTK. I didn't test with TDM-GCC-32, because for god knows what reason, the 32-bit version ships with headers from Windows 95 OSR2 only. So I built with TDM-GCC-64 with arch=x86. And uh, apparently, moving or resizing a window causes a Visual C++ runtime exception in the GTK+ DLLs. This doesn't happen with trance or renshuu built with TDM-GCC-32. So, yeah, like I said, don't use -m32. |
|
|
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. |