Launcher... for the launchers?

[badbob001]

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]

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]

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]

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]

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

[agentq]

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]

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]

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]

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

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.

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

wheres this guy at? hes late...

[Tramboi]

this next month, if you wish.

wheres this guy at? hes late... [/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]

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.

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.

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.

[iPwnzorz]

this next month, if you wish.

wheres this guy at? hes late...

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]

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.