Launcher And Application Reliability


RiX0R

Idler-Inside
Joined
Sep 20, 2005
Messages
294
Website
rix0r.nl
The way launching applications is organized currently can be called less-than-ideal.

One common problem I have: the menu doesn't automatically reload itself after starting an application, so it is up to the application to restart the menu. If for some reason it does not: black screen, gp2x hangs, and you can look forward to another half-minute of booting.

I can see why the menu does it this way: we're on an embedded device, memory is expensive, and the game will need all the memory it can get: best to unload the menu.

However, the added effect that, if the application fails to restart the menu when it's done (because it crashes, or whatever), your gp2x effectively hangs, is pretty fubar. In fact, it hasn't even crashed. It is still working properly! There's just no application running to do something constructive.

A quick fix for this problem is of course the launcher scripts we see now, that launch the game and afterwards restart the menu. But that solution seems kind of clunky to me, and very unelegant to have both a "game binary" and a "make sure we can eventually return to the menu script" for each game.

I can't see a structural solution to this, except modifying the menu so that it will ensure it can restart itself. That's not gonna happen right now, because we don't have access to the source. Alternatively, as an intermediate solution, we can devise a launcher/loader standard that will take care of the gory details and will allow easy usage by all developers: ideally via copy/pasting a simple script and editing a few filenames. We can combine this with esavior's proposal from this thread.

---

Another (related) problem is that if games throw an error, for any reason whatsoever, the output is not visible. The output has gone to the console, but the console is hidden, and the menu isn't restarted. This effectively leaves you with a black screen and the wonder: what has just gone wrong?

There's no way to find out and therefore no way to fix it (except guessing and brute forcing -- yuck).

New launchers should capture the console output from the application, and display it to the user in case the program failed with an error (exitcode != 0). That way, the user has a change of diagnosing and fixing the problem.

---

Edit: And the launcher can take care of "sync" remounting for games that require it. Though I still wonder if we're not better off mounting the thing as "sync" by default.
 
Last edited by a moderator:
I'm pretty sure the user does not want a way of diagnosing and fixing the problem. The user simply wants something that brings them back to the main menu regardless of what happens when they exit the game.
 
I'm talking about things like missing files or libraries. Methinks it would be quite useful to know which files are missing and where you were supposed to install them.
 
RiX0R said:
One common problem I have: the menu doesn't automatically reload itself after starting an application, so it is up to the application to restart the menu. If for some reason it does not: black screen, gp2x hangs, and you can look forward to another half-minute of booting.
I find this incredibly annoying also. I must have restarted my gp2x 20 times just trying to install the sdl libraries correctly. The temporary fix is as you stated use a script to launch the application, and you can even use the ones I already wrote up :D. But in the long term we shouldn't really be doing this. The correct solution is better exception handling. Catching exceptions and correcting the problem or dumping back to menu is a much better way of handling dumps than scripts. Hopefully the developers will take advantage of exception handling in c++ and you will see the black screen of doom much less often.

Then of course when a program exits normally we can always use atexit to dump back to menu.

fomit said:
I'm pretty sure the user does not want a way of diagnosing and fixing the problem. The user simply wants something that brings them back to the main menu regardless of what happens when they exit the game.
RiX0R
I disagree. I think the user wants a application that works. I don't think applications should dump to a console, but even just saving debug information to a file on the card, or putting it into a display dialog would be much better than black screening. Every user will just okay past the dialog, but if they come here saying X game is dieing we can atleast say... look on your SD card, there is a file called coolgame_outputdump and ask them to put the contents here. That way someone here might be able to suggest a solution. Error dialogs are not for the user, they are for the developers to help the users.
 
Last edited by a moderator:
Back
Top