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

70 lines
2.4 KiB
C++
Raw Normal View History

Update to v102r19 release. byuu says: Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on Windows (ugh ...) Now to await posts about this in four more threads again ;) Changelog: - GBA: rewrote PPU from a scanline-based renderer to a pixel-based renderer - ruby: fixed video/gdi bugs Note that there's an approximately 21% speed penalty compared to v102r18 for the pixel-based renderer. Also, horizontal mosaic effects are not yet implemented. But they should be prior to v103. This one is a little tricky as it currently works on fully rendered scanlines. I need to roll the mosaic into the background renderers, and then for sprites, well ... see below. The trickiest part by far of this new renderer is the object (sprite) system. Unlike every other system I emulate, the GBA supports affine rendering of its sprites. Or in other words, rotation effects. And it also has a very complex priority system. Right now, I can't see any way that the GBA PPU could render pixels in real-time like this. My belief is that there's a 240-entry buffer that fills up the next scanline's row of pixels. Which means it probably also runs on the last scanline of Vblank so that the first scanline has sprite data. However, I didn't design my object renderer like this just yet. For now, it creates a buffer of all 240 pixels right away at the start of the scanline. I know\!\! That's technically scanline-based. But it's only for fetching object tiledata, and it's only temporary. What needs to happen is I need a way to run something like a "mini libco thread" inside of the main thread, so that the object renderer can run in parallel with the rest of the PPU, yet not be a hideous abomination of a state machine, yet also not be horrendously slow as a full libco thread would be. I'm envisioning some kind of stackless yielding coroutine. But I'll need to think through how to design that, given the absence of coroutines even in C++17.
2017-06-04 03:16:44 +00:00
auto PPU::Screen::run(uint x, uint y) -> uint15 {
if(ppu.blank()) return 0x7fff;
//determine active window
uint1 active[6] = {true, true, true, true, true, true}; //enable all layers if no windows are enabled
if(ppu.window0.io.enable || ppu.window1.io.enable || ppu.window2.io.enable) {
memory::copy(&active, &ppu.window3.io.active, sizeof(active));
if(ppu.window2.io.enable && ppu.window2.output) memory::copy(&active, &ppu.window2.io.active, sizeof(active));
if(ppu.window1.io.enable && ppu.window1.output) memory::copy(&active, &ppu.window1.io.active, sizeof(active));
if(ppu.window0.io.enable && ppu.window0.output) memory::copy(&active, &ppu.window0.io.active, sizeof(active));
}
Update to v087r21 release. byuu says: Timer speedup added. Boosts Mr. Driller 2 title from 170fps to 400fps. Other games still benefit, but not as amazingly. I don't dip below 160fps ever here. Reverted the memory speed to 2 for everything for now, to fix Castlevania slowdown. We obviously need to add the N/S stuff before we do that. Added linear BG and linear OBJ mosaic-Y. Did not add mosaic-X, or any mosaic to the affine/bitmap modes, because I'm not sure when to apply the compensation. Rewrote layer stuff. It now has two layers (above and below), and it performs the four blending modes as needed. Didn't add semi-transparent sprites because the docs are too confusing. Added a blur filter directly into the PPU for now. This obviously violates my interface, but F-Zero needed it for HUD display. We can remove it when we have an official release with a blur filter available. The filter still doesn't warp colors like a real GBA, because I don't know the formula.
2012-04-10 11:41:35 +00:00
Update to v102r19 release. byuu says: Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on Windows (ugh ...) Now to await posts about this in four more threads again ;) Changelog: - GBA: rewrote PPU from a scanline-based renderer to a pixel-based renderer - ruby: fixed video/gdi bugs Note that there's an approximately 21% speed penalty compared to v102r18 for the pixel-based renderer. Also, horizontal mosaic effects are not yet implemented. But they should be prior to v103. This one is a little tricky as it currently works on fully rendered scanlines. I need to roll the mosaic into the background renderers, and then for sprites, well ... see below. The trickiest part by far of this new renderer is the object (sprite) system. Unlike every other system I emulate, the GBA supports affine rendering of its sprites. Or in other words, rotation effects. And it also has a very complex priority system. Right now, I can't see any way that the GBA PPU could render pixels in real-time like this. My belief is that there's a 240-entry buffer that fills up the next scanline's row of pixels. Which means it probably also runs on the last scanline of Vblank so that the first scanline has sprite data. However, I didn't design my object renderer like this just yet. For now, it creates a buffer of all 240 pixels right away at the start of the scanline. I know\!\! That's technically scanline-based. But it's only for fetching object tiledata, and it's only temporary. What needs to happen is I need a way to run something like a "mini libco thread" inside of the main thread, so that the object renderer can run in parallel with the rest of the PPU, yet not be a hideous abomination of a state machine, yet also not be horrendously slow as a full libco thread would be. I'm envisioning some kind of stackless yielding coroutine. But I'll need to think through how to design that, given the absence of coroutines even in C++17.
2017-06-04 03:16:44 +00:00
//priority sorting: find topmost two pixels
Pixel layers[6] = {
Update to v102r20 release. byuu says: Changelog: - nall: `#undef OUT` on Windows platform - GBA: add missing CPU prefetch state to serialization (this was breaking serialization in games using ROM prefetch) - GBA: reset all PPU data in the power() function (some things were missing before, causing issues on reset) - GBA: restored horizontal mosaic emulation to the new pixel-based renderer - GBA: fixed tilemap background horizontal flipping (Legend of Spyro - warning screen) - GBA: fixed d8 bits of scroll registers (ATV - Thunder Ridge Racers - menu screen) - SFC: DRAM refresh ticks the ALU MUL/DIV registers five steps forward [reported by kevtris] - SFC: merged dmaCounter and autoJoypadCounter into new shared clockCounter - left stub for old dmaCounter so that I can do some traces to ensure the new code's 100% identical GBA save states would have been broken since whenever I emulated ROM prefetch. I guess not many people are using the GBA core ...
2017-06-06 01:39:27 +00:00
ppu.objects.mosaic,
ppu.bg0.mosaic,
ppu.bg1.mosaic,
ppu.bg2.mosaic,
ppu.bg3.mosaic,
Update to v102r19 release. byuu says: Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on Windows (ugh ...) Now to await posts about this in four more threads again ;) Changelog: - GBA: rewrote PPU from a scanline-based renderer to a pixel-based renderer - ruby: fixed video/gdi bugs Note that there's an approximately 21% speed penalty compared to v102r18 for the pixel-based renderer. Also, horizontal mosaic effects are not yet implemented. But they should be prior to v103. This one is a little tricky as it currently works on fully rendered scanlines. I need to roll the mosaic into the background renderers, and then for sprites, well ... see below. The trickiest part by far of this new renderer is the object (sprite) system. Unlike every other system I emulate, the GBA supports affine rendering of its sprites. Or in other words, rotation effects. And it also has a very complex priority system. Right now, I can't see any way that the GBA PPU could render pixels in real-time like this. My belief is that there's a 240-entry buffer that fills up the next scanline's row of pixels. Which means it probably also runs on the last scanline of Vblank so that the first scanline has sprite data. However, I didn't design my object renderer like this just yet. For now, it creates a buffer of all 240 pixels right away at the start of the scanline. I know\!\! That's technically scanline-based. But it's only for fetching object tiledata, and it's only temporary. What needs to happen is I need a way to run something like a "mini libco thread" inside of the main thread, so that the object renderer can run in parallel with the rest of the PPU, yet not be a hideous abomination of a state machine, yet also not be horrendously slow as a full libco thread would be. I'm envisioning some kind of stackless yielding coroutine. But I'll need to think through how to design that, given the absence of coroutines even in C++17.
2017-06-04 03:16:44 +00:00
{true, 3, ppu.pram[0]},
};
Update to v087r21 release. byuu says: Timer speedup added. Boosts Mr. Driller 2 title from 170fps to 400fps. Other games still benefit, but not as amazingly. I don't dip below 160fps ever here. Reverted the memory speed to 2 for everything for now, to fix Castlevania slowdown. We obviously need to add the N/S stuff before we do that. Added linear BG and linear OBJ mosaic-Y. Did not add mosaic-X, or any mosaic to the affine/bitmap modes, because I'm not sure when to apply the compensation. Rewrote layer stuff. It now has two layers (above and below), and it performs the four blending modes as needed. Didn't add semi-transparent sprites because the docs are too confusing. Added a blur filter directly into the PPU for now. This obviously violates my interface, but F-Zero needed it for HUD display. We can remove it when we have an official release with a blur filter available. The filter still doesn't warp colors like a real GBA, because I don't know the formula.
2012-04-10 11:41:35 +00:00
Update to v102r19 release. byuu says: Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on Windows (ugh ...) Now to await posts about this in four more threads again ;) Changelog: - GBA: rewrote PPU from a scanline-based renderer to a pixel-based renderer - ruby: fixed video/gdi bugs Note that there's an approximately 21% speed penalty compared to v102r18 for the pixel-based renderer. Also, horizontal mosaic effects are not yet implemented. But they should be prior to v103. This one is a little tricky as it currently works on fully rendered scanlines. I need to roll the mosaic into the background renderers, and then for sprites, well ... see below. The trickiest part by far of this new renderer is the object (sprite) system. Unlike every other system I emulate, the GBA supports affine rendering of its sprites. Or in other words, rotation effects. And it also has a very complex priority system. Right now, I can't see any way that the GBA PPU could render pixels in real-time like this. My belief is that there's a 240-entry buffer that fills up the next scanline's row of pixels. Which means it probably also runs on the last scanline of Vblank so that the first scanline has sprite data. However, I didn't design my object renderer like this just yet. For now, it creates a buffer of all 240 pixels right away at the start of the scanline. I know\!\! That's technically scanline-based. But it's only for fetching object tiledata, and it's only temporary. What needs to happen is I need a way to run something like a "mini libco thread" inside of the main thread, so that the object renderer can run in parallel with the rest of the PPU, yet not be a hideous abomination of a state machine, yet also not be horrendously slow as a full libco thread would be. I'm envisioning some kind of stackless yielding coroutine. But I'll need to think through how to design that, given the absence of coroutines even in C++17.
2017-06-04 03:16:44 +00:00
uint aboveLayer = 5, belowLayer = 5;
for(int priority = 3; priority >= 0; priority--) {
for(int layer = 5; layer >= 0; layer--) {
if(layers[layer].enable && layers[layer].priority == priority && active[layer]) {
belowLayer = aboveLayer;
aboveLayer = layer;
}
}
}
Update to v087r21 release. byuu says: Timer speedup added. Boosts Mr. Driller 2 title from 170fps to 400fps. Other games still benefit, but not as amazingly. I don't dip below 160fps ever here. Reverted the memory speed to 2 for everything for now, to fix Castlevania slowdown. We obviously need to add the N/S stuff before we do that. Added linear BG and linear OBJ mosaic-Y. Did not add mosaic-X, or any mosaic to the affine/bitmap modes, because I'm not sure when to apply the compensation. Rewrote layer stuff. It now has two layers (above and below), and it performs the four blending modes as needed. Didn't add semi-transparent sprites because the docs are too confusing. Added a blur filter directly into the PPU for now. This obviously violates my interface, but F-Zero needed it for HUD display. We can remove it when we have an official release with a blur filter available. The filter still doesn't warp colors like a real GBA, because I don't know the formula.
2012-04-10 11:41:35 +00:00
Update to v102r19 release. byuu says: Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on Windows (ugh ...) Now to await posts about this in four more threads again ;) Changelog: - GBA: rewrote PPU from a scanline-based renderer to a pixel-based renderer - ruby: fixed video/gdi bugs Note that there's an approximately 21% speed penalty compared to v102r18 for the pixel-based renderer. Also, horizontal mosaic effects are not yet implemented. But they should be prior to v103. This one is a little tricky as it currently works on fully rendered scanlines. I need to roll the mosaic into the background renderers, and then for sprites, well ... see below. The trickiest part by far of this new renderer is the object (sprite) system. Unlike every other system I emulate, the GBA supports affine rendering of its sprites. Or in other words, rotation effects. And it also has a very complex priority system. Right now, I can't see any way that the GBA PPU could render pixels in real-time like this. My belief is that there's a 240-entry buffer that fills up the next scanline's row of pixels. Which means it probably also runs on the last scanline of Vblank so that the first scanline has sprite data. However, I didn't design my object renderer like this just yet. For now, it creates a buffer of all 240 pixels right away at the start of the scanline. I know\!\! That's technically scanline-based. But it's only for fetching object tiledata, and it's only temporary. What needs to happen is I need a way to run something like a "mini libco thread" inside of the main thread, so that the object renderer can run in parallel with the rest of the PPU, yet not be a hideous abomination of a state machine, yet also not be horrendously slow as a full libco thread would be. I'm envisioning some kind of stackless yielding coroutine. But I'll need to think through how to design that, given the absence of coroutines even in C++17.
2017-06-04 03:16:44 +00:00
auto above = layers[aboveLayer];
auto below = layers[belowLayer];
auto eva = min(16u, (uint)io.blendEVA);
auto evb = min(16u, (uint)io.blendEVB);
auto evy = min(16u, (uint)io.blendEVY);
uint15 color = above.color;
Update to v087r22 release. byuu says: Changelog: - fixed below pixel green channel on color blending - added semi-transparent objects [Exophase's method] - added full support for windows (both inputs, OBJ windows, and output, with optional color effect disable) - EEPROM uses nall::bitarray now to be friendlier to saving memory to disk - removed incomplete mosaic support for now (too broken, untested) - improved sprite priority. Hopefully it's right now. Just about everything should look great now. It took 25 days, but we finally have the BIOS rendering correctly. In order to do OBJ windows, I had to drop my above/below buffers entirely. I went with the nuclear option. There's separate layers for all BGs and objects. I build the OBJ window table during object rendering. So as a result, after rendering I go back and apply windows (and the object window that now exists.) After that, I have to do a painful Z-buffer select of the top two most important pixels. Since I now know the layers, the blending enable tests are a lot nicer, at least. But this obviously has quite a speed hit: 390fps to 325fps for Mr. Driller 2 title screen. TONC says that "bad" window coordinates do really insane things. GBAtek says it's a simple y2 < y1 || y2 > 160 ? 160 : y2; x2 < x1 || x2 > 240 ? 240 : x2; I like the GBAtek version more, so I went with that. I sure hope it's right ... but my guess is the hardware does this with a counter that wraps around or something. Also, say you have two OBJ mode 2 sprites that overlap each other, but with different priorities. The lower (more important) priority sprite has a clear pixel, but the higher priority sprite has a set pixel. Do we set the "inside OBJ window" flag to true here? Eg does the value OR, or does it hold the most important sprite's pixel value? Cydrak suspects it's OR-based, I concur from what I can see. Mosaic, I am at a loss. I really need a lot more information in order to implement it. For backgrounds, does it apply to the Vcounter of the entire screen? Or does it apply post-scroll? Or does it even apply after every adjust in affine/bitmap modes? I'm betting the hcounter background mosaic starts at the leftmost edge of the screen, and repeats previous pixels to apply the effect. Like SNES, very simple. For sprites, the SNES didn't have this. Does the mosaic grid start at (0,0) of the screen, or at (0,0) of each sprite? The latter will look a lot nicer, but be a lot more complex. Is mosaic on affine objects any different than mosaic of linear(tiled) objects? With that out of the way, we still have to fix the CPU memory access timing, add the rest of the CPU penalty cycles, the memory rotation / alignment / extend behavior needs to be fixed, the shifter desperately needs to be moved from loops to single shift operations, and I need to add flash memory support.
2012-04-13 11:49:32 +00:00
Update to v102r19 release. byuu says: Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on Windows (ugh ...) Now to await posts about this in four more threads again ;) Changelog: - GBA: rewrote PPU from a scanline-based renderer to a pixel-based renderer - ruby: fixed video/gdi bugs Note that there's an approximately 21% speed penalty compared to v102r18 for the pixel-based renderer. Also, horizontal mosaic effects are not yet implemented. But they should be prior to v103. This one is a little tricky as it currently works on fully rendered scanlines. I need to roll the mosaic into the background renderers, and then for sprites, well ... see below. The trickiest part by far of this new renderer is the object (sprite) system. Unlike every other system I emulate, the GBA supports affine rendering of its sprites. Or in other words, rotation effects. And it also has a very complex priority system. Right now, I can't see any way that the GBA PPU could render pixels in real-time like this. My belief is that there's a 240-entry buffer that fills up the next scanline's row of pixels. Which means it probably also runs on the last scanline of Vblank so that the first scanline has sprite data. However, I didn't design my object renderer like this just yet. For now, it creates a buffer of all 240 pixels right away at the start of the scanline. I know\!\! That's technically scanline-based. But it's only for fetching object tiledata, and it's only temporary. What needs to happen is I need a way to run something like a "mini libco thread" inside of the main thread, so that the object renderer can run in parallel with the rest of the PPU, yet not be a hideous abomination of a state machine, yet also not be horrendously slow as a full libco thread would be. I'm envisioning some kind of stackless yielding coroutine. But I'll need to think through how to design that, given the absence of coroutines even in C++17.
2017-06-04 03:16:44 +00:00
//color blending
if(active[SFX]) {
if(above.translucent && io.blendBelow[belowLayer]) {
color = blend(above.color, eva, below.color, evb);
} else if(io.blendMode == 1 && io.blendAbove[aboveLayer] && io.blendBelow[belowLayer]) {
color = blend(above.color, eva, below.color, evb);
} else if(io.blendMode == 2 && io.blendAbove[aboveLayer]) {
color = blend(above.color, 16 - evy, 0x7fff, evy);
} else if(io.blendMode == 3 && io.blendAbove[aboveLayer]) {
color = blend(above.color, 16 - evy, 0x0000, evy);
Update to v087r22 release. byuu says: Changelog: - fixed below pixel green channel on color blending - added semi-transparent objects [Exophase's method] - added full support for windows (both inputs, OBJ windows, and output, with optional color effect disable) - EEPROM uses nall::bitarray now to be friendlier to saving memory to disk - removed incomplete mosaic support for now (too broken, untested) - improved sprite priority. Hopefully it's right now. Just about everything should look great now. It took 25 days, but we finally have the BIOS rendering correctly. In order to do OBJ windows, I had to drop my above/below buffers entirely. I went with the nuclear option. There's separate layers for all BGs and objects. I build the OBJ window table during object rendering. So as a result, after rendering I go back and apply windows (and the object window that now exists.) After that, I have to do a painful Z-buffer select of the top two most important pixels. Since I now know the layers, the blending enable tests are a lot nicer, at least. But this obviously has quite a speed hit: 390fps to 325fps for Mr. Driller 2 title screen. TONC says that "bad" window coordinates do really insane things. GBAtek says it's a simple y2 < y1 || y2 > 160 ? 160 : y2; x2 < x1 || x2 > 240 ? 240 : x2; I like the GBAtek version more, so I went with that. I sure hope it's right ... but my guess is the hardware does this with a counter that wraps around or something. Also, say you have two OBJ mode 2 sprites that overlap each other, but with different priorities. The lower (more important) priority sprite has a clear pixel, but the higher priority sprite has a set pixel. Do we set the "inside OBJ window" flag to true here? Eg does the value OR, or does it hold the most important sprite's pixel value? Cydrak suspects it's OR-based, I concur from what I can see. Mosaic, I am at a loss. I really need a lot more information in order to implement it. For backgrounds, does it apply to the Vcounter of the entire screen? Or does it apply post-scroll? Or does it even apply after every adjust in affine/bitmap modes? I'm betting the hcounter background mosaic starts at the leftmost edge of the screen, and repeats previous pixels to apply the effect. Like SNES, very simple. For sprites, the SNES didn't have this. Does the mosaic grid start at (0,0) of the screen, or at (0,0) of each sprite? The latter will look a lot nicer, but be a lot more complex. Is mosaic on affine objects any different than mosaic of linear(tiled) objects? With that out of the way, we still have to fix the CPU memory access timing, add the rest of the CPU penalty cycles, the memory rotation / alignment / extend behavior needs to be fixed, the shifter desperately needs to be moved from loops to single shift operations, and I need to add flash memory support.
2012-04-13 11:49:32 +00:00
}
Update to v087r21 release. byuu says: Timer speedup added. Boosts Mr. Driller 2 title from 170fps to 400fps. Other games still benefit, but not as amazingly. I don't dip below 160fps ever here. Reverted the memory speed to 2 for everything for now, to fix Castlevania slowdown. We obviously need to add the N/S stuff before we do that. Added linear BG and linear OBJ mosaic-Y. Did not add mosaic-X, or any mosaic to the affine/bitmap modes, because I'm not sure when to apply the compensation. Rewrote layer stuff. It now has two layers (above and below), and it performs the four blending modes as needed. Didn't add semi-transparent sprites because the docs are too confusing. Added a blur filter directly into the PPU for now. This obviously violates my interface, but F-Zero needed it for HUD display. We can remove it when we have an official release with a blur filter available. The filter still doesn't warp colors like a real GBA, because I don't know the formula.
2012-04-10 11:41:35 +00:00
}
Update to v102r19 release. byuu says: Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on Windows (ugh ...) Now to await posts about this in four more threads again ;) Changelog: - GBA: rewrote PPU from a scanline-based renderer to a pixel-based renderer - ruby: fixed video/gdi bugs Note that there's an approximately 21% speed penalty compared to v102r18 for the pixel-based renderer. Also, horizontal mosaic effects are not yet implemented. But they should be prior to v103. This one is a little tricky as it currently works on fully rendered scanlines. I need to roll the mosaic into the background renderers, and then for sprites, well ... see below. The trickiest part by far of this new renderer is the object (sprite) system. Unlike every other system I emulate, the GBA supports affine rendering of its sprites. Or in other words, rotation effects. And it also has a very complex priority system. Right now, I can't see any way that the GBA PPU could render pixels in real-time like this. My belief is that there's a 240-entry buffer that fills up the next scanline's row of pixels. Which means it probably also runs on the last scanline of Vblank so that the first scanline has sprite data. However, I didn't design my object renderer like this just yet. For now, it creates a buffer of all 240 pixels right away at the start of the scanline. I know\!\! That's technically scanline-based. But it's only for fetching object tiledata, and it's only temporary. What needs to happen is I need a way to run something like a "mini libco thread" inside of the main thread, so that the object renderer can run in parallel with the rest of the PPU, yet not be a hideous abomination of a state machine, yet also not be horrendously slow as a full libco thread would be. I'm envisioning some kind of stackless yielding coroutine. But I'll need to think through how to design that, given the absence of coroutines even in C++17.
2017-06-04 03:16:44 +00:00
return color;
Update to v087r21 release. byuu says: Timer speedup added. Boosts Mr. Driller 2 title from 170fps to 400fps. Other games still benefit, but not as amazingly. I don't dip below 160fps ever here. Reverted the memory speed to 2 for everything for now, to fix Castlevania slowdown. We obviously need to add the N/S stuff before we do that. Added linear BG and linear OBJ mosaic-Y. Did not add mosaic-X, or any mosaic to the affine/bitmap modes, because I'm not sure when to apply the compensation. Rewrote layer stuff. It now has two layers (above and below), and it performs the four blending modes as needed. Didn't add semi-transparent sprites because the docs are too confusing. Added a blur filter directly into the PPU for now. This obviously violates my interface, but F-Zero needed it for HUD display. We can remove it when we have an official release with a blur filter available. The filter still doesn't warp colors like a real GBA, because I don't know the formula.
2012-04-10 11:41:35 +00:00
}
Update to v102r19 release. byuu says: Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on Windows (ugh ...) Now to await posts about this in four more threads again ;) Changelog: - GBA: rewrote PPU from a scanline-based renderer to a pixel-based renderer - ruby: fixed video/gdi bugs Note that there's an approximately 21% speed penalty compared to v102r18 for the pixel-based renderer. Also, horizontal mosaic effects are not yet implemented. But they should be prior to v103. This one is a little tricky as it currently works on fully rendered scanlines. I need to roll the mosaic into the background renderers, and then for sprites, well ... see below. The trickiest part by far of this new renderer is the object (sprite) system. Unlike every other system I emulate, the GBA supports affine rendering of its sprites. Or in other words, rotation effects. And it also has a very complex priority system. Right now, I can't see any way that the GBA PPU could render pixels in real-time like this. My belief is that there's a 240-entry buffer that fills up the next scanline's row of pixels. Which means it probably also runs on the last scanline of Vblank so that the first scanline has sprite data. However, I didn't design my object renderer like this just yet. For now, it creates a buffer of all 240 pixels right away at the start of the scanline. I know\!\! That's technically scanline-based. But it's only for fetching object tiledata, and it's only temporary. What needs to happen is I need a way to run something like a "mini libco thread" inside of the main thread, so that the object renderer can run in parallel with the rest of the PPU, yet not be a hideous abomination of a state machine, yet also not be horrendously slow as a full libco thread would be. I'm envisioning some kind of stackless yielding coroutine. But I'll need to think through how to design that, given the absence of coroutines even in C++17.
2017-06-04 03:16:44 +00:00
auto PPU::Screen::blend(uint15 above, uint eva, uint15 below, uint evb) -> uint15 {
Update to v087r21 release. byuu says: Timer speedup added. Boosts Mr. Driller 2 title from 170fps to 400fps. Other games still benefit, but not as amazingly. I don't dip below 160fps ever here. Reverted the memory speed to 2 for everything for now, to fix Castlevania slowdown. We obviously need to add the N/S stuff before we do that. Added linear BG and linear OBJ mosaic-Y. Did not add mosaic-X, or any mosaic to the affine/bitmap modes, because I'm not sure when to apply the compensation. Rewrote layer stuff. It now has two layers (above and below), and it performs the four blending modes as needed. Didn't add semi-transparent sprites because the docs are too confusing. Added a blur filter directly into the PPU for now. This obviously violates my interface, but F-Zero needed it for HUD display. We can remove it when we have an official release with a blur filter available. The filter still doesn't warp colors like a real GBA, because I don't know the formula.
2012-04-10 11:41:35 +00:00
uint5 ar = above >> 0, ag = above >> 5, ab = above >> 10;
Update to v087r22 release. byuu says: Changelog: - fixed below pixel green channel on color blending - added semi-transparent objects [Exophase's method] - added full support for windows (both inputs, OBJ windows, and output, with optional color effect disable) - EEPROM uses nall::bitarray now to be friendlier to saving memory to disk - removed incomplete mosaic support for now (too broken, untested) - improved sprite priority. Hopefully it's right now. Just about everything should look great now. It took 25 days, but we finally have the BIOS rendering correctly. In order to do OBJ windows, I had to drop my above/below buffers entirely. I went with the nuclear option. There's separate layers for all BGs and objects. I build the OBJ window table during object rendering. So as a result, after rendering I go back and apply windows (and the object window that now exists.) After that, I have to do a painful Z-buffer select of the top two most important pixels. Since I now know the layers, the blending enable tests are a lot nicer, at least. But this obviously has quite a speed hit: 390fps to 325fps for Mr. Driller 2 title screen. TONC says that "bad" window coordinates do really insane things. GBAtek says it's a simple y2 < y1 || y2 > 160 ? 160 : y2; x2 < x1 || x2 > 240 ? 240 : x2; I like the GBAtek version more, so I went with that. I sure hope it's right ... but my guess is the hardware does this with a counter that wraps around or something. Also, say you have two OBJ mode 2 sprites that overlap each other, but with different priorities. The lower (more important) priority sprite has a clear pixel, but the higher priority sprite has a set pixel. Do we set the "inside OBJ window" flag to true here? Eg does the value OR, or does it hold the most important sprite's pixel value? Cydrak suspects it's OR-based, I concur from what I can see. Mosaic, I am at a loss. I really need a lot more information in order to implement it. For backgrounds, does it apply to the Vcounter of the entire screen? Or does it apply post-scroll? Or does it even apply after every adjust in affine/bitmap modes? I'm betting the hcounter background mosaic starts at the leftmost edge of the screen, and repeats previous pixels to apply the effect. Like SNES, very simple. For sprites, the SNES didn't have this. Does the mosaic grid start at (0,0) of the screen, or at (0,0) of each sprite? The latter will look a lot nicer, but be a lot more complex. Is mosaic on affine objects any different than mosaic of linear(tiled) objects? With that out of the way, we still have to fix the CPU memory access timing, add the rest of the CPU penalty cycles, the memory rotation / alignment / extend behavior needs to be fixed, the shifter desperately needs to be moved from loops to single shift operations, and I need to add flash memory support.
2012-04-13 11:49:32 +00:00
uint5 br = below >> 0, bg = below >> 5, bb = below >> 10;
Update to v087r21 release. byuu says: Timer speedup added. Boosts Mr. Driller 2 title from 170fps to 400fps. Other games still benefit, but not as amazingly. I don't dip below 160fps ever here. Reverted the memory speed to 2 for everything for now, to fix Castlevania slowdown. We obviously need to add the N/S stuff before we do that. Added linear BG and linear OBJ mosaic-Y. Did not add mosaic-X, or any mosaic to the affine/bitmap modes, because I'm not sure when to apply the compensation. Rewrote layer stuff. It now has two layers (above and below), and it performs the four blending modes as needed. Didn't add semi-transparent sprites because the docs are too confusing. Added a blur filter directly into the PPU for now. This obviously violates my interface, but F-Zero needed it for HUD display. We can remove it when we have an official release with a blur filter available. The filter still doesn't warp colors like a real GBA, because I don't know the formula.
2012-04-10 11:41:35 +00:00
Update to v095r07 release. byuu says: Changelog: - entire GBA core ported to auto function() -> return; syntax - fixed GBA BLDY bug that was causing flickering in a few games - replaced nall/config usage with nall/string/markup/node - this merges all configuration files to a unified settings.bml file - added "Ignore Manifests" option to the advanced setting tab - this lets you keep a manifest.bml for an older version of higan; if you want to do regression testing Be sure to remap your controller/hotkey inputs, and for SNES, choose "Gamepad" from "Controller Port 1" in the system menu. Otherwise you won't get any input. No need to blow away your old config files, unless you want to.
2015-11-16 08:38:05 +00:00
uint r = (ar * eva + br * evb) >> 4;
uint g = (ag * eva + bg * evb) >> 4;
uint b = (ab * eva + bb * evb) >> 4;
Update to v087r21 release. byuu says: Timer speedup added. Boosts Mr. Driller 2 title from 170fps to 400fps. Other games still benefit, but not as amazingly. I don't dip below 160fps ever here. Reverted the memory speed to 2 for everything for now, to fix Castlevania slowdown. We obviously need to add the N/S stuff before we do that. Added linear BG and linear OBJ mosaic-Y. Did not add mosaic-X, or any mosaic to the affine/bitmap modes, because I'm not sure when to apply the compensation. Rewrote layer stuff. It now has two layers (above and below), and it performs the four blending modes as needed. Didn't add semi-transparent sprites because the docs are too confusing. Added a blur filter directly into the PPU for now. This obviously violates my interface, but F-Zero needed it for HUD display. We can remove it when we have an official release with a blur filter available. The filter still doesn't warp colors like a real GBA, because I don't know the formula.
2012-04-10 11:41:35 +00:00
Update to v102r19 release. byuu says: Note: add `#undef OUT` to the top of higan/gba/ppu/ppu.hpp to compile on Windows (ugh ...) Now to await posts about this in four more threads again ;) Changelog: - GBA: rewrote PPU from a scanline-based renderer to a pixel-based renderer - ruby: fixed video/gdi bugs Note that there's an approximately 21% speed penalty compared to v102r18 for the pixel-based renderer. Also, horizontal mosaic effects are not yet implemented. But they should be prior to v103. This one is a little tricky as it currently works on fully rendered scanlines. I need to roll the mosaic into the background renderers, and then for sprites, well ... see below. The trickiest part by far of this new renderer is the object (sprite) system. Unlike every other system I emulate, the GBA supports affine rendering of its sprites. Or in other words, rotation effects. And it also has a very complex priority system. Right now, I can't see any way that the GBA PPU could render pixels in real-time like this. My belief is that there's a 240-entry buffer that fills up the next scanline's row of pixels. Which means it probably also runs on the last scanline of Vblank so that the first scanline has sprite data. However, I didn't design my object renderer like this just yet. For now, it creates a buffer of all 240 pixels right away at the start of the scanline. I know\!\! That's technically scanline-based. But it's only for fetching object tiledata, and it's only temporary. What needs to happen is I need a way to run something like a "mini libco thread" inside of the main thread, so that the object renderer can run in parallel with the rest of the PPU, yet not be a hideous abomination of a state machine, yet also not be horrendously slow as a full libco thread would be. I'm envisioning some kind of stackless yielding coroutine. But I'll need to think through how to design that, given the absence of coroutines even in C++17.
2017-06-04 03:16:44 +00:00
return min(31u, r) << 0 | min(31u, g) << 5 | min(31u, b) << 10;
}
auto PPU::Screen::power() -> void {
Update to v106r30 release. byuu says: Changelog: - nall/GNUmakefile: fixed findstring parameter arguments [Screwtape] - nall/Windows: always include -mthreads -lpthread for all applications - nall/memory: code restructuring I really wanted to work on the new PPU today, but I thought I'd spend a few minutes making some minor improvements to nall::memory, that was five and a half hours ago. Now I have a 67KiB diff of changes. Sigh.
2018-05-28 01:16:27 +00:00
io = {};
Update to v087r21 release. byuu says: Timer speedup added. Boosts Mr. Driller 2 title from 170fps to 400fps. Other games still benefit, but not as amazingly. I don't dip below 160fps ever here. Reverted the memory speed to 2 for everything for now, to fix Castlevania slowdown. We obviously need to add the N/S stuff before we do that. Added linear BG and linear OBJ mosaic-Y. Did not add mosaic-X, or any mosaic to the affine/bitmap modes, because I'm not sure when to apply the compensation. Rewrote layer stuff. It now has two layers (above and below), and it performs the four blending modes as needed. Didn't add semi-transparent sprites because the docs are too confusing. Added a blur filter directly into the PPU for now. This obviously violates my interface, but F-Zero needed it for HUD display. We can remove it when we have an official release with a blur filter available. The filter still doesn't warp colors like a real GBA, because I don't know the formula.
2012-04-10 11:41:35 +00:00
}