Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Josh @ Dreamland

Announcements / Licensing, the ultimatum
« on: May 31, 2014, 11:45:32 AM »
I'm going to attempt once more to contact a third party for help with this licensing fiasco. I'm going to give everyone an opportunity to weigh in on what I'm sending before I send it; this is our official request for help.

I have sent a very similar letter to this one in the past, but I fear it did not adequately convey our issue, based on the response I received. Here is the text that will be sent this time:


I am writing on behalf of all contributing members of the ENIGMA Development Environment ( , We maintain a free-software game development platform designed to simplify creation of various games while offering sufficient features to create games of any size.

Heretofore, all of the code in our project, including that in the game engine, has been GPL-licensed. Now, while our developer base is still relatively small, we are discussing a means by which our users could have more license freedom in the games they create. As our tools not only link against the GPL game engine code we provide, but in fact integrate segments of GPL code into their game code directly, all of our users are presently bound by the terms of the GPL, and so cannot release a closed-source version of their games.

What our team is looking for is a means of allowing our users to close-source their games in a way that no contributors biding by our license can take legal action against them, but to ensure that in all other cases, linking against our code causes the resulting module to use our license.

What we do not want is to become the next WINE vs CrossOver Office; that is, we do not want someone to exploit our license to maintain a closed-source version of our engine with exceptional improvements. If someone improves our engine, we want to be able to pull in those improvements, or at very least see how they did it and mimic.

The mantra of this operation is "Prohibit ENIGMA forks which prohibit ENIGMA forks." This "prohibiting" is supposed to be done by enforcing the full terms of the GNU General Public License. In short, we want the terms of the GPL to apply, but to allow users to choose their own license for their own games created in the engine.

The immediately obvious answer to our problem is to select a license such as the Mozilla Public License, which seems to allow just that. The issue is, this license would allow a third party to extend ENIGMA using their own proprietary code, which could then draw users away from ENIGMA, and get them hooked on these closed-source additions. We therefore want extensions to ENIGMA itself to be covered by this license/exception or by plain GPL, to ensure it remains free for everyone.

The crux of the problem is that the only time we do not want the GPL to apply is when a user actually releases a game made in this engine.

That said, which license/exceptions could we use? Would there be merit in a custom exception?

Thanks much,
Josh Ventura

If this request fails, I will embrace the MPL or a similar license for the sake of forward progress.

Programming Help / Re: Instance Creation Codes
« on: May 18, 2014, 09:35:23 AM »
That's actually something we should probably run checking for, even outside debug mode. A null check after that lookup is basically free, and malformed strings happen all the time.

Anyway, no problem.

Issues Help Desk / Re: game end event does not work !
« on: May 18, 2014, 09:32:44 AM »
If the game end events are performed during the call in GM, our answer's pretty obvious. But that'd mean that calling game_end in the game end event is yet another caveat.

Not that we've had something like that before. *cough* screen_redraw *cough*

Issues Help Desk / Re: game end event does not work !
« on: May 17, 2014, 01:07:15 PM »
All that has to happen for that is someone iterating over the instances, calling myevent_game_end, after the WinMain loop finishes.

Issues Help Desk / Re: game end event does not work !
« on: May 17, 2014, 12:26:09 PM »
Then I'm amazed at how we could possibly have a problem, here. :P

It's much easier to remember that FACE_LEFT is the constant given to facing left than it is to remember 0 means the same. What he's doing is correct; it just seems ENIGMA isn't incorporating the constants from LGM correctly.

You can add them to definitions, if you're feeling so inclined, as a temporary fix. ENIGMA Settings -> Definitions; then just declare your constants as const int or enum.

Code: (C++) [Select]
enum {

Programming Help / Re: Enumerations are not working
« on: May 17, 2014, 11:42:46 AM »
Those aren't supported in the current EDL spec. They are planned for the future.

You can include them in definitions, presently, under ENIGMA settings.

Issues Help Desk / Re: game end event does not work !
« on: May 17, 2014, 11:41:10 AM »
If game_end() is just calling abort(), or exit(0), we have a problem. It should be posting WM_QUIT, which will allow control to reach the end of WinMain.

General ENIGMA / Re: Variable performance
« on: May 17, 2014, 11:37:38 AM »
Variant is scalar (unless you count the fact that string is an array itself). Var uses some memory magic to throw together a Lua table. Construction time is pretty horrifying, but it has a good use time.

Those global assign times are horrifying. I'm not sure how to deal with those, but since they are literally worse than assigning instance variables, I do have one obvious solution. :P

Don't get me wrong; the with assign times are abysmal, but those can stand for some obvious improvement.

Issues Help Desk / Re: Full Screen bug? and help
« on: May 17, 2014, 11:02:20 AM »
You can edit views live using the existing arrays. I've gone and documented them for you, here.

Issues Help Desk / Re: Networking, Stability and Learning path
« on: May 17, 2014, 09:23:50 AM »
ENIGMA uses Berkeley sockets for its networking. Its library has extremely little field testing; it works, as far as we know. Interest in creating online games here is extremely limited, as most people here lack the resources to test such a game effectively.

The socket library is low-level enough that if you are willing to invest the time required to learn how to use it, you are able to do anything you see done in professional online games. The technology is simple and mostly unchanging.

We have our own wiki, but my favorite resource, if you are brand new to GM, was an old CHM written by Mark Overmars. Yoyo has probably gotten rid of it, I'm afraid.

Our Android support is unmaintained, and has been totally dead (as far as we can tell) for a long time. Enough interest will probably eventually arise to rekindle it.

Issues Help Desk / Re: game end event does not work !
« on: May 17, 2014, 09:16:31 AM »
I never liked how Windows handles screen resolution changes. Any game can change your display to any size, regardless of whether your monitor even reports support for it. Then Windows doesn't take responsibility for restoring it when, say, the game ends or crashes. Anything we do to restore the resolution is just going to fail in certain cases. Really, our only good way of handling it is to throw a global in to keep track of the original display size, throw a global boolean in to denote whether the resolution was changed (and should be restored to this), and then have the display_set_size function do this:

Code: (C++) [Select]
if (!display_size_changed) {
  display_size_set = true;
  display_original_width = display_get_width();
  display_original_height = display_get_width();

Then at the end of WinMain, if (display_size_changed) display_set_size(display_original_width, display_original_height);.

I would ask a Windows maintainer to do this, as I can't test if I make this change.

Programming Help / Re: Instance Creation Codes
« on: May 17, 2014, 09:09:03 AM »
So, Robert recently edited the draw_string function. It wouldn't surprise me if it crashes your game when passed an empty string or an uninitialized variable. Could you verify this by drawing string(string_length(text))? That will at least tell us what's going on.

Another item to consider is the fact that your string contains a "²" character. Did you modify your font to contain this glyph? Does it crash in debug mode? What happens if you remove this glyph?

General ENIGMA / Re: Variable performance
« on: May 17, 2014, 08:41:27 AM »
I'm glad we actually have a benchmarking tool. This can be fixed with a little reflection, and depending on the user's mood, a little memory. Throughout ENIGMA's past, I've hemmed and hawed about how to treat variables referenced in with blocks. The current behavior is to look them up in the same manner as ID-referenced variables. The other behavior was to scope them into everything, so they exist and are located in the same place in every object, and therefore are trivial to access.

A third behavior I have not attempted is using virtual tables to store the variable access methods. This would make arbitraryId.myvariable into getter(arbitraryId)->get_myvariable(). This moves the burden from a switch statement based on object index to a simple virtual call. We're probably already incurring a by-pointer function call, so this could only mean savings.

The simplest way to take care of the whole "var" fiasco is with some static analysis of the code. This cannot be done with the current compiler.

Note: the behavior you are seeing, ie, GM being faster at setting a single var index, is due to the fact that GM's variables are always a map. So nothing special is constructed when you need to assign to a var. It's not that assigning to a var is expensive—constructing one is. There might be a way to improve that by enforcing a single var implementation, and moving the contents of var4_lua.cpp into var4.cpp. This would remove the need to do the allocation tricks I've done, and expose all code to the optimizer. Another quick trick might be replacing std::map with a faster map type; you could try hash_map.

Please do a benchmark with variant instead of var.

General ENIGMA / Re: EDC Partially Fixed
« on: May 12, 2014, 09:47:06 PM »
We weren't hacked; someone just decided that a good item to display on failure is "ಠ_ಠ". This was RackSpace side, which was funny. That's the only reason it was worth remarking on.

The only issue with the EDC was in how we retrieve our API URLs from the Service Catalog we are given along with our auth token. The problem was that we were just taking the first service in the catalog. That *used* to be the only service listed, but now we're given a catalog of some 25 other services, and we wanted the 14th in the list, called "CloudFiles". So now I just filter for that string. RackSpace actually recommends just hard-coding the URLs, though, so we'll probably switch to that in the near future (or next time this breaks).