unofficial LaunchELF v4.30

[dlanor]

Originally Posted by suloku

Here's a corrected version of the source:

Changes:
- a stupid typo when reactivating ps2host functioncs make it unable t compile.

I never Copy/Pasted that typo so it's not a problem here.
"host:" works just fine in my current beta.

- substituted he strcmp if statement for "if(setting->Main_Skin[0])"

I'll do the same here. Not that it's very important, but it will save some code space, which is always good.

- solved a bug that made the background skin image file appear in the main screen when launching ps2net instead of main skin image file. I don't really know what caused that behaviour, but it's working correctly now.

Why do you say you don't know ?
In the bugfix version you added the following to the end of the function loadNetModules

	if (setting->main[0]) {
	main_active = 1;
	loadSkin(BACKGROUND_PIC, 0, 0);
	}

That makes it pretty clear why the background was wrong in your previous version. The only reason for any confusion about it is that the bug never struck if you used PS2Net from the main menu, but only when you used it through the FileBrowser, because then the old skin would be active when the PS2Net routine is reached, but it exits to the main menu without using the exit code of the FileBrowser, which would have restored the background.

In any case I'll still release my current beta, with that minor bug, in my next post, which will also contain a description of the many changes I made to your code, and some of my ideas concerning GUI design.

Right now I'm looking into positioning the text, I think the best opition is to make a new cnf file for main screen text positioning.

I don't know about that. Then we'd have to make yet another config option for what such file to load. I really don't like splitting configs up into lots of different files, all of which must be present for the program to work right. (Fortunately uLE does work without any extra files too.)

But I concede that there is one huge point in favor of a separate file in this particular case, as it is the only practical way to distribute and use new GUI skin designs. It would be a bit much to expect each user to hand-edit their CNFs to paste in new skin coordinates for each skin switch.

But it could still be handled by similar means as the normal CNF loading, as an extra routine performed after loading the regular CNF, in case it contained a variable specifying an external GUI coordinate file. And of course that extra routine should also be used whenever that variable is configured. (But only when the main config menu is exited with OK, to save the changes.)

Best regards: dlanor

[suloku]

Originally Posted by dlanor

Ok, but I think you're going a bit far in assuming that all languages can translate "Halt" to a word of four letters or less...
(Even in english it's grammatically incorrect, as it should be "Halted".)

I know, but I just added it as a way to shorten the text to make it fit into a red button where the timer runs out. Anyway, it's not a troublesome part to delete or modify from code.

Originally Posted by dlanor

Please don't bother. I'll have to do it myself anyway, as I've made considerable changes to your code.

Already did in the source above, but if you have already changed the code I've nothing to say.

Anyway, the bugfic mentioned above is adding the following lines at the end of loadNetModules function in main.c:

if (setting->main[0]) {
main_active = 1;
loadSkin(BACKGROUND_PIC, 0, 0);

Originally Posted by dlanor

Btw:
For future contributions, please include a comment with your 'handle' at the start of *every* insertion/edit you make in the code, just one such comment for each contiguous block of course, with a similar comment at the end of the inserted/edited section. I don't add contributions to uLE just by dropping in the files provided (except for entirely new files), but insist on doing it by copy/paste of each modified section. This way I know I've seen it all, and that it's all good.

A good format for such commenting would be like this:

//suloku: edit start
...Several lines of edited code...
//suloku: edit end

For single-line edits an alternate comment form would be to just append a comment to that line, like this:

...modified single-line code...//suloku: edit line

If such a line already has a comment, yours should be hacked to the end of the line, repeating the redundant "//" (so I or EP may globally edit it out later)

OK, sorry for trouble, I will do that allways from now on. BTW, you can use a program called ExamDiff to see all the changes, it's a powerfull text file comparing.

If you want I can look all the files and send them to you commented so you can see all changes, even though you already did some modifications.

Originally Posted by dlanor

----- snip ----- re: Fixed VS freely positioned GUI buttons
I'm not sure about that. We always discussed it as a feature to be modified by text editor. Having another config menu will add significantly to the code. But I'm not ruling it out. A lot depends on how concise it can be made. A lot of that code will be repetitive, doing the same things for several entries in what is effectively a coordinate array. So smart use of a loop could simplify that menu handling a lot, by reusing the same code for each 'button' handled.


You kidding ?

The PS2 only has 16 buttons, of which our menu uses 14, plus the 'Default' entry and the two string positions for Delay/Timeout and the countdown/Halt indicator, thus making for a total of 17 string positions. Even if we double that by putting X and Y on separate lines, its still no more than 34 text lines. What could possibly be so bad about that ? (It's just temprorary storage for uLE, released after use for initializing the internal 'setting' struct.)

The real problem is the code to load/save those lines, since that code needs to refer to the name of each variable in the file. For this I'm inclined to use a scheme similar to that used for the PathPad, so that a fairly tight loop can reuse the same code for each of the string coordinates in saving, while the loading code will accept any such variable containing a valid array index (in the range 0..16, that is).

Well, I don't really think making a configurable text positioning screen would take that big size in ule.

By the way, if you think that 34 new arrays in the cnf file aren't that much, i'll start looking into this, but maybe i'll wait until I see the changes you made to the code I added.

Originally Posted by dlanor

"USBD IRX" is the generic driver handling low_level access to all USB devices
I myself have a hub, mouse, and keyboard connected at all times, in addition to my USB HDD (or sometimes a flash drive instead). Of course, uLE itself doesn't support all devices, but only USB_mass and a keyboard.

Does this mean that it's just an option to use diferent usb drivers for the specified functions, meaning ule uses the hdusbfs driver for both by default?

[dlanor]

@everyone:
Here is the first beta release of uLE incorporating a modified form of the main menu GUI code developed by suloku.

This beta release does NOT include the latests changes posted by suloku, so the bug of losing the GUI skin display when using PS2Net from FileBrowser still remains. But that problem is easily cured each time, simply by entering any other menu and exiting again. So just pressing 'Select' and then 'Triangle' will do the trick. (By entering and exiting the config menu.)

@suloku:
I've now integrated your GUI-skin changes into the current version of uLE, but in so doing I found several things that needed changing, as follows:

There was a grave error in the choice of terminology, rather consistently applied to most variables and struct members related to the GUI skin, whereby the single word "main" was used as if synonymous to the words "GUI skin". So I've changed all such instances. I've also corrected the only slightly better instances of "Main Skin" to be "GUI Skin" instead. IMO The 'main' skin remains the one used throughout all uLE subprograms and menus apart from the launch menu, and in that one as well if no GUI skin is chosen. Some other uses of the term "main" were also changed simply to "GUI" as well.

This changed terminology affects all of the files you edited suloku, and it means that the CNF files you used with that version will not work right with my release without editing them first.


There were two errors in the "Skin Settings..." menu, such that the menu would be exited automatically after choice of a JPG for use as GUI skin, or after canceling such choice. I'll change that so the user will remain in this menu until the command RETURN (or Triangle button) is used.

NB: I realize that you were misled into making those two errors by the behaviour of the original code for "Apply New Skin". But the reason for its exit was that this command is the one which really activates the current choice, the other commands merely being used to set it up for preview and further editing (brightness etc). And since that skin choice was the ONLY choice in that menu, exiting when the choice was finally applied was appropriate.

With another JPG being chosen in the same menu, such exit is no longer proper for either of them, and I've instead added another "Apply" command for the GUI skin. Both the 'Apply' commands now stay in this menu after use, their only effect being to copy the path string into skinSave/GUI_save, and in the case of the former also to activate the skin for the current menu.

Another error in that menu is that the "GUI Skin Path" command had an incorrect tooltip (should have same as "Skin Path" command).

Another new change in this menu is that I made the preview window serve both GUI JPGs. At first entrance it will always show the old skin JPG, but whenever you use either of the commands to choose a new JPG, or to 'Apply' that JPG to the real settings, then the preview window will switch to showing that JPG, and a text row above that window will inform you of the current state.

There's a serious lack of optimization in how the new code redraws the GUI screen, causing a need for extreme duplication of the function calls performing that operation. Those are duplicated at the end of virtually every menu or subprogram in all of uLE, which may/will lead back to the main menu. This needs to be changed so that the GUI skin is redrawn only from a single location inside the code for the main menu.

There's also a similar lack in optimization in how the non-GUI skin is redrawn for all of the cases where an internal subprogram is launched (via the RunElf function), causing extreme duplication of those display function calls as well. This usage too needs to be better optimized to avoid redundant duplication.

For now though, I've left such optimization as-is, since I had enough other work to do, but I plan to fix this later on

There's also a problem with the brightness setting, as that will currently be shared by both JPGs, though only editable (visibly) for the non-GUI skin. This really should be fixed by separating that variable (both in CNF and program code) into two independent ones, so that the brightness control will only affect the JPG currently shown in the preview window, with finalization of that setting at the following 'Apply' command for that JPG.

Regardless of any 'Apply' commands though, ALL settings will still revert to the original ones if you exit the main config menu without using its OK command to explicitly save settings.


This implementation still suffers from several weaknesses though, which is in part unavoidable due to its nature.

1: Tooltips in the GUI menu only exist as part of that JPG, and therefore they are locked in language to whatever the skin designer used.

2: For the same reason, the usefulness of any GUI skin is reduced by 50% since that is the chance it will contain incorrect OK/Cancel choices for the users' preferences.

3: Just like all text generated by the old methods, all text, symbols, and other graphics on a GUI skin must also follow the main rule for interlace design, which is that EVERY pixel must have a vertically adjacent pixel with which it does not contrast greatly either in colour or brightness. That is not true of the example skin. (The tooltips flicker much worse than normal text.)

4: It is never acceptable for any graphics on a GUI skin to interfere with the readability of the status information displayed in the top text line, in the way that the current GUI template does when used with NTSC resolutions. The 'frame' used needs to be lowered slightly, so as to leave the status text unaffected. At a guess 4 pixels would be sufficient.

Note that point 2 above means that any 'complete' skin design must consist of 2 slightly different JPG files, so as to cover both gamepad usage standards.

Point 4 is probably another instance where you were misled by imitating the frame that uLE can generate. That's a mistake because no single JPG can do the same, as the frame generated by uLE has different dimensions for PAL and NTSC. There are two obvious ways to fix this problem.

One way is to lower the frame used in the JPG, so that you have a margin of at least 4 pixels in PAL mode, relative to 'descenders' of lower case characters in the status messages. (Or 6 pixels relative to upper case characters.) Then NTSC should work with the 'descenders' just touching that frame (instead of overlaying it, like now).

Another way is to simply skip having the frame in the JPG at all, as you can always enable the one in uLE instead, which will adapt it's position and size automatically to suit the current resolution. But if you want some fancy frame instead (unlike the current JPG), then you'll need to use the first solution, of keeping it low enough on screen to leave the status line unaffected.

I've included an extra JPG in the release, nearly identical to yours except that I erased the frame. This skin works equally well in NTSC and PAL.

Best regards: dlanor

[dlanor]

----- snip ----- re: comment 'markers' for edited code

Originally Posted by suloku

OK, sorry for trouble, I will do that allways from now on.

Good. It makes things so much easier when merging stuff from a contributor.

BTW, you can use a program called ExamDiff to see all the changes, it's a powerfull text file comparing.

I assume that's some GUI version of the standard 'diff' utility (which I've used through cygwin+bash). If so then I guess I should look it up, as that sort of thing could help in cases like these.

If you want I can look all the files and send them to you commented so you can see all changes, even though you already did some modifications.

No, don't bother. I think I caught all the changes already.

Well, I don't really think making a configurable text positioning screen would take that big size in ule.

That depends. Just having a simple coordinate entry screen is one thing, definitely no problem, but trying to make it 'WYSIWYG' is something entirely different. That's not something I'd favor.

By the way, if you think that 34 new arrays

Huh ?
I meant 34 text lines, to be used for initializing a simple array like:

int GUI_positions[17][2];

in the cnf file aren't that much, i'll start looking into this, but maybe i'll wait until I see the changes you made to the code I added.

The current beta is already posted, with some notes on the changes.

Does this mean that it's just an option to use diferent usb drivers for the specified functions,

Yes. If no external files are specified then the internal drivers, embedded in the code of uLE, will be be loaded and used by default. Nowdays there should be no reason to use external modules, as the homebrew ones we use give the best results with most USB devices. We just keep those options for compatibility with the few who actually do need some other module.

meaning ule uses the hdusbfs driver for both by default?

"usbhdfsd.irx" (by Herben) is only a driver for "USB_mass", not for generic low_level USB I/O, so we also embed the "usbd.irx" supplied by PS2SDK. Both of those drivers are used by default if no external drivers are specified, which is the normal case nowdays. (I never use external drivers except in testing them.)

The same also applies to the USB keyboard driver, for which the embedded one is the "ps2kbd.irx" supplied by PS2SDK.

Best regards: dlanor

[suloku]

That was quick!

Regarding to the GUI skin config menu, as you said I did it because of the current behaviour of that menu, I didn't want to start coding something really complicated as I just wanted to store the path in the cnf file.

About the redundant code, I just couldn't think of any other way to make the image load at the required time. My programming skills are very limited.

Refering to the image and the frames, I did all my tests on PAL display, and as you said NTSC display is a little messed up, I didn't realize it when positioning the text.

Originally Posted by dlanor

That depends. Just having a simple coordinate entry screen is one thing, definitely no problem, but trying to make it 'WYSIWYG' is something entirely different. That's not something I'd favor.

I've thought another way of doing that, that consist in a mixture of both methods: a simple coordinate entry screen that loads anytime, with a simple button press, the launch menu screen and GUI skin, but only the display, not complete menu. Then another button press (or releasing the same button pressed before) returns to the coordinate entry screen to continue editing.

I see a problem in this though, as he changes should be stored before previewing and then returning to previous configuration should be impossible unless the user knew the previous values.

[dlanor]

Originally Posted by suloku

Refering to the image and the frames, I did all my tests on PAL display, and as you said NTSC display is a little messed up, I didn't realize it when positioning the text.

I assumed as much. In any case you shouldn't take what I said as criticism of your contribution. I just needed you to know what I changed and why I did it. And for the GUI image design it was also important to make others aware of the pitfalls.


----- snip ----- re: WYSISYG GUI text positioning

I've thought another way of doing that, that consist in a mixture of both methods: a simple coordinate entry screen that loads anytime, with a simple button press, the launch menu screen and GUI skin, but only the display, not complete menu. Then another button press (or releasing the same button pressed before) returns to the coordinate entry screen to continue editing.

I see a problem in this though, as he changes should be stored before previewing and then returning to previous configuration should be impossible unless the user knew the previous values.

This could be handled by an extra struct for saving the settings, and either restoring or scrapping that depending on how you exit from the preview screen. (Simply using two different buttons to exit.) This is the same method used for the main config menu, so it should work fine here too.

Best regards: dlanor

[zabolyx]

Hey kids nice to see things working away.

I'd like to throw in this. How about a file that lists the coordinates of text in a file named the same as the skin file made. this would allow for several things to happen such as users can develope their skins and set the locations without relying on the user to do so like with the text color setting on the old skinning. and in doing so this would allow for each menu page (is that a good word) to have a seperate skin and locations. I have a custom skin made for each of my pages HDLoader, Emus, Media players, Utilities, and so one.

A tiny file to go with each skin. this file could also contain text color settings for the pages as well. This wouldn't be a bad idea to implement on the older skins as well.

[Z-Saber]

Terrific work, everyone. I'll probably wait for the full-fledged release and skip the beta though, considering the unoptimized nature of the code and some of the caveats (flickering).

[zabolyx]

@Z-Saber

If you have a second MC use it. It's always nice having testing help for a project like this. The more testing the faster the errors can be tracked down and fixed.

[dlanor]

Originally Posted by zabolyx

Hey kids nice to see things working away.

I'd like to throw in this. How about a file that lists the coordinates of text in a file named the same as the skin file made.

That's a kind of dependency I've always tried to avoid in uLE, just as I've always tried to avoid dependency on external files at all. (Allowing them is one thing, dependency is another.) But I do see how it would make skin distribution much easier, and without adding a new file-name config to the uLE config menus. Since the skins require proper skin-specific settings to become useful, I agree that we do need to add a convenient way of loading such skin-specific settings.

this would allow for several things to happen such as users can develope their skins and set the locations without relying on the user to do so like with the text color setting on the old skinning.

That is true. And it should be noted that NO skin design, old type or new type, is complete without specification of the color settings. Remember that even the GUI skin must have a background color that allows the status line at the top of the screen to be visible, as that is still displayed by traditional uLE methods using the standard color settings.


Hmmm. We could add a feature to always look for an extra file with the same name prefix as the skin file, both for standard skins and GUI skins. I'm not sure what suffix to use though, though ".CNF" may be the most appropriate, since the contents should be compatible to the uLE CNF parser.

For standard skins that extra file should contain only color settings, in exactly the same form they have in the main CNF file, so these new files can be created by Cut/Paste in some text editor, and also so that they may be parsed by the same routines that handle the main CNF.

For the new GUI skins the extra file should contain the same color settings, but also settings for the GUI text positions, again in a format acceptable to the main CNF as well. And as mentioned previously, the brightness setting should also be separate for each skin, and thus also stored in the 'extra' CNF.

Such a new standard would allow positions and colours for skins to be set either in the main CNF or in the extra CNF files, with proper fallback on defaults in case an extra CNF is missing (this is allowed, so not an error) or somehow fails to load properly. The defaults used will primarily be the settings of the main CNF, or if those are missing (also allowed, though abnormal) then the internal defaults of the program. And for the case of GUI skins the same also applies to GUI text positions. If they are missing from the extra CNF, or if that file fails to load, then default positions defined either in the main CNF or in the program itself will be used.

I think this proposal maximizes the flexibility and freedom for GUI designers, while still allowing for efficient handling of these matters in uLE.

and in doing so this would allow for each menu page (is that a good word)

If you mean alternate CNFs switched to by 'Load CNF++'/'Load CNF--', then yes. I too tend to think of those as alternate menu pages, and that was also the main motivation for developing those commands.

to have a seperate skin and locations. I have a custom skin made for each of my pages HDLoader, Emus, Media players, Utilities, and so one.

Personally I feel that is making it a little too specialized. Why have a whole CNF setup just to launch a single program like HDLoader...? That sort of defeats the purpose of having a normal menu, unless you need lots of differently patched versions, I guess.

A tiny file to go with each skin. this file could also contain text color settings for the pages as well. This wouldn't be a bad idea to implement on the older skins as well.

As stated in some detail above, I agree completely.

Best regards: dlanor

[dlanor]

Originally Posted by Z-Saber

Terrific work, everyone. I'll probably wait for the full-fledged release and skip the beta though, considering the unoptimized nature of the code and some of the caveats (flickering).

The only effect of the optimization should be a minor decrease of the code size (VERY minor in the normal compressed ELF).

And the flickering referred to has nothing to do with the program code, but is caused by some text strings in the JPG skin which are unsuitably rendered for use in interlaced resolutions. No program changes can affect that.

But there may be many other improvements in the main release to come, which is why you'll have to wait a little longer for it. That's one of the reasons the Beta exists, so that those who don't want to wait can try some of the new stuff right now. (And report any problems so we can correct those.)

Best regards: dlanor

[dlanor]

Originally Posted by zabolyx

@Z-Saber

If you have a second MC use it. It's always nice having testing help for a project like this. The more testing the faster the errors can be tracked down and fixed.

Another good way of testing a beta is to install it in an extra folder, with its own copy of LAUNCHELF.CNF in that folder, so that any new CNF changes will not affect the default CNF in the SYS-CONF folder.

Then you can boot up your standard release of uLE and use this to launch the Beta version in the extra folder, and be certain that none of the CNF changes you try will affect your boot-up uLE.

Just don't forget to place a LAUNCHELF.CNF file inside the same folder as the Beta ELF, to make sure that that the Beta will never touch the CNF of your regular uLE installation.

And don't do such Beta testing on the HDD, as uLE will default to saving CNFs in mc0:/SYS-CONF/ when launched from HDD even if you do have a proper CNF in the same HDD folder (for complex techie reasons we can't avoid). But on MC or USB such testing works fine.

Best regards: dlanor

[zabolyx]

Well Big "D". My HD Loader menu has HDL Classic, HDL 8b, HDL GOW2, and HDL 7c on it as well as Filebrowser for moving around my game saves. so that what 5 items on one page. so it's not wasted on a single command

I'm glad you like the idea though. with all the emus though I almost need a second menu... Scumm, NES, GB, Genesis, SNES, 2600, 5200, TG-16.. crap I know I have more because the only button left is L3. This new skinning would be a great new toy to play with. I can't wait till everything is working.

Sadly I can't play with the new one yet because I've had my station over at a friends house all week. I might be getting it back Sat though and will gladdly tear into this version.

[ubergeek42]

I'm working on making a guide on how to compile uLaunchElf, since we all know how difficult it can be to get everything in order, and I have a few suggestions to make.

Why is everything assumed to be in the $PS2DEV directory. I don't keep the SMS sources/binaries in the root of my ps2dev folder, to me it seems disorganized. I think maybe there should be an sms variable defined at the beginning that determines where stuff like sms is located. It can default to the ps2dev directory, b