- 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.
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.
