bsnes/higan/sfc/ppu-fast/line.cpp

103 lines
3.7 KiB
C++
Raw Normal View History

uint PPU::Line::start = 0;
uint PPU::Line::count = 0;
auto PPU::Line::flush() -> void {
if(Line::count) {
Update to v106r35 release. byuu says: Changelog: - sfc/ppu-fast: fixed overscan crash - sfc/ppu-fast: fixed direct color mode - sfc: reconnected MSU1 support - higan: game.sfc/msu1/data.rom, game.sfc/msu1/track-#.pcm - bsnes: game.msu, game-#.pcm - bsnes: added cheat code editor - bsnes: added cheat code database support - sfc/ppu-fast: clear overscan lines when overscan disabled - sfc: output 223/239 lines instead of 224/240 lines - bsnes: fix aspect correction calculation - bsnes: crop line 224 when overscan masking is enabled - bsnes: exposed Expansion Port menu; but hid “21fx” from the list of devices - bsnes: tools menu is hidden until a game is loaded - ruby/input/keyboard/quartz: fixed compilation error So only bsnes the automated overscan cropping option. In higan, you can crop however many lines you like from the top or bottom of the image. But for bsnes, it automatically eats sixteen lines. My view right now is that if bsnes is meant to be the casual gaming emulator, that it should eat line 224 in this mode. Most games show content here, but because of the way the SNES PPU works, the very last line ends up on its very own tile row (line 0 isn't rendered), if the scroll registers don't account for it. There's a small number of games that will draw junk data to the very last scanline of the frame as a result of this. So I chose, at least for now, to hide it. Users can obviously disable overscan cropping to see this scanline. I'm open to being convinced not to do this, if someone has a compelling reason. We're pretty much screwed one way or the other with no overscan masking. If we output 239 lines, then most games will render 7 blank lines + 224 drawn lines + 8 blank lines, and the black top and bottom aren't centered. But if we output 240 lines to get 8 + 224 + 8, then games that do use overscan will have a blank line at the very bottom of the window. I'm also trying out a modified cheat code file format. It's been forever since I bothered to look at it, and the “cartridge” parent node doesn't match what I'm doing with trying to rename “cartridge” to “game” in manifests. And indeed, the idea of requiring a root node is rather superfluous for a cheat code file. Current format looks like this: cheat description: foo code: 7e2000=20+7e2001=30?40 enabled cheat description: bar code: 7e4000=80 Open to discussing this, and I'd like to sync up with Snes9X before they push out a new release, and I'll agree to finalize and never change this format again. I chose to use .cht for the extension when using game files (eg gamename.cht)
2018-06-03 13:14:42 +00:00
#pragma omp parallel for if(Line::count >= 8)
for(uint y = 0; y < Line::count; y++) {
ppu.lines[Line::start + y].render();
}
Line::start = 0;
Line::count = 0;
}
}
auto PPU::Line::render() -> void {
auto output = ppu.output + y * 1024;
if(ppu.interlace() && ppu.field()) output += 512;
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 width = !ppu.hires() ? 256 : 512;
if(io.displayDisable) {
Update to v106r35 release. byuu says: Changelog: - sfc/ppu-fast: fixed overscan crash - sfc/ppu-fast: fixed direct color mode - sfc: reconnected MSU1 support - higan: game.sfc/msu1/data.rom, game.sfc/msu1/track-#.pcm - bsnes: game.msu, game-#.pcm - bsnes: added cheat code editor - bsnes: added cheat code database support - sfc/ppu-fast: clear overscan lines when overscan disabled - sfc: output 223/239 lines instead of 224/240 lines - bsnes: fix aspect correction calculation - bsnes: crop line 224 when overscan masking is enabled - bsnes: exposed Expansion Port menu; but hid “21fx” from the list of devices - bsnes: tools menu is hidden until a game is loaded - ruby/input/keyboard/quartz: fixed compilation error So only bsnes the automated overscan cropping option. In higan, you can crop however many lines you like from the top or bottom of the image. But for bsnes, it automatically eats sixteen lines. My view right now is that if bsnes is meant to be the casual gaming emulator, that it should eat line 224 in this mode. Most games show content here, but because of the way the SNES PPU works, the very last line ends up on its very own tile row (line 0 isn't rendered), if the scroll registers don't account for it. There's a small number of games that will draw junk data to the very last scanline of the frame as a result of this. So I chose, at least for now, to hide it. Users can obviously disable overscan cropping to see this scanline. I'm open to being convinced not to do this, if someone has a compelling reason. We're pretty much screwed one way or the other with no overscan masking. If we output 239 lines, then most games will render 7 blank lines + 224 drawn lines + 8 blank lines, and the black top and bottom aren't centered. But if we output 240 lines to get 8 + 224 + 8, then games that do use overscan will have a blank line at the very bottom of the window. I'm also trying out a modified cheat code file format. It's been forever since I bothered to look at it, and the “cartridge” parent node doesn't match what I'm doing with trying to rename “cartridge” to “game” in manifests. And indeed, the idea of requiring a root node is rather superfluous for a cheat code file. Current format looks like this: cheat description: foo code: 7e2000=20+7e2001=30?40 enabled cheat description: bar code: 7e4000=80 Open to discussing this, and I'd like to sync up with Snes9X before they push out a new release, and I'll agree to finalize and never change this format again. I chose to use .cht for the extension when using game files (eg gamename.cht)
2018-06-03 13:14:42 +00:00
memory::fill<uint32>(output, width);
return;
}
Update to v106r35 release. byuu says: Changelog: - sfc/ppu-fast: fixed overscan crash - sfc/ppu-fast: fixed direct color mode - sfc: reconnected MSU1 support - higan: game.sfc/msu1/data.rom, game.sfc/msu1/track-#.pcm - bsnes: game.msu, game-#.pcm - bsnes: added cheat code editor - bsnes: added cheat code database support - sfc/ppu-fast: clear overscan lines when overscan disabled - sfc: output 223/239 lines instead of 224/240 lines - bsnes: fix aspect correction calculation - bsnes: crop line 224 when overscan masking is enabled - bsnes: exposed Expansion Port menu; but hid “21fx” from the list of devices - bsnes: tools menu is hidden until a game is loaded - ruby/input/keyboard/quartz: fixed compilation error So only bsnes the automated overscan cropping option. In higan, you can crop however many lines you like from the top or bottom of the image. But for bsnes, it automatically eats sixteen lines. My view right now is that if bsnes is meant to be the casual gaming emulator, that it should eat line 224 in this mode. Most games show content here, but because of the way the SNES PPU works, the very last line ends up on its very own tile row (line 0 isn't rendered), if the scroll registers don't account for it. There's a small number of games that will draw junk data to the very last scanline of the frame as a result of this. So I chose, at least for now, to hide it. Users can obviously disable overscan cropping to see this scanline. I'm open to being convinced not to do this, if someone has a compelling reason. We're pretty much screwed one way or the other with no overscan masking. If we output 239 lines, then most games will render 7 blank lines + 224 drawn lines + 8 blank lines, and the black top and bottom aren't centered. But if we output 240 lines to get 8 + 224 + 8, then games that do use overscan will have a blank line at the very bottom of the window. I'm also trying out a modified cheat code file format. It's been forever since I bothered to look at it, and the “cartridge” parent node doesn't match what I'm doing with trying to rename “cartridge” to “game” in manifests. And indeed, the idea of requiring a root node is rather superfluous for a cheat code file. Current format looks like this: cheat description: foo code: 7e2000=20+7e2001=30?40 enabled cheat description: bar code: 7e4000=80 Open to discussing this, and I'd like to sync up with Snes9X before they push out a new release, and I'll agree to finalize and never change this format again. I chose to use .cht for the extension when using game files (eg gamename.cht)
2018-06-03 13:14:42 +00:00
bool hires = io.pseudoHires || io.bgMode == 5 || io.bgMode == 6;
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
bool hiresMode7 = io.bgMode == 7 && configuration.hacks.ppuFast.hiresMode7;
Update to v106r35 release. byuu says: Changelog: - sfc/ppu-fast: fixed overscan crash - sfc/ppu-fast: fixed direct color mode - sfc: reconnected MSU1 support - higan: game.sfc/msu1/data.rom, game.sfc/msu1/track-#.pcm - bsnes: game.msu, game-#.pcm - bsnes: added cheat code editor - bsnes: added cheat code database support - sfc/ppu-fast: clear overscan lines when overscan disabled - sfc: output 223/239 lines instead of 224/240 lines - bsnes: fix aspect correction calculation - bsnes: crop line 224 when overscan masking is enabled - bsnes: exposed Expansion Port menu; but hid “21fx” from the list of devices - bsnes: tools menu is hidden until a game is loaded - ruby/input/keyboard/quartz: fixed compilation error So only bsnes the automated overscan cropping option. In higan, you can crop however many lines you like from the top or bottom of the image. But for bsnes, it automatically eats sixteen lines. My view right now is that if bsnes is meant to be the casual gaming emulator, that it should eat line 224 in this mode. Most games show content here, but because of the way the SNES PPU works, the very last line ends up on its very own tile row (line 0 isn't rendered), if the scroll registers don't account for it. There's a small number of games that will draw junk data to the very last scanline of the frame as a result of this. So I chose, at least for now, to hide it. Users can obviously disable overscan cropping to see this scanline. I'm open to being convinced not to do this, if someone has a compelling reason. We're pretty much screwed one way or the other with no overscan masking. If we output 239 lines, then most games will render 7 blank lines + 224 drawn lines + 8 blank lines, and the black top and bottom aren't centered. But if we output 240 lines to get 8 + 224 + 8, then games that do use overscan will have a blank line at the very bottom of the window. I'm also trying out a modified cheat code file format. It's been forever since I bothered to look at it, and the “cartridge” parent node doesn't match what I'm doing with trying to rename “cartridge” to “game” in manifests. And indeed, the idea of requiring a root node is rather superfluous for a cheat code file. Current format looks like this: cheat description: foo code: 7e2000=20+7e2001=30?40 enabled cheat description: bar code: 7e4000=80 Open to discussing this, and I'd like to sync up with Snes9X before they push out a new release, and I'll agree to finalize and never change this format again. I chose to use .cht for the extension when using game files (eg gamename.cht)
2018-06-03 13:14:42 +00:00
auto aboveColor = cgram[0];
auto belowColor = hires ? cgram[0] : io.col.fixedColor;
for(uint x : range(256 << hiresMode7)) {
Update to v106r35 release. byuu says: Changelog: - sfc/ppu-fast: fixed overscan crash - sfc/ppu-fast: fixed direct color mode - sfc: reconnected MSU1 support - higan: game.sfc/msu1/data.rom, game.sfc/msu1/track-#.pcm - bsnes: game.msu, game-#.pcm - bsnes: added cheat code editor - bsnes: added cheat code database support - sfc/ppu-fast: clear overscan lines when overscan disabled - sfc: output 223/239 lines instead of 224/240 lines - bsnes: fix aspect correction calculation - bsnes: crop line 224 when overscan masking is enabled - bsnes: exposed Expansion Port menu; but hid “21fx” from the list of devices - bsnes: tools menu is hidden until a game is loaded - ruby/input/keyboard/quartz: fixed compilation error So only bsnes the automated overscan cropping option. In higan, you can crop however many lines you like from the top or bottom of the image. But for bsnes, it automatically eats sixteen lines. My view right now is that if bsnes is meant to be the casual gaming emulator, that it should eat line 224 in this mode. Most games show content here, but because of the way the SNES PPU works, the very last line ends up on its very own tile row (line 0 isn't rendered), if the scroll registers don't account for it. There's a small number of games that will draw junk data to the very last scanline of the frame as a result of this. So I chose, at least for now, to hide it. Users can obviously disable overscan cropping to see this scanline. I'm open to being convinced not to do this, if someone has a compelling reason. We're pretty much screwed one way or the other with no overscan masking. If we output 239 lines, then most games will render 7 blank lines + 224 drawn lines + 8 blank lines, and the black top and bottom aren't centered. But if we output 240 lines to get 8 + 224 + 8, then games that do use overscan will have a blank line at the very bottom of the window. I'm also trying out a modified cheat code file format. It's been forever since I bothered to look at it, and the “cartridge” parent node doesn't match what I'm doing with trying to rename “cartridge” to “game” in manifests. And indeed, the idea of requiring a root node is rather superfluous for a cheat code file. Current format looks like this: cheat description: foo code: 7e2000=20+7e2001=30?40 enabled cheat description: bar code: 7e4000=80 Open to discussing this, and I'd like to sync up with Snes9X before they push out a new release, and I'll agree to finalize and never change this format again. I chose to use .cht for the extension when using game files (eg gamename.cht)
2018-06-03 13:14:42 +00:00
above[x] = {Source::COL, 0, aboveColor};
below[x] = {Source::COL, 0, belowColor};
}
renderBackground(io.bg1, Source::BG1);
renderBackground(io.bg2, Source::BG2);
renderBackground(io.bg3, Source::BG3);
renderBackground(io.bg4, Source::BG4);
renderObject(io.obj);
renderWindow(io.col.window, io.col.window.aboveMask, windowAbove);
renderWindow(io.col.window, io.col.window.belowMask, windowBelow);
Update to v106r35 release. byuu says: Changelog: - sfc/ppu-fast: fixed overscan crash - sfc/ppu-fast: fixed direct color mode - sfc: reconnected MSU1 support - higan: game.sfc/msu1/data.rom, game.sfc/msu1/track-#.pcm - bsnes: game.msu, game-#.pcm - bsnes: added cheat code editor - bsnes: added cheat code database support - sfc/ppu-fast: clear overscan lines when overscan disabled - sfc: output 223/239 lines instead of 224/240 lines - bsnes: fix aspect correction calculation - bsnes: crop line 224 when overscan masking is enabled - bsnes: exposed Expansion Port menu; but hid “21fx” from the list of devices - bsnes: tools menu is hidden until a game is loaded - ruby/input/keyboard/quartz: fixed compilation error So only bsnes the automated overscan cropping option. In higan, you can crop however many lines you like from the top or bottom of the image. But for bsnes, it automatically eats sixteen lines. My view right now is that if bsnes is meant to be the casual gaming emulator, that it should eat line 224 in this mode. Most games show content here, but because of the way the SNES PPU works, the very last line ends up on its very own tile row (line 0 isn't rendered), if the scroll registers don't account for it. There's a small number of games that will draw junk data to the very last scanline of the frame as a result of this. So I chose, at least for now, to hide it. Users can obviously disable overscan cropping to see this scanline. I'm open to being convinced not to do this, if someone has a compelling reason. We're pretty much screwed one way or the other with no overscan masking. If we output 239 lines, then most games will render 7 blank lines + 224 drawn lines + 8 blank lines, and the black top and bottom aren't centered. But if we output 240 lines to get 8 + 224 + 8, then games that do use overscan will have a blank line at the very bottom of the window. I'm also trying out a modified cheat code file format. It's been forever since I bothered to look at it, and the “cartridge” parent node doesn't match what I'm doing with trying to rename “cartridge” to “game” in manifests. And indeed, the idea of requiring a root node is rather superfluous for a cheat code file. Current format looks like this: cheat description: foo code: 7e2000=20+7e2001=30?40 enabled cheat description: bar code: 7e4000=80 Open to discussing this, and I'd like to sync up with Snes9X before they push out a new release, and I'll agree to finalize and never change this format again. I chose to use .cht for the extension when using game files (eg gamename.cht)
2018-06-03 13:14:42 +00:00
auto luma = io.displayBrightness << 15;
if(hiresMode7) for(uint x : range(512)) {
auto Above = above[x >> 1].source >= Source::OBJ1 ? above[x >> 1] : above[x >> 1 | (x & 1 ? 256 : 0)];
auto Below = below[x >> 1].source >= Source::OBJ1 ? below[x >> 1] : below[x >> 1 | (x & 1 ? 256 : 0)];
*output++ = luma | pixel(x >> 1, Above, Below);
} else if(width == 256) for(uint x : range(256)) {
*output++ = luma | pixel(x, above[x], below[x]);
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
} else if(!hires) for(uint x : range(256)) {
auto color = luma | pixel(x, above[x], below[x]);
*output++ = color;
*output++ = color;
} else for(uint x : range(256)) {
*output++ = luma | pixel(x, below[x], above[x]);
*output++ = luma | pixel(x, above[x], below[x]);
}
}
auto PPU::Line::pixel(uint x, Pixel above, Pixel below) const -> uint15 {
if(!windowAbove[x]) above.color = 0x0000;
if(!windowBelow[x]) return above.color;
if(!io.col.enable[above.source]) return above.color;
if(!io.col.blendMode) return blend(above.color, io.col.fixedColor, io.col.halve && windowAbove[x]);
return blend(above.color, below.color, io.col.halve && windowAbove[x] && below.source != Source::COL);
}
auto PPU::Line::blend(uint x, uint y, bool halve) const -> uint15 {
if(!io.col.mathMode) { //add
if(!halve) {
uint sum = x + y;
uint carry = (sum - ((x ^ y) & 0x0421)) & 0x8420;
return (sum - carry) | (carry - (carry >> 5));
} else {
return (x + y - ((x ^ y) & 0x0421)) >> 1;
}
} else { //sub
uint diff = x - y + 0x8420;
uint borrow = (diff - ((x ^ y) & 0x8420)) & 0x8420;
if(!halve) {
return (diff - borrow) & (borrow - (borrow >> 5));
} else {
return (((diff - borrow) & (borrow - (borrow >> 5))) & 0x7bde) >> 1;
}
}
}
Update to v106r35 release. byuu says: Changelog: - sfc/ppu-fast: fixed overscan crash - sfc/ppu-fast: fixed direct color mode - sfc: reconnected MSU1 support - higan: game.sfc/msu1/data.rom, game.sfc/msu1/track-#.pcm - bsnes: game.msu, game-#.pcm - bsnes: added cheat code editor - bsnes: added cheat code database support - sfc/ppu-fast: clear overscan lines when overscan disabled - sfc: output 223/239 lines instead of 224/240 lines - bsnes: fix aspect correction calculation - bsnes: crop line 224 when overscan masking is enabled - bsnes: exposed Expansion Port menu; but hid “21fx” from the list of devices - bsnes: tools menu is hidden until a game is loaded - ruby/input/keyboard/quartz: fixed compilation error So only bsnes the automated overscan cropping option. In higan, you can crop however many lines you like from the top or bottom of the image. But for bsnes, it automatically eats sixteen lines. My view right now is that if bsnes is meant to be the casual gaming emulator, that it should eat line 224 in this mode. Most games show content here, but because of the way the SNES PPU works, the very last line ends up on its very own tile row (line 0 isn't rendered), if the scroll registers don't account for it. There's a small number of games that will draw junk data to the very last scanline of the frame as a result of this. So I chose, at least for now, to hide it. Users can obviously disable overscan cropping to see this scanline. I'm open to being convinced not to do this, if someone has a compelling reason. We're pretty much screwed one way or the other with no overscan masking. If we output 239 lines, then most games will render 7 blank lines + 224 drawn lines + 8 blank lines, and the black top and bottom aren't centered. But if we output 240 lines to get 8 + 224 + 8, then games that do use overscan will have a blank line at the very bottom of the window. I'm also trying out a modified cheat code file format. It's been forever since I bothered to look at it, and the “cartridge” parent node doesn't match what I'm doing with trying to rename “cartridge” to “game” in manifests. And indeed, the idea of requiring a root node is rather superfluous for a cheat code file. Current format looks like this: cheat description: foo code: 7e2000=20+7e2001=30?40 enabled cheat description: bar code: 7e4000=80 Open to discussing this, and I'd like to sync up with Snes9X before they push out a new release, and I'll agree to finalize and never change this format again. I chose to use .cht for the extension when using game files (eg gamename.cht)
2018-06-03 13:14:42 +00:00
auto PPU::Line::directColor(uint paletteIndex, uint paletteColor) const -> uint15 {
//paletteIndex = bgr
//paletteColor = BBGGGRRR
//output = 0 BBb00 GGGg0 RRRr0
return (paletteColor << 2 & 0x001c) + (paletteIndex << 1 & 0x0002) //R
+ (paletteColor << 4 & 0x0380) + (paletteIndex << 5 & 0x0040) //G
+ (paletteColor << 7 & 0x6000) + (paletteIndex << 10 & 0x1000); //B
}
auto PPU::Line::plotAbove(uint x, uint source, uint priority, uint color) -> void {
if(priority > above[x].priority) above[x] = {source, priority, color};
}
auto PPU::Line::plotBelow(uint x, uint source, uint priority, uint color) -> void {
if(priority > below[x].priority) below[x] = {source, priority, color};
}