MSX
July 28th, 2005, 18:47
Browsing ps2dev's forums and andon just made a new thread announcing his development of 0.02pd2, which should be released soon, and he talked about a way to increase the FPS 15-20 :D.
0.02pd2's in SVN right now, in fact it's been there for well over a week. It's not finished and ready for release yet, but I wanted to mention it and request help optimizing the tile drawing code (see below).
I added a new file manager where you can copy/move files around on your Memory Stick and even copy/move files between Memory Sticks (however, files > ~3.5 Mb or so will require multiple swaps, because the available heap memory is very small).
I translated the file delete confirmation dialog in the file selector
I improved the battery stats to include estimated (the Kernel's estimation, not my own :P) runtime and corrected the reported percentage.
Corrected a bug where the PSP would completely hang if you exited from the Home button menu while in the file selector. As far as I know, this still affects 0.02y29+.
Cleaned up the SceGU backend, giving it similar interfaces as the Snes9x OpenGL backend.
When using the SceGU backend, the scissor region is now set appropriately, so that the unused portions of the square render texture are not drawn. (This was most obvious in "Normal" mode or "4:3" with HiRes mode enabled).
ROMs that use 239 scanlines ("Overscan") are properly handled within the SceGU backend now.
Cleaned up the code in psp.cpp... If you intend to do a diff vs. a version of y's port, make sure you enable "ignore whitespace" :)
Because of the new file manager, you need to use START + SELECT to exit the game from the menu now. This has always been possible, but there used to be a menu option that did the same thing.
Similarly, there's no continue menu option... Simply press X to close the main menu.
Integrated all of y's "optimizations" from 0.02y28. A lot of them really have no measurable performance increase and some of them even break compatibility with certain games unfortunately. I'll systematically revert the ones that are causing issues before 0.02pd2 is officially released.
On the note of optimization, I'm looking into optimizing the tile code to use the GPU at the moment. This is the one key area that's keeping Snes9x from running at "full speed" on the PSP. Optimization really needs to be focused on this and not the more trivial things y's been working on.
I have discovered through a lot of hard work (sucks without gprof support) that branching is what's killing performance in the tile drawing code. If you take out the if (...) branches and perform every operation over every iteration of the loops, the framerate shoots up a good 15-20 FPS. While I'm going to attempt to attack the situation using the GPU, someone who's skilled with MIPS assembly may want to write optimized variants of DrawTile16 (...) and DrawTile16_OBJ (...) (see gfx.cpp and tile.cpp) that use conditional moves instead of the more expensive branches; that would help performance tremendously.
Attacking the issue with the GPU in mind is a major challenge. First of all, the SNES hardware has the capability to change all sorts of things between scanlines, and a tile's "depth" (or priority) is on a per-pixel basis. This is difficult to handle on the PSP, which has a fixed function fragment pipeline. So it may prove futile, but I'll give it a shot anyway.
Origin: http://forums.ps2dev.org/viewtopic.php?t=2850
0.02pd2's in SVN right now, in fact it's been there for well over a week. It's not finished and ready for release yet, but I wanted to mention it and request help optimizing the tile drawing code (see below).
I added a new file manager where you can copy/move files around on your Memory Stick and even copy/move files between Memory Sticks (however, files > ~3.5 Mb or so will require multiple swaps, because the available heap memory is very small).
I translated the file delete confirmation dialog in the file selector
I improved the battery stats to include estimated (the Kernel's estimation, not my own :P) runtime and corrected the reported percentage.
Corrected a bug where the PSP would completely hang if you exited from the Home button menu while in the file selector. As far as I know, this still affects 0.02y29+.
Cleaned up the SceGU backend, giving it similar interfaces as the Snes9x OpenGL backend.
When using the SceGU backend, the scissor region is now set appropriately, so that the unused portions of the square render texture are not drawn. (This was most obvious in "Normal" mode or "4:3" with HiRes mode enabled).
ROMs that use 239 scanlines ("Overscan") are properly handled within the SceGU backend now.
Cleaned up the code in psp.cpp... If you intend to do a diff vs. a version of y's port, make sure you enable "ignore whitespace" :)
Because of the new file manager, you need to use START + SELECT to exit the game from the menu now. This has always been possible, but there used to be a menu option that did the same thing.
Similarly, there's no continue menu option... Simply press X to close the main menu.
Integrated all of y's "optimizations" from 0.02y28. A lot of them really have no measurable performance increase and some of them even break compatibility with certain games unfortunately. I'll systematically revert the ones that are causing issues before 0.02pd2 is officially released.
On the note of optimization, I'm looking into optimizing the tile code to use the GPU at the moment. This is the one key area that's keeping Snes9x from running at "full speed" on the PSP. Optimization really needs to be focused on this and not the more trivial things y's been working on.
I have discovered through a lot of hard work (sucks without gprof support) that branching is what's killing performance in the tile drawing code. If you take out the if (...) branches and perform every operation over every iteration of the loops, the framerate shoots up a good 15-20 FPS. While I'm going to attempt to attack the situation using the GPU, someone who's skilled with MIPS assembly may want to write optimized variants of DrawTile16 (...) and DrawTile16_OBJ (...) (see gfx.cpp and tile.cpp) that use conditional moves instead of the more expensive branches; that would help performance tremendously.
Attacking the issue with the GPU in mind is a major challenge. First of all, the SNES hardware has the capability to change all sorts of things between scanlines, and a tile's "depth" (or priority) is on a per-pixel basis. This is difficult to handle on the PSP, which has a fixed function fragment pipeline. So it may prove futile, but I'll give it a shot anyway.
Origin: http://forums.ps2dev.org/viewtopic.php?t=2850