Question About .gpe Files

[blueshift]

I was following this guide for making shortcuts to my applications. But I noticed something odd.

With some of the applications (like wiz2600, the Atari 2600 emulator) the .gpe file that I'm asked to link to in the .ini file IS the emulator's executable file, which make sense. But with other applications (like gpSP, the Game Boy Advance emulator) the .gpe file is a shell script that is a separate file from the emulator's actual executable file.

Why would I be asked to set the .ini shortcut file's path to a shell script instead of the actual executable file? Why do some emulators set the executable file it's self as the .gpe while others set a shell script as the .gpe?

I don't have my Wiz yet so I can't test this out for myself. So I just did what the guide told me to do and linked to the .gpe file for each application's .ini shortcut file irregardless of whether it was an executable file or a shell script. So that when it arrives all I'll have to do is copy the "game" folder over to the SD card and I'll theoretically be good to go.

 

[torpor]

It doesn't matter either way if you link to a starter-script or directly to your applications executable - its up to you. Some apps prefer to have stuff in the starter script like 'cd to the right directory', set some ENV vars, etc. But its entirely up to you if you need this or not .. some Wiz .GPE's just have everything they need to get started in the main() and leave it at that.

One advantage to using a starter-script is that it makes overclocking for individual emulators pretty simple - you can insert a line to do the overclocking in the script before your main executable gets fired up, and this means customized overclocking rules on a per-application basis. Handy also for other things (like inserting USB drivers, or whatever) ..

 

[blueshift]

It doesn't matter either way if you link to a starter-script or directly to your applications executable - its up to you. Some apps prefer to have stuff in the starter script like 'cd to the right directory', set some ENV vars, etc. But its entirely up to you if you need this or not .. some Wiz .GPE's just have everything they need to get started in the main() and leave it at that.

One advantage to using a starter-script is that it makes overclocking for individual emulators pretty simple - you can insert a line to do the overclocking in the script before your main executable gets fired up, and this means customized overclocking rules on a per-application basis. Handy also for other things (like inserting USB drivers, or whatever) ..

That's pretty much what I thought, thanks for confirming. The part in the instructions that made me really curious was that it said to put a path to the executable file that ends in .gpe and I saw that the executable and the .gpe file aren't always the same thing.

[info]
name="The title you want to see in the list"
path="/relative/path/to/your/executable.gpe"
icon="/relative/path/to/an/icon.png"

 

[skeezix]

There are many good reasons to send to a sh first.

ie: It gives you a wrapper around the executable, so you can set up or do other things. Common things you would do in the sh, that in turn invokes the bin are..

1) The most important, imho .. call the bin, and then call gp2xmenu. Why? if the app dies, the sh will launch the menu. For apps that embed the call into the menu right in the bin.. if the app crashes, your'e just toast. More to point, it closes off options.. what if you want to do somethign after the app exits, like logging, or something? It is bad form to put the menu call in the bin, imho. What if you want to call a different menu, say, or something (Without altering the menu itself.)

2) Setting up shared libs, or moving things around, setting env-vars, etc. ie: I commonly alter LD_CONFIG_PATH in the wrapper sh script

3) Logging; I like to spit out date-time info to serial or filesystem before/after app launches, for debugging

4) Can go on and on.

So, having a sh wrapper is a _Very_ handy thing. For apps that don't do it, you can just rename the bin to something else, name your sh script what the bins name was, and good to go, for half the above. IF tyhe bin calls the menu directly (poor idea imho), then you can rename the menu to something else, and put a sh in its place, which in turn launches the menu, thus giving you a hook.

jeff