Oct 15 2010, 12:44 pm
In response to Airjoe
|
|
Nadrew
  |
The only real option there is removing MySQL support.
|
Nadrew wrote:
The only real option there is removing MySQL support. Right, because going open source would lead to such a downturn in profits! | |
Right, because going open source would lead to such a downturn in profits! I believe they're afraid of people making many changes to the engine, and releasing it closed-source as their own creation. | |
OrangeWeapons wrote:
I believe they're afraid of people making many changes to the engine, and releasing it closed-source as their own creation. Unique viewpoint you got there. Anywho, I think the best hope of anything resembling 'open source' for BYOND would be to have some sort of way to mod aesthetic properties of BYOND, like the interface controls, using something like python. But that isn't really related to the topic of this thread. Long story short: yes, it's worthwhile to use DLL files to provide features BYOND currently doesn't have. | |
The support ramifications of forking BYOND is huge, and were BYOND GPL, said forked project would be breaking licence by being closed source as well as being a nightmare to maintain. It's not a risk, nor is it the main blocker on going open source with BYOND code.
| |
DivineTraveller wrote:
From my limited point of view, "the source is too messy." There is a lot more work involved in going "open source" than simply uploading a zip file. (BYOND games themselves, of course, notwithstanding) But back on topic, DLLs are useful for certain intensive operations. As Stephen pointed out, the overhead involved in transmitting any data back and forth makes any brief operations impractical. For particular uses, image generation comes to mind. I switched over to using a DLL for generating light maps, and the generation time dropped from 3 minutes to about 20 seconds. That's almost a palatable wait time for a single-player game! | |
brief operations impractical. What operations and overhead are we talking about? I remember someone ran a number of tests over a .dll version of Deadron's text_handling, and the results were a significant speed increase. | |
Toadfish wrote:
brief operations impractical. I was thinking anything non-text, oddly enough, as it would have to be encoded before being transferred to the DLL, and then the return value decoded. I haven't run any benchmarks, however, so I won't comment on what point the increased speed of execution in a DLL outweighs the overhead of this translation (and whatever overhead is involved in the DLL call itself). Has anyone had any experience with making calls to a DLL every single frame, or more often? Did you notice any performance issues? | |
Well, "anything non-text" is a vague category. There can be different levels of complexity involved in parsing the string (compare a calculation vs. sorting problem vs. something-more-difficult-to-parse). And of course, you can't directly create objects using a .dll. And you might also not need to parse the string immediately after calling the .dll (for example, you might want to store a lot of sorted arrays but only parse them for certain events). So determining what exactly this overhead is is not trivial. But it's probably safe to assume .dlls are significantly faster for most things not involving more than simple parsing and string conversion, that aren't completely elementary... which in retrospect is what you meant. ;p
| |