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 parser {
|
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
|
|
|
//export from bitstream to canvas
|
Update to v097r14 release.
byuu says:
This is a few days old, but oh well.
This WIP changes nall,hiro,ruby,icarus back to (u)int(8,16,32,64)_t.
I'm slowly pushing for (u)int(8,16,32,64) to use my custom
Integer<Size>/Natural<Size> classes instead. But it's going to be one
hell of a struggle to get that into higan.
2016-02-16 09:11:58 +00:00
|
|
|
auto load(bitstream& stream, uint64_t offset, context& ctx, uint width, uint height) -> void {
|
2011-12-12 10:59:53 +00:00
|
|
|
canvas.allocate(width, height);
|
2013-12-03 10:01:59 +00:00
|
|
|
canvas.fill(ctx.paddingColor);
|
2011-12-12 10:59:53 +00:00
|
|
|
parse(1, stream, offset, ctx, width, height);
|
|
|
|
}
|
|
|
|
|
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
|
|
|
//import from canvas to bitstream
|
2015-12-14 09:41:06 +00:00
|
|
|
auto save(bitstream& stream, uint64_t offset, context& ctx) -> bool {
|
2011-12-12 10:59:53 +00:00
|
|
|
if(stream.readonly) return false;
|
2015-06-18 10:48:53 +00:00
|
|
|
parse(0, stream, offset, ctx, canvas.width(), canvas.height());
|
2011-12-12 10:59:53 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
Update to v097r14 release.
byuu says:
This is a few days old, but oh well.
This WIP changes nall,hiro,ruby,icarus back to (u)int(8,16,32,64)_t.
I'm slowly pushing for (u)int(8,16,32,64) to use my custom
Integer<Size>/Natural<Size> classes instead. But it's going to be one
hell of a struggle to get that into higan.
2016-02-16 09:11:58 +00:00
|
|
|
auto read(uint x, uint y) const -> uint32_t {
|
2015-12-14 09:41:06 +00:00
|
|
|
uint addr = y * canvas.width() + x;
|
2015-06-18 10:48:53 +00:00
|
|
|
if(addr >= canvas.width() * canvas.height()) return 0u;
|
Update to v097r14 release.
byuu says:
This is a few days old, but oh well.
This WIP changes nall,hiro,ruby,icarus back to (u)int(8,16,32,64)_t.
I'm slowly pushing for (u)int(8,16,32,64) to use my custom
Integer<Size>/Natural<Size> classes instead. But it's going to be one
hell of a struggle to get that into higan.
2016-02-16 09:11:58 +00:00
|
|
|
auto buffer = (uint32_t*)canvas.data();
|
2011-12-12 10:59:53 +00:00
|
|
|
return buffer[addr];
|
|
|
|
}
|
|
|
|
|
2015-12-14 09:41:06 +00:00
|
|
|
auto write(uint x, uint y, uint32_t data) -> void {
|
|
|
|
uint addr = y * canvas.width() + x;
|
2015-06-18 10:48:53 +00:00
|
|
|
if(addr >= canvas.width() * canvas.height()) return;
|
Update to v097r14 release.
byuu says:
This is a few days old, but oh well.
This WIP changes nall,hiro,ruby,icarus back to (u)int(8,16,32,64)_t.
I'm slowly pushing for (u)int(8,16,32,64) to use my custom
Integer<Size>/Natural<Size> classes instead. But it's going to be one
hell of a struggle to get that into higan.
2016-02-16 09:11:58 +00:00
|
|
|
auto buffer = (uint32_t*)canvas.data();
|
2011-12-12 10:59:53 +00:00
|
|
|
buffer[addr] = data;
|
|
|
|
}
|
|
|
|
|
Update to v097r14 release.
byuu says:
This is a few days old, but oh well.
This WIP changes nall,hiro,ruby,icarus back to (u)int(8,16,32,64)_t.
I'm slowly pushing for (u)int(8,16,32,64) to use my custom
Integer<Size>/Natural<Size> classes instead. But it's going to be one
hell of a struggle to get that into higan.
2016-02-16 09:11:58 +00:00
|
|
|
auto parse(bool load, bitstream& stream, uint64_t offset, context& ctx, uint width, uint height) -> void {
|
2011-12-12 10:59:53 +00:00
|
|
|
stream.endian = ctx.endian;
|
2015-12-14 09:41:06 +00:00
|
|
|
uint canvasWidth = width / (ctx.mosaicWidth * ctx.tileWidth * ctx.blockWidth + ctx.paddingWidth);
|
|
|
|
uint canvasHeight = height / (ctx.mosaicHeight * ctx.tileHeight * ctx.blockHeight + ctx.paddingHeight);
|
|
|
|
uint bitsPerBlock = ctx.depth * ctx.blockWidth * ctx.blockHeight;
|
2011-12-12 10:59:53 +00:00
|
|
|
|
2015-12-14 09:41:06 +00:00
|
|
|
uint objectOffset = 0;
|
|
|
|
for(uint objectY = 0; objectY < canvasHeight; objectY++) {
|
|
|
|
for(uint objectX = 0; objectX < canvasWidth; objectX++) {
|
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(objectOffset >= ctx.count && ctx.count > 0) break;
|
2015-12-14 09:41:06 +00:00
|
|
|
uint objectIX = objectX * ctx.objectWidth();
|
|
|
|
uint objectIY = objectY * ctx.objectHeight();
|
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
|
|
|
objectOffset++;
|
2011-12-12 10:59:53 +00:00
|
|
|
|
2015-12-14 09:41:06 +00:00
|
|
|
uint mosaicOffset = 0;
|
|
|
|
for(uint mosaicY = 0; mosaicY < ctx.mosaicHeight; mosaicY++) {
|
|
|
|
for(uint mosaicX = 0; mosaicX < ctx.mosaicWidth; mosaicX++) {
|
|
|
|
uint mosaicData = ctx.mosaic(mosaicOffset, mosaicOffset);
|
|
|
|
uint mosaicIX = (mosaicData % ctx.mosaicWidth) * (ctx.tileWidth * ctx.blockWidth);
|
|
|
|
uint mosaicIY = (mosaicData / ctx.mosaicWidth) * (ctx.tileHeight * ctx.blockHeight);
|
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
|
|
|
mosaicOffset++;
|
2011-12-12 10:59:53 +00:00
|
|
|
|
2015-12-14 09:41:06 +00:00
|
|
|
uint tileOffset = 0;
|
|
|
|
for(uint tileY = 0; tileY < ctx.tileHeight; tileY++) {
|
|
|
|
for(uint tileX = 0; tileX < ctx.tileWidth; tileX++) {
|
|
|
|
uint tileData = ctx.tile(tileOffset, tileOffset);
|
|
|
|
uint tileIX = (tileData % ctx.tileWidth) * ctx.blockWidth;
|
|
|
|
uint tileIY = (tileData / ctx.tileWidth) * ctx.blockHeight;
|
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
|
|
|
tileOffset++;
|
2011-12-12 10:59:53 +00:00
|
|
|
|
2015-12-14 09:41:06 +00:00
|
|
|
uint blockOffset = 0;
|
|
|
|
for(uint blockY = 0; blockY < ctx.blockHeight; blockY++) {
|
|
|
|
for(uint blockX = 0; blockX < ctx.blockWidth; blockX++) {
|
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(load) {
|
2015-12-14 09:41:06 +00:00
|
|
|
uint palette = 0;
|
|
|
|
for(uint n = 0; n < ctx.depth; n++) {
|
|
|
|
uint index = blockOffset++;
|
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(ctx.order == 1) index = (index % ctx.depth) * ctx.blockWidth * ctx.blockHeight + (index / ctx.depth);
|
|
|
|
palette |= stream.read(offset + ctx.block(index, index)) << n;
|
2011-12-12 10:59:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
write(
|
|
|
|
objectIX + mosaicIX + tileIX + blockX,
|
|
|
|
objectIY + mosaicIY + tileIY + blockY,
|
|
|
|
ctx.palette(palette, palette)
|
|
|
|
);
|
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 /* save */ {
|
2011-12-12 10:59:53 +00:00
|
|
|
uint32_t palette = read(
|
|
|
|
objectIX + mosaicIX + tileIX + blockX,
|
|
|
|
objectIY + mosaicIY + tileIY + blockY
|
|
|
|
);
|
|
|
|
|
2015-12-14 09:41:06 +00:00
|
|
|
for(uint n = 0; n < ctx.depth; n++) {
|
|
|
|
uint index = blockOffset++;
|
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(ctx.order == 1) index = (index % ctx.depth) * ctx.blockWidth * ctx.blockHeight + (index / ctx.depth);
|
|
|
|
stream.write(offset + ctx.block(index, index), palette & 1);
|
2011-12-12 10:59:53 +00:00
|
|
|
palette >>= 1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
} //blockX
|
|
|
|
} //blockY
|
|
|
|
|
|
|
|
offset += ctx.blockStride;
|
|
|
|
} //tileX
|
|
|
|
|
|
|
|
offset += ctx.blockOffset;
|
|
|
|
} //tileY
|
|
|
|
|
|
|
|
offset += ctx.tileStride;
|
|
|
|
} //mosaicX
|
|
|
|
|
|
|
|
offset += ctx.tileOffset;
|
|
|
|
} //mosaicY
|
|
|
|
|
|
|
|
offset += ctx.mosaicStride;
|
|
|
|
} //objectX
|
|
|
|
|
|
|
|
offset += ctx.mosaicOffset;
|
|
|
|
} //objectY
|
|
|
|
}
|
2015-12-14 09:41:06 +00:00
|
|
|
|
|
|
|
image canvas;
|
2011-12-12 10:59:53 +00:00
|
|
|
};
|
|
|
|
|
2016-01-07 08:14:33 +00:00
|
|
|
}}
|