2016-01-07 08:14:33 +00:00
|
|
|
#pragma once
|
2011-12-12 10:59:53 +00:00
|
|
|
|
2016-01-07 08:14:33 +00:00
|
|
|
namespace nall { namespace mosaic {
|
2011-12-12 10:59:53 +00:00
|
|
|
|
|
|
|
struct context {
|
2015-12-14 09:41:06 +00:00
|
|
|
context() {
|
|
|
|
reset();
|
|
|
|
}
|
|
|
|
|
|
|
|
auto objectWidth() const -> uint { return blockWidth * tileWidth * mosaicWidth + paddingWidth; }
|
|
|
|
auto objectHeight() const -> uint { return blockHeight * tileHeight * mosaicHeight + paddingHeight; }
|
|
|
|
auto objectSize() const -> uint {
|
|
|
|
uint size = blockStride * tileWidth * tileHeight * mosaicWidth * mosaicHeight
|
|
|
|
+ blockOffset * tileHeight * mosaicWidth * mosaicHeight
|
|
|
|
+ tileStride * mosaicWidth * mosaicHeight
|
|
|
|
+ tileOffset * mosaicHeight;
|
2011-12-12 10:59:53 +00:00
|
|
|
return max(1u, size);
|
|
|
|
}
|
|
|
|
|
2015-12-14 09:41:06 +00:00
|
|
|
auto reset() -> void {
|
|
|
|
offset = 0;
|
|
|
|
width = 0;
|
|
|
|
height = 0;
|
|
|
|
count = 0;
|
|
|
|
|
|
|
|
endian = 1;
|
|
|
|
order = 0;
|
|
|
|
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 = 0;
|
|
|
|
palette.reset();
|
|
|
|
}
|
|
|
|
|
|
|
|
auto eval(const string& expression) -> uint {
|
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
|
|
|
}
|
|
|
|
|
2015-12-14 09:41:06 +00:00
|
|
|
auto eval(vector<uint>& buffer, const string& expression_) -> void {
|
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(?*) ?*")) {
|
2016-05-16 09:51:12 +00:00
|
|
|
item.trimLeft("f(", 1L);
|
2015-07-14 09:32:43 +00:00
|
|
|
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
|
|
|
|
2015-12-14 09:41:06 +00:00
|
|
|
uint length = eval(args(0, "0"));
|
|
|
|
uint offset = eval(args(1, "0"));
|
|
|
|
uint stride = eval(args(2, "0"));
|
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(args.size() < 2) offset = buffer.size();
|
|
|
|
if(args.size() < 3) stride = 1;
|
|
|
|
|
2015-12-14 09:41:06 +00:00
|
|
|
for(uint n = 0; n < length; n++) {
|
2011-12-12 10:59:53 +00:00
|
|
|
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*")) {
|
2015-12-14 09:41:06 +00:00
|
|
|
uint offset = 0;
|
2016-05-16 09:51:12 +00:00
|
|
|
item.trimLeft("base64", 1L);
|
2013-07-29 09:42:45 +00:00
|
|
|
if(item.match("(?*) *")) {
|
2016-05-16 09:51:12 +00:00
|
|
|
item.trimLeft("(", 1L);
|
2015-07-14 09:32:43 +00:00
|
|
|
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 *")) {
|
2016-05-16 09:51:12 +00:00
|
|
|
item.trimLeft("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
|
|
|
//...
|
2016-05-16 09:51:12 +00:00
|
|
|
} else if(item) {
|
2011-12-12 10:59:53 +00:00
|
|
|
buffer.append(eval(item));
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-12-14 09:41:06 +00:00
|
|
|
auto parse(const string& data) -> void {
|
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();
|
|
|
|
}
|
|
|
|
|
2015-12-14 09:41:06 +00:00
|
|
|
auto load(const string& filename) -> bool {
|
|
|
|
if(auto filedata = string::read(filename)) {
|
|
|
|
parse(filedata);
|
|
|
|
return true;
|
|
|
|
}
|
|
|
|
return false;
|
2011-12-12 10:59:53 +00:00
|
|
|
}
|
|
|
|
|
2015-12-14 09:41:06 +00:00
|
|
|
auto sanitize() -> void {
|
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
|
|
|
}
|
|
|
|
|
2015-12-14 09:41:06 +00:00
|
|
|
uint offset;
|
|
|
|
uint width;
|
|
|
|
uint height;
|
|
|
|
uint count;
|
|
|
|
|
|
|
|
bool endian; //0 = lsb, 1 = msb
|
|
|
|
bool order; //0 = linear, 1 = planar
|
|
|
|
uint depth; //1 - 24bpp
|
|
|
|
|
|
|
|
uint blockWidth;
|
|
|
|
uint blockHeight;
|
|
|
|
uint blockStride;
|
|
|
|
uint blockOffset;
|
|
|
|
vector<uint> block;
|
|
|
|
|
|
|
|
uint tileWidth;
|
|
|
|
uint tileHeight;
|
|
|
|
uint tileStride;
|
|
|
|
uint tileOffset;
|
|
|
|
vector<uint> tile;
|
|
|
|
|
|
|
|
uint mosaicWidth;
|
|
|
|
uint mosaicHeight;
|
|
|
|
uint mosaicStride;
|
|
|
|
uint mosaicOffset;
|
|
|
|
vector<uint> mosaic;
|
|
|
|
|
|
|
|
uint paddingWidth;
|
|
|
|
uint paddingHeight;
|
|
|
|
uint paddingColor;
|
|
|
|
vector<uint> palette;
|
2011-12-12 10:59:53 +00:00
|
|
|
};
|
|
|
|
|
2016-01-07 08:14:33 +00:00
|
|
|
}}
|