#159008 - thegamefreak0134 - Tue Jun 24, 2008 9:03 am
There are a lot of features that I want to add to my Image Editing program that I'm working on. One of those is the ability to add tools and filters using a plugin system. The trouble is, I've never tried anything of the sort, and I'm a bit stuck on where to begin.
Ideally, plugins would be stored as a single file on the SD card. They would be loaded by the program to a specified address when run, and thus the start of the plugin would contain pointers to the three or four standard functions that would be used to make the plugin tick. (I'm thinking something along the lines of an Init() Refresh() Finalize() system)
The trouble is, I'm not sure how to achieve this with code. The simplest way I can think of would be to tell the compiler to start the code at a specified location, with the elements defined in a set order, but I've only ever seen this done in assembly, and I'm not sure how to do it in C++.
My other thought was a DLL approach, but if my knowledge is anywhere near correct, that's something only a windows machine is capable of? Or is it platform independent?
If I can get something going that will allow me to load code from the SD card and run it, I can go with that and work out a plugin specification for the thing. I know it's possible, as other homebrew has used a similar approach, I'm just not sure at all how its done.
I apologize for my general lack of understanding on the subject. Thanks for any info you have, ^_^
-gamefreak
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#159010 - Maxxie - Tue Jun 24, 2008 9:36 am
I am using some kind of dynamical loaded code for the level logic in my not yet ready project.
I did it in a way like the DLDI and declared a non existant memory section so i can scan for this address word and replace it for the code beeing relocateable. The plan is to extend this by creating another copy of the code with a different address to ensure by comparing that the found word is really an address rather then some rare instruction.
I have created a different crt0 that contains two pointers to function tables (one at base+0, the other at base+4). One is filled on loading (with the functions the host program exports, like malloc,free etc) and one by the client containing "onInit", "onVBlank" etc.
The tables are arrays of a struct with the function name, and the function base address. The last entry is filled with NULL,NULL to mark the end.
To call such a function is then alike windows DLL loading in runtime via
LoadModule() & GetProcAddress()
#159018 - kusma - Tue Jun 24, 2008 11:22 am
| thegamefreak0134 wrote: |
| There are a lot of features that I want to add to my Image Editing program that I'm working on. One of those is the ability to add tools and filters using a plugin system. The trouble is, I've never tried anything of the sort, and I'm a bit stuck on where to begin. |
As far as I know, there's no publically available code to do anything DLL-alike. The closest that springs to mind, is Mighty Max's kernel-hack (from the "Building an OS"-thread) but it only relocates the code, there's no linking IIRC. Writing a run-time linker for the DS could be a fun task in theory, but I fear it would end up being a link-script nightmare ;)
Instead, I'd ask myself what the real use for a plug-in system is. How does it make your application more usefull? Are you afraid you've missed important features that people could develop for themselves? If so - release the source code, and the problem is solved without any technical hassle!
Another approach could be to write the plug-ins in some kind of a scripting-language that is interpreted on the host. I know Python has been ported to the DS, but it might be a bit big for your taste. Then again, any application being complex enough to require a plug-in system is probably so big that the interpreter-overhead is neglectable.
#159024 - silent_code - Tue Jun 24, 2008 12:48 pm
I though the (publicly available, open source) NDS Linux port had support for dynamically loaded libraries? ;^D
Overlays might be a bit less involved and would probably be sufficient. Give it a try.
EDIT: Or maybe you would like to port something like glib to the NDS?
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#159042 - tepples - Tue Jun 24, 2008 8:17 pm
| kusma wrote: |
| Instead, I'd ask myself what the real use for a plug-in system is. How does it make your application more usefull? Are you afraid you've missed important features that people could develop for themselves? If so - release the source code, and the problem is solved without any technical hassle! |
But once the developer adds all features that have been submitted as patches, the code + data might end up exceeding 4 MB. At that point, the program needs to use an overlay, and that's the same principle as a DLL.
| Quote: |
| Another approach could be to write the plug-ins in some kind of a scripting-language that is interpreted on the host. I know Python has been ported to the DS, but it might be a bit big for your taste. Then again, any application being complex enough to require a plug-in system is probably so big that the interpreter-overhead is neglectable. |
It's for an image editor. Image editor plug-ins perform digital signal processing. Interpreter overhead isn't negligible in DSP software that needs to run an inner loop for each pixel.
My suggestion: Try to write a parser for the ELF object file format. It's a relocatable format that devkitARM can already be coaxed into generating. Even if you don't end up actually using ELF, you will still understand the issues behind loading code.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#159045 - kusma - Tue Jun 24, 2008 9:14 pm
| tepples wrote: |
But once the developer adds all features that have been submitted as patches, the code + data might end up exceeding 4 MB. At that point, the program needs to use an overlay, and that's the same principle as a DLL.
|
Sure, but 4MB of code sure is a lot. An overlay might help if he's actually struggling with code-size, yeah. I just got the impression from the way he asked that he considered it a nice-to-have feature, and looked for simple solutions.
| tepples wrote: |
It's for an image editor. Image editor plug-ins perform digital signal processing. Interpreter overhead isn't negligible in DSP software that needs to run an inner loop for each pixel.
|
Wow, that's what I call prematurely disqualifying a suggestion. I've personally written image editors with high performance requirements that were scriptable, and it worked out just fine. You do it by giving the scripter high-level functionality that can be used together to perform more specific operations. Like a function to copy a picture, apply a box-filter to a picture, paint a circle at a given position etc. Those functions could be implemented as a part of the image programs internal API. And if the developer wants to do his own pixel-manipulation, you allow him to do that even though it's slow.
#159144 - thegamefreak0134 - Thu Jun 26, 2008 4:39 am
Actually, pixel manipulation would work normally if I was able to do C(++) code for my plugins. I plan on passing a pointer to the pcx_file type, which would allow them do, if desired, directly manipulate the image data. Of course, the built in getPixel/setPixel functions (which work for colors or indexes, depending on the mode) are a lot safer, but still, this gives them something.
OK, so I guess here's my real question. Is there (A) a way to tell the compiler to start the memory for a chunk of code at a certain memory address? (similar to .org in most aseemblers) If I can do that, I can simply require that they declare a const struct at the start with pointers to everything else.
If not, is there a way, given a pointer to the function, to copy that function over to a given memory address, and rewrite it to run from that position? Or possibly simple compile the function in the first place so that it can run from any memory location, given pointers to routines such as malloc?
I think if I can get something going like that, then I can work from there. I'll learn both the .o anf .elf file formats, and see which one will work better for this project on my own. I'm just not sure how to get the silly thing to compile in a predictible way. ^_^
Thanks for the answers so far. Oh, and I don't think an interpreter is a good idea at all. Seems way too slow, and I don't really want to try to implement a scripting language, as that's a but beyond the scope of this project. It's just an image editor, after all. ^_^
And don't worry. If it can't do plugins, the world isn't going to end. It would just be a nice feature.
-gamefreak
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#159158 - silent_code - Thu Jun 26, 2008 10:56 am
Have you looked at DSOrganize's "plug in" architecture?
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.
#159301 - thegamefreak0134 - Sat Jun 28, 2008 10:52 pm
Well, DragonMinded promptly removed support from it, and then dropped all methods of contact entirely, so I can't really ask him about it. Something like that is probably what I had in mind though. Does anyone have any info about how it worked?
-gamefreak
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#159302 - silent_code - Sat Jun 28, 2008 11:22 pm
I can still see old version (builds) listed there, but aren't the sources available, too? ... and what is the problem with contacting him, anyway?
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.