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.
2015-08-18 10:18:00 +00:00
|
|
|
#if defined(Hiro_Alignment)
|
|
|
|
|
Update to bsnes v107.1 release.
byuu says:
Don't let the point release fool you, there are many significant changes in this
release. I will be keeping bsnes releases using a point system until the new
higan release is ready.
Changelog:
- GUI: added high DPI support
- GUI: fixed the state manager image preview
- Windows: added a new waveOut driver with support for dynamic rate control
- Windows: corrected the XAudio 2.1 dynamic rate control support [BearOso]
- Windows: corrected the Direct3D 9.0 fullscreen exclusive window centering
- Windows: fixed XInput controller support on Windows 10
- SFC: added high-level emulation for the DSP1, DSP2, DSP4, ST010, and Cx4
coprocessors
- SFC: fixed a slight rendering glitch in the intro to Megalomania
If the coprocessor firmware is missing, bsnes will fallback on HLE where it is
supported, which is everything other than SD Gundam GX and the two Hayazashi
Nidan Morita Shougi games.
The Windows dynamic rate control works best with Direct3D in fullscreen
exclusive mode. I recommend the waveOut driver over the XAudio 2.1 driver, as it
is not possible to target a single XAudio2 version on all Windows OS releases.
The waveOut driver should work everywhere out of the box.
Note that with DRC, the synchronization source is your monitor, so you will
want to be running at 60hz (NTSC) or 50hz (PAL). If you have an adaptive sync
monitor, you should instead use the WASAPI (exclusive) or ASIO audio driver.
2019-04-09 01:16:30 +00:00
|
|
|
const Alignment Alignment::Center = {0.5, 0.5};
|
|
|
|
|
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.
2015-08-18 10:18:00 +00:00
|
|
|
Alignment::Alignment() {
|
|
|
|
setAlignment(-1.0, -1.0);
|
|
|
|
}
|
|
|
|
|
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.
2017-09-08 06:06:21 +00:00
|
|
|
Alignment::Alignment(float horizontal, float vertical) {
|
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.
2015-08-18 10:18:00 +00:00
|
|
|
setAlignment(horizontal, vertical);
|
|
|
|
}
|
|
|
|
|
|
|
|
Alignment::operator bool() const {
|
|
|
|
return state.horizontal >= 0.0 && state.horizontal <= 1.0
|
|
|
|
&& state.vertical >= 0.0 && state.vertical <= 1.0;
|
|
|
|
}
|
|
|
|
|
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.
2017-09-08 06:06:21 +00:00
|
|
|
auto Alignment::horizontal() const -> float {
|
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.
2015-08-18 10:18:00 +00:00
|
|
|
return state.horizontal;
|
|
|
|
}
|
|
|
|
|
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.
2015-08-30 02:08:26 +00:00
|
|
|
auto Alignment::reset() -> type& {
|
|
|
|
return setAlignment(-1.0, -1.0);
|
|
|
|
}
|
|
|
|
|
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.
2017-09-08 06:06:21 +00:00
|
|
|
auto Alignment::setAlignment(float horizontal, float vertical) -> type& {
|
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.
2015-08-18 10:18:00 +00:00
|
|
|
state.horizontal = horizontal;
|
|
|
|
state.vertical = vertical;
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
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.
2017-09-08 06:06:21 +00:00
|
|
|
auto Alignment::setHorizontal(float horizontal) -> type& {
|
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.
2015-08-18 10:18:00 +00:00
|
|
|
state.horizontal = horizontal;
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
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.
2017-09-08 06:06:21 +00:00
|
|
|
auto Alignment::setVertical(float vertical) -> type& {
|
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.
2015-08-18 10:18:00 +00:00
|
|
|
state.vertical = vertical;
|
|
|
|
return *this;
|
|
|
|
}
|
|
|
|
|
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.
2017-09-08 06:06:21 +00:00
|
|
|
auto Alignment::vertical() const -> float {
|
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.
2015-08-18 10:18:00 +00:00
|
|
|
return state.vertical;
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|