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