Update to v095r05 release.
byuu says:
Changelog:
- GBA: lots of emulation improvements
- PPU PRAM is 16-bits wide
- DMA masks &~1/Half, &~3/Word
- VRAM OBJ 8-bit writes are ignored
- OAM 8-bit writes are ignored
- BGnCNT unused bits are writable*
- BG(0,1)CNT can't set the d13
- BLDALPHA is readable (fixes Donkey Kong Country, etc)
- SNES: lots of code cleanups
- sfc/chip => sfc/coprocessor
- UI: save most recent controller selection
GBA test scores: 1552/1552, 37/38, 1020/1260
(* forgot to add the value to the read function, so endrift's I/O tests
for them will fail. Fixed locally.)
Note: SNES is the only system with multiple controller/expansion port
options, and as such is the only one with a "None" option. Because it's
shared by the controller and expansion port, it ends up sorted first in
the list. This means that on your first run, you'll need to go to Super
Famicom->Controller Port 1 and select "Gamepad", otherwise input won't
work.
Also note that changing the expansion port device requires loading a new
cart. Unlike controllers, you aren't meant to hotplug expansion port
devices.
2015-11-12 10:15:03 +00:00
|
|
|
auto PPUcounter::serialize(serializer& s) -> void {
|
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);
|
|
|
|
}
|
|
|
|
|
Update to v095r05 release.
byuu says:
Changelog:
- GBA: lots of emulation improvements
- PPU PRAM is 16-bits wide
- DMA masks &~1/Half, &~3/Word
- VRAM OBJ 8-bit writes are ignored
- OAM 8-bit writes are ignored
- BGnCNT unused bits are writable*
- BG(0,1)CNT can't set the d13
- BLDALPHA is readable (fixes Donkey Kong Country, etc)
- SNES: lots of code cleanups
- sfc/chip => sfc/coprocessor
- UI: save most recent controller selection
GBA test scores: 1552/1552, 37/38, 1020/1260
(* forgot to add the value to the read function, so endrift's I/O tests
for them will fail. Fixed locally.)
Note: SNES is the only system with multiple controller/expansion port
options, and as such is the only one with a "None" option. Because it's
shared by the controller and expansion port, it ends up sorted first in
the list. This means that on your first run, you'll need to go to Super
Famicom->Controller Port 1 and select "Gamepad", otherwise input won't
work.
Also note that changing the expansion port device requires loading a new
cart. Unlike controllers, you aren't meant to hotplug expansion port
devices.
2015-11-12 10:15:03 +00:00
|
|
|
auto PPU::serialize(serializer& s) -> void {
|
2012-03-23 10:43:39 +00:00
|
|
|
Thread::serialize(s);
|
2010-08-09 13:33:44 +00:00
|
|
|
PPUcounter::serialize(s);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.array(memory.vram);
|
|
|
|
s.array(memory.oam);
|
|
|
|
s.array(memory.cgram);
|
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
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(ppu1.version);
|
|
|
|
s.integer(ppu1.mdr);
|
|
|
|
|
|
|
|
s.integer(ppu2.version);
|
|
|
|
s.integer(ppu2.mdr);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
|
|
|
s.integer(display.interlace);
|
|
|
|
s.integer(display.overscan);
|
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
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);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(latch.oamAddress);
|
|
|
|
s.integer(latch.cgramAddress);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(r.displayDisable);
|
|
|
|
s.integer(r.displayBrightness);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(r.oamBaseAddress);
|
|
|
|
s.integer(r.oamAddress);
|
|
|
|
s.integer(r.oamPriority);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(r.bgPriority);
|
|
|
|
s.integer(r.bgMode);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(r.hoffsetMode7);
|
|
|
|
s.integer(r.voffsetMode7);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(r.vramIncrementMode);
|
|
|
|
s.integer(r.vramMapping);
|
|
|
|
s.integer(r.vramIncrementSize);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(r.vramAddress);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(r.repeatMode7);
|
|
|
|
s.integer(r.vflipMode7);
|
|
|
|
s.integer(r.hflipMode7);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(r.m7a);
|
|
|
|
s.integer(r.m7b);
|
|
|
|
s.integer(r.m7c);
|
|
|
|
s.integer(r.m7d);
|
|
|
|
s.integer(r.m7x);
|
|
|
|
s.integer(r.m7y);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(r.cgramAddress);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(r.extbg);
|
|
|
|
s.integer(r.pseudoHires);
|
|
|
|
s.integer(r.overscan);
|
|
|
|
s.integer(r.interlace);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(r.hcounter);
|
|
|
|
s.integer(r.vcounter);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
|
|
|
bg1.serialize(s);
|
|
|
|
bg2.serialize(s);
|
|
|
|
bg3.serialize(s);
|
|
|
|
bg4.serialize(s);
|
2016-06-14 10:51:54 +00:00
|
|
|
oam.serialize(s);
|
2010-08-09 13:28:56 +00:00
|
|
|
window.serialize(s);
|
|
|
|
screen.serialize(s);
|
|
|
|
}
|
|
|
|
|
Update to v095r05 release.
byuu says:
Changelog:
- GBA: lots of emulation improvements
- PPU PRAM is 16-bits wide
- DMA masks &~1/Half, &~3/Word
- VRAM OBJ 8-bit writes are ignored
- OAM 8-bit writes are ignored
- BGnCNT unused bits are writable*
- BG(0,1)CNT can't set the d13
- BLDALPHA is readable (fixes Donkey Kong Country, etc)
- SNES: lots of code cleanups
- sfc/chip => sfc/coprocessor
- UI: save most recent controller selection
GBA test scores: 1552/1552, 37/38, 1020/1260
(* forgot to add the value to the read function, so endrift's I/O tests
for them will fail. Fixed locally.)
Note: SNES is the only system with multiple controller/expansion port
options, and as such is the only one with a "None" option. Because it's
shared by the controller and expansion port, it ends up sorted first in
the list. This means that on your first run, you'll need to go to Super
Famicom->Controller Port 1 and select "Gamepad", otherwise input won't
work.
Also note that changing the expansion port device requires loading a new
cart. Unlike controllers, you aren't meant to hotplug expansion port
devices.
2015-11-12 10:15:03 +00:00
|
|
|
auto PPU::Background::serialize(serializer& s) -> void {
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(r.tiledataAddress);
|
|
|
|
s.integer(r.screenAddress);
|
|
|
|
s.integer(r.screenSize);
|
|
|
|
s.integer(r.mosaic);
|
|
|
|
s.integer(r.tileSize);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(r.mode);
|
|
|
|
s.array(r.priority);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(r.aboveEnable);
|
|
|
|
s.integer(r.belowEnable);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(r.hoffset);
|
|
|
|
s.integer(r.voffset);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(latch.hoffset);
|
|
|
|
s.integer(latch.voffset);
|
2011-06-05 03:45:04 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(output.above.priority);
|
|
|
|
s.integer(output.above.palette);
|
|
|
|
s.integer(output.above.tile);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
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);
|
|
|
|
|
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
|
|
|
|
2016-06-14 10:51:54 +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);
|
2016-06-14 10:51:54 +00:00
|
|
|
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);
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
auto PPU::OAM::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);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
|
|
|
s.integer(t.x);
|
|
|
|
s.integer(t.y);
|
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(t.itemCount);
|
|
|
|
s.integer(t.tileCount);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
|
|
|
s.integer(t.active);
|
2016-02-18 10:32:22 +00:00
|
|
|
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);
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(t.tile[p][n].data);
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(output.above.priority);
|
|
|
|
s.integer(output.above.palette);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(output.below.priority);
|
|
|
|
s.integer(output.below.palette);
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-06-14 10:51:54 +00:00
|
|
|
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);
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
Update to v095r05 release.
byuu says:
Changelog:
- GBA: lots of emulation improvements
- PPU PRAM is 16-bits wide
- DMA masks &~1/Half, &~3/Word
- VRAM OBJ 8-bit writes are ignored
- OAM 8-bit writes are ignored
- BGnCNT unused bits are writable*
- BG(0,1)CNT can't set the d13
- BLDALPHA is readable (fixes Donkey Kong Country, etc)
- SNES: lots of code cleanups
- sfc/chip => sfc/coprocessor
- UI: save most recent controller selection
GBA test scores: 1552/1552, 37/38, 1020/1260
(* forgot to add the value to the read function, so endrift's I/O tests
for them will fail. Fixed locally.)
Note: SNES is the only system with multiple controller/expansion port
options, and as such is the only one with a "None" option. Because it's
shared by the controller and expansion port, it ends up sorted first in
the list. This means that on your first run, you'll need to go to Super
Famicom->Controller Port 1 and select "Gamepad", otherwise input won't
work.
Also note that changing the expansion port device requires loading a new
cart. Unlike controllers, you aren't meant to hotplug expansion port
devices.
2015-11-12 10:15:03 +00:00
|
|
|
auto PPU::Window::serialize(serializer& s) -> void {
|
2016-06-14 10:51:54 +00:00
|
|
|
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.oam.oneEnable);
|
|
|
|
s.integer(r.oam.oneInvert);
|
|
|
|
s.integer(r.oam.twoEnable);
|
|
|
|
s.integer(r.oam.twoInvert);
|
|
|
|
s.integer(r.oam.mask);
|
|
|
|
s.integer(r.oam.aboveEnable);
|
|
|
|
s.integer(r.oam.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);
|
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(x);
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
Update to v095r05 release.
byuu says:
Changelog:
- GBA: lots of emulation improvements
- PPU PRAM is 16-bits wide
- DMA masks &~1/Half, &~3/Word
- VRAM OBJ 8-bit writes are ignored
- OAM 8-bit writes are ignored
- BGnCNT unused bits are writable*
- BG(0,1)CNT can't set the d13
- BLDALPHA is readable (fixes Donkey Kong Country, etc)
- SNES: lots of code cleanups
- sfc/chip => sfc/coprocessor
- UI: save most recent controller selection
GBA test scores: 1552/1552, 37/38, 1020/1260
(* forgot to add the value to the read function, so endrift's I/O tests
for them will fail. Fixed locally.)
Note: SNES is the only system with multiple controller/expansion port
options, and as such is the only one with a "None" option. Because it's
shared by the controller and expansion port, it ends up sorted first in
the list. This means that on your first run, you'll need to go to Super
Famicom->Controller Port 1 and select "Gamepad", otherwise input won't
work.
Also note that changing the expansion port device requires loading a new
cart. Unlike controllers, you aren't meant to hotplug expansion port
devices.
2015-11-12 10:15:03 +00:00
|
|
|
auto PPU::Screen::serialize(serializer& s) -> void {
|
2016-06-14 10:51:54 +00:00
|
|
|
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.oam.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);
|
2013-01-23 08:28:35 +00:00
|
|
|
s.integer(math.transparent);
|
2016-06-14 10:51:54 +00:00
|
|
|
s.integer(math.blendMode);
|
|
|
|
s.integer(math.colorHalve);
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|