2016-01-07 17:14:33 +09:00
|
|
|
#pragma once
|
2010-08-09 22:28:56 +09:00
|
|
|
|
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.
2015-02-26 19:10:46 +09:00
|
|
|
#include <nall/traits.hpp>
|
|
|
|
|
|
2010-08-09 22:28:56 +09:00
|
|
|
#undef min
|
|
|
|
|
#undef max
|
|
|
|
|
|
2019-01-16 09:46:42 +09:00
|
|
|
namespace nall {
|
2010-08-09 22:28:56 +09:00
|
|
|
|
Update to v106r87 release.
byuu says:
These WIPs are gonna be unstable for a bit, sorry. Large amounts of
changes. Right now, higan+bsnes compile, but only with cores="sfc gb".
There's a new nall::Settings class, which I really dislike the design
of, but as long as the classes that use it remain stable, then ... I'll
have to live with it for now.
Interface loses both the old get/set/cap interface, plus the
configuration interface. It now returns either properties() or
options(). Both return a Settings& object. There's also helpers for
accessing individual properties and options by string lookup.
Properties are immutable traits of the hardware itself: CPU version, PPU
VRAM size, boot ROM information, etc.
Options are mutable traits that users may change.
The idea with nall/settings is to build out a kind of extremely complex
configuration object that'll do everything we'd ever want:
- allow recursive children settings similar to Markup::Node
- access values directly without dynamic_cast (type erasure) or
string conversion (Markup::Node style)
- serialize to and unserialize from BML
- support valid values to guarantee that the settings are never in an
invalid state
- support latching of values to cache reads without another separate
variable (so the GUI can modify any variables at any time safely)
Todo:
- allow binding callback functions on assignment, so that eg changing
video/colorEmulation will regenerate the video palette
- provide a hint on whether an option can be changed dynamically at
run-time, or only statically at first load
- provide descriptions for each setting
And then once the class is fully fleshed out, I want to build a tool
that will generate a fancy modal hiro Window from a Settings& object.
Once that is complete, we'll then have System → Options to configure
per-emulator settings (like bsnes PPU stuff) that otherwise doesn't fit
into higan's GUI. We will be exposing the extended Super Famicom options
to the bsnes GUI, of course. That's the emulator tab there.
Next up, higan's systems tab will need to generate blank default
property files for each system, and let you configure system properties
from this screen. That's going to mean that, by allowing the same system
to appear multiple times, that each entry gets its own options file,
which will have to be stored somewhere.
And to do all of that, we really need to work out how to handle regions
first. It may have to be something radical like FitzRoy's idea, or it
may be that we can come up with something a little less drastic. But I
have no idea right now ...
What I'd really like to do is start trying to get bsnes v107 out
already. The two things holding it up are: fixing the desync between the
settings.bml GUI settings and options.bml SNES properties (I know what's
wrong, I just have to fix it), and getting XAudio2 DRC working (I copied
BearOso's implementation details, but it just doesn't work for me ...).
Then I also have to install Windows, set up a dev environment with
msys2, and build it all.
Lots and lots of work ...
2019-01-25 13:35:11 +09:00
|
|
|
template<typename T, typename U> constexpr auto min(const T& t, const U& u) -> T {
|
Update to v106r77 release.
byuu says:
So this turned out to be a rather unproductive ten-hour rabbit hole, but
...
I reworked nall/primitives.hpp a lot. And because the changes are
massive, testing of this WIP for regressions is critically important. I
really can't stress that enough, we're almost certainly going to have
some hidden regressions here ...
We now have a nall/primitives/ subfolder that splits up the classes into
manageable components. The bit-field support is now shared between both
Natural and Integer. All of the assignment operator overloads are now
templated and take references instead of values. Things like the
GSU::Register class are non-copyable on account of the function<>
object inside of it, and previously only operator= would work with
classes like that.
The big change is nall/primitives/operators.hpp, which is a really
elaborate system to compute the minimum number of bits needed for any
operation, and to return a Natural<T> or Integer<T> when one or both of
the arguments are such a type.
Unfortunately, it doesn't really work yet ... Kirby's Dream Land 3
breaks if we include operators.hpp. Zelda 3 runs fine with this, but I
had to make a huge amount of core changes, including introducing a new
ternary(bool, lhs, rhs) function to nall/algorithm to get past
Natural<X> and Natural<Y> not being equivalent (is_integral types get a
special exemption to ternary ?: type equivalence, yet it's impossible to
simulate with our own classes, which is bullshit.) The horrifying part
is that ternary() will evaluate both lhs and rhs, unlike ?:
I converted some of the functions to test ? uint(x) : uint(y), and
others to ternary(test, x, y) ... I don't have a strong preference
either way yet.
But the part where things may have gotten broken is in the changes to
where ternary() was placed. Some cases like in the GBA PPU renderer, it
was rather unclear the order of evaluations, so I may have made a
mistake somewhere.
So again, please please test this if you can. Or even better, look over
the diff.
Longer-term, I'd really like the enable nall/primitives/operators.hpp,
but right now I'm not sure why Kirby's Dream Land 3 is breaking. Help
would be appreciated, but ... it's gonna be really complex and difficult
to debug, so I'm probably gonna be on my own here ... sigh.
2019-01-13 15:25:14 +09:00
|
|
|
return t < u ? t : (T)u;
|
2013-05-02 20:25:45 +09:00
|
|
|
}
|
|
|
|
|
|
Update to v106r87 release.
byuu says:
These WIPs are gonna be unstable for a bit, sorry. Large amounts of
changes. Right now, higan+bsnes compile, but only with cores="sfc gb".
There's a new nall::Settings class, which I really dislike the design
of, but as long as the classes that use it remain stable, then ... I'll
have to live with it for now.
Interface loses both the old get/set/cap interface, plus the
configuration interface. It now returns either properties() or
options(). Both return a Settings& object. There's also helpers for
accessing individual properties and options by string lookup.
Properties are immutable traits of the hardware itself: CPU version, PPU
VRAM size, boot ROM information, etc.
Options are mutable traits that users may change.
The idea with nall/settings is to build out a kind of extremely complex
configuration object that'll do everything we'd ever want:
- allow recursive children settings similar to Markup::Node
- access values directly without dynamic_cast (type erasure) or
string conversion (Markup::Node style)
- serialize to and unserialize from BML
- support valid values to guarantee that the settings are never in an
invalid state
- support latching of values to cache reads without another separate
variable (so the GUI can modify any variables at any time safely)
Todo:
- allow binding callback functions on assignment, so that eg changing
video/colorEmulation will regenerate the video palette
- provide a hint on whether an option can be changed dynamically at
run-time, or only statically at first load
- provide descriptions for each setting
And then once the class is fully fleshed out, I want to build a tool
that will generate a fancy modal hiro Window from a Settings& object.
Once that is complete, we'll then have System → Options to configure
per-emulator settings (like bsnes PPU stuff) that otherwise doesn't fit
into higan's GUI. We will be exposing the extended Super Famicom options
to the bsnes GUI, of course. That's the emulator tab there.
Next up, higan's systems tab will need to generate blank default
property files for each system, and let you configure system properties
from this screen. That's going to mean that, by allowing the same system
to appear multiple times, that each entry gets its own options file,
which will have to be stored somewhere.
And to do all of that, we really need to work out how to handle regions
first. It may have to be something radical like FitzRoy's idea, or it
may be that we can come up with something a little less drastic. But I
have no idea right now ...
What I'd really like to do is start trying to get bsnes v107 out
already. The two things holding it up are: fixing the desync between the
settings.bml GUI settings and options.bml SNES properties (I know what's
wrong, I just have to fix it), and getting XAudio2 DRC working (I copied
BearOso's implementation details, but it just doesn't work for me ...).
Then I also have to install Windows, set up a dev environment with
msys2, and build it all.
Lots and lots of work ...
2019-01-25 13:35:11 +09:00
|
|
|
template<typename T, typename U, typename... P> constexpr auto min(const T& t, const U& u, P&&... p) -> T {
|
2022-09-13 16:47:47 +09:00
|
|
|
return t < u ? min(t, std::forward<P>(p)...) : min(u, std::forward<P>(p)...);
|
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.
2015-02-26 19:10:46 +09:00
|
|
|
}
|
|
|
|
|
|
Update to v106r87 release.
byuu says:
These WIPs are gonna be unstable for a bit, sorry. Large amounts of
changes. Right now, higan+bsnes compile, but only with cores="sfc gb".
There's a new nall::Settings class, which I really dislike the design
of, but as long as the classes that use it remain stable, then ... I'll
have to live with it for now.
Interface loses both the old get/set/cap interface, plus the
configuration interface. It now returns either properties() or
options(). Both return a Settings& object. There's also helpers for
accessing individual properties and options by string lookup.
Properties are immutable traits of the hardware itself: CPU version, PPU
VRAM size, boot ROM information, etc.
Options are mutable traits that users may change.
The idea with nall/settings is to build out a kind of extremely complex
configuration object that'll do everything we'd ever want:
- allow recursive children settings similar to Markup::Node
- access values directly without dynamic_cast (type erasure) or
string conversion (Markup::Node style)
- serialize to and unserialize from BML
- support valid values to guarantee that the settings are never in an
invalid state
- support latching of values to cache reads without another separate
variable (so the GUI can modify any variables at any time safely)
Todo:
- allow binding callback functions on assignment, so that eg changing
video/colorEmulation will regenerate the video palette
- provide a hint on whether an option can be changed dynamically at
run-time, or only statically at first load
- provide descriptions for each setting
And then once the class is fully fleshed out, I want to build a tool
that will generate a fancy modal hiro Window from a Settings& object.
Once that is complete, we'll then have System → Options to configure
per-emulator settings (like bsnes PPU stuff) that otherwise doesn't fit
into higan's GUI. We will be exposing the extended Super Famicom options
to the bsnes GUI, of course. That's the emulator tab there.
Next up, higan's systems tab will need to generate blank default
property files for each system, and let you configure system properties
from this screen. That's going to mean that, by allowing the same system
to appear multiple times, that each entry gets its own options file,
which will have to be stored somewhere.
And to do all of that, we really need to work out how to handle regions
first. It may have to be something radical like FitzRoy's idea, or it
may be that we can come up with something a little less drastic. But I
have no idea right now ...
What I'd really like to do is start trying to get bsnes v107 out
already. The two things holding it up are: fixing the desync between the
settings.bml GUI settings and options.bml SNES properties (I know what's
wrong, I just have to fix it), and getting XAudio2 DRC working (I copied
BearOso's implementation details, but it just doesn't work for me ...).
Then I also have to install Windows, set up a dev environment with
msys2, and build it all.
Lots and lots of work ...
2019-01-25 13:35:11 +09:00
|
|
|
template<typename T, typename U> constexpr auto max(const T& t, const U& u) -> T {
|
Update to v106r77 release.
byuu says:
So this turned out to be a rather unproductive ten-hour rabbit hole, but
...
I reworked nall/primitives.hpp a lot. And because the changes are
massive, testing of this WIP for regressions is critically important. I
really can't stress that enough, we're almost certainly going to have
some hidden regressions here ...
We now have a nall/primitives/ subfolder that splits up the classes into
manageable components. The bit-field support is now shared between both
Natural and Integer. All of the assignment operator overloads are now
templated and take references instead of values. Things like the
GSU::Register class are non-copyable on account of the function<>
object inside of it, and previously only operator= would work with
classes like that.
The big change is nall/primitives/operators.hpp, which is a really
elaborate system to compute the minimum number of bits needed for any
operation, and to return a Natural<T> or Integer<T> when one or both of
the arguments are such a type.
Unfortunately, it doesn't really work yet ... Kirby's Dream Land 3
breaks if we include operators.hpp. Zelda 3 runs fine with this, but I
had to make a huge amount of core changes, including introducing a new
ternary(bool, lhs, rhs) function to nall/algorithm to get past
Natural<X> and Natural<Y> not being equivalent (is_integral types get a
special exemption to ternary ?: type equivalence, yet it's impossible to
simulate with our own classes, which is bullshit.) The horrifying part
is that ternary() will evaluate both lhs and rhs, unlike ?:
I converted some of the functions to test ? uint(x) : uint(y), and
others to ternary(test, x, y) ... I don't have a strong preference
either way yet.
But the part where things may have gotten broken is in the changes to
where ternary() was placed. Some cases like in the GBA PPU renderer, it
was rather unclear the order of evaluations, so I may have made a
mistake somewhere.
So again, please please test this if you can. Or even better, look over
the diff.
Longer-term, I'd really like the enable nall/primitives/operators.hpp,
but right now I'm not sure why Kirby's Dream Land 3 is breaking. Help
would be appreciated, but ... it's gonna be really complex and difficult
to debug, so I'm probably gonna be on my own here ... sigh.
2019-01-13 15:25:14 +09:00
|
|
|
return t > u ? t : (T)u;
|
2013-05-02 20:25:45 +09:00
|
|
|
}
|
|
|
|
|
|
Update to v106r87 release.
byuu says:
These WIPs are gonna be unstable for a bit, sorry. Large amounts of
changes. Right now, higan+bsnes compile, but only with cores="sfc gb".
There's a new nall::Settings class, which I really dislike the design
of, but as long as the classes that use it remain stable, then ... I'll
have to live with it for now.
Interface loses both the old get/set/cap interface, plus the
configuration interface. It now returns either properties() or
options(). Both return a Settings& object. There's also helpers for
accessing individual properties and options by string lookup.
Properties are immutable traits of the hardware itself: CPU version, PPU
VRAM size, boot ROM information, etc.
Options are mutable traits that users may change.
The idea with nall/settings is to build out a kind of extremely complex
configuration object that'll do everything we'd ever want:
- allow recursive children settings similar to Markup::Node
- access values directly without dynamic_cast (type erasure) or
string conversion (Markup::Node style)
- serialize to and unserialize from BML
- support valid values to guarantee that the settings are never in an
invalid state
- support latching of values to cache reads without another separate
variable (so the GUI can modify any variables at any time safely)
Todo:
- allow binding callback functions on assignment, so that eg changing
video/colorEmulation will regenerate the video palette
- provide a hint on whether an option can be changed dynamically at
run-time, or only statically at first load
- provide descriptions for each setting
And then once the class is fully fleshed out, I want to build a tool
that will generate a fancy modal hiro Window from a Settings& object.
Once that is complete, we'll then have System → Options to configure
per-emulator settings (like bsnes PPU stuff) that otherwise doesn't fit
into higan's GUI. We will be exposing the extended Super Famicom options
to the bsnes GUI, of course. That's the emulator tab there.
Next up, higan's systems tab will need to generate blank default
property files for each system, and let you configure system properties
from this screen. That's going to mean that, by allowing the same system
to appear multiple times, that each entry gets its own options file,
which will have to be stored somewhere.
And to do all of that, we really need to work out how to handle regions
first. It may have to be something radical like FitzRoy's idea, or it
may be that we can come up with something a little less drastic. But I
have no idea right now ...
What I'd really like to do is start trying to get bsnes v107 out
already. The two things holding it up are: fixing the desync between the
settings.bml GUI settings and options.bml SNES properties (I know what's
wrong, I just have to fix it), and getting XAudio2 DRC working (I copied
BearOso's implementation details, but it just doesn't work for me ...).
Then I also have to install Windows, set up a dev environment with
msys2, and build it all.
Lots and lots of work ...
2019-01-25 13:35:11 +09:00
|
|
|
template<typename T, typename U, typename... P> constexpr auto max(const T& t, const U& u, P&&... p) -> T {
|
2022-09-13 16:47:47 +09:00
|
|
|
return t > u ? max(t, std::forward<P>(p)...) : max(u, std::forward<P>(p)...);
|
2010-08-09 22:28:56 +09:00
|
|
|
}
|
|
|
|
|
|
2019-01-16 09:46:42 +09:00
|
|
|
}
|