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

280 lines
7.5 KiB
C++
Raw Normal View History

First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
#include "mode7.cpp"
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
auto PPU::Background::voffset() const -> uint16 {
if(r.mosaic) return latch.voffset;
return r.voffset;
Update to v095r05 release. byuu says: Changelog: - GBA: lots of emulation improvements - PPU PRAM is 16-bits wide - DMA masks &~1/Half, &~3/Word - VRAM OBJ 8-bit writes are ignored - OAM 8-bit writes are ignored - BGnCNT unused bits are writable* - BG(0,1)CNT can't set the d13 - BLDALPHA is readable (fixes Donkey Kong Country, etc) - SNES: lots of code cleanups - sfc/chip => sfc/coprocessor - UI: save most recent controller selection GBA test scores: 1552/1552, 37/38, 1020/1260 (* forgot to add the value to the read function, so endrift's I/O tests for them will fail. Fixed locally.) Note: SNES is the only system with multiple controller/expansion port options, and as such is the only one with a "None" option. Because it's shared by the controller and expansion port, it ends up sorted first in the list. This means that on your first run, you'll need to go to Super Famicom->Controller Port 1 and select "Gamepad", otherwise input won't work. Also note that changing the expansion port device requires loading a new cart. Unlike controllers, you aren't meant to hotplug expansion port devices.
2015-11-12 10:15:03 +00:00
}
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
auto PPU::Background::hoffset() const -> uint16 {
if(r.mosaic) return latch.hoffset;
return r.hoffset;
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
}
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 v095r05 release. byuu says: Changelog: - GBA: lots of emulation improvements - PPU PRAM is 16-bits wide - DMA masks &~1/Half, &~3/Word - VRAM OBJ 8-bit writes are ignored - OAM 8-bit writes are ignored - BGnCNT unused bits are writable* - BG(0,1)CNT can't set the d13 - BLDALPHA is readable (fixes Donkey Kong Country, etc) - SNES: lots of code cleanups - sfc/chip => sfc/coprocessor - UI: save most recent controller selection GBA test scores: 1552/1552, 37/38, 1020/1260 (* forgot to add the value to the read function, so endrift's I/O tests for them will fail. Fixed locally.) Note: SNES is the only system with multiple controller/expansion port options, and as such is the only one with a "None" option. Because it's shared by the controller and expansion port, it ends up sorted first in the list. This means that on your first run, you'll need to go to Super Famicom->Controller Port 1 and select "Gamepad", otherwise input won't work. Also note that changing the expansion port device requires loading a new cart. Unlike controllers, you aren't meant to hotplug expansion port devices.
2015-11-12 10:15:03 +00:00
auto PPU::Background::frame() -> void {
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
//H = 0
Update to v095r05 release. byuu says: Changelog: - GBA: lots of emulation improvements - PPU PRAM is 16-bits wide - DMA masks &~1/Half, &~3/Word - VRAM OBJ 8-bit writes are ignored - OAM 8-bit writes are ignored - BGnCNT unused bits are writable* - BG(0,1)CNT can't set the d13 - BLDALPHA is readable (fixes Donkey Kong Country, etc) - SNES: lots of code cleanups - sfc/chip => sfc/coprocessor - UI: save most recent controller selection GBA test scores: 1552/1552, 37/38, 1020/1260 (* forgot to add the value to the read function, so endrift's I/O tests for them will fail. Fixed locally.) Note: SNES is the only system with multiple controller/expansion port options, and as such is the only one with a "None" option. Because it's shared by the controller and expansion port, it ends up sorted first in the list. This means that on your first run, you'll need to go to Super Famicom->Controller Port 1 and select "Gamepad", otherwise input won't work. Also note that changing the expansion port device requires loading a new cart. Unlike controllers, you aren't meant to hotplug expansion port devices.
2015-11-12 10:15:03 +00:00
auto PPU::Background::scanline() -> void {
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 v095r05 release. byuu says: Changelog: - GBA: lots of emulation improvements - PPU PRAM is 16-bits wide - DMA masks &~1/Half, &~3/Word - VRAM OBJ 8-bit writes are ignored - OAM 8-bit writes are ignored - BGnCNT unused bits are writable* - BG(0,1)CNT can't set the d13 - BLDALPHA is readable (fixes Donkey Kong Country, etc) - SNES: lots of code cleanups - sfc/chip => sfc/coprocessor - UI: save most recent controller selection GBA test scores: 1552/1552, 37/38, 1020/1260 (* forgot to add the value to the read function, so endrift's I/O tests for them will fail. Fixed locally.) Note: SNES is the only system with multiple controller/expansion port options, and as such is the only one with a "None" option. Because it's shared by the controller and expansion port, it ends up sorted first in the list. This means that on your first run, you'll need to go to Super Famicom->Controller Port 1 and select "Gamepad", otherwise input won't work. Also note that changing the expansion port device requires loading a new cart. Unlike controllers, you aren't meant to hotplug expansion port devices.
2015-11-12 10:15:03 +00:00
auto PPU::Background::begin() -> void {
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
bool hires = (ppu.r.bgMode == 5 || ppu.r.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 v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
y = ppu.vcounter();
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(y == 1) {
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
mosaic.vcounter = r.mosaic + 1;
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.voffset = 1;
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
latch.hoffset = r.hoffset;
latch.voffset = r.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) {
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
mosaic.vcounter = r.mosaic + 1;
mosaic.voffset += r.mosaic + 1;
latch.hoffset = r.hoffset;
latch.voffset = r.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 v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
tileCounter = (7 - (latch.hoffset & 7)) << hires;
for(auto& d : data) d = 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
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
mosaic.hcounter = r.mosaic + 1;
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.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
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
if(r.mode == Mode::Mode7) return beginMode7();
if(r.mosaic == 0) {
latch.hoffset = r.hoffset;
latch.voffset = r.voffset;
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
}
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
}
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
auto PPU::Background::getTile() -> void {
bool hires = (ppu.r.bgMode == 5 || ppu.r.bgMode == 6);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint colorDepth = (r.mode == Mode::BPP2 ? 0 : r.mode == Mode::BPP4 ? 1 : 2);
uint paletteOffset = (ppu.r.bgMode == 0 ? id << 5 : 0);
uint paletteSize = 2 << colorDepth;
uint tileMask = 0x0fff >> colorDepth;
uint tiledataIndex = r.tiledataAddress >> (4 + colorDepth);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint tileHeight = (r.tileSize == TileSize::Size8x8 ? 3 : 4);
uint tileWidth = (!hires ? tileHeight : 4);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint 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 v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint hmask = (tileHeight == 3 ? width : width << 1);
uint vmask = hmask;
if(r.screenSize & 1) hmask <<= 1;
if(r.screenSize & 2) vmask <<= 1;
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
hmask--;
vmask--;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint px = x << hires;
uint py = (r.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 v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint hscroll = hoffset();
uint vscroll = voffset();
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
if(hires) {
hscroll <<= 1;
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
if(ppu.r.interlace) py = (py << 1) + ppu.field();
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
}
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint hoffset = hscroll + px;
uint voffset = vscroll + py;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
if(ppu.r.bgMode == 2 || ppu.r.bgMode == 4 || ppu.r.bgMode == 6) {
uint16 offsetX = (x + (hscroll & 7));
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
if(offsetX >= 8) {
uint hval = ppu.bg3.getTile((offsetX - 8) + (ppu.bg3.hoffset() & ~7), ppu.bg3.voffset() + 0);
uint vval = ppu.bg3.getTile((offsetX - 8) + (ppu.bg3.hoffset() & ~7), ppu.bg3.voffset() + 8);
uint validMask = (id == ID::BG1 ? 0x2000 : 0x4000);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
if(ppu.r.bgMode == 4) {
if(hval & validMask) {
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 & 0x8000) == 0) {
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
hoffset = offsetX + (hval & ~7);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
} else {
voffset = y + hval;
}
}
} else {
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
if(hval & validMask) hoffset = offsetX + (hval & ~7);
if(vval & validMask) 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 v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint screenX = (r.screenSize & 1 ? 32 << 5 : 0);
uint screenY = (r.screenSize & 2 ? 32 << 5 : 0);
if(r.screenSize == 3) screenY <<= 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 v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint tx = hoffset >> tileWidth;
uint ty = voffset >> tileHeight;
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 = ((ty & 0x1f) << 5) + (tx & 0x1f);
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
if(tx & 0x20) offset += screenX;
if(ty & 0x20) offset += screenY;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint16 address = r.screenAddress + (offset << 1);
tile = (ppu.memory.vram[address + 0] << 0) + (ppu.memory.vram[address + 1] << 8);
bool mirrorY = tile & 0x8000;
bool mirrorX = tile & 0x4000;
priority = r.priority[bool(tile & 0x2000)];
paletteNumber = (tile >> 10) & 7;
paletteIndex = paletteOffset + (paletteNumber << paletteSize);
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 v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
if(tileWidth == 4 && (bool)(hoffset & 8) != mirrorX) tile += 1;
if(tileHeight == 4 && (bool)(voffset & 8) != mirrorY) tile += 16;
uint16 character = ((tile & 0x03ff) + tiledataIndex) & tileMask;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
if(mirrorY) voffset ^= 7;
offset = (character << (4 + colorDepth)) + ((voffset & 7) << 1);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
switch(r.mode) {
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
case Mode::BPP8:
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
data[1].byte(3) = ppu.memory.vram[offset + 49];
data[1].byte(2) = ppu.memory.vram[offset + 48];
data[1].byte(1) = ppu.memory.vram[offset + 33];
data[1].byte(0) = ppu.memory.vram[offset + 32];
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
case Mode::BPP4:
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
data[0].byte(3) = ppu.memory.vram[offset + 17];
data[0].byte(2) = ppu.memory.vram[offset + 16];
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
case Mode::BPP2:
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
data[0].byte(1) = ppu.memory.vram[offset + 1];
data[0].byte(0) = ppu.memory.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
}
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
if(mirrorX) for(auto n : range(2)) {
data[n] = ((data[n] >> 4) & 0x0f0f0f0f) | ((data[n] << 4) & 0xf0f0f0f0);
data[n] = ((data[n] >> 2) & 0x33333333) | ((data[n] << 2) & 0xcccccccc);
data[n] = ((data[n] >> 1) & 0x55555555) | ((data[n] << 1) & 0xaaaaaaaa);
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
}
}
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v095r05 release. byuu says: Changelog: - GBA: lots of emulation improvements - PPU PRAM is 16-bits wide - DMA masks &~1/Half, &~3/Word - VRAM OBJ 8-bit writes are ignored - OAM 8-bit writes are ignored - BGnCNT unused bits are writable* - BG(0,1)CNT can't set the d13 - BLDALPHA is readable (fixes Donkey Kong Country, etc) - SNES: lots of code cleanups - sfc/chip => sfc/coprocessor - UI: save most recent controller selection GBA test scores: 1552/1552, 37/38, 1020/1260 (* forgot to add the value to the read function, so endrift's I/O tests for them will fail. Fixed locally.) Note: SNES is the only system with multiple controller/expansion port options, and as such is the only one with a "None" option. Because it's shared by the controller and expansion port, it ends up sorted first in the list. This means that on your first run, you'll need to go to Super Famicom->Controller Port 1 and select "Gamepad", otherwise input won't work. Also note that changing the expansion port device requires loading a new cart. Unlike controllers, you aren't meant to hotplug expansion port devices.
2015-11-12 10:15:03 +00:00
auto PPU::Background::run(bool screen) -> void {
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
if(ppu.vcounter() == 0) return;
bool hires = (ppu.r.bgMode == 5 || ppu.r.bgMode == 6);
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 v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
if(screen == Screen::Below) {
output.above.priority = 0;
output.below.priority = 0;
if(!hires) 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 v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
if(tileCounter-- == 0) {
tileCounter = 7;
getTile();
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
}
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 v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
if(r.mode == Mode::Mode7) return runMode7();
Update to v094r39 release. byuu says: Changelog: - SNES mid-scanline BGMODE fixes finally merged (can run atx2.zip{mode7.smc}+mtest(2).sfc properly now) - Makefile now discards all built-in rules and variables - switch on bool warning disabled for GCC now as well (was already disabled for Clang) - when loading a game, if any required files are missing, display a warning message box (manifest.bml, program.rom, bios.rom, etc) - when loading a game (or a game slot), if manifest.bml is missing, it will invoke icarus to try and generate it - if that fails (icarus is missing or the folder is bad), you will get a warning telling you that the manifest can't be loaded The warning prompt on missing files work for both games and the .sys folders and their files. For some reason, failing to load the DMG/CGB BIOS is causing a crash before I can display the modal dialog. I have no idea why, and the stack frame backtrace is junk. I also can't seem to abort the failed loading process. If I call Program::unloadMedia(), I get a nasty segfault. Again with a really nasty stack trace. So for now, it'll just end up sitting there emulating an empty ROM (solid black screen.) In time, I'd like to fix that too. Lastly, I need a better method than popen for Windows. popen is kind of ugly and flashes a console window for a brief second even if the application launched is linked with -mwindows. Not sure if there even is one (I need to read the stdout result, so CreateProcess may not work unless I do something nasty like "> %tmp%/temp") I'm also using the regular popen instead of _wpopen, so for this WIP, it won't work if your game folder has non-English letters in the path.
2015-08-04 09:00:55 +00:00
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint8 palette = getTileColor();
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) {
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
mosaic.hcounter = r.mosaic + 1;
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 = priority;
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
mosaic.palette = palette ? paletteIndex + palette : 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.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 v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
if(screen == Screen::Above) 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 v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
if(!hires || screen == Screen::Above) if(r.aboveEnable) output.above = mosaic;
if(!hires || screen == Screen::Below) if(r.belowEnable) output.below = mosaic;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
}
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
auto PPU::Background::getTileColor() -> uint {
uint 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
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
switch(r.mode) {
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
case Mode::BPP8:
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
color += data[1] >> 28 & 0x80;
color += data[1] >> 21 & 0x40;
color += data[1] >> 14 & 0x20;
color += data[1] >> 7 & 0x10;
data[1] <<= 1;
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
case Mode::BPP4:
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
color += data[0] >> 28 & 0x08;
color += data[0] >> 21 & 0x04;
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
case Mode::BPP2:
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
color += data[0] >> 14 & 0x02;
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;
}
Update to v095r05 release. byuu says: Changelog: - GBA: lots of emulation improvements - PPU PRAM is 16-bits wide - DMA masks &~1/Half, &~3/Word - VRAM OBJ 8-bit writes are ignored - OAM 8-bit writes are ignored - BGnCNT unused bits are writable* - BG(0,1)CNT can't set the d13 - BLDALPHA is readable (fixes Donkey Kong Country, etc) - SNES: lots of code cleanups - sfc/chip => sfc/coprocessor - UI: save most recent controller selection GBA test scores: 1552/1552, 37/38, 1020/1260 (* forgot to add the value to the read function, so endrift's I/O tests for them will fail. Fixed locally.) Note: SNES is the only system with multiple controller/expansion port options, and as such is the only one with a "None" option. Because it's shared by the controller and expansion port, it ends up sorted first in the list. This means that on your first run, you'll need to go to Super Famicom->Controller Port 1 and select "Gamepad", otherwise input won't work. Also note that changing the expansion port device requires loading a new cart. Unlike controllers, you aren't meant to hotplug expansion port devices.
2015-11-12 10:15:03 +00:00
auto PPU::Background::reset() -> void {
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
r.tiledataAddress = (random(0x0000) & 0x07) << 13;
r.screenAddress = (random(0x0000) & 0x7c) << 9;
r.screenSize = random(0);
r.mosaic = random(0);
r.tileSize = random(0);
r.mode = 0;
for(auto& p : r.priority) p = 0;
r.aboveEnable = random(0);
r.belowEnable = random(0);
r.hoffset = random(0x0000);
r.voffset = random(0x0000);
latch.hoffset = 0;
latch.voffset = 0;
output.above.palette = 0;
output.above.priority = 0;
output.below.palette = 0;
output.below.priority = 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.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 v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
tileCounter = 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;
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
paletteNumber = 0;
paletteIndex = 0;
for(auto& d : data) d = 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 v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
auto PPU::Background::getTile(uint x, uint y) -> uint {
bool hires = (ppu.r.bgMode == 5 || ppu.r.bgMode == 6);
uint tileHeight = (r.tileSize == TileSize::Size8x8 ? 3 : 4);
uint tileWidth = (!hires ? tileHeight : 4);
uint width = (!hires ? 256 : 512);
uint maskX = (tileHeight == 3 ? width : width << 1);
uint maskY = maskX;
if(r.screenSize & 1) maskX <<= 1;
if(r.screenSize & 2) maskY <<= 1;
maskX--;
maskY--;
uint screenX = (r.screenSize & 1 ? 32 << 5 : 0);
uint screenY = (r.screenSize & 2 ? 32 << 5 : 0);
if(r.screenSize == 3) screenY <<= 1;
x = (x & maskX) >> tileWidth;
y = (y & maskY) >> tileHeight;
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 offset = ((y & 0x1f) << 5) + (x & 0x1f);
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
if(x & 0x20) offset += screenX;
if(y & 0x20) offset += screenY;
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
Update to v099r01 release. byuu says: Changelog: - massive cleanups and optimizations on the PPU core - ~9% speedup over v099 official This is pretty much it for the low-hanging fruit of speeding up higan. Any more gains from this point will be extremely hard-fought, unfortunately.
2016-06-14 10:51:54 +00:00
uint16 address = r.screenAddress + (offset << 1);
return (ppu.memory.vram[address + 0] << 0) + (ppu.memory.vram[address + 1] << 8);
First version split into asnes and bsnes.
2010-08-09 13:28:56 +00:00
}