nullDC Now Open-Source

You don't have to allow closed source plugins. A standard GPLv3 license does not permit it. GPLv2 somewhat allowed it, but GPLv3 does not. nullDC is GPLv3, so closed source plugins aren't allowed, since a licensing exception was not added to allow closed source plugins.

 

Shouldn't the priority be cleaning up the pathetic failure of the code base before doing any embellishments? It is a mess after all (for instance, why the fuck would you issue an x86 INT 3 on an exception?).

 

That's the "standard" invoke-the-debugger INT for many development packages.

Perhaps the main argument for no plugins is it forces people to work on the given control/display/whatever code or do something else. Plugins == 100 people working on 100 plugins. No plugins == 5 people working on the same code. This was very evident in DaedalusX64 for the PSP. They picked the plugins that were best (at the time) and moved them directly into the main daedalus code. No plugins at that point. For some odd reason, work on the video progresses MUCH faster than the original plugin the code was derived from. Go fig.

 

I don't have a problem with that. Really I don't. I just think plugins aren't a bad idea and can be advantageous. My only problem right now is that if nullDC became non plugin based, how are you going to make it cross-platform without making the codebase modular?

It's not impossible to make a monolithic cross platform emulator. Heck, the pSX emulator is like that! But you need to have a strategy on how to do it.

 

Not everyone uses IDEs with built-in debuggers you know :P . Its useful for inserting a breakpoint in code from whatever editor you are using. When control reaches there, you can then break into Visual Studio (assuming Windows). So, in that way, you use VS only for good debugging stuff while using your favorite (lightweight) editor for editing/writing source (since VS' editor and its intellisense were made after developers of VS had buttsex with middle aged hairy gay men). I used this trick all the time when I did development on Windows. Basically, makefile+Textpad for building/editing and VS debugger for debugging.

 

Very true. I'm sure they'll hash out something that nobody is satisfied with. :v:

 

Yeah, that's what I'm doing first. Also, you people have to remember: I'm NOT FUCKING COMMITTING THIS TO THE STANDARD CODEBASE. I will make sure any loose ends that could cause bitching like this on a larger scale are cleaned up before I propose merging this with the official svn. God people you are acting like a bunch of kids. On a side note if anybody knows how to do a reliable, cross-platform plugin system, please tell me. (E.g. .so for Linux, .dll for Windows, whateverthefuck for Mac)

 

I don't, but you might want to check PCSX2 and Dolphin emulator projects, they seem to have got it down pat...

 

I wasn't aware emulators couldn't, you know, come with their own plugins. Most emulators developed with plugin systems usually come with their own plugins. These plugins are usually developed by the development teams. A plugin system hasn't stopped Dolphin, for instance, from coming with rather good plugins. Plus, other people have made their own plugins where they thought the originals were bad, at least for Dolphin, which seem to be included with the latest beta releases. Hmm. Not to mention the variety of N64 video plugins for the various emulators - Project 64 and its plugins come to mind, with stuff like Rice Video and its texture replacement support. Either way, I don't think something like that would have happened, or been able to happen, with a "closed" (note the quotes) system.

On a sidenote... I've never actually seen one of those "terrible" plugins you keep talking about when you talk about how bad plugins are. Are you sure they, you know, exist? Let alone used?

 

SDL has some cross platform functions (which are just mainly wrappers) to load dynamic libraries. Qt too has a cross-platform plugin system but that may be an overkill if you aren't using Qt.

 

PSP homebrew doesn't support exporting variables in prx libraries, and most PSP homebrew devs aren't very familiar with doing plugins via prx libs in any case. I did a couple examples on ps2dev for folks to show how to use prx libs as plugins, and variables all have to use accessor functions. So while you COULD do plugins for emulators on the PSP, it's still much easier to not use them.

You don't remember when everyone and their dog had a plugin for ePSXe? There were literally DOZENS of plugins for video, sound, and input, most of which sucked and were closed source. After a few years, a scant few rose to the top of the heap as ones acknowledged to be the best.

 

N64, don't forget the N64.

 

Did I mention how excited I am that people might get around to making a good Dreamcast emulator?

Because I'm so excited.

I just wish I could help, but I'm pretty awful at coding, and emulators confuse the bejeezus outta me.

 

But ePSXe itself is closed source.... So, why complain about closed source plugins for a closed source emulator....?

 

Because other PSX emulators used the ePSXe interface so they could also use the plugins. So it wound up affecting even open source emulations. But it goes back to my original point - if you allow plugins, you usually wind up with lots of people working on their own plugin, while any "official" plugins are ignored. If you don't allow plugins, you don't get nearly as many people helping, but the ones that do are at least working on the same code, advancing it more quickly.

There are other considerations, so I'm not endorsing any position here, especially since I'm working on other things. If the people actually involved wish to use plugins, that's fine with me.

 

I'm sorry; I thought this topic was about nullDC being open source, not nullDC being ported to PSP. Wait, hang on a sec.
Look, while your example about "taking the best plugins and focusing development on them" sounds like a good argument against plugins, the problem is that if Daedalus hadn't supported plugins, those plugins wouldn't have existed. Also, considering how lively the PSP emulation scene is, of course there's going to be more work done on the various parts of the system compared to the work being done on the original stuff.

And no - I wasn't around for ePSXe, but from the looks of things, times have changed.

 

And of course, ePSXe now no longer works in Ubuntu, since they remove GTK+ 1.2 from the repositories...

 

Now THERE'S an argument I can get behind.