Launcher... for the launchers?

Subforum for discussion and help with ScummVM's Nintendo DS port

Moderator: ScummVM Team

Post Reply
badbob001
Posts: 24
Joined: Mon Oct 31, 2005 8:36 pm

Launcher... for the launchers?

Post by badbob001 » Tue Jul 15, 2008 8:27 pm

I think the whole 'use build x for game y' implementation needs to be made easier without one needing to carry a cheat sheet along with the NDS. I assume the scummvm code was broken up to multiple builds due to limitations of the NDS. How about a separate launcher that will show what games you have installed and then use the correct build to launch? Is it even possible for a NDS app to launch another NDS app?

Forget_the_Rest
Posts: 26
Joined: Tue Jul 15, 2008 9:11 pm

Post by Forget_the_Rest » Tue Jul 15, 2008 9:15 pm

You are right about the DS version being split up due to the capabilities of the console.

I'm not sure if it is possible to load one app from another but even if it was, I'm not sure it would be worth it unless you could then get it to unload the first app.

fingolfin
Retired
Posts: 1466
Joined: Wed Sep 21, 2005 4:12 pm

Post by fingolfin » Tue Jul 15, 2008 11:02 pm

A much better solution will be when/if the DS port implements support for engine *plugins*. The ScummVM architecture makes it possible for ports to do that, but it requires extra work... But the result would be one binary for all engines, and IMO is the superior solution.

agentq
ScummVM Porter
Posts: 806
Joined: Wed Dec 21, 2005 4:29 pm
Location: London, UK

Post by agentq » Wed Jul 16, 2008 9:08 am

I have considered writing a launcher for the separate builds. It's perfectly possible to launch one program from another, but the problem with this is that it could only work for games which had already been added to the game list by running one of the builds separately, as the game engine needs to be loaded in order to detect it's data files the first time. This strikes me as an easy way to make things more confusing and create more support requests.

The proper way to do it would be to use loadable modules as Fingolfin says, but I don't think the DS homebrew libraries support such a thing, so I would have to create some support. I don't know much about how this works, so this is something to look at some time in the future, unless someone else wants to have a go at it.

Tramboi
Posts: 42
Joined: Fri Sep 22, 2006 7:20 pm

Post by Tramboi » Thu Jul 17, 2008 8:39 am

I can probably check this next month, if you wish.

agentq
ScummVM Porter
Posts: 806
Joined: Wed Dec 21, 2005 4:29 pm
Location: London, UK

Post by agentq » Fri Jul 18, 2008 8:28 am

Feel free, if it sounds interesting. A couple of things I would worry about are the memory taken up by the module's symbol table, and I would avoid using position independent code, as it will cause a speed penalty. Sounds like a tricky job, but the dreamcast elf loader looks quite straightforward.

Tramboi
Posts: 42
Joined: Fri Sep 22, 2006 7:20 pm

Post by Tramboi » Fri Jul 18, 2008 9:16 am

agentq wrote:Feel free, if it sounds interesting. A couple of things I would worry about are the memory taken up by the module's symbol table, and I would avoid using position independent code, as it will cause a speed penalty. Sounds like a tricky job, but the dreamcast elf loader looks quite straightforward.
You have a point with the symbol table size, but we can probably ditch it once the relocation is done.
Merging tcm sections can prove tricky too ^^
All this will greatly depend on the toolchain support, and on documentation about ARM specifics of the elf libs, but at least we can try ( and fail :) ).

agentq
ScummVM Porter
Posts: 806
Joined: Wed Dec 21, 2005 4:29 pm
Location: London, UK

Post by agentq » Sat Jul 19, 2008 10:22 am

We probably can't ditch the symbol table after relocation, because the dlsym() call can be used to retrieve the address of a symbol at any time. We'll just have to make sure that only the necessary symbols are exported. I'm not sure whether the current plugins export everything or not, because the symbol table could easily run to hundreds of Kb with all the string names.

Toolchain support for this is zero as far as I can tell. This will have to be a custom solution. On the other hand, the loader for the Dreamcast's ELF format looks fairly straightforward. I have no idea how linker scripts work though.

I would imagine that arm-specific ELF file layout information should be easy to come by.

Bowen747x
Posts: 47
Joined: Tue Aug 05, 2008 7:13 pm
Location: Ny

Post by Bowen747x » Thu Oct 30, 2008 8:30 am

agentq wrote:It's perfectly possible to launch one program from another, but the problem with this is that it could only work for games which had already been added to the game list by running one of the builds separately, as the game engine needs to be loaded in order to detect it's data files the first time.
if this is possible... why wouldnt we just use the ADD Game function with the first loader and have it auto-detect which build needs to be loaded. Then when we pick the game, the first launcher closes and the game could be run without adding it to the list for the build. If the launcher could auto load the Game for the builder? (But, maybe this cant be done automatically?) im guessing and i know the works not as simple, hell if i could even do it :oops:

and i get why we have seperate builds, to me its no biggie i only use A and D. but i was just reading and figured since agentq says it is possible, why not compress the launcher to ONE app.

Tramboi wrote:I can probably check this next month, if you wish.
wheres this guy at? hes late... :lol:

Tramboi
Posts: 42
Joined: Fri Sep 22, 2006 7:20 pm

Post by Tramboi » Fri Dec 19, 2008 8:20 am

Bowen747x wrote: this next month, if you wish.
wheres this guy at? hes late... :lol:[/quote]

Well the brutal truth is that I tried for a few days... and failed :)
After 50 plugging and unplugging my µSD from PC to DS and back, I gave up :shameonme:

Since a few months I'm overwhelmed by professionnal and personal stuff :(

fingolfin
Retired
Posts: 1466
Joined: Wed Sep 21, 2005 4:12 pm

Post by fingolfin » Fri Dec 19, 2008 3:07 pm

agentq wrote:We probably can't ditch the symbol table after relocation, because the dlsym() call can be used to retrieve the address of a symbol at any time.
Actually, with the ScummVM plugin system, we can guarantee that dlsym is only used a few times during the loading of a plugin, then never again. In fact, you don't even have to implement an dlsym() compatible API. All you need is to provide a subclass of DynamicPlugin (see also the files in backends/plugins/). Granted, you need to implement DynamicPlugin::findSymbol() for that, but this method is only called from DynamicPlugin::loadPlugin() and then never again.

agentq wrote: We'll just have to make sure that only the necessary symbols are exported. I'm not sure whether the current plugins export everything or not, because the symbol table could easily run to hundreds of Kb with all the string names.
ScummVM heavily relies on backlinking. But that just means you have to resolve symbols in the plugins when loading them; after DynamicPlugin::loadPlugin() run, you are free to ditch the complete symbol table.
agentq wrote:Toolchain support for this is zero as far as I can tell. This will have to be a custom solution. On the other hand, the loader for the Dreamcast's ELF format looks fairly straightforward. I have no idea how linker scripts work though.

I would imagine that arm-specific ELF file layout information should be easy to come by.
I don't know much about linker scripts myself, but looking at the DC linker script, it seems pretty much straightforward, too. ARM ELF info is easily available on the net via Google, too.

User avatar
iPwnzorz
Posts: 301
Joined: Sat Jan 06, 2007 3:55 pm
Location: Hampshire, England

Post by iPwnzorz » Fri Dec 19, 2008 3:35 pm

Tramboi wrote:
Bowen747x wrote: this next month, if you wish.
wheres this guy at? hes late... :lol:
Well the brutal truth is that I tried for a few days... and failed :)
After 50 plugging and unplugging my µSD from PC to DS and back, I gave up :shameonme:[/quote]

If you want avoid that there is a piece of homebrew called DSFTP which lets you use the DS as an FTP server. You can transfer files to and from the DS to and from the PC as if it was a normal *NIX server.

Uploads/Downloads can be a bit slow - but I find it takes the frustration out of repeatedly plugging the MicroSD in and out.

Helps when I make R4 Themes... Not the same thing, but same sort of concept.

Tramboi
Posts: 42
Joined: Fri Sep 22, 2006 7:20 pm

Post by Tramboi » Fri Dec 19, 2008 6:59 pm

iPwnzorz wrote:If you want avoid that there is a piece of homebrew called DSFTP which lets you use the DS as an FTP server. You can transfer files to and from the DS to and from the PC as if it was a normal *NIX server.

Uploads/Downloads can be a bit slow - but I find it takes the frustration out of repeatedly plugging the MicroSD in and out.

Helps when I make R4 Themes... Not the same thing, but same sort of concept.
Well I should know I'm the one who coded the UNZIP command for DS-FTP to decrease upload time :)

But ScummVM is too big for this to be practical.

Post Reply