bsnes/higan/sfc/ppu/serialization.cpp

281 lines
6.2 KiB
C++
Raw Normal View History

auto PPUcounter::serialize(serializer& s) -> void {
s.integer(status.interlace);
s.integer(status.field);
s.integer(status.vcounter);
s.integer(status.hcounter);
s.array(history.field);
s.array(history.vcounter);
s.array(history.hcounter);
s.integer(history.index);
}
auto PPU::serialize(serializer& s) -> void {
Thread::serialize(s);
PPUcounter::serialize(s);
s.integer(vram.mask);
s.array(vram.data, vram.mask + 1);
s.array(oam.data);
s.array(cgram.data);
s.integer(ppu1.version);
s.integer(ppu1.mdr);
s.integer(ppu2.version);
s.integer(ppu2.mdr);
s.integer(display.interlace);
s.integer(display.overscan);
s.integer(latch.vram);
s.integer(latch.oam);
s.integer(latch.cgram);
s.integer(latch.bgofs);
s.integer(latch.mode7);
s.integer(latch.counters);
s.integer(latch.hcounter);
s.integer(latch.vcounter);
s.integer(latch.oamAddress);
s.integer(latch.cgramAddress);
s.integer(r.displayDisable);
s.integer(r.displayBrightness);
s.integer(r.oamBaseAddress);
s.integer(r.oamAddress);
s.integer(r.oamPriority);
s.integer(r.bgPriority);
s.integer(r.bgMode);
s.integer(r.hoffsetMode7);
s.integer(r.voffsetMode7);
s.integer(r.vramIncrementMode);
s.integer(r.vramMapping);
s.integer(r.vramIncrementSize);
s.integer(r.vramAddress);
s.integer(r.repeatMode7);
s.integer(r.vflipMode7);
s.integer(r.hflipMode7);
s.integer(r.m7a);
s.integer(r.m7b);
s.integer(r.m7c);
s.integer(r.m7d);
s.integer(r.m7x);
s.integer(r.m7y);
s.integer(r.cgramAddress);
s.integer(r.cgramAddressLatch);
s.integer(r.extbg);
s.integer(r.pseudoHires);
s.integer(r.overscan);
s.integer(r.interlace);
s.integer(r.hcounter);
s.integer(r.vcounter);
bg1.serialize(s);
bg2.serialize(s);
bg3.serialize(s);
bg4.serialize(s);
obj.serialize(s);
window.serialize(s);
screen.serialize(s);
}
auto PPU::Background::serialize(serializer& s) -> void {
s.integer(r.tiledataAddress);
s.integer(r.screenAddress);
s.integer(r.screenSize);
s.integer(r.mosaic);
s.integer(r.tileSize);
s.integer(r.mode);
s.array(r.priority);
s.integer(r.aboveEnable);
s.integer(r.belowEnable);
s.integer(r.hoffset);
s.integer(r.voffset);
s.integer(latch.hoffset);
s.integer(latch.voffset);
Update to v079 release. byuu says: This release includes Nintendo Super System DIP switch emulation and improved PPU rendering accuracy, among other things. Changelog: - added Nintendo Super System DIP switch emulation [requires XML setting maps] - emulated Super Game Boy $6001 VRAM offset selection port [ikari_01] - fixed randomness initialization of S-SMP port registers [fixes DBZ:Hyper Dimension and Ninja Warriors] - mosaic V-countdown caches BGOFS registers (fixes Super Turrican 2 effect) [reported by zal16] - non-mosaic BGOFS registers are always cached at H=60 (fixes NHL '94 and Super Mario World flickering) - fixed 2xSaI family of renderers on 64-bit systems - cleaned up SMP source code - phoenix: fixed a bug when closing bsnes while minimized Please note that the mosaic BGOFS fix is only for the accuracy profile. Unfortunately the older scanline-based compatibility renderer's code is nearly unmaintainable at this point, so I haven't yet been able to backport the fixes. Also, I have written a new cycle-accurate SMP core that does not use libco. The aim is to implement it into Snes9X v1.54. But it would of course be prudent to test the new core first. [...then in the next post...] Decided to keep that Super Mario World part a surprise, so ... surprise! Realized while working on the Super Turrican 2 mosaic fix, and from looking at NHL '94 and Dai Kaijuu Monogatari 2's behavior, that BGOFS registers must be cached between H=0 and H=88 for the entire scanline ... they can't work otherwise, and it'd be stupid for the PPU to re-add the offset to the position on every pixel anyway. I chose H=60 for now. Once I am set up with the RGB monitor and the North American cartridge dumping is completed, I'll set it on getting exact timings for all these things. It'll probably require a smallish speed hit to allow exact-cycle timing events for everything in the PPU.
2011-06-05 03:45:04 +00:00
s.integer(output.above.priority);
s.integer(output.above.palette);
s.integer(output.above.tile);
s.integer(output.below.priority);
s.integer(output.below.palette);
s.integer(output.below.tile);
Update to v068r12 release. (there was no r11 release posted to the WIP thread) byuu says: This took ten hours of mind boggling insanity to pull off. It upgrades the S-PPU dot-based renderer to fetch one tile, and then output all of its pixels before fetching again. It sounds easy enough, but it's insanely difficult. I ended up taking one small shortcut, in that rather than fetch at -7, I fetch at the first instance where a tile is needed to plot to x=0. So if you have {-3 to +4 } as a tile, it fetches at -3. That won't work so well on hardware, if two BGs fetch at the same X offset, they won't have time. I have had no luck staggering the reads at BG1=-7, BG3=-5, etc. While I can shift and fetch just fine, what happens is that when a new tile is fetched in, that gives a new palette, priority, etc; and this ends up happening between two tiles which results in the right-most edges of the screen ending up with the wrong colors and such. Offset-per-tile is cheap as always. Although looking at it, I'm not sure how BG3 could pre-fetch, especially with the way one or two OPT modes can fetch two tiles. There's no magic in Hoffset caching yet, so the SMW1 pixel issue is still there. Mode 7 got a bugfix, it was off-by-one horizontally from the mosaic code. After re-designing the BG mosaic, I ended up needing a separate mosaic for Mode7, and in the process I fixed that bug. The obvious change is that the Chrono Trigger Mode7->Mode2 transition doesn't cause the pendulum to jump anymore. Windows were simplified just a tad. The range testing is shared for all modes now. Ironically, it's a bit slower, but I'll take less code over more speed for the accuracy core. Speaking of speed, because there's so much less calculations per pixel for BGs, performance for the entire emulator has gone up by 30% in the accuracy core. Pretty neat overall, I can maintain 60fps in all but, yeah you can guess can't you?
2010-09-04 03:36:03 +00:00
s.integer(x);
s.integer(y);
s.integer(mosaic.priority);
s.integer(mosaic.palette);
s.integer(mosaic.tile);
s.integer(mosaic.vcounter);
s.integer(mosaic.voffset);
s.integer(mosaic.hcounter);
s.integer(mosaic.hoffset);
Update to v068r12 release. (there was no r11 release posted to the WIP thread) byuu says: This took ten hours of mind boggling insanity to pull off. It upgrades the S-PPU dot-based renderer to fetch one tile, and then output all of its pixels before fetching again. It sounds easy enough, but it's insanely difficult. I ended up taking one small shortcut, in that rather than fetch at -7, I fetch at the first instance where a tile is needed to plot to x=0. So if you have {-3 to +4 } as a tile, it fetches at -3. That won't work so well on hardware, if two BGs fetch at the same X offset, they won't have time. I have had no luck staggering the reads at BG1=-7, BG3=-5, etc. While I can shift and fetch just fine, what happens is that when a new tile is fetched in, that gives a new palette, priority, etc; and this ends up happening between two tiles which results in the right-most edges of the screen ending up with the wrong colors and such. Offset-per-tile is cheap as always. Although looking at it, I'm not sure how BG3 could pre-fetch, especially with the way one or two OPT modes can fetch two tiles. There's no magic in Hoffset caching yet, so the SMW1 pixel issue is still there. Mode 7 got a bugfix, it was off-by-one horizontally from the mosaic code. After re-designing the BG mosaic, I ended up needing a separate mosaic for Mode7, and in the process I fixed that bug. The obvious change is that the Chrono Trigger Mode7->Mode2 transition doesn't cause the pendulum to jump anymore. Windows were simplified just a tad. The range testing is shared for all modes now. Ironically, it's a bit slower, but I'll take less code over more speed for the accuracy core. Speaking of speed, because there's so much less calculations per pixel for BGs, performance for the entire emulator has gone up by 30% in the accuracy core. Pretty neat overall, I can maintain 60fps in all but, yeah you can guess can't you?
2010-09-04 03:36:03 +00:00
s.integer(tileCounter);
Update to v068r12 release. (there was no r11 release posted to the WIP thread) byuu says: This took ten hours of mind boggling insanity to pull off. It upgrades the S-PPU dot-based renderer to fetch one tile, and then output all of its pixels before fetching again. It sounds easy enough, but it's insanely difficult. I ended up taking one small shortcut, in that rather than fetch at -7, I fetch at the first instance where a tile is needed to plot to x=0. So if you have {-3 to +4 } as a tile, it fetches at -3. That won't work so well on hardware, if two BGs fetch at the same X offset, they won't have time. I have had no luck staggering the reads at BG1=-7, BG3=-5, etc. While I can shift and fetch just fine, what happens is that when a new tile is fetched in, that gives a new palette, priority, etc; and this ends up happening between two tiles which results in the right-most edges of the screen ending up with the wrong colors and such. Offset-per-tile is cheap as always. Although looking at it, I'm not sure how BG3 could pre-fetch, especially with the way one or two OPT modes can fetch two tiles. There's no magic in Hoffset caching yet, so the SMW1 pixel issue is still there. Mode 7 got a bugfix, it was off-by-one horizontally from the mosaic code. After re-designing the BG mosaic, I ended up needing a separate mosaic for Mode7, and in the process I fixed that bug. The obvious change is that the Chrono Trigger Mode7->Mode2 transition doesn't cause the pendulum to jump anymore. Windows were simplified just a tad. The range testing is shared for all modes now. Ironically, it's a bit slower, but I'll take less code over more speed for the accuracy core. Speaking of speed, because there's so much less calculations per pixel for BGs, performance for the entire emulator has gone up by 30% in the accuracy core. Pretty neat overall, I can maintain 60fps in all but, yeah you can guess can't you?
2010-09-04 03:36:03 +00:00
s.integer(tile);
s.integer(priority);
s.integer(paletteNumber);
s.integer(paletteIndex);
Update to v068r12 release. (there was no r11 release posted to the WIP thread) byuu says: This took ten hours of mind boggling insanity to pull off. It upgrades the S-PPU dot-based renderer to fetch one tile, and then output all of its pixels before fetching again. It sounds easy enough, but it's insanely difficult. I ended up taking one small shortcut, in that rather than fetch at -7, I fetch at the first instance where a tile is needed to plot to x=0. So if you have {-3 to +4 } as a tile, it fetches at -3. That won't work so well on hardware, if two BGs fetch at the same X offset, they won't have time. I have had no luck staggering the reads at BG1=-7, BG3=-5, etc. While I can shift and fetch just fine, what happens is that when a new tile is fetched in, that gives a new palette, priority, etc; and this ends up happening between two tiles which results in the right-most edges of the screen ending up with the wrong colors and such. Offset-per-tile is cheap as always. Although looking at it, I'm not sure how BG3 could pre-fetch, especially with the way one or two OPT modes can fetch two tiles. There's no magic in Hoffset caching yet, so the SMW1 pixel issue is still there. Mode 7 got a bugfix, it was off-by-one horizontally from the mosaic code. After re-designing the BG mosaic, I ended up needing a separate mosaic for Mode7, and in the process I fixed that bug. The obvious change is that the Chrono Trigger Mode7->Mode2 transition doesn't cause the pendulum to jump anymore. Windows were simplified just a tad. The range testing is shared for all modes now. Ironically, it's a bit slower, but I'll take less code over more speed for the accuracy core. Speaking of speed, because there's so much less calculations per pixel for BGs, performance for the entire emulator has gone up by 30% in the accuracy core. Pretty neat overall, I can maintain 60fps in all but, yeah you can guess can't you?
2010-09-04 03:36:03 +00:00
s.array(data);
}
auto PPU::Object::serialize(serializer& s) -> void {
s.integer(r.aboveEnable);
s.integer(r.belowEnable);
s.integer(r.interlace);
s.integer(r.baseSize);
s.integer(r.nameSelect);
s.integer(r.tiledataAddress);
s.integer(r.firstSprite);
s.array(r.priority);
s.integer(r.timeOver);
s.integer(r.rangeOver);
s.integer(t.x);
s.integer(t.y);
s.integer(t.itemCount);
s.integer(t.tileCount);
s.integer(t.active);
for(auto p : range(2)) {
for(auto n : range(32)) {
s.integer(t.item[p][n].valid);
s.integer(t.item[p][n].index);
}
for(auto n : range(34)) {
s.integer(t.tile[p][n].valid);
s.integer(t.tile[p][n].x);
s.integer(t.tile[p][n].priority);
s.integer(t.tile[p][n].palette);
s.integer(t.tile[p][n].hflip);
s.integer(t.tile[p][n].data);
}
}
s.integer(output.above.priority);
s.integer(output.above.palette);
s.integer(output.below.priority);
s.integer(output.below.palette);
for(auto n : range(128)) {
s.integer(list[n].x);
s.integer(list[n].y);
s.integer(list[n].character);
s.integer(list[n].nameSelect);
s.integer(list[n].vflip);
s.integer(list[n].hflip);
s.integer(list[n].priority);
s.integer(list[n].palette);
s.integer(list[n].size);
}
}
auto PPU::Window::serialize(serializer& s) -> void {
s.integer(r.bg1.oneEnable);
s.integer(r.bg1.oneInvert);
s.integer(r.bg1.twoEnable);
s.integer(r.bg1.twoInvert);
s.integer(r.bg1.mask);
s.integer(r.bg1.aboveEnable);
s.integer(r.bg1.belowEnable);
s.integer(r.bg2.oneEnable);
s.integer(r.bg2.oneInvert);
s.integer(r.bg2.twoEnable);
s.integer(r.bg2.twoInvert);
s.integer(r.bg2.mask);
s.integer(r.bg2.aboveEnable);
s.integer(r.bg2.belowEnable);
s.integer(r.bg3.oneEnable);
s.integer(r.bg3.oneInvert);
s.integer(r.bg3.twoEnable);
s.integer(r.bg3.twoInvert);
s.integer(r.bg3.mask);
s.integer(r.bg3.aboveEnable);
s.integer(r.bg3.belowEnable);
s.integer(r.bg4.oneEnable);
s.integer(r.bg4.oneInvert);
s.integer(r.bg4.twoEnable);
s.integer(r.bg4.twoInvert);
s.integer(r.bg4.mask);
s.integer(r.bg4.aboveEnable);
s.integer(r.bg4.belowEnable);
s.integer(r.obj.oneEnable);
s.integer(r.obj.oneInvert);
s.integer(r.obj.twoEnable);
s.integer(r.obj.twoInvert);
s.integer(r.obj.mask);
s.integer(r.obj.aboveEnable);
s.integer(r.obj.belowEnable);
s.integer(r.col.oneEnable);
s.integer(r.col.oneInvert);
s.integer(r.col.twoEnable);
s.integer(r.col.twoInvert);
s.integer(r.col.mask);
s.integer(r.col.aboveMask);
s.integer(r.col.belowMask);
s.integer(r.oneLeft);
s.integer(r.oneRight);
s.integer(r.twoLeft);
s.integer(r.twoRight);
s.integer(output.above.colorEnable);
s.integer(output.below.colorEnable);
Update to v068r12 release. (there was no r11 release posted to the WIP thread) byuu says: This took ten hours of mind boggling insanity to pull off. It upgrades the S-PPU dot-based renderer to fetch one tile, and then output all of its pixels before fetching again. It sounds easy enough, but it's insanely difficult. I ended up taking one small shortcut, in that rather than fetch at -7, I fetch at the first instance where a tile is needed to plot to x=0. So if you have {-3 to +4 } as a tile, it fetches at -3. That won't work so well on hardware, if two BGs fetch at the same X offset, they won't have time. I have had no luck staggering the reads at BG1=-7, BG3=-5, etc. While I can shift and fetch just fine, what happens is that when a new tile is fetched in, that gives a new palette, priority, etc; and this ends up happening between two tiles which results in the right-most edges of the screen ending up with the wrong colors and such. Offset-per-tile is cheap as always. Although looking at it, I'm not sure how BG3 could pre-fetch, especially with the way one or two OPT modes can fetch two tiles. There's no magic in Hoffset caching yet, so the SMW1 pixel issue is still there. Mode 7 got a bugfix, it was off-by-one horizontally from the mosaic code. After re-designing the BG mosaic, I ended up needing a separate mosaic for Mode7, and in the process I fixed that bug. The obvious change is that the Chrono Trigger Mode7->Mode2 transition doesn't cause the pendulum to jump anymore. Windows were simplified just a tad. The range testing is shared for all modes now. Ironically, it's a bit slower, but I'll take less code over more speed for the accuracy core. Speaking of speed, because there's so much less calculations per pixel for BGs, performance for the entire emulator has gone up by 30% in the accuracy core. Pretty neat overall, I can maintain 60fps in all but, yeah you can guess can't you?
2010-09-04 03:36:03 +00:00
s.integer(x);
}
auto PPU::Screen::serialize(serializer& s) -> void {
s.integer(r.blendMode);
s.integer(r.directColor);
s.integer(r.colorMode);
s.integer(r.colorHalve);
s.integer(r.bg1.colorEnable);
s.integer(r.bg2.colorEnable);
s.integer(r.bg3.colorEnable);
s.integer(r.bg4.colorEnable);
s.integer(r.obj.colorEnable);
s.integer(r.back.colorEnable);
s.integer(r.colorBlue);
s.integer(r.colorGreen);
s.integer(r.colorRed);
s.integer(math.above.color);
s.integer(math.above.colorEnable);
s.integer(math.below.color);
s.integer(math.below.colorEnable);
s.integer(math.transparent);
s.integer(math.blendMode);
s.integer(math.colorHalve);
}