2011-12-12 10:59:53 +00:00
|
|
|
#ifdef NALL_MOSAIC_INTERNAL_HPP
|
|
|
|
|
|
|
|
namespace nall {
|
|
|
|
namespace mosaic {
|
|
|
|
|
|
|
|
struct context {
|
|
|
|
unsigned offset;
|
|
|
|
unsigned width;
|
|
|
|
unsigned height;
|
|
|
|
unsigned count;
|
|
|
|
|
Update to v084r05 release.
(note: before the post announcing this release, there had been
a discussion of a performance optimisation that made the Super Scope
emulation a lot faster, but caused problems for the Justifier perpheral)
byuu says:
Spent a good two hours trying things to no avail.
I was trying to allow the CPU to run ahead, and sync on accesses to
$4016/4017/4201/4213, but that doesn't work because the controllers have
access to strobe IObit at will.
The codebase is really starting to get difficult to work with. I am
guessing because the days of massive development are long over, and the
code is starting to age.
Jonas' fix works 98% of the time, but there's still a few missed shots
here and there. So that's not going to work either.
So ... I give up. I've disabled the speed hack, so that it works 100% of
the time.
Did the same for the Super Scope: it may not have the same problem, but
I like consistency and don't feel like taking the chance.
This doesn't affect the mouse, since the mouse does not latch the
counters to indicate its X/Y position.
Speed hit is 92->82fps (accuracy profile), but only for Super Scope and
Justifier games.
But ... at least it works now. Slow and working is better than fast and
broken.
I appreciate the help in researching the issue, Jonas and krom.
Also pulled in phoenix/Makefile, which simplifies ui/Makefile.
Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on
Debian.
2011-12-18 03:19:45 +00:00
|
|
|
bool endian; //0 = lsb, 1 = msb
|
|
|
|
bool order; //0 = linear, 1 = planar
|
|
|
|
unsigned depth; //1 - 24bpp
|
2011-12-12 10:59:53 +00:00
|
|
|
|
|
|
|
unsigned blockWidth;
|
|
|
|
unsigned blockHeight;
|
|
|
|
unsigned blockStride;
|
|
|
|
unsigned blockOffset;
|
Update to v088r02 release.
byuu says:
Basically, the current implementation of nall/array is deprecated now.
The old method was for non-reference types, it acted like a vector for
POD types (raw memory allocation instead of placement new construction.)
And for reference types, it acted like an unordered set. Yeah, not good.
As of right now, nall/array is no longer used. The vector type usage was
replaced with actual vectors.
I've created nall/set, which now contains the specialization for
reference types.
nall/set basically acts much like std::unordered_set. No auto-sort, only
one of each type is allowed, automatic growth.
This will be the same both for reference and non-reference types ...
however, the non-reference type wasn't implemented just yet.
Future plans for nall/array are for it to be a statically allocated
block of memory, ala array<type, size>, which is meant for RAII memory
usage.
Have to work on the specifics, eg the size as a template parameter may
be problematic. I'd like to return allocated chunks of memory (eg
file::read) in this container so that I don't have to manually free the
data anymore.
I also removed nall/moduloarray, and moved that into the SNES DSP class,
since that's the only thing that uses it.
2012-04-26 10:56:15 +00:00
|
|
|
vector<unsigned> block;
|
2011-12-12 10:59:53 +00:00
|
|
|
|
|
|
|
unsigned tileWidth;
|
|
|
|
unsigned tileHeight;
|
|
|
|
unsigned tileStride;
|
|
|
|
unsigned tileOffset;
|
Update to v088r02 release.
byuu says:
Basically, the current implementation of nall/array is deprecated now.
The old method was for non-reference types, it acted like a vector for
POD types (raw memory allocation instead of placement new construction.)
And for reference types, it acted like an unordered set. Yeah, not good.
As of right now, nall/array is no longer used. The vector type usage was
replaced with actual vectors.
I've created nall/set, which now contains the specialization for
reference types.
nall/set basically acts much like std::unordered_set. No auto-sort, only
one of each type is allowed, automatic growth.
This will be the same both for reference and non-reference types ...
however, the non-reference type wasn't implemented just yet.
Future plans for nall/array are for it to be a statically allocated
block of memory, ala array<type, size>, which is meant for RAII memory
usage.
Have to work on the specifics, eg the size as a template parameter may
be problematic. I'd like to return allocated chunks of memory (eg
file::read) in this container so that I don't have to manually free the
data anymore.
I also removed nall/moduloarray, and moved that into the SNES DSP class,
since that's the only thing that uses it.
2012-04-26 10:56:15 +00:00
|
|
|
vector<unsigned> tile;
|
2011-12-12 10:59:53 +00:00
|
|
|
|
|
|
|
unsigned mosaicWidth;
|
|
|
|
unsigned mosaicHeight;
|
|
|
|
unsigned mosaicStride;
|
|
|
|
unsigned mosaicOffset;
|
Update to v088r02 release.
byuu says:
Basically, the current implementation of nall/array is deprecated now.
The old method was for non-reference types, it acted like a vector for
POD types (raw memory allocation instead of placement new construction.)
And for reference types, it acted like an unordered set. Yeah, not good.
As of right now, nall/array is no longer used. The vector type usage was
replaced with actual vectors.
I've created nall/set, which now contains the specialization for
reference types.
nall/set basically acts much like std::unordered_set. No auto-sort, only
one of each type is allowed, automatic growth.
This will be the same both for reference and non-reference types ...
however, the non-reference type wasn't implemented just yet.
Future plans for nall/array are for it to be a statically allocated
block of memory, ala array<type, size>, which is meant for RAII memory
usage.
Have to work on the specifics, eg the size as a template parameter may
be problematic. I'd like to return allocated chunks of memory (eg
file::read) in this container so that I don't have to manually free the
data anymore.
I also removed nall/moduloarray, and moved that into the SNES DSP class,
since that's the only thing that uses it.
2012-04-26 10:56:15 +00:00
|
|
|
vector<unsigned> mosaic;
|
2011-12-12 10:59:53 +00:00
|
|
|
|
|
|
|
unsigned paddingWidth;
|
|
|
|
unsigned paddingHeight;
|
|
|
|
unsigned paddingColor;
|
Update to v088r02 release.
byuu says:
Basically, the current implementation of nall/array is deprecated now.
The old method was for non-reference types, it acted like a vector for
POD types (raw memory allocation instead of placement new construction.)
And for reference types, it acted like an unordered set. Yeah, not good.
As of right now, nall/array is no longer used. The vector type usage was
replaced with actual vectors.
I've created nall/set, which now contains the specialization for
reference types.
nall/set basically acts much like std::unordered_set. No auto-sort, only
one of each type is allowed, automatic growth.
This will be the same both for reference and non-reference types ...
however, the non-reference type wasn't implemented just yet.
Future plans for nall/array are for it to be a statically allocated
block of memory, ala array<type, size>, which is meant for RAII memory
usage.
Have to work on the specifics, eg the size as a template parameter may
be problematic. I'd like to return allocated chunks of memory (eg
file::read) in this container so that I don't have to manually free the
data anymore.
I also removed nall/moduloarray, and moved that into the SNES DSP class,
since that's the only thing that uses it.
2012-04-26 10:56:15 +00:00
|
|
|
vector<unsigned> palette;
|
2011-12-12 10:59:53 +00:00
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
unsigned objectWidth() const { return blockWidth * tileWidth * mosaicWidth + paddingWidth; }
|
|
|
|
unsigned objectHeight() const { return blockHeight * tileHeight * mosaicHeight + paddingHeight; }
|
|
|
|
unsigned objectSize() const {
|
2011-12-12 10:59:53 +00:00
|
|
|
unsigned size = blockStride * tileWidth * tileHeight * mosaicWidth * mosaicHeight
|
|
|
|
+ blockOffset * tileHeight * mosaicWidth * mosaicHeight
|
|
|
|
+ tileStride * mosaicWidth * mosaicHeight
|
|
|
|
+ tileOffset * mosaicHeight;
|
|
|
|
return max(1u, size);
|
|
|
|
}
|
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
unsigned eval(const string& expression) {
|
2013-07-29 09:42:45 +00:00
|
|
|
if(auto result = Eval::integer(expression)) return result();
|
|
|
|
return 0u;
|
2011-12-12 10:59:53 +00:00
|
|
|
}
|
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
void eval(vector<unsigned>& buffer, const string& expression_) {
|
Update to v084r05 release.
(note: before the post announcing this release, there had been
a discussion of a performance optimisation that made the Super Scope
emulation a lot faster, but caused problems for the Justifier perpheral)
byuu says:
Spent a good two hours trying things to no avail.
I was trying to allow the CPU to run ahead, and sync on accesses to
$4016/4017/4201/4213, but that doesn't work because the controllers have
access to strobe IObit at will.
The codebase is really starting to get difficult to work with. I am
guessing because the days of massive development are long over, and the
code is starting to age.
Jonas' fix works 98% of the time, but there's still a few missed shots
here and there. So that's not going to work either.
So ... I give up. I've disabled the speed hack, so that it works 100% of
the time.
Did the same for the Super Scope: it may not have the same problem, but
I like consistency and don't feel like taking the chance.
This doesn't affect the mouse, since the mouse does not latch the
counters to indicate its X/Y position.
Speed hit is 92->82fps (accuracy profile), but only for Super Scope and
Justifier games.
But ... at least it works now. Slow and working is better than fast and
broken.
I appreciate the help in researching the issue, Jonas and krom.
Also pulled in phoenix/Makefile, which simplifies ui/Makefile.
Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on
Debian.
2011-12-18 03:19:45 +00:00
|
|
|
string expression = expression_;
|
|
|
|
bool function = false;
|
2013-05-02 11:25:45 +00:00
|
|
|
for(auto& c : expression) {
|
Update to v084r05 release.
(note: before the post announcing this release, there had been
a discussion of a performance optimisation that made the Super Scope
emulation a lot faster, but caused problems for the Justifier perpheral)
byuu says:
Spent a good two hours trying things to no avail.
I was trying to allow the CPU to run ahead, and sync on accesses to
$4016/4017/4201/4213, but that doesn't work because the controllers have
access to strobe IObit at will.
The codebase is really starting to get difficult to work with. I am
guessing because the days of massive development are long over, and the
code is starting to age.
Jonas' fix works 98% of the time, but there's still a few missed shots
here and there. So that's not going to work either.
So ... I give up. I've disabled the speed hack, so that it works 100% of
the time.
Did the same for the Super Scope: it may not have the same problem, but
I like consistency and don't feel like taking the chance.
This doesn't affect the mouse, since the mouse does not latch the
counters to indicate its X/Y position.
Speed hit is 92->82fps (accuracy profile), but only for Super Scope and
Justifier games.
But ... at least it works now. Slow and working is better than fast and
broken.
I appreciate the help in researching the issue, Jonas and krom.
Also pulled in phoenix/Makefile, which simplifies ui/Makefile.
Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on
Debian.
2011-12-18 03:19:45 +00:00
|
|
|
if(c == '(') function = true;
|
|
|
|
if(c == ')') function = false;
|
|
|
|
if(c == ',' && function == true) c = ';';
|
|
|
|
}
|
|
|
|
|
2011-12-12 10:59:53 +00:00
|
|
|
lstring list = expression.split(",");
|
2013-05-02 11:25:45 +00:00
|
|
|
for(auto& item : list) {
|
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 10:10:46 +00:00
|
|
|
item.strip();
|
2013-07-29 09:42:45 +00:00
|
|
|
if(item.match("f(?*) ?*")) {
|
2015-07-14 09:32:43 +00:00
|
|
|
item.ltrim("f(", 1L);
|
|
|
|
lstring part = item.split(") ", 1L);
|
|
|
|
lstring args = part[0].split(";", 3L).strip();
|
Update to v084r05 release.
(note: before the post announcing this release, there had been
a discussion of a performance optimisation that made the Super Scope
emulation a lot faster, but caused problems for the Justifier perpheral)
byuu says:
Spent a good two hours trying things to no avail.
I was trying to allow the CPU to run ahead, and sync on accesses to
$4016/4017/4201/4213, but that doesn't work because the controllers have
access to strobe IObit at will.
The codebase is really starting to get difficult to work with. I am
guessing because the days of massive development are long over, and the
code is starting to age.
Jonas' fix works 98% of the time, but there's still a few missed shots
here and there. So that's not going to work either.
So ... I give up. I've disabled the speed hack, so that it works 100% of
the time.
Did the same for the Super Scope: it may not have the same problem, but
I like consistency and don't feel like taking the chance.
This doesn't affect the mouse, since the mouse does not latch the
counters to indicate its X/Y position.
Speed hit is 92->82fps (accuracy profile), but only for Super Scope and
Justifier games.
But ... at least it works now. Slow and working is better than fast and
broken.
I appreciate the help in researching the issue, Jonas and krom.
Also pulled in phoenix/Makefile, which simplifies ui/Makefile.
Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on
Debian.
2011-12-18 03:19:45 +00:00
|
|
|
|
|
|
|
unsigned length = eval(args(0, "0"));
|
|
|
|
unsigned offset = eval(args(1, "0"));
|
|
|
|
unsigned stride = eval(args(2, "0"));
|
|
|
|
if(args.size() < 2) offset = buffer.size();
|
|
|
|
if(args.size() < 3) stride = 1;
|
|
|
|
|
2011-12-12 10:59:53 +00:00
|
|
|
for(unsigned n = 0; n < length; n++) {
|
|
|
|
string fn = part[1];
|
2013-05-05 09:21:30 +00:00
|
|
|
fn.replace("n", string{n});
|
|
|
|
fn.replace("o", string{offset});
|
|
|
|
fn.replace("p", string{buffer.size()});
|
Update to v084r05 release.
(note: before the post announcing this release, there had been
a discussion of a performance optimisation that made the Super Scope
emulation a lot faster, but caused problems for the Justifier perpheral)
byuu says:
Spent a good two hours trying things to no avail.
I was trying to allow the CPU to run ahead, and sync on accesses to
$4016/4017/4201/4213, but that doesn't work because the controllers have
access to strobe IObit at will.
The codebase is really starting to get difficult to work with. I am
guessing because the days of massive development are long over, and the
code is starting to age.
Jonas' fix works 98% of the time, but there's still a few missed shots
here and there. So that's not going to work either.
So ... I give up. I've disabled the speed hack, so that it works 100% of
the time.
Did the same for the Super Scope: it may not have the same problem, but
I like consistency and don't feel like taking the chance.
This doesn't affect the mouse, since the mouse does not latch the
counters to indicate its X/Y position.
Speed hit is 92->82fps (accuracy profile), but only for Super Scope and
Justifier games.
But ... at least it works now. Slow and working is better than fast and
broken.
I appreciate the help in researching the issue, Jonas and krom.
Also pulled in phoenix/Makefile, which simplifies ui/Makefile.
Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on
Debian.
2011-12-18 03:19:45 +00:00
|
|
|
buffer.resize(offset + 1);
|
|
|
|
buffer[offset] = eval(fn);
|
|
|
|
offset += stride;
|
|
|
|
}
|
2013-07-29 09:42:45 +00:00
|
|
|
} else if(item.match("base64*")) {
|
Update to v084r05 release.
(note: before the post announcing this release, there had been
a discussion of a performance optimisation that made the Super Scope
emulation a lot faster, but caused problems for the Justifier perpheral)
byuu says:
Spent a good two hours trying things to no avail.
I was trying to allow the CPU to run ahead, and sync on accesses to
$4016/4017/4201/4213, but that doesn't work because the controllers have
access to strobe IObit at will.
The codebase is really starting to get difficult to work with. I am
guessing because the days of massive development are long over, and the
code is starting to age.
Jonas' fix works 98% of the time, but there's still a few missed shots
here and there. So that's not going to work either.
So ... I give up. I've disabled the speed hack, so that it works 100% of
the time.
Did the same for the Super Scope: it may not have the same problem, but
I like consistency and don't feel like taking the chance.
This doesn't affect the mouse, since the mouse does not latch the
counters to indicate its X/Y position.
Speed hit is 92->82fps (accuracy profile), but only for Super Scope and
Justifier games.
But ... at least it works now. Slow and working is better than fast and
broken.
I appreciate the help in researching the issue, Jonas and krom.
Also pulled in phoenix/Makefile, which simplifies ui/Makefile.
Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on
Debian.
2011-12-18 03:19:45 +00:00
|
|
|
unsigned offset = 0;
|
2015-07-14 09:32:43 +00:00
|
|
|
item.ltrim("base64", 1L);
|
2013-07-29 09:42:45 +00:00
|
|
|
if(item.match("(?*) *")) {
|
2015-07-14 09:32:43 +00:00
|
|
|
item.ltrim("(", 1L);
|
|
|
|
lstring part = item.split(") ", 1L);
|
Update to v084r05 release.
(note: before the post announcing this release, there had been
a discussion of a performance optimisation that made the Super Scope
emulation a lot faster, but caused problems for the Justifier perpheral)
byuu says:
Spent a good two hours trying things to no avail.
I was trying to allow the CPU to run ahead, and sync on accesses to
$4016/4017/4201/4213, but that doesn't work because the controllers have
access to strobe IObit at will.
The codebase is really starting to get difficult to work with. I am
guessing because the days of massive development are long over, and the
code is starting to age.
Jonas' fix works 98% of the time, but there's still a few missed shots
here and there. So that's not going to work either.
So ... I give up. I've disabled the speed hack, so that it works 100% of
the time.
Did the same for the Super Scope: it may not have the same problem, but
I like consistency and don't feel like taking the chance.
This doesn't affect the mouse, since the mouse does not latch the
counters to indicate its X/Y position.
Speed hit is 92->82fps (accuracy profile), but only for Super Scope and
Justifier games.
But ... at least it works now. Slow and working is better than fast and
broken.
I appreciate the help in researching the issue, Jonas and krom.
Also pulled in phoenix/Makefile, which simplifies ui/Makefile.
Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on
Debian.
2011-12-18 03:19:45 +00:00
|
|
|
offset = eval(part[0]);
|
|
|
|
item = part(1, "");
|
|
|
|
}
|
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 10:10:46 +00:00
|
|
|
item.strip();
|
2013-05-02 11:25:45 +00:00
|
|
|
for(auto& c : item) {
|
Update to v084r05 release.
(note: before the post announcing this release, there had been
a discussion of a performance optimisation that made the Super Scope
emulation a lot faster, but caused problems for the Justifier perpheral)
byuu says:
Spent a good two hours trying things to no avail.
I was trying to allow the CPU to run ahead, and sync on accesses to
$4016/4017/4201/4213, but that doesn't work because the controllers have
access to strobe IObit at will.
The codebase is really starting to get difficult to work with. I am
guessing because the days of massive development are long over, and the
code is starting to age.
Jonas' fix works 98% of the time, but there's still a few missed shots
here and there. So that's not going to work either.
So ... I give up. I've disabled the speed hack, so that it works 100% of
the time.
Did the same for the Super Scope: it may not have the same problem, but
I like consistency and don't feel like taking the chance.
This doesn't affect the mouse, since the mouse does not latch the
counters to indicate its X/Y position.
Speed hit is 92->82fps (accuracy profile), but only for Super Scope and
Justifier games.
But ... at least it works now. Slow and working is better than fast and
broken.
I appreciate the help in researching the issue, Jonas and krom.
Also pulled in phoenix/Makefile, which simplifies ui/Makefile.
Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on
Debian.
2011-12-18 03:19:45 +00:00
|
|
|
if(c >= 'A' && c <= 'Z') buffer.append(offset + c - 'A' + 0);
|
|
|
|
if(c >= 'a' && c <= 'z') buffer.append(offset + c - 'a' + 26);
|
|
|
|
if(c >= '0' && c <= '9') buffer.append(offset + c - '0' + 52);
|
|
|
|
if(c == '-') buffer.append(offset + 62);
|
|
|
|
if(c == '_') buffer.append(offset + 63);
|
2011-12-12 10:59:53 +00:00
|
|
|
}
|
2013-07-29 09:42:45 +00:00
|
|
|
} else if(item.match("file *")) {
|
2015-07-14 09:32:43 +00:00
|
|
|
item.ltrim("file ", 1L);
|
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 10:10:46 +00:00
|
|
|
item.strip();
|
Update to v084r05 release.
(note: before the post announcing this release, there had been
a discussion of a performance optimisation that made the Super Scope
emulation a lot faster, but caused problems for the Justifier perpheral)
byuu says:
Spent a good two hours trying things to no avail.
I was trying to allow the CPU to run ahead, and sync on accesses to
$4016/4017/4201/4213, but that doesn't work because the controllers have
access to strobe IObit at will.
The codebase is really starting to get difficult to work with. I am
guessing because the days of massive development are long over, and the
code is starting to age.
Jonas' fix works 98% of the time, but there's still a few missed shots
here and there. So that's not going to work either.
So ... I give up. I've disabled the speed hack, so that it works 100% of
the time.
Did the same for the Super Scope: it may not have the same problem, but
I like consistency and don't feel like taking the chance.
This doesn't affect the mouse, since the mouse does not latch the
counters to indicate its X/Y position.
Speed hit is 92->82fps (accuracy profile), but only for Super Scope and
Justifier games.
But ... at least it works now. Slow and working is better than fast and
broken.
I appreciate the help in researching the issue, Jonas and krom.
Also pulled in phoenix/Makefile, which simplifies ui/Makefile.
Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on
Debian.
2011-12-18 03:19:45 +00:00
|
|
|
//...
|
|
|
|
} else if(item.empty() == false) {
|
2011-12-12 10:59:53 +00:00
|
|
|
buffer.append(eval(item));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
void parse(const string& data) {
|
2011-12-12 10:59:53 +00:00
|
|
|
reset();
|
|
|
|
|
|
|
|
lstring lines = data.split("\n");
|
2013-05-02 11:25:45 +00:00
|
|
|
for(auto& line : lines) {
|
2015-07-14 09:32:43 +00:00
|
|
|
lstring part = line.split(":", 1L).strip();
|
2011-12-12 10:59:53 +00:00
|
|
|
if(part.size() != 2) continue;
|
|
|
|
|
|
|
|
if(part[0] == "offset") offset = eval(part[1]);
|
|
|
|
if(part[0] == "width") width = eval(part[1]);
|
|
|
|
if(part[0] == "height") height = eval(part[1]);
|
|
|
|
if(part[0] == "count") count = eval(part[1]);
|
|
|
|
|
|
|
|
if(part[0] == "endian") endian = eval(part[1]);
|
Update to v084r05 release.
(note: before the post announcing this release, there had been
a discussion of a performance optimisation that made the Super Scope
emulation a lot faster, but caused problems for the Justifier perpheral)
byuu says:
Spent a good two hours trying things to no avail.
I was trying to allow the CPU to run ahead, and sync on accesses to
$4016/4017/4201/4213, but that doesn't work because the controllers have
access to strobe IObit at will.
The codebase is really starting to get difficult to work with. I am
guessing because the days of massive development are long over, and the
code is starting to age.
Jonas' fix works 98% of the time, but there's still a few missed shots
here and there. So that's not going to work either.
So ... I give up. I've disabled the speed hack, so that it works 100% of
the time.
Did the same for the Super Scope: it may not have the same problem, but
I like consistency and don't feel like taking the chance.
This doesn't affect the mouse, since the mouse does not latch the
counters to indicate its X/Y position.
Speed hit is 92->82fps (accuracy profile), but only for Super Scope and
Justifier games.
But ... at least it works now. Slow and working is better than fast and
broken.
I appreciate the help in researching the issue, Jonas and krom.
Also pulled in phoenix/Makefile, which simplifies ui/Makefile.
Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on
Debian.
2011-12-18 03:19:45 +00:00
|
|
|
if(part[0] == "order") order = eval(part[1]);
|
2011-12-12 10:59:53 +00:00
|
|
|
if(part[0] == "depth") depth = eval(part[1]);
|
|
|
|
|
|
|
|
if(part[0] == "blockWidth") blockWidth = eval(part[1]);
|
|
|
|
if(part[0] == "blockHeight") blockHeight = eval(part[1]);
|
|
|
|
if(part[0] == "blockStride") blockStride = eval(part[1]);
|
|
|
|
if(part[0] == "blockOffset") blockOffset = eval(part[1]);
|
|
|
|
if(part[0] == "block") eval(block, part[1]);
|
|
|
|
|
|
|
|
if(part[0] == "tileWidth") tileWidth = eval(part[1]);
|
|
|
|
if(part[0] == "tileHeight") tileHeight = eval(part[1]);
|
|
|
|
if(part[0] == "tileStride") tileStride = eval(part[1]);
|
|
|
|
if(part[0] == "tileOffset") tileOffset = eval(part[1]);
|
|
|
|
if(part[0] == "tile") eval(tile, part[1]);
|
|
|
|
|
|
|
|
if(part[0] == "mosaicWidth") mosaicWidth = eval(part[1]);
|
|
|
|
if(part[0] == "mosaicHeight") mosaicHeight = eval(part[1]);
|
|
|
|
if(part[0] == "mosaicStride") mosaicStride = eval(part[1]);
|
|
|
|
if(part[0] == "mosaicOffset") mosaicOffset = eval(part[1]);
|
|
|
|
if(part[0] == "mosaic") eval(mosaic, part[1]);
|
|
|
|
|
|
|
|
if(part[0] == "paddingWidth") paddingWidth = eval(part[1]);
|
|
|
|
if(part[0] == "paddingHeight") paddingHeight = eval(part[1]);
|
|
|
|
if(part[0] == "paddingColor") paddingColor = eval(part[1]);
|
|
|
|
if(part[0] == "palette") eval(palette, part[1]);
|
|
|
|
}
|
|
|
|
|
|
|
|
sanitize();
|
|
|
|
}
|
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
bool load(const string& filename) {
|
2013-07-29 09:42:45 +00:00
|
|
|
string filedata = string::read(filename);
|
|
|
|
if(filedata.empty()) return false;
|
2011-12-12 10:59:53 +00:00
|
|
|
parse(filedata);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
void sanitize() {
|
2011-12-12 10:59:53 +00:00
|
|
|
if(depth < 1) depth = 1;
|
|
|
|
if(depth > 24) depth = 24;
|
|
|
|
|
|
|
|
if(blockWidth < 1) blockWidth = 1;
|
|
|
|
if(blockHeight < 1) blockHeight = 1;
|
|
|
|
|
|
|
|
if(tileWidth < 1) tileWidth = 1;
|
|
|
|
if(tileHeight < 1) tileHeight = 1;
|
|
|
|
|
|
|
|
if(mosaicWidth < 1) mosaicWidth = 1;
|
|
|
|
if(mosaicHeight < 1) mosaicHeight = 1;
|
2013-12-03 10:01:59 +00:00
|
|
|
|
|
|
|
//set alpha to full opacity
|
|
|
|
paddingColor |= 255u << 24;
|
|
|
|
for(auto& color : palette) color |= 255u << 24;
|
2011-12-12 10:59:53 +00:00
|
|
|
}
|
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
void reset() {
|
2011-12-12 10:59:53 +00:00
|
|
|
offset = 0;
|
|
|
|
width = 0;
|
|
|
|
height = 0;
|
|
|
|
count = 0;
|
|
|
|
|
|
|
|
endian = 1;
|
Update to v084r05 release.
(note: before the post announcing this release, there had been
a discussion of a performance optimisation that made the Super Scope
emulation a lot faster, but caused problems for the Justifier perpheral)
byuu says:
Spent a good two hours trying things to no avail.
I was trying to allow the CPU to run ahead, and sync on accesses to
$4016/4017/4201/4213, but that doesn't work because the controllers have
access to strobe IObit at will.
The codebase is really starting to get difficult to work with. I am
guessing because the days of massive development are long over, and the
code is starting to age.
Jonas' fix works 98% of the time, but there's still a few missed shots
here and there. So that's not going to work either.
So ... I give up. I've disabled the speed hack, so that it works 100% of
the time.
Did the same for the Super Scope: it may not have the same problem, but
I like consistency and don't feel like taking the chance.
This doesn't affect the mouse, since the mouse does not latch the
counters to indicate its X/Y position.
Speed hit is 92->82fps (accuracy profile), but only for Super Scope and
Justifier games.
But ... at least it works now. Slow and working is better than fast and
broken.
I appreciate the help in researching the issue, Jonas and krom.
Also pulled in phoenix/Makefile, which simplifies ui/Makefile.
Linux port defaults to GTK+ now. I can't get QGtkStyle to look good on
Debian.
2011-12-18 03:19:45 +00:00
|
|
|
order = 0;
|
2011-12-12 10:59:53 +00:00
|
|
|
depth = 1;
|
|
|
|
|
|
|
|
blockWidth = 1;
|
|
|
|
blockHeight = 1;
|
|
|
|
blockStride = 0;
|
|
|
|
blockOffset = 0;
|
|
|
|
block.reset();
|
|
|
|
|
|
|
|
tileWidth = 1;
|
|
|
|
tileHeight = 1;
|
|
|
|
tileStride = 0;
|
|
|
|
tileOffset = 0;
|
|
|
|
tile.reset();
|
|
|
|
|
|
|
|
mosaicWidth = 1;
|
|
|
|
mosaicHeight = 1;
|
|
|
|
mosaicStride = 0;
|
|
|
|
mosaicOffset = 0;
|
|
|
|
mosaic.reset();
|
|
|
|
|
|
|
|
paddingWidth = 0;
|
|
|
|
paddingHeight = 0;
|
2013-12-03 10:01:59 +00:00
|
|
|
paddingColor = 0;
|
2011-12-12 10:59:53 +00:00
|
|
|
palette.reset();
|
|
|
|
}
|
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
context() {
|
2011-12-12 10:59:53 +00:00
|
|
|
reset();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|