bsnes/higan/sfc/ppu/background.hpp

88 lines
1.7 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 Background {
Background(uint id) : id(id) {}
alwaysinline auto hires() const -> bool;
alwaysinline auto hoffset() const -> uint16;
alwaysinline auto voffset() const -> uint16;
auto frame() -> void;
auto scanline() -> void;
auto begin() -> void;
auto run(bool screen) -> void;
Update to v102r02 release. byuu says: Changelog: - I caved on the `samples[] = {0.0}` thing, but I'm very unhappy about it - if it's really invalid C++, then GCC needs to stop accepting it in strict `-std=c++14` mode - Emulator::Interface::Information::resettable is gone - Emulator::Interface::reset() is gone - FC, SFC, MD cores updated to remove soft reset behavior - split GameBoy::Interface into GameBoyInterface, GameBoyColorInterface - split WonderSwan::Interface into WonderSwanInterface, WonderSwanColorInterface - PCE: fixed off-by-one scanline error [hex_usr] - PCE: temporary hack to prevent crashing when VDS is set to < 2 - hiro: Cocoa: removed (u)int(#) constants; converted (u)int(#) types to (u)int_(#)t types - icarus: replaced usage of unique with strip instead (so we don't mess up frameworks on macOS) - libco: added macOS-specific section marker [Ryphecha] So ... the major news this time is the removal of the soft reset behavior. This is a major!! change that results in a 100KiB diff file, and it's very prone to accidental mistakes!! If anyone is up for testing, or even better -- looking over the code changes between v102r01 and v102r02 and looking for any issues, please do so. Ideally we'll want to test every NES mapper type and every SNES coprocessor type by loading said games and power cycling to make sure the games are all cleanly resetting. It's too big of a change for me to cover there not being any issues on my own, but this is truly critical code, so yeah ... please help if you can. We technically lose a bit of hardware documentation here. The soft reset events do all kinds of interesting things in all kinds of different chips -- or at least they do on the SNES. This is obviously not ideal. But in the process of removing these portions of code, I found a few mistakes I had made previously. It simplifies resetting the system state a lot when not trying to have all the power() functions call the reset() functions to share partial functionality. In the future, the goal will be to come up with a way to add back in the soft reset behavior via keyboard binding as with the Master System core. What's going to have to happen is that the key binding will have to send a "reset pulse" to every emulated chip, and those chips are going to have to act independently to power() instead of reusing functionality. We'll get there eventually, but there's many things of vastly greater importance to work on right now, so it'll be a while. The information isn't lost ... we'll just have to pull it out of v102 when we are ready. Note that I left the SNES reset vector simulation code in, even though it's not possible to trigger, for the time being. Also ... the Super Game Boy core is still disconnected. To be honest, it totally slipped my mind when I released v102 that it wasn't connected again yet. This one's going to be pretty tricky to be honest. I'm thinking about making a third GameBoy::Interface class just for SGB, and coming up with some way of bypassing platform-> calls when in this mode.
2017-01-22 21:04:26 +00:00
auto power() -> void;
auto getTile() -> void;
auto getTileColor() -> uint;
Update to v106r33 release. byuu says: Changelog: - nall/GNUmakefile: added `openmp=(true,false)` option; can be toggled when building higan/bsnes - defaults to disabled on macOS, because Xcode doesn't stupidly doesn't ship with support for it - higan/GNUmakefile: forgot to switch target,profile back from bsnes,fast to higan,accurate - this is just gonna happen from time to time, sorry - sfc/dsp: when using the fast profile, the DSP syncs per sample instead of per clock - should only negatively impact Koushien 2, but is a fairly significant speedup otherwise - sfc/ppc,ppu-fast: optimized the code a bit (ppu 130fps to 133fps) - sfc/ppu-fast: basic vertical mosaic support (not accurate, but should look okay hopefully) - sfc/ppu-fast: added missing mode7 hflip support - sfc/ppu-fast: added support to render at 256-width and/or 240-height - gives a decent speed boost, and also allows all of the older quark shaders to work nicely again - it does violate the contract of Emulator::Interface, but oh well, it works fine in the bsnes GUI - sfc/ppu-fast: use cached CGRAM values for mode7 and sprites - sfc/ppu-fast: use global range/time over flags in object rendering - may not actually work as we intended since it's a race condition even if it's only ORing the flags - really don't want to have to make those variables atomic if I don't have to - sfc/ppu-fast: should fully support interlace and overscan modes now - hiro/cocoa: updated macOS Gatekeeper disable support to work on 10.13+ - ruby: forgot to fix macOS input driver, sorry - nall/GNUmakefile: if uname is present, then just default to rm instead of del (fixes Msys) Note: blur emulation option will break pretty badly in 256x240 output mode. I'll fix it later.
2018-05-31 07:06:55 +00:00
auto getTile(uint x, uint y) -> uint16;
alwaysinline auto clip(int n) -> int;
auto beginMode7() -> void;
auto runMode7() -> void;
auto serialize(serializer&) -> void;
struct ID { enum : uint { BG1, BG2, BG3, BG4 }; };
const uint id;
struct Mode { enum : uint { BPP2, BPP4, BPP8, Mode7, Inactive }; };
struct ScreenSize { enum : uint { Size32x32, Size32x64, Size64x32, Size64x64 }; };
struct TileSize { enum : uint { Size8x8, Size16x16 }; };
struct Screen { enum : uint { Above, Below }; };
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
struct IO {
uint16 tiledataAddress;
uint16 screenAddress;
uint2 screenSize;
uint1 tileSize;
uint8 mode;
uint8 priority[2];
uint1 aboveEnable;
uint1 belowEnable;
uint16 hoffset;
uint16 voffset;
Update to v099r14 release. byuu says: Changelog: - (u)int(max,ptr) abbreviations removed; use _t suffix now [didn't feel like they were contributing enough to be worth it] - cleaned up nall::integer,natural,real functionality - toInteger, toNatural, toReal for parsing strings to numbers - fromInteger, fromNatural, fromReal for creating strings from numbers - (string,Markup::Node,SQL-based-classes)::(integer,natural,real) left unchanged - template<typename T> numeral(T value, long padding, char padchar) -> string for print() formatting - deduces integer,natural,real based on T ... cast the value if you want to override - there still exists binary,octal,hex,pointer for explicit print() formatting - lstring -> string_vector [but using lstring = string_vector; is declared] - would be nice to remove the using lstring eventually ... but that'd probably require 10,000 lines of changes >_> - format -> string_format [no using here; format was too ambiguous] - using integer = Integer<sizeof(int)*8>; and using natural = Natural<sizeof(uint)*8>; declared - for consistency with boolean. These three are meant for creating zero-initialized values implicitly (various uses) - R65816::io() -> idle() and SPC700::io() -> idle() [more clear; frees up struct IO {} io; naming] - SFC CPU, PPU, SMP use struct IO {} io; over struct (Status,Registers) {} (status,registers); now - still some CPU::Status status values ... they didn't really fit into IO functionality ... will have to think about this more - SFC CPU, PPU, SMP now use step() exclusively instead of addClocks() calling into step() - SFC CPU joypad1_bits, joypad2_bits were unused; killed them - SFC PPU CGRAM moved into PPU::Screen; since nothing else uses it - SFC PPU OAM moved into PPU::Object; since nothing else uses it - the raw uint8[544] array is gone. OAM::read() constructs values from the OAM::Object[512] table now - this avoids having to determine how we want to sub-divide the two OAM memory sections - this also eliminates the OAM::synchronize() functionality - probably more I'm forgetting The FPS fluctuations are driving me insane. This WIP went from 128fps to 137fps. Settled on 133.5fps for the final build. But nothing I changed should have affected performance at all. This level of fluctuation makes it damn near impossible to know whether I'm speeding things up or slowing things down with changes.
2016-07-01 11:50:32 +00:00
} io;
struct Latch {
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
uint16 hoffset;
uint16 voffset;
} latch;
struct Pixel {
uint8 priority; //0 = none (transparent)
uint8 palette;
uint16 tile;
} above, below;
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 {
Pixel above;
Pixel below;
} output;
struct Mosaic {
static uint4 size;
uint1 enable;
uint16 vcounter;
uint16 hcounter;
uint16 voffset;
uint16 hoffset;
Pixel pixel;
} mosaic;
int x;
int y;
uint3 tileCounter;
uint16 tile;
uint8 priority;
uint3 paletteNumber;
uint8 paletteIndex;
uint32 data[2];
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;
};