[GerbilSoft]

Overlord, on Apr 24 2009, 03:24 PM, said:

EDIT: OK, Gerbil got in first, so instead I'll ask - why are the plugins binary, because they've been made by other people? That's a pretty annoying restriction if there's no way to make them crossplatform.

No, they're binary because they're compiled :P I meant binary as in "not scripting language". The actual plugin code is open, but the plugins have to be compiled for specific architectures. You can compile a plugin for i386, or for AMD64, or for PowerPC, but you can't run an AMD64 plugin on i386, an i386 plugin on PowerPC, etc.

Most of the plugins in Gens/GS should compile for multiple architectures. Some have optimizations on i386, which are disabled on non-i386 platforms. A few plugins (2xSaI, Super Eagle, Super 2xSaI, hq?x) are i386 asm only, and will not compile on other platforms.

[Chilly Willy]

GerbilSoft, on Apr 25 2009, 05:02 PM, said:

Overlord, on Apr 24 2009, 03:24 PM, said:

EDIT: OK, Gerbil got in first, so instead I'll ask - why are the plugins binary, because they've been made by other people? That's a pretty annoying restriction if there's no way to make them crossplatform.

No, they're binary because they're compiled :P I meant binary as in "not scripting language". The actual plugin code is open, but the plugins have to be compiled for specific architectures. You can compile a plugin for i386, or for AMD64, or for PowerPC, but you can't run an AMD64 plugin on i386, an i386 plugin on PowerPC, etc.

Most of the plugins in Gens/GS should compile for multiple architectures. Some have optimizations on i386, which are disabled on non-i386 platforms. A few plugins (2xSaI, Super Eagle, Super 2xSaI, hq?x) are i386 asm only, and will not compile on other platforms.

Well, you couldn't load a Windows plugin on linux because of the difference in structure, but say you have a plugin compiled for linux - the structure would be the same for all brands of linux, including different CPUs. Linux on ARM is the same as linux on MIPS is the same as linux on PPC is the same as linux on x86. The difference is the binary object code generated for the specific CPU. Everything else would be the same... unless you use a ELF format file to wrap the plugin. Then you can look at the CPU field in the ELF header.

[GerbilSoft]

Chilly Willy, on Apr 26 2009, 12:24 AM, said:

GerbilSoft, on Apr 25 2009, 05:02 PM, said:

Overlord, on Apr 24 2009, 03:24 PM, said:

EDIT: OK, Gerbil got in first, so instead I'll ask - why are the plugins binary, because they've been made by other people? That's a pretty annoying restriction if there's no way to make them crossplatform.

No, they're binary because they're compiled :P I meant binary as in "not scripting language". The actual plugin code is open, but the plugins have to be compiled for specific architectures. You can compile a plugin for i386, or for AMD64, or for PowerPC, but you can't run an AMD64 plugin on i386, an i386 plugin on PowerPC, etc.

Most of the plugins in Gens/GS should compile for multiple architectures. Some have optimizations on i386, which are disabled on non-i386 platforms. A few plugins (2xSaI, Super Eagle, Super 2xSaI, hq?x) are i386 asm only, and will not compile on other platforms.

Well, you couldn't load a Windows plugin on linux because of the difference in structure, but say you have a plugin compiled for linux - the structure would be the same for all brands of linux, including different CPUs. Linux on ARM is the same as linux on MIPS is the same as linux on PPC is the same as linux on x86. The difference is the binary object code generated for the specific CPU. Everything else would be the same... unless you use a ELF format file to wrap the plugin. Then you can look at the CPU field in the ELF header.

Yeah, I kinda don't want to write my own dynamic loader. Gens/GS uses dlopen() to load plugins on Linux. If the plugin was compiled for a different CPU, dlopen() will simply return an error.

[Chilly Willy]

GerbilSoft, on Apr 25 2009, 10:26 PM, said:

Yeah, I kinda don't want to write my own dynamic loader. Gens/GS uses dlopen() to load plugins on Linux. If the plugin was compiled for a different CPU, dlopen() will simply return an error.

That makes more sense then. From the description, it sounded like a custom binary object. That certainly makes things easier on linux, as you mention. So as long as the dev avoids assembly (or includes different assembly for each supported cpu), they SHOULD be able to compile their plugin for nearly any linux system. I'm sure the Pandora folks will be happy to hear that. I'm sure they're watching Gens/GS closely for their own SEGA needs.