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

288 lines
8.1 KiB
C++
Raw Normal View History

First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
#ifdef PPU_CPP
#include "mode7.cpp"
Update to v088r16 release. byuu says: Changelog: - fixed BGnxOFS to not cache when MOSAIC is not in effect [fixes Air Strike Patrol "Good Luck" text] - added GameBoy::Interface::Hook for SGB bindings [SGB works again] - do not create bsnes/ folder unless it is absolutely needed (eg you create a save state or state manager archive) - SuperFX works [needed to call system.init() in Interface::Interface()] Last chance for any bug reports, at this point I pretty much consider ethos to be finished. It's shipping without BS-X BIOS game loading support. Sorry, I can't figure that one out.
2012-05-09 23:35:29 +00:00
unsigned PPU::Background::voffset() const {
if(regs.mosaic) return cache.voffset;
return regs.voffset;
}
unsigned PPU::Background::hoffset() const {
if(regs.mosaic) return cache.hoffset;
return regs.hoffset;
}
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
//V = 0, H = 0
Update to v068r02 release. byuu says: This adds mosaic improvements to the S-PPU dot renderer. Specifically, it eliminates the mosaic_table entirely, and performs mosaic adjustment per pixel instead. It also moves from a mosaic countdown for mosaic Y to a mosaic counter (incrementing). In the process, I realized Sim Earth's map was broken, so I fixed that. In doing so, I also fixed my old Mode7 demo that was always off-by-one, causing different results on real hardware versus emulation. But then I broke both Final Fantasy 5 and Air Strike Patrol effects that use Mode7 but no mosaic. I'm not really sure what's going on, but I think I am close. This is the first time I can reproduce the Mode7 test ROM results without screwing with M7Y which was obviously wrong. I think that somehow a mosaic >= 1 is glitching the Ycounter for the BG layers to tick one extra time. There's a workaround that's not very nice to get everything going right now. It could very well be that the workaround is hardware accurate, but I can't help but feel there's a more eloquent way of doing this.
2010-08-28 09:47:06 +00:00
void PPU::Background::frame() {
}
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
//H = 0
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
void PPU::Background::scanline() {
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
}
Update to v088r16 release. byuu says: Changelog: - fixed BGnxOFS to not cache when MOSAIC is not in effect [fixes Air Strike Patrol "Good Luck" text] - added GameBoy::Interface::Hook for SGB bindings [SGB works again] - do not create bsnes/ folder unless it is absolutely needed (eg you create a save state or state manager archive) - SuperFX works [needed to call system.init() in Interface::Interface()] Last chance for any bug reports, at this point I pretty much consider ethos to be finished. It's shipping without BS-X BIOS game loading support. Sorry, I can't figure that one out.
2012-05-09 23:35:29 +00:00
//H = 28
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
void PPU::Background::begin() {
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 hires = (self.regs.bgmode == 5 || self.regs.bgmode == 6);
Update to v068r14 release. byuu says: Holy hell, that was a total brain twister. After hours of crazy bit twiddling and debug printf's, I finally figured out how to allow both lores and hires scrolling in the accurate PPU renderer. In the process, I modified the main loop to run from -7 to 255, regardless of the hires setting, and perform X adjustment inside the tile fetching. This fixed a strange main/subscreen misalignment issue, so I was able to restore the proper sub-then-main rendering for the final screen output stage. Code looks a good bit cleaner this way overall. I also added load state and save state menus to the tools menu, so you can use the menubar to load and save to ten slots. I am thinking that I should nuke the icons. As pretty as they are, it's getting tiresome trying to find icons for everything, I have no pictures to represent loading or saving a slot, nor to represent individual slots. I'll just stick to radios and checkboxes.
2010-09-05 23:08:03 +00:00
x = -7;
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
y = self.vcounter();
Update to v078r07 release. byuu says: Would appreciate testing on any games with mosaic, especially Mode7 mosaic.I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program. This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging. I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run(). I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now. Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-06-05 03:25:24 +00:00
if(y == 1) {
mosaic.vcounter = regs.mosaic + 1;
mosaic.voffset = 1;
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
cache.hoffset = regs.hoffset;
cache.voffset = regs.voffset;
Update to v078r07 release. byuu says: Would appreciate testing on any games with mosaic, especially Mode7 mosaic.I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program. This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging. I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run(). I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now. Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-06-05 03:25:24 +00:00
} else if(--mosaic.vcounter == 0) {
mosaic.vcounter = regs.mosaic + 1;
mosaic.voffset += regs.mosaic + 1;
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
cache.hoffset = regs.hoffset;
cache.voffset = regs.voffset;
Update to v068r02 release. byuu says: This adds mosaic improvements to the S-PPU dot renderer. Specifically, it eliminates the mosaic_table entirely, and performs mosaic adjustment per pixel instead. It also moves from a mosaic countdown for mosaic Y to a mosaic counter (incrementing). In the process, I realized Sim Earth's map was broken, so I fixed that. In doing so, I also fixed my old Mode7 demo that was always off-by-one, causing different results on real hardware versus emulation. But then I broke both Final Fantasy 5 and Air Strike Patrol effects that use Mode7 but no mosaic. I'm not really sure what's going on, but I think I am close. This is the first time I can reproduce the Mode7 test ROM results without screwing with M7Y which was obviously wrong. I think that somehow a mosaic >= 1 is glitching the Ycounter for the BG layers to tick one extra time. There's a workaround that's not very nice to get everything going right now. It could very well be that the workaround is hardware accurate, but I can't help but feel there's a more eloquent way of doing this.
2010-08-28 09:47:06 +00:00
}
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
tile_counter = (7 - (cache.hoffset & 7)) << hires;
Update to v078r07 release. byuu says: Would appreciate testing on any games with mosaic, especially Mode7 mosaic.I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program. This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging. I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run(). I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now. Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-06-05 03:25:24 +00:00
for(unsigned n = 0; n < 8; n++) data[n] = 0;
mosaic.hcounter = regs.mosaic + 1;
mosaic.hoffset = 0;
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
if(regs.mode == Mode::Mode7) return begin_mode7();
if(regs.mosaic == 0) {
cache.hoffset = regs.hoffset;
cache.voffset = regs.voffset;
}
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
}
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
void PPU::Background::get_tile() {
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
bool hires = (self.regs.bgmode == 5 || self.regs.bgmode == 6);
unsigned color_depth = (regs.mode == Mode::BPP2 ? 0 : regs.mode == Mode::BPP4 ? 1 : 2);
Update to v078r07 release. byuu says: Would appreciate testing on any games with mosaic, especially Mode7 mosaic.I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program. This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging. I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run(). I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now. Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-06-05 03:25:24 +00:00
unsigned palette_offset = (self.regs.bgmode == 0 ? id << 5 : 0);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
unsigned palette_size = 2 << color_depth;
unsigned tile_mask = 0x0fff >> color_depth;
unsigned tiledata_index = regs.tiledata_addr >> (4 + color_depth);
unsigned tile_height = (regs.tile_size == TileSize::Size8x8 ? 3 : 4);
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
unsigned tile_width = (!hires ? tile_height : 4);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v068r14 release. byuu says: Holy hell, that was a total brain twister. After hours of crazy bit twiddling and debug printf's, I finally figured out how to allow both lores and hires scrolling in the accurate PPU renderer. In the process, I modified the main loop to run from -7 to 255, regardless of the hires setting, and perform X adjustment inside the tile fetching. This fixed a strange main/subscreen misalignment issue, so I was able to restore the proper sub-then-main rendering for the final screen output stage. Code looks a good bit cleaner this way overall. I also added load state and save state menus to the tools menu, so you can use the menubar to load and save to ten slots. I am thinking that I should nuke the icons. As pretty as they are, it's getting tiresome trying to find icons for everything, I have no pictures to represent loading or saving a slot, nor to represent individual slots. I'll just stick to radios and checkboxes.
2010-09-05 23:08:03 +00:00
unsigned width = 256 << hires;
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
Update to v078r07 release. byuu says: Would appreciate testing on any games with mosaic, especially Mode7 mosaic.I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program. This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging. I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run(). I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now. Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-06-05 03:25:24 +00:00
unsigned hmask = (tile_height == 3 ? width : width << 1);
unsigned vmask = hmask;
if(regs.screen_size & 1) hmask <<= 1;
if(regs.screen_size & 2) vmask <<= 1;
hmask--;
vmask--;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v068r14 release. byuu says: Holy hell, that was a total brain twister. After hours of crazy bit twiddling and debug printf's, I finally figured out how to allow both lores and hires scrolling in the accurate PPU renderer. In the process, I modified the main loop to run from -7 to 255, regardless of the hires setting, and perform X adjustment inside the tile fetching. This fixed a strange main/subscreen misalignment issue, so I was able to restore the proper sub-then-main rendering for the final screen output stage. Code looks a good bit cleaner this way overall. I also added load state and save state menus to the tools menu, so you can use the menubar to load and save to ten slots. I am thinking that I should nuke the icons. As pretty as they are, it's getting tiresome trying to find icons for everything, I have no pictures to represent loading or saving a slot, nor to represent individual slots. I'll just stick to radios and checkboxes.
2010-09-05 23:08:03 +00:00
unsigned px = x << hires;
Update to v078r07 release. byuu says: Would appreciate testing on any games with mosaic, especially Mode7 mosaic.I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program. This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging. I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run(). I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now. Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-06-05 03:25:24 +00:00
unsigned py = (regs.mosaic == 0 ? y : mosaic.voffset);
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
Update to v088r16 release. byuu says: Changelog: - fixed BGnxOFS to not cache when MOSAIC is not in effect [fixes Air Strike Patrol "Good Luck" text] - added GameBoy::Interface::Hook for SGB bindings [SGB works again] - do not create bsnes/ folder unless it is absolutely needed (eg you create a save state or state manager archive) - SuperFX works [needed to call system.init() in Interface::Interface()] Last chance for any bug reports, at this point I pretty much consider ethos to be finished. It's shipping without BS-X BIOS game loading support. Sorry, I can't figure that one out.
2012-05-09 23:35:29 +00:00
unsigned hscroll = hoffset();
unsigned vscroll = voffset();
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
if(hires) {
hscroll <<= 1;
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
if(self.regs.interlace) py = (py << 1) + self.field();
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
}
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
unsigned hoffset = hscroll + px;
unsigned voffset = vscroll + py;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
if(self.regs.bgmode == 2 || self.regs.bgmode == 4 || self.regs.bgmode == 6) {
Update to v068r14 release. byuu says: Holy hell, that was a total brain twister. After hours of crazy bit twiddling and debug printf's, I finally figured out how to allow both lores and hires scrolling in the accurate PPU renderer. In the process, I modified the main loop to run from -7 to 255, regardless of the hires setting, and perform X adjustment inside the tile fetching. This fixed a strange main/subscreen misalignment issue, so I was able to restore the proper sub-then-main rendering for the final screen output stage. Code looks a good bit cleaner this way overall. I also added load state and save state menus to the tools menu, so you can use the menubar to load and save to ten slots. I am thinking that I should nuke the icons. As pretty as they are, it's getting tiresome trying to find icons for everything, I have no pictures to represent loading or saving a slot, nor to represent individual slots. I'll just stick to radios and checkboxes.
2010-09-05 23:08:03 +00:00
uint16 offset_x = (x + (hscroll & 7));
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v068r14 release. byuu says: Holy hell, that was a total brain twister. After hours of crazy bit twiddling and debug printf's, I finally figured out how to allow both lores and hires scrolling in the accurate PPU renderer. In the process, I modified the main loop to run from -7 to 255, regardless of the hires setting, and perform X adjustment inside the tile fetching. This fixed a strange main/subscreen misalignment issue, so I was able to restore the proper sub-then-main rendering for the final screen output stage. Code looks a good bit cleaner this way overall. I also added load state and save state menus to the tools menu, so you can use the menubar to load and save to ten slots. I am thinking that I should nuke the icons. As pretty as they are, it's getting tiresome trying to find icons for everything, I have no pictures to represent loading or saving a slot, nor to represent individual slots. I'll just stick to radios and checkboxes.
2010-09-05 23:08:03 +00:00
if(offset_x >= 8) {
Update to v088r16 release. byuu says: Changelog: - fixed BGnxOFS to not cache when MOSAIC is not in effect [fixes Air Strike Patrol "Good Luck" text] - added GameBoy::Interface::Hook for SGB bindings [SGB works again] - do not create bsnes/ folder unless it is absolutely needed (eg you create a save state or state manager archive) - SuperFX works [needed to call system.init() in Interface::Interface()] Last chance for any bug reports, at this point I pretty much consider ethos to be finished. It's shipping without BS-X BIOS game loading support. Sorry, I can't figure that one out.
2012-05-09 23:35:29 +00:00
unsigned hval = self.bg3.get_tile((offset_x - 8) + (self.bg3.hoffset() & ~7), self.bg3.voffset() + 0);
unsigned vval = self.bg3.get_tile((offset_x - 8) + (self.bg3.hoffset() & ~7), self.bg3.voffset() + 8);
Update to v068r14 release. byuu says: Holy hell, that was a total brain twister. After hours of crazy bit twiddling and debug printf's, I finally figured out how to allow both lores and hires scrolling in the accurate PPU renderer. In the process, I modified the main loop to run from -7 to 255, regardless of the hires setting, and perform X adjustment inside the tile fetching. This fixed a strange main/subscreen misalignment issue, so I was able to restore the proper sub-then-main rendering for the final screen output stage. Code looks a good bit cleaner this way overall. I also added load state and save state menus to the tools menu, so you can use the menubar to load and save to ten slots. I am thinking that I should nuke the icons. As pretty as they are, it's getting tiresome trying to find icons for everything, I have no pictures to represent loading or saving a slot, nor to represent individual slots. I'll just stick to radios and checkboxes.
2010-09-05 23:08:03 +00:00
unsigned valid_mask = (id == ID::BG1 ? 0x2000 : 0x4000);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
if(self.regs.bgmode == 4) {
Update to v068r14 release. byuu says: Holy hell, that was a total brain twister. After hours of crazy bit twiddling and debug printf's, I finally figured out how to allow both lores and hires scrolling in the accurate PPU renderer. In the process, I modified the main loop to run from -7 to 255, regardless of the hires setting, and perform X adjustment inside the tile fetching. This fixed a strange main/subscreen misalignment issue, so I was able to restore the proper sub-then-main rendering for the final screen output stage. Code looks a good bit cleaner this way overall. I also added load state and save state menus to the tools menu, so you can use the menubar to load and save to ten slots. I am thinking that I should nuke the icons. As pretty as they are, it's getting tiresome trying to find icons for everything, I have no pictures to represent loading or saving a slot, nor to represent individual slots. I'll just stick to radios and checkboxes.
2010-09-05 23:08:03 +00:00
if(hval & valid_mask) {
if((hval & 0x8000) == 0) {
hoffset = offset_x + (hval & ~7);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
} else {
voffset = y + hval;
}
}
} else {
Update to v068r14 release. byuu says: Holy hell, that was a total brain twister. After hours of crazy bit twiddling and debug printf's, I finally figured out how to allow both lores and hires scrolling in the accurate PPU renderer. In the process, I modified the main loop to run from -7 to 255, regardless of the hires setting, and perform X adjustment inside the tile fetching. This fixed a strange main/subscreen misalignment issue, so I was able to restore the proper sub-then-main rendering for the final screen output stage. Code looks a good bit cleaner this way overall. I also added load state and save state menus to the tools menu, so you can use the menubar to load and save to ten slots. I am thinking that I should nuke the icons. As pretty as they are, it's getting tiresome trying to find icons for everything, I have no pictures to represent loading or saving a slot, nor to represent individual slots. I'll just stick to radios and checkboxes.
2010-09-05 23:08:03 +00:00
if(hval & valid_mask) hoffset = offset_x + (hval & ~7);
if(vval & valid_mask) voffset = y + vval;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
}
}
}
Update to v078r07 release. byuu says: Would appreciate testing on any games with mosaic, especially Mode7 mosaic.I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program. This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging. I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run(). I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now. Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-06-05 03:25:24 +00:00
hoffset &= hmask;
voffset &= vmask;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v068r14 release. byuu says: Holy hell, that was a total brain twister. After hours of crazy bit twiddling and debug printf's, I finally figured out how to allow both lores and hires scrolling in the accurate PPU renderer. In the process, I modified the main loop to run from -7 to 255, regardless of the hires setting, and perform X adjustment inside the tile fetching. This fixed a strange main/subscreen misalignment issue, so I was able to restore the proper sub-then-main rendering for the final screen output stage. Code looks a good bit cleaner this way overall. I also added load state and save state menus to the tools menu, so you can use the menubar to load and save to ten slots. I am thinking that I should nuke the icons. As pretty as they are, it's getting tiresome trying to find icons for everything, I have no pictures to represent loading or saving a slot, nor to represent individual slots. I'll just stick to radios and checkboxes.
2010-09-05 23:08:03 +00:00
unsigned screen_x = (regs.screen_size & 1 ? 32 << 5 : 0);
unsigned screen_y = (regs.screen_size & 2 ? 32 << 5 : 0);
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
if(regs.screen_size == 3) screen_y <<= 1;
unsigned tx = hoffset >> tile_width;
unsigned ty = voffset >> tile_height;
uint16 offset = ((ty & 0x1f) << 5) + (tx & 0x1f);
if(tx & 0x20) offset += screen_x;
if(ty & 0x20) offset += screen_y;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
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
uint16 addr = regs.screen_addr + (offset << 1);
Update to v074r11 release. byuu says: Changelog: - debugger compiles on all three profiles - libsnes compiles on all three platforms (no API changes to libsnes) - memory.cpp : namespace memory removed (wram -> cpu, apuram -> smp, vram, oam, cgram -> ppu) - sa1.cpp : namespace memory removed (SA-1 specific functions merged inline to SA1::bus_read,write) - GameBoy: added serial link support with interrupts and proper 8192hz timing, but obviously it acts as if no other GB is connected to it - GameBoy: added STAT OAM interrupt, and better STAT d1,d0 mode values - UI: since Qt is dead, I've renamed the config files back to bsnes.cfg and bsnes-geometry.cfg - SA1: IRAM was not syncing to CPU on SA-1 side - PPU/Accuracy and PPU/Performance needed Sprite oam renamed to Sprite sprite; so that I could add uint8 oam[544] - makes more sense anyway, OAM = object attribute memory, obj or sprite are better names for Sprite rendering class - more cleanup
2011-01-24 09:03:17 +00:00
tile = (ppu.vram[addr + 0] << 0) + (ppu.vram[addr + 1] << 8);
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 mirror_y = tile & 0x8000;
bool mirror_x = tile & 0x4000;
priority = (tile & 0x2000 ? regs.priority1 : regs.priority0);
palette_number = (tile >> 10) & 7;
palette_index = palette_offset + (palette_number << palette_size);
if(tile_width == 4 && (bool)(hoffset & 8) != mirror_x) tile += 1;
if(tile_height == 4 && (bool)(voffset & 8) != mirror_y) tile += 16;
uint16 character = ((tile & 0x03ff) + tiledata_index) & tile_mask;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
if(mirror_y) voffset ^= 7;
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
offset = (character << (4 + color_depth)) + ((voffset & 7) << 1);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v086r03 release. byuu says: Cart unload save path was using the new game rather than the old game. Caused by trying to allow a failed cartridge load to not unload the current game. But that's so uncommon that it's not worth worrying about. It'll always unload before trying to load a new game now. Removed the TM/TS disable speedup, to fix Madara 2's text boxes. This actually did cause a slight performance penalty on games that disable layers via TM/TS. Zelda 3 inside Link's house is a good example. It knocked the FPS from 98.5 to 94.5. So to counter that, I removed conditionals from tiledata loading and decoding, and used fall through switches. This boosted us back to 97.0. The -march=native flag apparently works better with SB now, so that was added, putting us up to 99.0fps. So it should be the same speed in the worst case, and slightly faster in the best case. Bumped the pre-render time to 68 clocks from 60 clocks. Adjusted sprite tile fetch time from 22 to 14 to compensate. This should give us perfectly stable Dai Kaijuu Monogatari 2 battles.
2012-02-18 07:49:52 +00:00
switch(regs.mode) {
case Mode::BPP8:
Update to v074r11 release. byuu says: Changelog: - debugger compiles on all three profiles - libsnes compiles on all three platforms (no API changes to libsnes) - memory.cpp : namespace memory removed (wram -> cpu, apuram -> smp, vram, oam, cgram -> ppu) - sa1.cpp : namespace memory removed (SA-1 specific functions merged inline to SA1::bus_read,write) - GameBoy: added serial link support with interrupts and proper 8192hz timing, but obviously it acts as if no other GB is connected to it - GameBoy: added STAT OAM interrupt, and better STAT d1,d0 mode values - UI: since Qt is dead, I've renamed the config files back to bsnes.cfg and bsnes-geometry.cfg - SA1: IRAM was not syncing to CPU on SA-1 side - PPU/Accuracy and PPU/Performance needed Sprite oam renamed to Sprite sprite; so that I could add uint8 oam[544] - makes more sense anyway, OAM = object attribute memory, obj or sprite are better names for Sprite rendering class - more cleanup
2011-01-24 09:03:17 +00:00
data[7] = ppu.vram[offset + 49];
Update to v086r03 release. byuu says: Cart unload save path was using the new game rather than the old game. Caused by trying to allow a failed cartridge load to not unload the current game. But that's so uncommon that it's not worth worrying about. It'll always unload before trying to load a new game now. Removed the TM/TS disable speedup, to fix Madara 2's text boxes. This actually did cause a slight performance penalty on games that disable layers via TM/TS. Zelda 3 inside Link's house is a good example. It knocked the FPS from 98.5 to 94.5. So to counter that, I removed conditionals from tiledata loading and decoding, and used fall through switches. This boosted us back to 97.0. The -march=native flag apparently works better with SB now, so that was added, putting us up to 99.0fps. So it should be the same speed in the worst case, and slightly faster in the best case. Bumped the pre-render time to 68 clocks from 60 clocks. Adjusted sprite tile fetch time from 22 to 14 to compensate. This should give us perfectly stable Dai Kaijuu Monogatari 2 battles.
2012-02-18 07:49:52 +00:00
data[6] = ppu.vram[offset + 48];
data[5] = ppu.vram[offset + 33];
data[4] = ppu.vram[offset + 32];
case Mode::BPP4:
data[3] = ppu.vram[offset + 17];
data[2] = ppu.vram[offset + 16];
case Mode::BPP2:
data[1] = ppu.vram[offset + 1];
data[0] = ppu.vram[offset + 0];
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
}
if(mirror_x) for(unsigned n = 0; n < 8; n++) {
Update to v068r14 release. byuu says: Holy hell, that was a total brain twister. After hours of crazy bit twiddling and debug printf's, I finally figured out how to allow both lores and hires scrolling in the accurate PPU renderer. In the process, I modified the main loop to run from -7 to 255, regardless of the hires setting, and perform X adjustment inside the tile fetching. This fixed a strange main/subscreen misalignment issue, so I was able to restore the proper sub-then-main rendering for the final screen output stage. Code looks a good bit cleaner this way overall. I also added load state and save state menus to the tools menu, so you can use the menubar to load and save to ten slots. I am thinking that I should nuke the icons. As pretty as they are, it's getting tiresome trying to find icons for everything, I have no pictures to represent loading or saving a slot, nor to represent individual slots. I'll just stick to radios and checkboxes.
2010-09-05 23:08:03 +00:00
//reverse data bits in data[n]: 01234567 -> 76543210
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
data[n] = ((data[n] >> 4) & 0x0f) | ((data[n] << 4) & 0xf0);
data[n] = ((data[n] >> 2) & 0x33) | ((data[n] << 2) & 0xcc);
data[n] = ((data[n] >> 1) & 0x55) | ((data[n] << 1) & 0xaa);
}
}
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v068r14 release. byuu says: Holy hell, that was a total brain twister. After hours of crazy bit twiddling and debug printf's, I finally figured out how to allow both lores and hires scrolling in the accurate PPU renderer. In the process, I modified the main loop to run from -7 to 255, regardless of the hires setting, and perform X adjustment inside the tile fetching. This fixed a strange main/subscreen misalignment issue, so I was able to restore the proper sub-then-main rendering for the final screen output stage. Code looks a good bit cleaner this way overall. I also added load state and save state menus to the tools menu, so you can use the menubar to load and save to ten slots. I am thinking that I should nuke the icons. As pretty as they are, it's getting tiresome trying to find icons for everything, I have no pictures to represent loading or saving a slot, nor to represent individual slots. I'll just stick to radios and checkboxes.
2010-09-05 23:08:03 +00:00
void PPU::Background::run(bool screen) {
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
if(self.vcounter() == 0) return;
bool hires = (self.regs.bgmode == 5 || self.regs.bgmode == 6);
Update to v068r14 release. byuu says: Holy hell, that was a total brain twister. After hours of crazy bit twiddling and debug printf's, I finally figured out how to allow both lores and hires scrolling in the accurate PPU renderer. In the process, I modified the main loop to run from -7 to 255, regardless of the hires setting, and perform X adjustment inside the tile fetching. This fixed a strange main/subscreen misalignment issue, so I was able to restore the proper sub-then-main rendering for the final screen output stage. Code looks a good bit cleaner this way overall. I also added load state and save state menus to the tools menu, so you can use the menubar to load and save to ten slots. I am thinking that I should nuke the icons. As pretty as they are, it's getting tiresome trying to find icons for everything, I have no pictures to represent loading or saving a slot, nor to represent individual slots. I'll just stick to radios and checkboxes.
2010-09-05 23:08:03 +00:00
if(screen == Screen::Sub) {
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
output.main.priority = 0;
output.sub.priority = 0;
Update to v068r14 release. byuu says: Holy hell, that was a total brain twister. After hours of crazy bit twiddling and debug printf's, I finally figured out how to allow both lores and hires scrolling in the accurate PPU renderer. In the process, I modified the main loop to run from -7 to 255, regardless of the hires setting, and perform X adjustment inside the tile fetching. This fixed a strange main/subscreen misalignment issue, so I was able to restore the proper sub-then-main rendering for the final screen output stage. Code looks a good bit cleaner this way overall. I also added load state and save state menus to the tools menu, so you can use the menubar to load and save to ten slots. I am thinking that I should nuke the icons. As pretty as they are, it's getting tiresome trying to find icons for everything, I have no pictures to represent loading or saving a slot, nor to represent individual slots. I'll just stick to radios and checkboxes.
2010-09-05 23:08:03 +00:00
if(hires == false) return;
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
}
Update to v078r07 release. byuu says: Would appreciate testing on any games with mosaic, especially Mode7 mosaic.I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program. This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging. I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run(). I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now. Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-06-05 03:25:24 +00:00
if(regs.mode == Mode::Inactive) return;
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
if(regs.mode == Mode::Mode7) return run_mode7();
Update to v068r14 release. byuu says: Holy hell, that was a total brain twister. After hours of crazy bit twiddling and debug printf's, I finally figured out how to allow both lores and hires scrolling in the accurate PPU renderer. In the process, I modified the main loop to run from -7 to 255, regardless of the hires setting, and perform X adjustment inside the tile fetching. This fixed a strange main/subscreen misalignment issue, so I was able to restore the proper sub-then-main rendering for the final screen output stage. Code looks a good bit cleaner this way overall. I also added load state and save state menus to the tools menu, so you can use the menubar to load and save to ten slots. I am thinking that I should nuke the icons. As pretty as they are, it's getting tiresome trying to find icons for everything, I have no pictures to represent loading or saving a slot, nor to represent individual slots. I'll just stick to radios and checkboxes.
2010-09-05 23:08:03 +00:00
if(tile_counter-- == 0) {
tile_counter = 7;
get_tile();
}
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
uint8 palette = get_tile_color();
Update to v078r07 release. byuu says: Would appreciate testing on any games with mosaic, especially Mode7 mosaic.I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program. This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging. I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run(). I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now. Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-06-05 03:25:24 +00:00
if(x == 0) mosaic.hcounter = 1;
if(x >= 0 && --mosaic.hcounter == 0) {
mosaic.hcounter = regs.mosaic + 1;
mosaic.priority = priority;
mosaic.palette = palette ? palette_index + palette : 0;
mosaic.tile = tile;
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
}
Update to v068r17 release. byuu says: This hopefully fixes vertical and horizontal mosaic with the accurate S-PPU core. It also adds frame-skipping support to the compatibility and performance S-PPU cores. This is not visible to the user interface, because I feel that virtually nobody is going to play with frame-skipping on when they could use a faster emulation with it off. However, I did use it to enhance the 'Fast Forward' key. When you press it, it will now turn off video and audio sync, and set a frameskip of 9. This allows you to speed things up an additional ~60% over your max theoretical speed without frameskipping. ~35% with the compatible core, because the PPU is less of a bottleneck for it. Slowdown was improved, it will turn on audio sync if it is off until you release the key to ensure you actually get 30fps. Eventually it'd probably be wise to set a cap on the fast forward speed, but I hardly think it's an issue on today's computers.
2010-09-09 06:34:54 +00:00
if(screen == Screen::Main) x++;
Update to v078r07 release. byuu says: Would appreciate testing on any games with mosaic, especially Mode7 mosaic.I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program. This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging. I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run(). I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now. Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-06-05 03:25:24 +00:00
if(mosaic.palette == 0) return;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v078r07 release. byuu says: Would appreciate testing on any games with mosaic, especially Mode7 mosaic.I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program. This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging. I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run(). I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now. Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-06-05 03:25:24 +00:00
if(hires == false || screen == Screen::Main) if(regs.main_enable) output.main = mosaic;
if(hires == false || screen == Screen::Sub ) if(regs.sub_enable ) output.sub = mosaic;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
}
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
unsigned PPU::Background::get_tile_color() {
unsigned color = 0;
Update to v086r03 release. byuu says: Cart unload save path was using the new game rather than the old game. Caused by trying to allow a failed cartridge load to not unload the current game. But that's so uncommon that it's not worth worrying about. It'll always unload before trying to load a new game now. Removed the TM/TS disable speedup, to fix Madara 2's text boxes. This actually did cause a slight performance penalty on games that disable layers via TM/TS. Zelda 3 inside Link's house is a good example. It knocked the FPS from 98.5 to 94.5. So to counter that, I removed conditionals from tiledata loading and decoding, and used fall through switches. This boosted us back to 97.0. The -march=native flag apparently works better with SB now, so that was added, putting us up to 99.0fps. So it should be the same speed in the worst case, and slightly faster in the best case. Bumped the pre-render time to 68 clocks from 60 clocks. Adjusted sprite tile fetch time from 22 to 14 to compensate. This should give us perfectly stable Dai Kaijuu Monogatari 2 battles.
2012-02-18 07:49:52 +00:00
switch(regs.mode) {
case Mode::BPP8:
color += (data[7] >> 0) & 0x80; data[7] <<= 1;
color += (data[6] >> 1) & 0x40; data[6] <<= 1;
color += (data[5] >> 2) & 0x20; data[5] <<= 1;
color += (data[4] >> 3) & 0x10; data[4] <<= 1;
case Mode::BPP4:
color += (data[3] >> 4) & 0x08; data[3] <<= 1;
color += (data[2] >> 5) & 0x04; data[2] <<= 1;
case Mode::BPP2:
color += (data[1] >> 6) & 0x02; data[1] <<= 1;
color += (data[0] >> 7) & 0x01; data[0] <<= 1;
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
}
Update to v086r03 release. byuu says: Cart unload save path was using the new game rather than the old game. Caused by trying to allow a failed cartridge load to not unload the current game. But that's so uncommon that it's not worth worrying about. It'll always unload before trying to load a new game now. Removed the TM/TS disable speedup, to fix Madara 2's text boxes. This actually did cause a slight performance penalty on games that disable layers via TM/TS. Zelda 3 inside Link's house is a good example. It knocked the FPS from 98.5 to 94.5. So to counter that, I removed conditionals from tiledata loading and decoding, and used fall through switches. This boosted us back to 97.0. The -march=native flag apparently works better with SB now, so that was added, putting us up to 99.0fps. So it should be the same speed in the worst case, and slightly faster in the best case. Bumped the pre-render time to 68 clocks from 60 clocks. Adjusted sprite tile fetch time from 22 to 14 to compensate. This should give us perfectly stable Dai Kaijuu Monogatari 2 battles.
2012-02-18 07:49:52 +00:00
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
return color;
}
void PPU::Background::reset() {
Update to v086 release. byuu says: The main focus of this release is Laevateinn, which is the new bsnes debugger. Unlike previous debuggers, Laevateinn is a standalone application with its own GUI entirely focused on debugging. Changelog: - created ui-debugger target (Laevateinn) - fixed multitap ports 2-4 [quequotion] - fixed ui-libsnes target compilation - fixed a crashing issue with NSS XML markup - improved cartridge-folder loading support - NES can now load .fc (headerless NES) or .prg+.chr (split NES) images - fixed cursor being visible in fullscreen mode when using Linux/Metacity window manager [ncbncb] - show normal cursor when using Linux/SDL video driver [ncbncb] - added menu accelerators - fixed a bug in performance profile SMP incw/decw instructions - SNES core can now optionally be built without Game Boy emulation core - added 2012-02-04 cheats.xml database [mightymo]
2012-02-13 11:44:02 +00:00
regs.tiledata_addr = (random(0x0000) & 0x07) << 13;
regs.screen_addr = (random(0x0000) & 0x7c) << 9;
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
regs.screen_size = random(0);
regs.mosaic = random(0);
regs.tile_size = random(0);
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
regs.mode = 0;
regs.priority0 = 0;
regs.priority1 = 0;
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
regs.main_enable = random(0);
regs.sub_enable = random(0);
regs.hoffset = random(0x0000);
regs.voffset = random(0x0000);
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
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
cache.hoffset = 0;
cache.voffset = 0;
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
output.main.palette = 0;
output.main.priority = 0;
output.sub.palette = 0;
output.sub.priority = 0;
Update to v078r07 release. byuu says: Would appreciate testing on any games with mosaic, especially Mode7 mosaic.I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program. This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging. I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run(). I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now. Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-06-05 03:25:24 +00:00
mosaic.priority = 0;
mosaic.palette = 0;
mosaic.tile = 0;
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
Update to v078r07 release. byuu says: Would appreciate testing on any games with mosaic, especially Mode7 mosaic.I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program. This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging. I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run(). I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now. Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-06-05 03:25:24 +00:00
mosaic.vcounter = 0;
mosaic.voffset = 0;
mosaic.hcounter = 0;
mosaic.hoffset = 0;
Update to v068r17 release. byuu says: This hopefully fixes vertical and horizontal mosaic with the accurate S-PPU core. It also adds frame-skipping support to the compatibility and performance S-PPU cores. This is not visible to the user interface, because I feel that virtually nobody is going to play with frame-skipping on when they could use a faster emulation with it off. However, I did use it to enhance the 'Fast Forward' key. When you press it, it will now turn off video and audio sync, and set a frameskip of 9. This allows you to speed things up an additional ~60% over your max theoretical speed without frameskipping. ~35% with the compatible core, because the PPU is less of a bottleneck for it. Slowdown was improved, it will turn on audio sync if it is off until you release the key to ensure you actually get 30fps. Eventually it'd probably be wise to set a cap on the fast forward speed, but I hardly think it's an issue on today's computers.
2010-09-09 06:34:54 +00:00
Update to v078r07 release. byuu says: Would appreciate testing on any games with mosaic, especially Mode7 mosaic.I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program. This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging. I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run(). I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now. Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-06-05 03:25:24 +00:00
x = 0;
y = 0;
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
Update to v068r14 release. byuu says: Holy hell, that was a total brain twister. After hours of crazy bit twiddling and debug printf's, I finally figured out how to allow both lores and hires scrolling in the accurate PPU renderer. In the process, I modified the main loop to run from -7 to 255, regardless of the hires setting, and perform X adjustment inside the tile fetching. This fixed a strange main/subscreen misalignment issue, so I was able to restore the proper sub-then-main rendering for the final screen output stage. Code looks a good bit cleaner this way overall. I also added load state and save state menus to the tools menu, so you can use the menubar to load and save to ten slots. I am thinking that I should nuke the icons. As pretty as they are, it's getting tiresome trying to find icons for everything, I have no pictures to represent loading or saving a slot, nor to represent individual slots. I'll just stick to radios and checkboxes.
2010-09-05 23:08:03 +00:00
tile_counter = 0;
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
tile = 0;
priority = 0;
palette_number = 0;
palette_index = 0;
for(unsigned n = 0; n < 8; n++) data[n] = 0;
}
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
unsigned PPU::Background::get_tile(unsigned x, unsigned y) {
bool hires = (self.regs.bgmode == 5 || self.regs.bgmode == 6);
unsigned tile_height = (regs.tile_size == TileSize::Size8x8 ? 3 : 4);
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
unsigned tile_width = (!hires ? tile_height : 4);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
unsigned width = (!hires ? 256 : 512);
Update to v078r07 release. byuu says: Would appreciate testing on any games with mosaic, especially Mode7 mosaic.I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program. This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging. I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run(). I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now. Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-06-05 03:25:24 +00:00
unsigned mask_x = (tile_height == 3 ? width : width << 1);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
unsigned mask_y = mask_x;
if(regs.screen_size & 1) mask_x <<= 1;
if(regs.screen_size & 2) mask_y <<= 1;
mask_x--;
mask_y--;
Update to v078r07 release. byuu says: Would appreciate testing on any games with mosaic, especially Mode7 mosaic.I have tested Super Turrican 2, Sim Earth, Contra III and SNES Test Program. This only applies to BG modes 0-6, and technically should not affect Mode7 at all. I am not sure if Mode7 needs the same change made or not, but given the way it fetches that could prove quite challenging. I also simplified the background renderer a good bit. See eg the pixel copy stuff in Background::run(). I've only fixed this in the accuracy renderer. I'm sorry, but the compatibility renderer is a fucking mess. I haven't really touched it in four or five years now. Will probably just revert to the accuracy/SMP in the performance profile for the next release since it's not being used otherwise. People can toggle it on if they want to try it out.
2011-06-05 03:25:24 +00:00
unsigned screen_x = (regs.screen_size & 1 ? 32 << 5 : 0);
unsigned screen_y = (regs.screen_size & 2 ? 32 << 5 : 0);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
if(regs.screen_size == 3) screen_y <<= 1;
x = (x & mask_x) >> tile_width;
y = (y & mask_y) >> tile_height;
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
uint16 offset = ((y & 0x1f) << 5) + (x & 0x1f);
if(x & 0x20) offset += screen_x;
if(y & 0x20) offset += screen_y;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
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
uint16 addr = regs.screen_addr + (offset << 1);
Update to v074r11 release. byuu says: Changelog: - debugger compiles on all three profiles - libsnes compiles on all three platforms (no API changes to libsnes) - memory.cpp : namespace memory removed (wram -> cpu, apuram -> smp, vram, oam, cgram -> ppu) - sa1.cpp : namespace memory removed (SA-1 specific functions merged inline to SA1::bus_read,write) - GameBoy: added serial link support with interrupts and proper 8192hz timing, but obviously it acts as if no other GB is connected to it - GameBoy: added STAT OAM interrupt, and better STAT d1,d0 mode values - UI: since Qt is dead, I've renamed the config files back to bsnes.cfg and bsnes-geometry.cfg - SA1: IRAM was not syncing to CPU on SA-1 side - PPU/Accuracy and PPU/Performance needed Sprite oam renamed to Sprite sprite; so that I could add uint8 oam[544] - makes more sense anyway, OAM = object attribute memory, obj or sprite are better names for Sprite rendering class - more cleanup
2011-01-24 09:03:17 +00:00
return (ppu.vram[addr + 0] << 0) + (ppu.vram[addr + 1] << 8);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
}
PPU::Background::Background(PPU &self, unsigned id) : self(self), id(id) {
}
#endif