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) {
|
2011-12-12 10:59:53 +00:00
|
|
|
intmax_t result;
|
|
|
|
if(fixedpoint::eval(expression, result) == false) return 0u;
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
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) {
|
2011-12-12 10:59:53 +00:00
|
|
|
item.trim();
|
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(item.wildcard("f(?*) ?*")) {
|
|
|
|
item.ltrim<1>("f(");
|
|
|
|
lstring part = item.split<1>(") ");
|
|
|
|
lstring args = part[0].split<3>(";");
|
|
|
|
for(auto &item : args) item.trim();
|
|
|
|
|
|
|
|
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;
|
|
|
|
}
|
|
|
|
} else if(item.wildcard("base64*")) {
|
|
|
|
unsigned offset = 0;
|
|
|
|
item.ltrim<1>("base64");
|
|
|
|
if(item.wildcard("(?*) *")) {
|
|
|
|
item.ltrim<1>("(");
|
|
|
|
lstring part = item.split<1>(") ");
|
|
|
|
offset = eval(part[0]);
|
|
|
|
item = part(1, "");
|
|
|
|
}
|
|
|
|
item.trim();
|
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
|
|
|
}
|
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.wildcard("file *")) {
|
|
|
|
item.ltrim<1>("file ");
|
|
|
|
item.trim();
|
|
|
|
//...
|
|
|
|
} 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) {
|
2011-12-12 10:59:53 +00:00
|
|
|
lstring part = line.split<1>(":");
|
|
|
|
if(part.size() != 2) continue;
|
|
|
|
part[0].trim();
|
|
|
|
part[1].trim();
|
|
|
|
|
|
|
|
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) {
|
2011-12-12 10:59:53 +00:00
|
|
|
string filedata;
|
|
|
|
if(filedata.readfile(filename) == false) return false;
|
|
|
|
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-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;
|
|
|
|
paddingColor = 0x000000;
|
|
|
|
palette.reset();
|
|
|
|
}
|
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
context() {
|
2011-12-12 10:59:53 +00:00
|
|
|
reset();
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|