Application Standard


Aimless_E

Member
Joined
Oct 10, 2005
Messages
461
This may have been better suited for the development section, but here it is. Some Programs have been release for the gp2x that require the user to go to utilities to play the game. While others will have more then one .gpe file listed in games making it harder for the user to select the right one.

For all those interested in programing for the gp2x I think we need to set some standards .

1. Extensions are for the GUI only not for the OS. If you name a script (name).gpe then it will show up in Games if you name it (name).gpu it willl show up in utilties. But it will run the same regardless of the extension or what menu its under.

2. If your program requires a script to return to the menu (most do I think) then you can name the main executable something like (game).bin, or (game).exec, or (game).exe, and even just (game). Then write the script you need and name it (game).gpe now you'll only have one file the users can pick from the menu and you know it will work correctly. :)

Im sure those who read this can add more so I leave it to you.
 
GPH should really fix the shell restart by having a small binary used to run the program and restart the shell when it exits (or if the program restarts the shell, the shell should check for and kill that mentioned small binary). I think they did it the way they did to avoid excess memory usage by unloading the shell from memory while running games (but not for utils, as they must have assumed they wouldn't need that much memory).
 
The shell isn't unloaded, it's the menu that needs restarting (as Aimless_E said), and the menu handles games and apps in exactly the same way. And GPH don't require apps to restart the menu, it's just something we do because we can :). How many other consoles let you return to a launcher without having to reset first? On the gp32 people coded their exit functions to reset, on the gp2x people exec gp2xmenu instead. I know which one I prefer.
 
I like Aimless E's suggestion to call the actual game binary game.bin or game the launching script game.gpe. I know that would be much easier and [sarcasm]it would give us another reason to not look at the readme file and then ask the stupid questions here in the forum[/sarcasm] :) .
 
I have taken to calling my executables somethinggpe and calling my shell script somethinglauncher.gpe. For example:

===== this is treelauncher.gpe =====
#!/bin/sh
#
./treegpe
#
# Re-load the GP2X menu on exit
cd /usr/gp2x
./gp2xmenu
===== end of treelauncher.gpe =====


I dithered a bit about calling treelauncher.gpe tree.gpe instead, but I couldn't really convince myself to change it.
 
Actually most of the time there's no need for a launcher script. The main reason I used one for Quake is that it was being a bit of a bugger and not always syncing data or loading the menu afterwards, but using the script was a quick and easy hack until I found the cause of the problem. A much neater solution is to call execl("/usr/bin/sync","sync",NULL); after saving data, and chdir("/usr/gp2x"); execl("gp2xmenu","gp2xmenu",NULL); in the exit function.
 
woogal posted on Dec 20 2005 at 07:59 AM said:
A much neater solution is to call execl("/usr/bin/sync","sync",NULL); after saving data, and chdir("/usr/gp2x"); execl("gp2xmenu","gp2xmenu",NULL); in the exit function.
Or just call sync() after saving data. Easier still.
 
Last edited by a moderator:
Back
Top