Open PS2 Loader Project Feature Requests

[dlanor]

Heres an idea i got that still gives us that 'eye-candy' and somewhat the Dynamic feel too. If this can be done, then we can have the large list and the icons/cover art too.

----- snip ----- re: I've no need to repeat the illustration here

Of course this is just an illustration, so the icon and cover art would change for each game.

I see what you mean, and I agree that it works fine for the cover art, but I don't see the point of having the icon art at all then, especially as I really hate the way the cursor point movement causes text lines not selected to 'move around'.

As for the icons, the ONLY point in having them as well as the cover pictures was because the icons were supposed to be visible all the time (when cursor point is stable anyway), so that every game available in the current screenful was shown with a graphic icon in addition to its written name.

Your method reverts the implementation to using stereotype miniature icons common for all games except the currently selected one, and since that one also has its cover art picture displayed, having its much smaller icon picture displayed as well is completely redundant.

Meaningful use of icons will inevitably require a fairly low amount of list entries per screen, as overly miniaturized icons also become meaningless when the user can no longer see what they represent. Even now the rendition of icons to the screen is somewhat compressed, as there simply isn't room for 10 icons of 64 pixels height on top of each other, neither in PAL (512/64==8) nor in NTSC (480/64==7.5).

So using much more than the current 10 list entries per screen will make the use of icons meaningless one way or another.

My own suggestion is that the current mode with 10 lines per screen (at least for PAL) with individual icons for all plus cover graphics for the selected entry should become one configurable choice, with its main alternate being an icon-less format using 20 lines per screen (again for PAL) but still allowing a cover graphic of the selected entry to be displayed. NTSC users may have to settle for a little less due to the 32 pixels lesser screen height though. Naturally the denser list formats could still use stereotype disc icons in front of the names, as pure decoration, much like the ones in your example (for the non-selected entries). But using individual icon files in a dense list mode is IMO completely pointless.


In regard to earlier discussion of the 'dynamic' menu, I can only repeat what I have said before, which is that I consider it not only difficult, but in fact impossible to create any menu system that displays only one game at a time while also allowing practical easy access to hundreds of games. Those two goals simply cannot be combined, and then it is the single-game method that must give way to more generically useful methods. Sure, we may keep it as an option a fanatic PS3 user might enable, but the larger user group is not going to touch it, as it becomes very impractical with a large number of games.

As for the use of separate game lists per device type, I actually prefer to have them separate, as it would be very hard for me to identify what I'm testing otherwise. Nearly all games I have on any device are also duplicated in my SMB fileshare, so I'd have to start renaming them to tell which is which if they all appear in a combined list.

And there is also the issue of game compatibility, as this can differ a lot for different loader cores. So two identical game entries shown in a combined list might still work differently, like if the game in question only runs on one medium but not on the other. For example, some games still have problems running with the SMB core, though they work fine with the USB core. (eg: The Nippon Ichi RPG "Phantom Brave")

Best regards: dlanor

[volca]

Valuable input guys, thanks . I think it is now obvious we should leave the game lists separate.

About the icons - I think it is okay to have them quite small next to a game's title if there is a way to enlarge. I was thinking a detail screen could've been implemented, with cover art, game name, genre, year of release, compatibility status, etc (A single file containing cover art, CD image and all these fields would then exist additionaly to the ul.cfg). A L1 and R1 would work as prev/next buttons, meaning one could browse the collection in detail mode with one game visible or in overview mode where N games would be shown. Another way to enable the per item icons is to introduce list zoom function. Since I'll be probably implementing TTF rendering it may work quite nicely.

Another space saving idea: The top source list selection could become a really narrow status panel (like mobile phones have) - selected game list would be shining, others would be half transparent. That would take less space.

Then there was the request to be able to filter the game list. That should be counted with when designing this as well (We probably need a button asigned to customize the filter and a status icon showing list is filtered). Or it could work not as a filter but as a cascaded view on the game lists - root would be categories (By Genre, By first letter, by year...) then the subcategories, inside those games themselves.

[jimmikaelkael]

Perhaps I was mistaken, but my impression from earlier discussions with him was that he was going to have a good look at all the components involved in the LAN usage, with a view to optimizing them, which for the in-game SMB core would include integrating several of those modules into one unit, to eliminate most of the overhead due to interactions between separate modules. That is one of the things that could give major speed improvements. Even so, that special module would be suitable only for OPL.

But a side effect of reworking the original guest-account SMB modules (originally taken from an ancient version of SMS I think) for use in the OPL GUI, inevitably means that their use will be much clarified in comparison to those old SMS sources where they were first used, making them more suitable for addition to other projects as well. And that is where uLE can benefit...

Just to clarify, before to have health problems, I was rewriting a module replacement for in-game SMSMAP, SMSTCPIP and SMB code all in one module as you stated (the final target for this code replacement being cdvdman module of course)

With misfire, we where testing my network code implementation (less SMB code) in PS2RD (http://bitbucket.org/misfire/ps2rd/overview/) as 'net' module. It's a lightweight replacement module for SMSMAP/SMSTCPIP but only provide a simple UDP interface. Once compiled without the UDPtty output it's approx. 10KB. The tests with this 'net' module have given quite good results.

Of course, the one for OPL implements TCP and SMB instead of UDP.
I did tested it before to go to hospital, but speed results were not those I expected, Max Payne Intro being more choppy than with SMS drivers, but FFXII intro being less skippy on the other hand...
I should really look again into these modules, as I was thinking of using the SMB request multiplexing trick to speed up things.

Concerning early OPL's SMB code, It was never based on SMS sources, as I've never looked at 1 line of code of that SMS driver (and didn't know at the time I first wrote smb code that SMS was SMB compatable).
I was mainly developped with the help of a great book(Implementing CIFS, Christopher R. Hertel) on SMB and the SNIA CIFS documentation.

[JNABK]

Ok, how about somthing like this:

Dont mind the small icons not having the game inages, its just an illustration and i didnt feel like putting all the individual icons , so i made green dots as a representation of them.

[yoshi314]

i think incompatible games could be grayed out/hidden for a particular list.

i prefer more minimalistic approach for a gui. the less fancy dialogs the better.

[izdubar]

----- re: suggested use of HDLoader Settings folder for store cov/ico graphics
No. We sometimes store complete HDD paths that way for convenience, but the fileXio functions can not work with any complete path in any form !!!

Instead all normal HDD file access is split over two different device groups. The "hdd0:" device is the only member of the first group, and is used to access the HDD partitions for mounting to a so-called 'mountpoint'. And these mountpoints form the other group of fileXio devices, named "pfs0:", "pfs1:", etc. Different HDD drivers may have different limits on the total number of separate mountpoint devices, but normal HDD drivers should allow at least four of them (the last one then being "pfs3:").

So given a full pathname like "hdd0:/HDLoader Settings/COV/SLUS_208.47.raw" (for "La Pucelle Tactics"), we would first use fileXioMount("pfs0:", "hdd0:/HDLoader Settings", FIO_MT_RDONLY) to mount the partition to the first mountpoint (assuming it is free), and then we can access the file as "pfs0:/COV/SLUS_208.47.raw". using normal fileXio file access functions, such as fileXioOpen etc.

Thanks for all these valuable informations. Moreover you point me to another solution, for the game code. After what you said I just looked at the code of LaunchHDDGame, and ... found it in the startup attribute of the HDD game structure ... I wonder how I didn't saw that last day ... must have been tired and was looking for "image" instead ... It should be now easy to add HDD support.

----- re: Size-checking raw files to avoid freeze-up
The reason why is very simple. some of those icons do not have dimensions of 64x64 but instead use 64x66 (eg: "apps.raw") or something like that (I only checked some).

You're correct again The Gimp must have tricked me ... so no more reason to not do the expected size check.

However I'm not sure I'll can do these changes in the next days, will see ...

[JNABK]

Another space saving idea: The top source list selection could become a really narrow status panel (like mobile phones have) - selected game list would be shining, others would be half transparent. That would take less space.

Do you mean something like this:

If its easier to print all 3 lists to screen, than have seperate ones print to screen per selection, then this could be a viable option to use. This would allow us to see ALL our games from one location and still be able to know what loader they belong to.

Edit
I took a peek at your 'net loading' animation......how bout something like one of these:

[dlanor]

Concerning early OPL's SMB code, It was never based on SMS sources, as I've never looked at 1 line of code of that SMS driver (and didn't know at the time I first wrote smb code that SMS was SMB compatable).

Sorry, my mistake! I simply assumed that the new implementation used an older one as basis, which was evidently wrong.

But that is all the better IMO, when it comes implementing the same drivers for some other homebrew, as this means that no closed source project (like SMS) is in any way involved.

I was mainly developped with the help of a great book(Implementing CIFS, Christopher R. Hertel) on SMB and the SNIA CIFS documentation.

I think I'll look those up myself then too...
(found a very nice PDF set for that book)

Best regards: dlanor

[dlanor]

If its easier to print all 3 lists to screen, than have seperate ones print to screen per selection, then this could be a viable option to use.

But that is simply not the case.

Creating a combined list using all the possible sources is much more complex than just using separate lists, especially when we include the needs for sorting and for refreshing list content after a hotswap of either a USB drive or an SMB fileshare. Not to mention the effect of doing both...

I believe there is NOTHING good to be gained from combining the lists into one, apart from the cleanup of the top menu resulting from eliminating the list choice icons.

This would allow us to see ALL our games from one location and still be able to know what loader they belong to.

I grant that it would do that, but I still would not prefer it to having separate lists.

Apart from that the general appearance of this layout is fine, except for the fact that the font you used here gives an erroneous impression of how much text we can cram into each line of the list.

The 9 characters of "Game name" would in reality occupy a much larger portion of the total screen width (like almost a quarter). So moving the start of the game title strings so far to the right as you did here (almost one third of the screen) will reduce the visible string length considerably. It will no longer be possibe to see the full 32 character strings that our standards allow.

But with a slightly thinner font used in OPL it might work better, though there is then a risk of losing clear readability. Great care must be taken in such font design, especially to ensure that it gives clear readability even on old-fashioned CRT TV sets, where interlace effects will be far more visible and disturbing than on a modern LCD set.

Best regards: dlanor

[JNABK]

I prefer the seperate lists to display per device too, but i was only showing what i thought was volca's idea. I have no idea which is the easiest to do when it comes to coding. But that could still work the same for cleaning up the top selection icons, the difference being a seperate list appears per selected icon. We could still use that top selection method to keep from needing to display all the icons at the same time.

I did mention in an earlier post that its dificult to design with the current font , but volca is working on a new font system, so these are just design ideas so far and im aware they might not look exactly as my illustrations in the end results.

Im sure once the font system is squared away and everyone happy with it, the designing will be easier to refine.