ShuriZma
/
bsnes
mirror of https://github.com/bsnes-emu/bsnes.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
bsnes/higan/sfc/ppu/serialization.cpp

285 lines
6.5 KiB
C++
Raw Normal View History

First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
#ifdef PPU_CPP
Update to 20100809 release. byuu says: This adds some sync.sh improvements to make it handle errors more gracefully. It also updates asnes a good bit. All of the four base processors now have all publicly accessible functions right at the top of the main headers, and everything else is private. This is to allow these headers to essentially take the place of the previous base classes in the old bsnes-merged format. So if there's something public there, you need to implement that exact function to make your own module. I removed the frame counter from the PPU, as it has nothing to do with emulation. That now resides inside the Qt -> SNES interface code. Quite amazing, I was actually saving the frame counter into the save state files before, yuck. Removed some baggage in the System class: it was friending a bunch of long-dead functions and classes. Forgot to re-add the CHEAT_SYSTEM define to info.hpp, so that's been put back.
2010-08-09 13:33:44 +00:00
void PPUcounter::serialize(serializer &s) {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
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);
}
void PPU::serialize(serializer &s) {
Update to v087r07 release. There was a "v087r07pre" release that I unfortunately missed. byuu says (about v087r07pre): Creates the bsnes/processor folder. This has a shared ARM core there which both the GBA and ST018 inherit. There are going to be separate decoders, and revision-specific checks, to support the differences between v3+. In the future, I also want to move the other processor cores here: - GBZ80 (GB, GBC) - 65816 (SNES CPU, SA-1) - NEC uPD (7725, 96050, maybe 7720 just for fun) - Hitachi HG51B169 - SuperFX - SPC700 - 65(C?)02 Basically, the GBA/ST018 forces my hand to start coding a bit more like a multi-system emulator. Right now, the ST018 is broken. Hence the pre. Apparently the GBA core being used now has some bugs. So this'll be a nice way to stress-test the GBA core a bit before we make it to ARMwrestler. byuu says (about v087r07): Both snes/chip/armdsp and gba/cpu use processor/arm now. Fixed THUMB to execute the BL prefix and suffix separately. I can now get the GBA BIOS stuck in some kind of infinite loop. Hooray ... I guess?
2012-03-23 10:43:39 +00:00
Thread::serialize(s);
Update to 20100809 release. byuu says: This adds some sync.sh improvements to make it handle errors more gracefully. It also updates asnes a good bit. All of the four base processors now have all publicly accessible functions right at the top of the main headers, and everything else is private. This is to allow these headers to essentially take the place of the previous base classes in the old bsnes-merged format. So if there's something public there, you need to implement that exact function to make your own module. I removed the frame counter from the PPU, as it has nothing to do with emulation. That now resides inside the Qt -> SNES interface code. Quite amazing, I was actually saving the frame counter into the save state files before, yuck. Removed some baggage in the System class: it was friending a bunch of long-dead functions and classes. Forgot to re-add the CHEAT_SYSTEM define to info.hpp, so that's been put back.
2010-08-09 13:33:44 +00:00
PPUcounter::serialize(s);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v074r11 release. byuu says: Changelog: - debugger compiles on all three profiles - libsnes compiles on all three platforms (no API changes to libsnes) - memory.cpp : namespace memory removed (wram -> cpu, apuram -> smp, vram, oam, cgram -> ppu) - sa1.cpp : namespace memory removed (SA-1 specific functions merged inline to SA1::bus_read,write) - GameBoy: added serial link support with interrupts and proper 8192hz timing, but obviously it acts as if no other GB is connected to it - GameBoy: added STAT OAM interrupt, and better STAT d1,d0 mode values - UI: since Qt is dead, I've renamed the config files back to bsnes.cfg and bsnes-geometry.cfg - SA1: IRAM was not syncing to CPU on SA-1 side - PPU/Accuracy and PPU/Performance needed Sprite oam renamed to Sprite sprite; so that I could add uint8 oam[544] - makes more sense anyway, OAM = object attribute memory, obj or sprite are better names for Sprite rendering class - more cleanup
2011-01-24 09:03:17 +00:00
s.array(vram);
s.array(oam);
s.array(cgram);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
s.integer(ppu1_version);
s.integer(ppu2_version);
s.integer(display.interlace);
s.integer(display.overscan);
s.integer(regs.ppu1_mdr);
s.integer(regs.ppu2_mdr);
s.integer(regs.vram_readbuffer);
s.integer(regs.oam_latchdata);
s.integer(regs.cgram_latchdata);
s.integer(regs.bgofs_latchdata);
s.integer(regs.mode7_latchdata);
s.integer(regs.counters_latched);
s.integer(regs.latch_hcounter);
s.integer(regs.latch_vcounter);
Update to v068r24 release. (there was no r23 release posted to the WIP thread) byuu says: Fixes OAM latchdata for all 3 cores and CGRAM address invalidation for the accuracy core (the only one that really does it because it needs cycle PPU timing.) Also removes the OAM/CGRAM read/write functions to put them inside the actual MMIO functions. Easier to handle all the special cases that way. VRAM is a bit more annoying since there's two read and two write functions. This should fix battletech/mechwarrior 3050 palette at least.
2010-09-24 13:15:21 +00:00
s.integer(regs.oam_iaddr);
s.integer(regs.cgram_iaddr);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
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(regs.display_disable);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
s.integer(regs.display_brightness);
s.integer(regs.oam_baseaddr);
s.integer(regs.oam_addr);
s.integer(regs.oam_priority);
s.integer(regs.bg3_priority);
s.integer(regs.bgmode);
s.integer(regs.mode7_hoffset);
s.integer(regs.mode7_voffset);
s.integer(regs.vram_incmode);
s.integer(regs.vram_mapping);
s.integer(regs.vram_incsize);
s.integer(regs.vram_addr);
s.integer(regs.mode7_repeat);
s.integer(regs.mode7_vflip);
s.integer(regs.mode7_hflip);
s.integer(regs.m7a);
s.integer(regs.m7b);
s.integer(regs.m7c);
s.integer(regs.m7d);
s.integer(regs.m7x);
s.integer(regs.m7y);
s.integer(regs.cgram_addr);
s.integer(regs.mode7_extbg);
s.integer(regs.pseudo_hires);
s.integer(regs.overscan);
s.integer(regs.interlace);
s.integer(regs.hcounter);
s.integer(regs.vcounter);
bg1.serialize(s);
bg2.serialize(s);
bg3.serialize(s);
bg4.serialize(s);
Update to v074r11 release. byuu says: Changelog: - debugger compiles on all three profiles - libsnes compiles on all three platforms (no API changes to libsnes) - memory.cpp : namespace memory removed (wram -> cpu, apuram -> smp, vram, oam, cgram -> ppu) - sa1.cpp : namespace memory removed (SA-1 specific functions merged inline to SA1::bus_read,write) - GameBoy: added serial link support with interrupts and proper 8192hz timing, but obviously it acts as if no other GB is connected to it - GameBoy: added STAT OAM interrupt, and better STAT d1,d0 mode values - UI: since Qt is dead, I've renamed the config files back to bsnes.cfg and bsnes-geometry.cfg - SA1: IRAM was not syncing to CPU on SA-1 side - PPU/Accuracy and PPU/Performance needed Sprite oam renamed to Sprite sprite; so that I could add uint8 oam[544] - makes more sense anyway, OAM = object attribute memory, obj or sprite are better names for Sprite rendering class - more cleanup
2011-01-24 09:03:17 +00:00
sprite.serialize(s);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
window.serialize(s);
screen.serialize(s);
}
void PPU::Background::serialize(serializer &s) {
s.integer(id);
s.integer(regs.tiledata_addr);
s.integer(regs.screen_addr);
s.integer(regs.screen_size);
s.integer(regs.mosaic);
s.integer(regs.tile_size);
s.integer(regs.mode);
s.integer(regs.priority0);
s.integer(regs.priority1);
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(regs.main_enable);
s.integer(regs.sub_enable);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
s.integer(regs.hoffset);
s.integer(regs.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(cache.hoffset);
s.integer(cache.voffset);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
s.integer(output.main.priority);
s.integer(output.main.palette);
s.integer(output.main.tile);
s.integer(output.sub.priority);
s.integer(output.sub.palette);
s.integer(output.sub.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);
Update to v078r07 release. byuu says: Would appreciate testing on any games with mosaic, especially Mode7 mosaic.I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program. This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging. I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run(). I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now. Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-06-05 03:25:24 +00:00
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
Update to v068r14 release. byuu says: Holy hell, that was a total brain twister. After hours of crazy bit twiddling and debug printf's, I finally figured out how to allow both lores and hires scrolling in the accurate PPU renderer. In the process, I modified the main loop to run from -7 to 255, regardless of the hires setting, and perform X adjustment inside the tile fetching. This fixed a strange main/subscreen misalignment issue, so I was able to restore the proper sub-then-main rendering for the final screen output stage. Code looks a good bit cleaner this way overall. I also added load state and save state menus to the tools menu, so you can use the menubar to load and save to ten slots. I am thinking that I should nuke the icons. As pretty as they are, it's getting tiresome trying to find icons for everything, I have no pictures to represent loading or saving a slot, nor to represent individual slots. I'll just stick to radios and checkboxes.
2010-09-05 23:08:03 +00:00
s.integer(tile_counter);
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(palette_number);
s.integer(palette_index);
s.array(data);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
}
void PPU::Sprite::serialize(serializer &s) {
for(unsigned i = 0; i < 128; i++) {
s.integer(list[i].x);
s.integer(list[i].y);
s.integer(list[i].character);
s.integer(list[i].nameselect);
s.integer(list[i].vflip);
s.integer(list[i].hflip);
s.integer(list[i].priority);
s.integer(list[i].palette);
s.integer(list[i].size);
}
s.integer(t.x);
s.integer(t.y);
s.integer(t.item_count);
s.integer(t.tile_count);
s.integer(t.active);
for(unsigned n = 0; n < 2; n++) {
s.array(t.item[n]);
for(unsigned i = 0; i < 34; i++) {
s.integer(t.tile[n][i].x);
s.integer(t.tile[n][i].priority);
s.integer(t.tile[n][i].palette);
s.integer(t.tile[n][i].hflip);
s.integer(t.tile[n][i].d0);
s.integer(t.tile[n][i].d1);
s.integer(t.tile[n][i].d2);
s.integer(t.tile[n][i].d3);
}
}
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(regs.main_enable);
s.integer(regs.sub_enable);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
s.integer(regs.interlace);
s.integer(regs.base_size);
s.integer(regs.nameselect);
s.integer(regs.tiledata_addr);
s.integer(regs.first_sprite);
s.integer(regs.priority0);
s.integer(regs.priority1);
s.integer(regs.priority2);
s.integer(regs.priority3);
s.integer(regs.time_over);
s.integer(regs.range_over);
s.integer(output.main.priority);
s.integer(output.main.palette);
s.integer(output.sub.priority);
s.integer(output.sub.palette);
}
void PPU::Window::serialize(serializer &s) {
s.integer(regs.bg1_one_enable);
s.integer(regs.bg1_one_invert);
s.integer(regs.bg1_two_enable);
s.integer(regs.bg1_two_invert);
s.integer(regs.bg2_one_enable);
s.integer(regs.bg2_one_invert);
s.integer(regs.bg2_two_enable);
s.integer(regs.bg2_two_invert);
s.integer(regs.bg3_one_enable);
s.integer(regs.bg3_one_invert);
s.integer(regs.bg3_two_enable);
s.integer(regs.bg3_two_invert);
s.integer(regs.bg4_one_enable);
s.integer(regs.bg4_one_invert);
s.integer(regs.bg4_two_enable);
s.integer(regs.bg4_two_invert);
s.integer(regs.oam_one_enable);
s.integer(regs.oam_one_invert);
s.integer(regs.oam_two_enable);
s.integer(regs.oam_two_invert);
s.integer(regs.col_one_enable);
s.integer(regs.col_one_invert);
s.integer(regs.col_two_enable);
s.integer(regs.col_two_invert);
s.integer(regs.one_left);
s.integer(regs.one_right);
s.integer(regs.two_left);
s.integer(regs.two_right);
s.integer(regs.bg1_mask);
s.integer(regs.bg2_mask);
s.integer(regs.bg3_mask);
s.integer(regs.bg4_mask);
s.integer(regs.oam_mask);
s.integer(regs.col_mask);
s.integer(regs.bg1_main_enable);
s.integer(regs.bg1_sub_enable);
s.integer(regs.bg2_main_enable);
s.integer(regs.bg2_sub_enable);
s.integer(regs.bg3_main_enable);
s.integer(regs.bg3_sub_enable);
s.integer(regs.bg4_main_enable);
s.integer(regs.bg4_sub_enable);
s.integer(regs.oam_main_enable);
s.integer(regs.oam_sub_enable);
s.integer(regs.col_main_mask);
s.integer(regs.col_sub_mask);
s.integer(output.main.color_enable);
s.integer(output.sub.color_enable);
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(one);
s.integer(two);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
}
void PPU::Screen::serialize(serializer &s) {
s.integer(regs.addsub_mode);
s.integer(regs.direct_color);
s.integer(regs.color_mode);
s.integer(regs.color_halve);
s.integer(regs.bg1_color_enable);
s.integer(regs.bg2_color_enable);
s.integer(regs.bg3_color_enable);
s.integer(regs.bg4_color_enable);
s.integer(regs.oam_color_enable);
s.integer(regs.back_color_enable);
s.integer(regs.color_b);
s.integer(regs.color_g);
s.integer(regs.color_r);
}
#endif