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

83 lines
1.3 KiB
C++
Raw Normal View History

Update to v085r08 release. byuu says: Changelog: - follow the Laevateinn topic to get most of it - also added NMI, IRQ step buttons to CPU debugger - also added trace masking + trace mask reset - also added memory export - cartridge loading is entirely folder-based now FitzRoy, I'll go ahead and make a second compromise with you for v086: I'll match the following: /path/to/SNES.sfc/*.sfc /path/to/NES.fc/*.prg, *.chr (split format) /path/to/NES.fc/*.fc (merged format) /path/to/GB.gb/*.gb /path/to/GBC.gbc/*.gbc Condition will be that there can only be one of each file. If there's more than one, it'll abort. That lets me name my ROMs as "Game.fc/Game.fc", and you can name yours as "Game.fc/cartridge.prg, cartridge.chr". Or whatever you want. We'll just go with that, see what fares out as the most popular, and then restrict it back to that method. The folder must have the .fc, etc extension though. That will be how we avoid false-positive folder matches. [Editor's note - the Laevateinn topic mentions these changes for v085r08: Added SMP/PPU breakpoints, SMP debugger, SMP stepping / tracing, memory editing on APU-bus / VRAM / OAM / CGRAM, save state menu, WRAM mirroring on breakpoints, protected MMIO memory regions (otherwise, viewing $002100 could crash your game.) Major missing components: - trace mask - trace mask clear / usage map clear - window geometry caching / sizing improvements - VRAM viewer - properties viewer - working memory export button The rest will most likely appear after v086 is released. ]
2012-02-12 05:35:40 +00:00
struct Sprite {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
struct SpriteItem {
uint16 x;
uint16 y;
uint8 character;
bool nameselect;
bool vflip;
bool hflip;
uint8 priority;
uint8 palette;
bool size;
unsigned width() const;
unsigned height() const;
} list[128];
struct TileItem {
uint16 x;
uint16 priority;
uint16 palette;
bool hflip;
uint8 d0, d1, d2, d3;
};
struct State {
unsigned x;
unsigned y;
unsigned item_count;
unsigned tile_count;
bool active;
uint8 item[2][32];
TileItem tile[2][34];
} t;
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
struct Regs {
bool main_enable;
bool sub_enable;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
bool interlace;
Update to v077r05 release. byuu says: Changelog: - fixed .nec and both .rtc file extensions (thanks krom) - randomized most S-PPU registers, should trip up some broken homebrew that does not initialize all registers - randomization is now seeded with time(0) rather than 'byuu' - SNES::interface.video_refresh() now always receives {256,512}x{240,480} - PPU/accuracy scanline 0 does not render the screen back color anymore, fixes strange coloring look on first scanline in PAL TV mode in non-overscan games - disabled hires blending in PPU/compatibility; all three cores act the same now
2011-04-27 08:57:31 +00:00
uint3 base_size;
uint2 nameselect;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
uint16 tiledata_addr;
uint8 first_sprite;
unsigned priority0;
unsigned priority1;
unsigned priority2;
unsigned priority3;
bool time_over;
bool range_over;
} regs;
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
struct Output {
struct Pixel {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
unsigned priority; //0 = none (transparent)
Update to v068r13 release. byuu says: Bug-fix night for the new PPUs. Accuracy: Fixed BG palette clamping, which fixes Taz-Mania. Added blocking for CGRAM writes during active display, to match the compatibility core. It really should override to the last fetched palette color, I'll probably try that out soon enough. Performance: Mosaic should match the other renderers. Unfortunately, as suspected, it murders speed. 290->275fps. It's now only 11fps faster, hardly worth it at all. But the old rendering code is really awful, so maybe it's for the best it gets refreshed. It's really tough to understand why this is such a performance hit, it's just a decrement+compare check four times per pixel. But yeah, it hits it really, really hard. Fixed a missing check in Mode4 offset-per-tile, fixes vertical alignment of a test image in the SNES Test Program.
2010-09-05 13:22:26 +00:00
uint8 palette;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
} main, sub;
} output;
//list.cpp
void update(unsigned addr, uint8 data);
Update to v077r05 release. byuu says: Changelog: - fixed .nec and both .rtc file extensions (thanks krom) - randomized most S-PPU registers, should trip up some broken homebrew that does not initialize all registers - randomization is now seeded with time(0) rather than 'byuu' - SNES::interface.video_refresh() now always receives {256,512}x{240,480} - PPU/accuracy scanline 0 does not render the screen back color anymore, fixes strange coloring look on first scanline in PAL TV mode in non-overscan games - disabled hires blending in PPU/compatibility; all three cores act the same now
2011-04-27 08:57:31 +00:00
void synchronize();
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
//sprite.cpp
void address_reset();
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
void set_first_sprite();
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
void frame();
void scanline();
void run();
void tilefetch();
void reset();
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
bool on_scanline(SpriteItem&);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
void serialize(serializer&);
Update to v092r09 release. byuu says: This will be another massive diff from the previous version. All of higan was updated to use the new foo& bar syntax, and I also updated switch statements to be consistent as well (but not in the disassemblers, was starting to get an RSI just from what I already did.) phoenix/{windows, cocoa, qt} need to be updated to use "string foo" instead of "const string& foo", and after that, the major diffs should be finished. This archive is the first time I'm posting my copy-on-write, size+capacity nall::string class, so any feedback on that is welcome as well.
2013-05-05 09:21:30 +00:00
Sprite(PPU& self);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v092r09 release. byuu says: This will be another massive diff from the previous version. All of higan was updated to use the new foo& bar syntax, and I also updated switch statements to be consistent as well (but not in the disassemblers, was starting to get an RSI just from what I already did.) phoenix/{windows, cocoa, qt} need to be updated to use "string foo" instead of "const string& foo", and after that, the major diffs should be finished. This archive is the first time I'm posting my copy-on-write, size+capacity nall::string class, so any feedback on that is welcome as well.
2013-05-05 09:21:30 +00:00
PPU& self;
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
friend class PPU;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
};