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/window.cpp

17 lines
350 B
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::Window::run(uint x, uint y) -> void {
auto x1 = io.x1, x2 = io.x2;
auto y1 = io.y1, y2 = io.y2;
if(x2 < x1 || x2 > 240) x2 = 240;
if(y2 < y1 || y2 > 160) y2 = 160;
output = (x >= x1 && x < x2 && y >= y1 && y < y2);
}
auto PPU::Window::power(uint id) -> void {
this->id = id;
memory::fill(&io, sizeof(IO));
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
output = 0;
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
}