It's quite simple, you simply need to use the NASM flags "-O1 -f elf -D __GCC2 -D __OBJ_ELF -g -w-orphan-labels" on BSD systems, you need also to have Linux kernel emulation running for some reason to do the build properly. Gens/GS doesn't seem to mind the modified GCC 4.2.1 compiler included with FreeBSD anyway. EDIT: I tried this with my other PC, I confirm that you need to use sysctl to enable Linux emulation, if you install GNOME it seems to automatically install the headers for GTK etc.
I test-compiled Gens/GS on FreeBSD 7.1 in VMware, and other than some include path problems (which I fixed), it seemed to work fine with Linux emulation disabled. However, this was with the in-development Release 7, not Milestone 6.
I'm getting close to releasing Gens/GS r7. In preparation, I'm starting to document the MDP v1.0.0 specification. The initial documents are available at http://www.soniccenter.org/gerbilsoft/gens/mdp/ . Note that the new HTML documentation is in draft stages, and not everything has been ported from the MDP v0.1 documentation that was included in Gens/GS m6. I would appreciate it if I could get some feedback on the MDP v1.0.0-draft specifications.
I don't know if you've tested Gens/GS m6 in Ubuntu 9.04 however I'm not getting a good resolution while on full screen. In 8.10, full screen would stretch the game to the entire screen while using 9.04 it isn't stretched to fit my resolution. Any way to rectify this? Also, keys are still fucking up while in fullscreen, hitting enter can sometimes go back to windowed. D:
I have a handful of requests. This'll become my standard Genesis emulator if two things can be added... -Add controller mapping for quicksave/quickload. -Add a turbo function, and let it be mapped as well. I spent around 30 minutes trying out the various settings, and this is an AWESOME emulator. I've just got way to used to having those functions, haha.
I noticed that you have fields for the CPU flags supported and required. If you are eventually looking at cross-platform support (say ARM or PPC or MIPS), you may wish to have a CPU type field as well with some predefined values. You'll need to distinguish between x86 and x86-64 for 64 bit support. PPC and MIPS also come in 32 bit or 64 bit varieties. I'm not sure is ARM has a 64 bit variant yet.
There's no need for this, and for a good reason: MDP plugins are binary. A plugin compiled for x86-64 will only work on x86-64 Gens, x86 with x86 Gens, MIPS with MIPS Gens, etc. I will provide different CPU flag defines for other CPUs though, e.g. AltiVec on PowerPC. Thanks. Key remapping for functions like save/load will be added eventually, as well as turbo functions. I'll have to check what changes were made in the Intel GMA drivers in 9.04 to see what broke. I'm guessing that they turned off scaling by default.
A quick Google says it doesn't, but your other architectures are valid enough. 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.
I've heard some bitching about this but not too many specifics. Apparently DRI2 is a clusterfuck for some reason
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.
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. :v:
