Short answer, no. Just because something is done in a DLL does not make it automatically better. In Byond, this is especially true, as the DLL support only allows for C functions which take text strings as arguments and which return text strings, so you must convert back and forth inside the DLL.

In reality, whether or not it runs faster depends on what you are doing, but whether or not it runs faster is not always important. The reason you are using Byond is because it is easy to use. The reason DLL support was added to Byond was to make it so that you can add your own functionality to Byond which is not already there (on the server side). This is what your main use of DLLs should be, and obviously using them for what they were intended makes them "worth it" since it's sometimes the only way to do what you want.

That said (especially the part about Byond's purpose for being used is that it is easy to use), if you can do some specific thing easier in C or in C++ (rarely going to happen, but it is possible), then obviously go ahead and use a DLL, or if you have a part of your project which is really being a bottleneck on your resources to the point where speed is noticeably impacted and you could easily use a DLL to find a way to make it a lot faster, then go ahead.

Converting a large portion of your procedures for DLL use would not be worth any possible speed gain, and it might not even be faster at all. So the basic answer to your question is "No, it is not worth it to convert most of your project into C or C++."

Then your question also begs a question in response: If you are considering writing most of your game in C++, why not do that, then go the extra half mile and do your own networking and graphics so you end up with your own standalone executable that doesn't need Byond? If you are already willing to put the effort into doing most of it in C++, and if you already know C++ well enough that this is a feasible option, it isn't much of a stretch to do the entire thing completely in C++, especially if you don't need any GUI widgets. This would be more satisfying than doing a bunch of it in C++ for use in Byond.

Thanks for the good example; I couldn't think of any good examples of things that actually are easier in C++ and so I left that part poorly explained.

I just thought of another example too. You could access external applications, such as MySQL, easier with C++ instead of doing hacky stuff with using PHP via Byond's browser support, or however the heck people are using MySQL with Byond these days.

Also, anything you use shell for could probably be done at least as easily in C, if not easier. C has very good support for that, since you could combine that with OS system calls, which are extremely easy for Windows in C just by including windows.h

Another good example would be to generate large, complex images that BYOND can't handle very well. I remember seeing someone do that a few years ago.

In the general case, no. You can't easily access the majority of the game's context (player mobs, where is this object on the map etc), needing to push that data via the DLL's interface in string form.

The main consequence of this is the need to form a string on DM's side to represent the object, make the call, deconstruct it on the DLL's side, then back again to return. This is obviously costly in time, for trivial tasks.

Further to that, seen as you can't access a lot of BYOND's functionality directly, there are some tasks which are impossible for a DLL to even attempt to speed up, for example path-finding (you can't look at the current running map, how are you going to plot a route?). Fortunately you are not undone, as chances are you can do some pretty significant optimisations in DM by altering your design to better suit that the problem actually is, not what you first thought it was.

As for memory, that really depends on you as a programmer. Frankly I don't consider this a worthy consideration with BYOND though, you've chosen to use a VMed language, aside from ridiculously excessive resource creation (hey everyone, have a load of runtime generated ... everything), memory isn't your big concern. If it was, you'd have picked another language.

I just did a forum search for MySQL to see how people are doing it now. I did not see anyone discussing how they are going about it, but I found a link to a MySQL library. Searching the library section I find 2 such libraries, both of which seem to leverage Dantom.DB, but doing a search for that offers up nothing, and searching my hard drive shows that it is not built in (at least not as a separate but prepackaged library).

Loduwijk wrote:

which seem to leverage Dantom.DB, but doing a search for that offers up nothing, and searching my hard drive shows that it is not built in (at least not as a separate but prepackaged library).

It's here: http://www.byond.com/hub/dantom/db

IIRC, the search systems ignore terms with fewer than 3 characters.

This is a concern we had at work recently. While we were not redistributing the MySQL client library ourselves, we were definitely using it, thus meaning we'd fallen into one of two choices:

1. Comply with the terms of GPLv2 or use Oracle's FOSS licencing exception.
2. Enter into a commercial licence with Oracle.

We chose the latter. It was deemed that simply not providing the library didn't get around GPLv2's concept of redistribution, as we still had their linker symbols etc.

I don't think so, as your work isn't touching their code directly. Similarly with the FOSS route, you'd follow the decisions taken on OpenJDK or GCC, the target output (DMB in this case, which is just a complex data file for BYOND) is separate to the platform itself.

No, but PHP itself did buy a license. I don't think it was an issue way back when MySQL was first hooked into. Now it's probably an issue and I honestly don't see MySQL support being important enough to spend money on it (on BYOND's end). Perhaps it is best to just leave it up to the game developers to find a way to provide their own MySQL support.

That's what I figured, thanks.



Still, it seems BYOND has a problem on its hands? Either remove MySQL support, pay for a commercial license, or go open source?

Plus, then they can stop using the excuse that they can't include a real Regex library because they're all GPL'd.