The above video goes away if you are a member and logged in, so log in now!
A few minor interface suggestions
A few minor interface suggestions –
Probably the biggest thing bugging me is that there's no way to switch the O and X buttons (eg have O be accept, X be cancel.) The patches for HDloader gave one the ability to do this a long time ago and I must admit I got used to it. Perhaps I've been playing too many JRPGs, but I've gotten used to it (and yeah, it's annoying that most modern ports of these games now have those buttons switched between the Western localization and the originals.) From what I can tell, it really seems like quite a lot of people actually do prefer this button layout like I do, though I realize we aren't in the majority. Still, it seems like it warrants an option. Programs like uLaunchELF and even the Free McBoot configuration let you configure them for this layout very easily (or does uLaunchELF even default to this? I forget now.) In fact, the Free McBoot configuration program asks you right off (though I wish it would save the setting instead of asking every single time you start it...) For now I've just modified the gamepad's include file to actually switch the scancodes defined to each of those two buttons such that the program thinks it's getting an X when I press O and vice versa (and while I was at it I switched the image files for the O and the X so that when it says press X or press O for something, it actually is saying the correct thing. It seems like the program pretty much relies on those images to be correct...) I'm not well versed in programming at all though and I'm not at all confident I'll always be able to do this with future releases. Plus it's just a pain having to actually modify OPL for something that, IMO, should really be built in. Then too, I doubt everyone who would prefer this button layout can even do that much. I wouldn't be shocked if quite a large number of them don't know how to operate linux to even be able to build it in the first place (though I won't deny that the build VMs provided to us are ridiculously easy to work with when we're familiar with linux, not everyone is familiar enough with it.) IMO this is actually big enough to warrant an actual setting in the program (which I do realize means it probably increases the size of the binary by some tiny amount, means a minor menu change, and etc, but overall I think wouldn't be too bad.)
One more minor thing I'd also like to suggest is that I'd like to be able to page through the lists using the left and right d-pad buttons rather than the shoulder buttons. Quite a few games use these buttons instead and I guess I've gotten used to it, but having used both methods over the years I would have to say that I think it's actually less work using the left and right directions to page instead. The shoulder buttons could then instead be used for switching between OPL modes. I don't know that this warrants an actual setting for it though. I personally believe that it's overall a better control configuration and would be worth being the normal configuration, but perhaps not everyone would agree? If not, at the minimum, the images being used at the top to show the modes are confusing. It shows, for example, an "R" for me to switch to apps mode which makes me think of the right shoulder button (which in turns makes me mentally switch over to left/right being the paging under the assumption that the shoulder buttons are to switch modes instead of pages.) If nothing else, perhaps the image itself should be changed to be less confusing? For example, showing an actual directional arrow instead of the letter R. I'd still prefer the controls themselves were switched, but if nothing else the image is misleading. I realize this is minor overall, but it IS an interface control thing that one runs into frequently, so it can become annoying overall to me at least.
Finally, if the setting to save the last game played is enabled, I think OPL shouldn't save the last played game if it's already saved -- or, alternately, perhaps it should save to the harddrive instead since this is one of those minor things that if you switch memory cards or whatever (or even carry one to a different machine,) won't be a big deal should you lose that setting. On slower memory cards like the one I was using (a 32MB that I think was made by Datel or some other major brand I'm forgetting) it can take an annoyingly long length of time just to start a game with this setting, thus forcing me to disable it. It seems rather unnecessary to actually stop and save the exact same thing that's already there though... Plus it's technically a little bit more wear on the memory card (well, I realize flash memory lasts a ridiculously long amount of time, but, after all, it is getting about time to consider the PS2 from the perspective of long terms now...) I'll admit that after playing Ar Tonelico II I bought an official SONY 8MB memory card (it literally took more than five minutes to make the initial save and literally required about two or three minutes or so every single time I loaded the save screen to actually make a save -- ironically the actual save itself took less than one minute after that first time) but it does bother me knowing that it's wasting time and cycles on saving what's already there when I'm just running the same game all over again (which I admit I do a lot, hence my enabling this option in the first place.) Again only a minor thing, but it is unnecessary to save what's already there after all.
I'll have a look for the first item.
Second item: buttons choice for the GUI were probably not decided but chosen on the fly. Now, it will please some people, and not everyone. But as you said, only thing that could be done is a "proper" control configuration screen. But that thing would take a lot of time to dev, and I'm not sure it is a top priority, as the current layout is pretty instinctive for most users. More-over I don't understand how the "R" / "L" image are confusing ? They are the exact representation of the real buttons on your PS2 pad. We can't put any other image that would be more significant.
Last item: That is not correct. I just made the test. Run twice time the same game, would not save the "LAST PLAYED" game again on MC. You will see the "Saving config" briefly, but it doesn't save the settings if the game code is the same (in fact it is done the way we handle config files, if value is the same, we don't change the "modified" flag, and a config which is not "modified" doesn't get saved). I even added a trace to check what file are saved, so no doubt about this.