Post by neko68k on Aug 23, 2006 23:14:26 GMT 1
would it be with the consolodation of code in LJR, presumably to reduce code duplication, to make it autodetect installed zem's and populate forms with options programatically. For instance, ljp-gen.zem could say, I need the defaults(resolution, fskip, etc) and additionally need asm/c option and then let LJR handle form construction for you.
I guess I'm just considering a plugin or driver architecture. Code an emu, drop it into the framework.
Or for example, to only display forms for drivers that are installed, so if ljp-snes.zem and ljp-gen.zem were installed, don't allow access to other forms. In other words, only GENS and SNES would apper in the drop down list.
I looked at the source for TCPMP a bit ago and it has a routine to scan for drivers on the SD card by checking their creator and app id's to decide whether they're drivers or not and load them accordingly. I dunno if ARMlets contain this sort of information, I guess I would assume they do but in TCPMP they're also wrapped in pdb's.
If not, you could maybe include a config file in the .zem file that indicates to the launcher that its for LJP and not something else like MetaViews Z* ports. Even an empty file thats called "this_is_a_ljp_driver" would be sufficient.
Then you wouldn't even need to release new versions of the launcher unless you had to or wanted to, just update the drivers or simply add new ones and *poof* new emulator in the lineup or emulation bug fixed and we didn't break the launcher.
I actually don't think I've seen this done anywhere in the emulation world. It could be compared to plugins for psx emu's or winamp.
I guess I'm just considering a plugin or driver architecture. Code an emu, drop it into the framework.
Or for example, to only display forms for drivers that are installed, so if ljp-snes.zem and ljp-gen.zem were installed, don't allow access to other forms. In other words, only GENS and SNES would apper in the drop down list.
I looked at the source for TCPMP a bit ago and it has a routine to scan for drivers on the SD card by checking their creator and app id's to decide whether they're drivers or not and load them accordingly. I dunno if ARMlets contain this sort of information, I guess I would assume they do but in TCPMP they're also wrapped in pdb's.
If not, you could maybe include a config file in the .zem file that indicates to the launcher that its for LJP and not something else like MetaViews Z* ports. Even an empty file thats called "this_is_a_ljp_driver" would be sufficient.
Then you wouldn't even need to release new versions of the launcher unless you had to or wanted to, just update the drivers or simply add new ones and *poof* new emulator in the lineup or emulation bug fixed and we didn't break the launcher.
I actually don't think I've seen this done anywhere in the emulation world. It could be compared to plugins for psx emu's or winamp.
-It could be compared to what's done in MESS I think, or in Richard Bannister's emulators for the Macintosh. However, MESS just hides the drivers that aren't needed (they're still statically linked) and Bannister's stuff is multiple apps linked to a central controlling library. If the launcher could be designed in such a way as to populate itself based on information from the modules, that'd be great! --I might even port a module or two.