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.
16
Developing ENIGMA / JDI NewTemplates branch
« on: February 19, 2014, 10:51:53 am »
Hi people,
I'm going to stop playing with blocks today and try to get this last JDI error fixed, at which point ENIGMA's engine will parse without error on Linux. I was going to boot up Windows and test it, but then I realized I don't feel like doing that at all. Plus, if I have people do this, I can test on multiple systems.
I'm going to assume that the preprocessor works without error, and so for the purpose of cross-platform testing, supplement GCC's. What I need from you is to do the following:
1. Open a terminal.
2. cd to your ENIGMA folder.
3. [snip]cd ENIGMAsystem/SHELL[/snip]
3. [snip]g++ -E SHELLmain.cpp <YOUR COMMAND LINE BUILD PARAMETERS, AS PRINTED IN LGM> -o preprocessed.cpp[/snip]
4. Upload preprocessed.cpp here as an attachment, or to dropbox, or if it's small enough (which is unlikely considering you people won't stop including STL headers from main), pastebin it.
5. Link me if necessary.
This will allow me to test JDI on arbitrary machines without booting or having access to any of them. The only thing that won't be tested this way is the preprocessor, which, as I said, should be working fine.
When this is done I'm going to go ahead and merge NewTemplates into master, at which point I will recommend integration into ENIGMA, but I will not advocate it or otherwise facilitate it, as it means writing the new compiler around it can finally happen.
I am particularly looking for a Windows dump, but any platform is welcome—the more, the merrier.
Cheers
I'm going to stop playing with blocks today and try to get this last JDI error fixed, at which point ENIGMA's engine will parse without error on Linux. I was going to boot up Windows and test it, but then I realized I don't feel like doing that at all. Plus, if I have people do this, I can test on multiple systems.
I'm going to assume that the preprocessor works without error, and so for the purpose of cross-platform testing, supplement GCC's. What I need from you is to do the following:
1. Open a terminal.
2. cd to your ENIGMA folder.
3. [snip]cd ENIGMAsystem/SHELL[/snip]
3. [snip]g++ -E SHELLmain.cpp <YOUR COMMAND LINE BUILD PARAMETERS, AS PRINTED IN LGM> -o preprocessed.cpp[/snip]
4. Upload preprocessed.cpp here as an attachment, or to dropbox, or if it's small enough (which is unlikely considering you people won't stop including STL headers from main), pastebin it.
5. Link me if necessary.
This will allow me to test JDI on arbitrary machines without booting or having access to any of them. The only thing that won't be tested this way is the preprocessor, which, as I said, should be working fine.
When this is done I'm going to go ahead and merge NewTemplates into master, at which point I will recommend integration into ENIGMA, but I will not advocate it or otherwise facilitate it, as it means writing the new compiler around it can finally happen.
I am particularly looking for a Windows dump, but any platform is welcome—the more, the merrier.
Cheers
17
General ENIGMA / HTML5 based IDE
« on: January 20, 2014, 12:26:29 pm »
I've never interfaced node.js with anything, personally (though I have linked V8 with things). It would be ideal to interface ENIGMA with it as a shared library, as it makes syntax checking faster and allows the compiler to keep relevant information in memory. A JavaScript IDE does exhibit a lot of promise—as I mentioned, there are already great code editing and image editing tools available in HTML5. I suppose the ENIGMA/node interface could be put off until the IDE actually worked, but I wouldn't run with this idea without involving some C++ code.
That said, your new biggest concern is speed. That code editor can get laggy on single big files. People will want to have multiple code files open at any given time... it can get messy. It's too bad there's no <html:use> similar to <svg:use>; another big emerging topic is the ability to have the same file open in multiple windows/tabs, and edit it concurrently. That tag is perfect for such occasions.
At this juncture, it might be best to split this topic. The requirements and ideals of this IDE project are larger than the entire rest of the contest; it should probably get its own thread.
That said, your new biggest concern is speed. That code editor can get laggy on single big files. People will want to have multiple code files open at any given time... it can get messy. It's too bad there's no <html:use> similar to <svg:use>; another big emerging topic is the ability to have the same file open in multiple windows/tabs, and edit it concurrently. That tag is perfect for such occasions.
At this juncture, it might be best to split this topic. The requirements and ideals of this IDE project are larger than the entire rest of the contest; it should probably get its own thread.
18
General ENIGMA / Linking Exception Draft
« on: January 19, 2014, 06:29:05 pm »
A recent troll brought up that we still haven't taken care of this, so it's about time we do so. This is the first draft of the linking exception I expect us to start incorporating into the engine.
DO NOT include this in anything right now. It is not only a bad idea for you to do so, it is probably illegal for you to do so.
The purpose of this topic is to discuss the terms of the license before I ask third parties who know more about this than I do to review the exception and provide more professional feedback.
DO NOT include this in anything right now. It is not only a bad idea for you to do so, it is probably illegal for you to do so.
The purpose of this topic is to discuss the terms of the license before I ask third parties who know more about this than I do to review the exception and provide more professional feedback.
Quote
The ENIGMA Linking Exception
Preamble
The purpose of this exception is to allow the ENIGMA project to maintain the
freedoms ensured by the GNU General Public License while granting users the
additional freedom of choosing a separate license for their own code.
This exception does not grant the ability to relicense the code in this
engine, except by optionally removing this exception, leaving the standard
GNU General Public License enforced.
This exception is wordy, but is meant to remove the threat of tactics such
as Embrace, Extend, Extinguish. The point of this exception is to encourage
Embracement and Extension, but in a way that keeps the extensions free and
so eliminates the threat of extinguishment.
This exception, in essence, grants users the ability to use the engine, but
not to modify it or extend it in a nontrivial manner without remaining free.
Terms
"GPL" refers to the GNU General Public License, as published by the Free
Software Foundation, version 3, or any later version.
"GPL Code" refers to code covered by the GPL.
"Non-GPL Code" refers to code not covered by the GPL.
Exception Text
Linking this library statically or dynamically with other modules is making
a combined work based on this library. Thus, the terms and conditions of the
GNU General Public License cover the whole combination.
As a special exception, the copyright holders of this library give You the
additional right to link the unmodified code of this Program with code not
covered under the GNU General Public License ("Non-GPL Code") and to
distribute linked combinations including the two, subject to the following
limitations:
1. Non-GPL Code permitted under this exception must only link to the
UNMODIFIED code of this Program through those well-defined interfaces
identified as "Approved Interfaces".
2. You are not required to advertise publicly your use of the UNMODIFIED
ENIGMA engine. However, if source code is requested, you must provide
some means of obtaining the original ENIGMA source code covered by this
exception. You may not deny the use of ENIGMA nor withold the version
number used. Note, again, that this license does not and cannot grant
your ability to withold your use of other GPL Code.
3. Non-GPL Code permitted under this exception may link to MODIFIED code
from this program through those well-defined interfaces identified as
"Approved Interfaces", provided that the modified code retain both the
original license AND this exception, without modification, and that at
least one of the following criteria are met:
i. Every copy of the combined work is accompanied by a written
statement that details to the recipient the version of ENIGMA
used and an offer by yourself to provide the ENIGMA source code
should the recipient request it.
ii. Details of your modifications and all code are made available
for integration with the code released by the copyright holders,
publicly or otherwise.
4. The combined work is not itself a general purpose game framework, game
engine, or related product. In such a case, this exception does not
apply and may not be preserved: all code is to be considered GPL.
5. The combined work is not itself a binary library intended for linking
into other software applications. In such a case, this exception does
not apply and may not be preserved: all code is to be considered GPL.
Approved Interfaces
Subject to the limitations from the previous section,
1. The files of Non-GPL Code may include the ENIGMA distribution header files
which explicitly grant this exception in their license.
2. The files of Non-GPL Code may link to the ENIGMA distribution source files
which explicitly grant this exception, provided the following criteria are
ALL met:
i. Code not included with the UNMODIFIED ENIGMA distribution must access
only data included within the unmodified ENIGMA distribution which are
contained in the namespace "enigma_user" in order to be covered by
this exception.
ii. Code not included with the UNMODIFIED ENIGMA distribution may not
include fixes for bugs or misbehaviors in the engine, except where
these changes are considered as modifications to the original source
and are subject accordingly to all terms of this exception (ie, where
this license and exception are upheld in the new code, and the new code
complies fully with this exception).
iii. The files of GPL Code covered by this exception, modified or otherwise,
MAY NOT link to Non-GPL Code. That is, even if code not covered by the
GPL may otherwise link to code that is covered by the GPL according to
this exception, for this to be allowed, the GPL Code may not depend on
any Non-GPL Code. It may, however, depend on GPL Code which is not
covered by this exception.
Redistribution with this exception
Only the copyright holders of each concerned file the ENIGMA engine may make
changes or additions to this exception, including the limitations and list of
Approved Interfaces. This exception may not be modified without the consent
of all of the covered file(s)' copyright holders.
When redistributing code covered by this exception, you may opt to exclude
the exception in your release. You are FORBIDDEN to include the exception in
the event that you have modified the contents of the "enigma_user" namespace
in such a way that allows additional access to variables outside of namespace
"enigma_user" by Non-GPL Code. To be explicit, all code manipulating data
internal to ENIGMA must be GPL-licensed, with or without this exception.
You must obey the GNU General Public License in all respects for all of the
Program code and other code used in conjunction with the Program except the
Non-GPL Code covered by this exception.
19
Developing ENIGMA / Style guidelines
« on: January 19, 2014, 06:00:06 pm »
New developers and old developers alike: I've noticed some bullshit happening in the engine. Specifically, one of the region_ functions is returning a variant. Don't do that.
I've started a page of basic guidelines on the wiki. Read it there, discuss here.
I've started a page of basic guidelines on the wiki. Read it there, discuss here.
20
Issues Help Desk / MOVED: How to connect space ship object to bullet object for that ship with instance id
« on: January 18, 2014, 11:52:57 am »
This topic has been moved to the new board, EDL Help.
http://enigma-dev.org/forums/index.php?topic=1693.0
http://enigma-dev.org/forums/index.php?topic=1693.0
21
I just graduated college. This means that for the first time in ages, I'm about to have some free time. However, I have decided I won't be doing that. Since my return, all I have gotten out of this community, primarily over IRC, is constant nagging about all the shit everyone needs from me. This includes updates to a bot that was broken eight months ago, the remaining EDC renovations Ism and I started months ago, which no one has touched since, the build system Fuckwit decided to obliterate, and the graphics system Robert started blenderizing. And after endless little tasks, I told them to back off—specifically, to shut up and leave me the fuck alone. What happened instead was a continuation of the relentless onslaught of me being called worthless, and frankly, I'm fed up.
So rather than devote my newly discovered free time to this project, I'm going to invest it in my more interesting ideas. I sort of miss the feeling of freedom I had when I was younger, to work on what I please. Knowing exactly what needs done to a system of this size deprives you of that.
TL;DR: A lack of motivation on all fronts coupled with the endless nagging of people I'm frankly sick of hearing from, topped off with Ism's informal resignation, has led me to present my own informal resignation.
I'll come back when either Ism and forthevin are back around, or I receive a formal letter of "eating shit" from Fuckwit. This will be after he realizes that a compiler isn't just a parser.
Seeing as I've left for a few solid months in the past without too much repercussion, you probably won't miss me very quickly. Just don't expect a sudden hike in bug fixes.
Ciao for now.
So rather than devote my newly discovered free time to this project, I'm going to invest it in my more interesting ideas. I sort of miss the feeling of freedom I had when I was younger, to work on what I please. Knowing exactly what needs done to a system of this size deprives you of that.
TL;DR: A lack of motivation on all fronts coupled with the endless nagging of people I'm frankly sick of hearing from, topped off with Ism's informal resignation, has led me to present my own informal resignation.
I'll come back when either Ism and forthevin are back around, or I receive a formal letter of "eating shit" from Fuckwit. This will be after he realizes that a compiler isn't just a parser.
Seeing as I've left for a few solid months in the past without too much repercussion, you probably won't miss me very quickly. Just don't expect a sudden hike in bug fixes.
Ciao for now.
22
General ENIGMA / Delusions of Grandeur
« on: August 01, 2013, 08:40:05 pm »
I spent the day migrating important chunks of the website's code to GitHub. This was largely for my own reasons (now I don't have to be afraid to edit files), but it's also for other members and potential web contributors to examine. This sparked as a result of my updating SMF to 2.0.4; we're on new software. The old version was becoming a liability due to exploits, etc.
So. You can find the source for the two bots here. You'll find the source to the SMF themes we use here. The source to the EDC (the least finished of all of these) is here.
I have not yet uploaded the source to the remainder of the site. I might get around to that tomorrow.
The biggest issue seems to be integrating the new SMF themes. In addition to being incomplete (I can't find the QuickEdit button), they break the EDC.
So. You can find the source for the two bots here. You'll find the source to the SMF themes we use here. The source to the EDC (the least finished of all of these) is here.
I have not yet uploaded the source to the remainder of the site. I might get around to that tomorrow.
The biggest issue seems to be integrating the new SMF themes. In addition to being incomplete (I can't find the QuickEdit button), they break the EDC.
23
Proposals / Compile Scripts
« on: July 16, 2013, 07:42:59 am »
A lot of what other toolkits have going for them is the capability of reflection. RTTI is useful; ENIGMA already has it to some extent by virtue of having object_index. While further reflection is, to some extent, planned, I do not want it to be a heavy emphasis in the engine.
I notice that a lot of what people try to do with reflection should have been done by their environment at compile time. Like listing classes that have <x>, or do <y>. The compiler does shitloads of this while compiling games; without proper compile-time reflection, there would be no way to translate EDL to C++. The issue is, the compiler's behavior is really static, and the compiler is the only entity with this capability.
Thus, I'm considering a mechanism I'm calling compile scripts. In this context, they are scripts of EDL run by the compiler which offer full reflection of all game entities. Scripts, objects, rooms, paths, timelines... If it's in the game, you can iterate it with the compiler. Having this mechanism would allow users to define functions which would otherwise require runtime reflection, but generally should not. Game Maker, for the part, provides a lot of functions to offer reflection in a somewhat efficient manner. For example, sprite_get_name(). What it lacks is a sprite_get_first() and sprite_get_next(). I am not proposing we add those directly. While they might be convenient for some games, they just waste space in others. I'm proposing a system that would allow users to define them.
Coupled with JDI, EDL's AST incorporates everything that is required to interpret that code, except the string and map object representations, which should be easy. Meanwhile, behind the scenes,
The above code is approximate, as it doesn't bail on the first error, and assumes that cs_this can be cs_map rather than a generic cs_object.
In other words, the define() operation only adds a key to be defined to some vector in the map object; the actual work is done elsewhere.
So, in the C++ module, the map object does this:
In the javascript model, it does this:
Optimizations will be made in the C++ version to ensure that all keys have the same type (all VT_INTEGER or VT_DOUBLE, or all VT_STRING), and the correct jdi::value cast will be used. This is because all keys are string in JavaScript, and the benefit of ensured compatibility outweighs the benefit of letting users mix types in a map. Use two maps.
That said, to implement such a compiler extension, the user will give something similar to the pseudo-EDL above, coupled with a regular Definitions resource which can use its results. The pseudo-EDL is the compile script, and is interpreted by the compiler. The Definitions resource is a script which defines functions run during the game.
Speaking of the Definitions resource: I want Definitions to allow scripting in each native language, as well as in EDL. It is looking as though EDL could easily be made to compile to any of the even vaguely planned backend languages, some of which might lead to it being a popular prototyping language outside the game design space. EDL could be a "write-once, compile in any of the languages that claim to be write-once, compile anywhere" language, which would make it even more useful to the sort of people who use GML for quick prototyping.
So, an example Definitions resource to go with the above psuedo-code would be this:
This allows the other EDL code in the game to be oblivious to the existence of that map. Equivalently, this should be able to be accomplished using the new EDL spec, still in progress, simply by adding the word "function" to the beginning.
The purpose of this topic is not for more stargazing, but rather for everyone else to present capabilities they think will be needed by these scripts. If you have an idea, shoot.
I notice that a lot of what people try to do with reflection should have been done by their environment at compile time. Like listing classes that have <x>, or do <y>. The compiler does shitloads of this while compiling games; without proper compile-time reflection, there would be no way to translate EDL to C++. The issue is, the compiler's behavior is really static, and the compiler is the only entity with this capability.
Thus, I'm considering a mechanism I'm calling compile scripts. In this context, they are scripts of EDL run by the compiler which offer full reflection of all game entities. Scripts, objects, rooms, paths, timelines... If it's in the game, you can iterate it with the compiler. Having this mechanism would allow users to define functions which would otherwise require runtime reflection, but generally should not. Game Maker, for the part, provides a lot of functions to offer reflection in a somewhat efficient manner. For example, sprite_get_name(). What it lacks is a sprite_get_first() and sprite_get_next(). I am not proposing we add those directly. While they might be convenient for some games, they just waste space in others. I'm proposing a system that would allow users to define them.
Code: (EDL) [Select]
global map item_sprites = [];
foreach (sprites as sprite) {
if (sprite.name.starts_with("spr_item_")) {
item_sprites.define(sprite.name, sprite.id);
}
}
Coupled with JDI, EDL's AST incorporates everything that is required to interpret that code, except the string and map object representations, which should be easy. Meanwhile, behind the scenes,
Code: (CPP) [Select]
jdi::value cs_map_define(cs_map* cs_this, jdi::AST_Node_Parameters *anp, jdi::error_handler *herr) {
if (anp.params.length() != 2)
return (herr->error("Expected two parameters to map::define"), value());
cs_this->definitions.push_back(value_pair(anp->params[0].eval(), anp->params[1].eval()));
}
compile_scripts::objects["map"].functions["define"] = cs_map_define;
The above code is approximate, as it doesn't bail on the first error, and assumes that cs_this can be cs_map rather than a generic cs_object.
In other words, the define() operation only adds a key to be defined to some vector in the map object; the actual work is done elsewhere.
- At syntax check time, it is up to ENIGMA to define that item_sprites is a global variable, if it is intended to be used in user code. If it is only intended to be used in library code, eg, in our definitions resource, we leave it out of our syntax checking definitions. I think this would be the preferable behavior.
- At compile time, the cs_map object is asked to generate code to ensure that the item_sprites object is what the library implementer thinks it is.
So, in the C++ module, the map object does this:
Code: (CPP) [Select]
string obj_map_cpp::get_code() {
string res;
for (value_pair_vector::iterator it = definitions.begin(); it != definitions.end(); ++it)
res += " item_sprites[" + it->second->first.toString() + "] = " + it->second->second.toString() + ";\n";
return res;
}
In the javascript model, it does this:
Code: (CPP) [Select]
string obj_map_cpp::get_code() {
string res = " item_sprites = {\n";
for (value_pair_vector::iterator it = definitions.begin(); it != definitions.end(); ++it)
res += " \"" + it->second->first.toString() + "\" : " + it->second->second.toString() + ",\n";
return res + " }\n";
}
Optimizations will be made in the C++ version to ensure that all keys have the same type (all VT_INTEGER or VT_DOUBLE, or all VT_STRING), and the correct jdi::value cast will be used. This is because all keys are string in JavaScript, and the benefit of ensured compatibility outweighs the benefit of letting users mix types in a map. Use two maps.
That said, to implement such a compiler extension, the user will give something similar to the pseudo-EDL above, coupled with a regular Definitions resource which can use its results. The pseudo-EDL is the compile script, and is interpreted by the compiler. The Definitions resource is a script which defines functions run during the game.
Speaking of the Definitions resource: I want Definitions to allow scripting in each native language, as well as in EDL. It is looking as though EDL could easily be made to compile to any of the even vaguely planned backend languages, some of which might lead to it being a popular prototyping language outside the game design space. EDL could be a "write-once, compile in any of the languages that claim to be write-once, compile anywhere" language, which would make it even more useful to the sort of people who use GML for quick prototyping.
So, an example Definitions resource to go with the above psuedo-code would be this:
Code: (CPP) [Select]
int item_get_sprite(string itemname) {
return item_sprite[itemname];
}
This allows the other EDL code in the game to be oblivious to the existence of that map. Equivalently, this should be able to be accomplished using the new EDL spec, still in progress, simply by adding the word "function" to the beginning.
The purpose of this topic is not for more stargazing, but rather for everyone else to present capabilities they think will be needed by these scripts. If you have an idea, shoot.
24
General ENIGMA / License Exemptions
« on: June 21, 2013, 05:47:38 am »
Developers with tendencies to law are probably aware that ENIGMA is GPL. Whether ENIGMA is GPL or LGPL, we will run into shitloads of legal issues with people distributing our games. In principle, this is okay; we're not assholes, so we won't sue them for using our toolkit how it was intended to be used. However, as the number of contributors continues to expand out of check, the problem turns into a big chain of people to trust. Chains, weakest link, etc.
I haven't addressed this issue because I trust the current development team to not be giant dicks. However, the general (and correct) inclination of the userbase is to not trust us. The GPL gives us all the tools to be as proprietary as Yoyo, but in a way that is pleasing to Stallman instead of to Ballmer. Currently, any developer—that means any one of forthevin, HaRRiKiRi, IsmAvatar, myself, polyfuck, or RobertBColton—any are capable of forcing someone to release the source to their game. This isn't the end of the world, obviously, but it's the end of the world to some of our userbase.
New developers are starting to show up at increasing rates. Now is the time to sort this shit. In case any of you were genuinely unaware of this issue, I apologize for leaving you in the dark about it.
The basic idea is that we need a custom Linking Exception similar to the one used in GCC. Basically, our linking exception would grant users the right to hard-link their game code to the engine when compiled using an "official" IDE. Here's the trick: How do we legally define an official IDE?
Call it selfish, but my personal inclination is to keep the code within the ENIGMA project, when closed-source. Basically, I want to allow a third party to make off with all engine code, provided that they do so in full free-and-open-source spirit; that is, with the intention of all derivative works being free and open-source, including user games. Why? It's not because I'm evil, or on a power trip.
Consider WINE. WINE is a great piece of software, in concept. In practice, it's too shitty to run Microsoft office. It's also X11-licensed. So one day, the now "Crossover Office" team decided to take WINE, fix it up professionally to be able to run MSO, and then close-source it and charge money. Puts a pit in my stomach.
Assuming we have a method for legal endorsement, this method should be conducive to our main goal, here: We need to provide incentive for any third-party distributors to contribute back to the project. That means we do not want people to fix up a critical piece of the engine that we're having trouble with, then close-source that part and charge money for it. We also, of course, don't want Yoyo making off with a chunk of ENIGMA of any size, but I don't think they'd reduce themselves to that level. They're too proud, and it's too risky for them.
Contributors:
If you hold any code in the project, I need your express and explicit permission to re-license your code according to an ENIGMA Linking Exception. The ENIGMA Linking Exception is not yet written; if you are versed in Legalese, or are an aspiring Richard Stallman, I would appreciate your help writing the exception.
If you have any aversion to the exception, I need to know about it. We have to agree. In face of disagreement, parts of ENIGMA could be GPL forever. We can only offer users as much freedom as is granted by the most-stingy developer. GPL is most stingy, X11 is least stingy. My code will be covered by this linking exception.
I haven't addressed this issue because I trust the current development team to not be giant dicks. However, the general (and correct) inclination of the userbase is to not trust us. The GPL gives us all the tools to be as proprietary as Yoyo, but in a way that is pleasing to Stallman instead of to Ballmer. Currently, any developer—that means any one of forthevin, HaRRiKiRi, IsmAvatar, myself, polyfuck, or RobertBColton—any are capable of forcing someone to release the source to their game. This isn't the end of the world, obviously, but it's the end of the world to some of our userbase.
New developers are starting to show up at increasing rates. Now is the time to sort this shit. In case any of you were genuinely unaware of this issue, I apologize for leaving you in the dark about it.
The basic idea is that we need a custom Linking Exception similar to the one used in GCC. Basically, our linking exception would grant users the right to hard-link their game code to the engine when compiled using an "official" IDE. Here's the trick: How do we legally define an official IDE?
Call it selfish, but my personal inclination is to keep the code within the ENIGMA project, when closed-source. Basically, I want to allow a third party to make off with all engine code, provided that they do so in full free-and-open-source spirit; that is, with the intention of all derivative works being free and open-source, including user games. Why? It's not because I'm evil, or on a power trip.
Consider WINE. WINE is a great piece of software, in concept. In practice, it's too shitty to run Microsoft office. It's also X11-licensed. So one day, the now "Crossover Office" team decided to take WINE, fix it up professionally to be able to run MSO, and then close-source it and charge money. Puts a pit in my stomach.
Assuming we have a method for legal endorsement, this method should be conducive to our main goal, here: We need to provide incentive for any third-party distributors to contribute back to the project. That means we do not want people to fix up a critical piece of the engine that we're having trouble with, then close-source that part and charge money for it. We also, of course, don't want Yoyo making off with a chunk of ENIGMA of any size, but I don't think they'd reduce themselves to that level. They're too proud, and it's too risky for them.
Contributors:
If you hold any code in the project, I need your express and explicit permission to re-license your code according to an ENIGMA Linking Exception. The ENIGMA Linking Exception is not yet written; if you are versed in Legalese, or are an aspiring Richard Stallman, I would appreciate your help writing the exception.
If you have any aversion to the exception, I need to know about it. We have to agree. In face of disagreement, parts of ENIGMA could be GPL forever. We can only offer users as much freedom as is granted by the most-stingy developer. GPL is most stingy, X11 is least stingy. My code will be covered by this linking exception.
25
General ENIGMA / The last of the engine compile warnings
« on: June 17, 2013, 09:04:47 am »
I was going to get started on a couple of the issues in the tracker (actually, I've done so), but the engine was so full of warnings, I had a hay day. I've created a new issue for the warnings that were my fault. The majority of the warnings were for variable-length arrays and floating point comparisons. I've corrected the floating point comparisons using a new header called <floatcomp.h>. From now on, instead of f1 == f2, include that header and use fequal(f1, f2). There is also an fnequal, fzero, and fnzero, which I trust are self-explanatory.
The only source that makes an exception is var.h in its division-by-zero checking. For that, it assumes only division by exactly zero is useful to report. If you think it's useful to strictly compare against zero elsewhere, let me know. The point of the header is mostly to make it easy to change out comparison behaviors, depending on need.
Other warnings that remain:
Universal_System/spriteinit.cpp: In function ‘void enigma::exe_loadsprs(FILE*)’:
Universal_System/spriteinit.cpp:105: warning: variable ‘collision_data’ set but not used [-Wunused-but-set-variable]
Forthevin: How are you accessing mask data in your precise collision system? It isn't being passed in from the sprite load mechanism.
Graphics_Systems/OpenGL1/glew.c:11678: warning: no previous declaration for ‘glxewContextInit’ [-Wmissing-declarations]|
Graphics_Systems/OpenGL1/glew.c:11960: warning: redundant redeclaration of ‘glxewContextInit’ [-Wredundant-decls]|
Our copy of glew is fucked up. Not touching it.
Universal_System/resource_data.cpp: In function ‘bool enigma_user::script_exists(int)’
Universal_System/resource_data.cpp:82: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Signed-unsigned comparison in script_exists (#228)
I'll commit this shortly.
Warnings to other developers:
Forthevin: I had to make a couple of your particle methods static.
Polygone: I tore the shit out of your grid functions.
The only source that makes an exception is var.h in its division-by-zero checking. For that, it assumes only division by exactly zero is useful to report. If you think it's useful to strictly compare against zero elsewhere, let me know. The point of the header is mostly to make it easy to change out comparison behaviors, depending on need.
Other warnings that remain:
Universal_System/spriteinit.cpp: In function ‘void enigma::exe_loadsprs(FILE*)’:
Universal_System/spriteinit.cpp:105: warning: variable ‘collision_data’ set but not used [-Wunused-but-set-variable]
Forthevin: How are you accessing mask data in your precise collision system? It isn't being passed in from the sprite load mechanism.
Graphics_Systems/OpenGL1/glew.c:11678: warning: no previous declaration for ‘glxewContextInit’ [-Wmissing-declarations]|
Graphics_Systems/OpenGL1/glew.c:11960: warning: redundant redeclaration of ‘glxewContextInit’ [-Wredundant-decls]|
Our copy of glew is fucked up. Not touching it.
Universal_System/resource_data.cpp: In function ‘bool enigma_user::script_exists(int)’
Universal_System/resource_data.cpp:82: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
Signed-unsigned comparison in script_exists (#228)
I'll commit this shortly.
Warnings to other developers:
Forthevin: I had to make a couple of your particle methods static.
Polygone: I tore the shit out of your grid functions.
26
General ENIGMA / hey plions
« on: June 15, 2013, 07:29:33 am »
Two quick items:
(1) Your "fix" for arbitrary dot-access variables isn't working. I've had fifty people reporting segfaults in the compiler recently, and Frogg reported that [snip=edl]someobject.unusedvariable[0][/snip] is the same object for any [snip]unusedvariable[/snip]. So basically, your fix apparently doesn't work, and in development teams, correlation usually does imply causation, so I'm guessing the segfault is from your shit.
(2) You do this practically everywhere:
It doesn't do jack shit without an & after enigma::tile, or enigma::room_background, or any of the other fifty places you do it.
...
Okay, I'll just start listing things.
(3) Does your fucking tile system assign an alpha to every single tile, but use it exclusively for tile_layer_show/hide? Is it actually drawing hundreds or thousands of completely transparent tiles when a layer is hidden?
I won't even blame you for that, because at least you implemented it. But holy shit.
(1) Your "fix" for arbitrary dot-access variables isn't working. I've had fifty people reporting segfaults in the compiler recently, and Frogg reported that [snip=edl]someobject.unusedvariable[0][/snip] is the same object for any [snip]unusedvariable[/snip]. So basically, your fix apparently doesn't work, and in development teams, correlation usually does imply causation, so I'm guessing the segfault is from your shit.
(2) You do this practically everywhere:
Code: [Select]
enigma::tile t = dit->second.tiles[i];
t.alpha = 1;
It doesn't do jack shit without an & after enigma::tile, or enigma::room_background, or any of the other fifty places you do it.
...
Okay, I'll just start listing things.
(3) Does your fucking tile system assign an alpha to every single tile, but use it exclusively for tile_layer_show/hide? Is it actually drawing hundreds or thousands of completely transparent tiles when a layer is hidden?
I won't even blame you for that, because at least you implemented it. But holy shit.
27
Off-Topic / Dear Polyfuck: Stop breaking the fucking repo
« on: June 02, 2013, 03:19:30 pm »
Dear Polyfuck: Stop breaking the fucking repo
If you continue to break the fucking repo on all non-Windows platforms--which I'll remind you that the majority of our users are on, because the rest can tolerate GM by virtue of being able to tolerate Winblows--I'm going to have you join Robert in club commit-to-fork-and-drop-pull-requests, where you should have been from the get-go.
We have *far* too many problems with the engine from the new MinGW release and the new release zip to be worrying about you fucking breaking mouse_x on a whim without so much as telling anyone.
At very least, tell Robert, because he won't fucking shut up about it until it's fixed, whether he fixes it, or he asks me how to fix it, or I fix it.
If you continue to break the fucking repo on all non-Windows platforms--which I'll remind you that the majority of our users are on, because the rest can tolerate GM by virtue of being able to tolerate Winblows--I'm going to have you join Robert in club commit-to-fork-and-drop-pull-requests, where you should have been from the get-go.
We have *far* too many problems with the engine from the new MinGW release and the new release zip to be worrying about you fucking breaking mouse_x on a whim without so much as telling anyone.
At very least, tell Robert, because he won't fucking shut up about it until it's fixed, whether he fixes it, or he asks me how to fix it, or I fix it.
28
General ENIGMA / Website and IRC Problems Version Control Could Fix
« on: May 26, 2013, 10:48:36 am »
Sorry to add yet another topic to this already overpopulated board. Maybe one day the whole forum will be this active, and I won't have to feel bad. I figure this is a good board to pollute, since people are already paying extra attention to it.
To cut to the chase, we need to start using version control EnigmaBot and other features of the website.
I have organized my points into •B•U•L•L•E•T•E•D• •L•I•S•T•S• to save everyone some brainpower and reading.
Rationale:
The idea: EnigmaBot and the SMF/Wiki extensions we have written need placed under version control, possibly in the same repository, at some point down the road.
Problems we need to address with which this change may or may not help:
Writing this has given me carpal tunnel.
Ism and I will get everything moved into a git repository and checked for sensitive information/passwords/etc at some point in the discrete future following discussion here. Any additional problem you have with the above, list them, as they are likely to be dealt with long before the site is on GitHub.
To cut to the chase, we need to start using version control EnigmaBot and other features of the website.
I have organized my points into •B•U•L•L•E•T•E•D• •L•I•S•T•S• to save everyone some brainpower and reading.
Rationale:
- Security: We don't have anything to hide except password hashes and private messages, which are part of the SQL database and would not be versioned.
- Moreover, we have tons of living proof that being open-source promotes contribution of security patches over exploitation of security holes (consider Linux).
- Feedback: This lets people drop pull requests and submit bug reports for features of the website that irk them.
- Disaster Recovery: This makes site-wide code backup obsolete.
- Ease of development: This makes updating pieces of the website a no-brainer, lets users edit code in their own environments.
- Peace of mind: This removes fear of fucking something up on the server and having to dig for the backup manually (yay, git checkout).
- Robert: I'll never have to put up with another episode of "zomg this needs blue and yellow and a grid background, so shell into the server and install my CSS patch or I'm leaving"
- Progress: Ism and I don't have to be the only people scratching our heads at why the fuck EnigmaBot has all these fucking issues
- We can take care of separating sensitive information to produce redistributable code up front, once and for all.
- Someone else can deal with the fact that our current SMF theme is based on ten-year-old code.
- Appropriateness: We version a lot of dumber projects, Calico being the dumbest to-date.
- Other people and communities could benefit from the shit I had to go through to hook the EDC up to SMF's database
The idea: EnigmaBot and the SMF/Wiki extensions we have written need placed under version control, possibly in the same repository, at some point down the road.
Problems we need to address with which this change may or may not help:
- EnigmaBot:
- When operators join, they are not notified if they have messages.
- Some of the repository search features are screwy
- Something is seriously wrong with !egrep / !lgrep / !etcgrep. It often completely misses search results.
- !grepnext cannot skip to the next file, in cases where there are nine hundred results in three files. The user is told only that there are 900 results.
- !eurl is a bit inconvenient; it does not attempt to find a file of near match (eg, by adding .h or .cpp)
- !eurl can not fetch the next file with a matching name, or a file with a matching name in a matching folder. Try !eurl'ing for SHELL/Makefile.
- This hasn't been a problem lately, but if an SQL timeout occurs, the bot's next query will fail relatively unceremoniously, but then the connection will be re-established and subsequent commands will succeed. Why can't the current command succeed, too?
- Forums:
- The forums are using an SMF 1.x theme, despite being on a (now outdated) version of SMF 2.
- One (very bitter, but still possibly correct) ex-user reported that this is a violation of the license used by SMF 1. I'll need to do more research on this.
- I believe that the license only concerns code redistribution (which is a problem if we want to version this forum software!), but,
- we may well need to update our footer code to include an SMF notice (which I don't have a problem with).
- My license preference is GPL, so if possible, I would like to have our extensions licensed under it
- A lot of good features are missing from our theme, due to its age and the consistency of our code at the time (Gary was 17, I 16, a2h 15).
- The icons are a bit inconsistent, and aren't vectored (I also made them when I was 16).
- SMF code and the extensions folder will not be versioned. If you want an extension added to SMF, file a tracker artifact.
- The actual BBCode extension, multiple-verification-answers extension, and any other extensions unique to or maintained by the ENIGMA team will be versioned.
- Site:
- The header and footer are dated (as in old), outdated (as in incorrect), and ugly (as in ugly).
- The transition to a2h's "v5" design will go much smoother in the presence of version control
- We could really use site scripts to handle release control and package builds
- The server could package the release zips currently maintained by Robert and Polydip
- Users could vote (yes/no) whether a release package/zip works for them, and the zips/packages with the highest rating could be listed first.
- EDC:
- Written when I was 18 (what does this tell you?)
- The badge system is not implemented, because I didn't understand how M:N relationships worked in SQL (comments seemed wasteful to me, and badges? Forget about it).
- The download system is also not modular (you can only give one download link!)
- Screenshots are unimplemented.
- There's no way to view games and blogs by most recent activity (one of the things the forums would offer over the EDC for posting games)
- You have to use external hosting for your games (meaning broken links will abound; cloud hosting is becoming extremely cheap compared to when I was younger
- Virus flagging and game rating are not implemented. These are absolutely necessary before we start our own hosting and accumulate a large userbase.
- If we do our own hosting, a file manager will be necessary.
- Wiki:
- Either the extensions folder will not be versioned, or pull requests to it will not be accepted. If you want a Wiki extension added or updated, file a tracker artifact.
- There may or may not be problems with the EDL and YAML GeSHi plugins, both of which were written by me (I know there are problems with the YAML one; I'll fix those at some point).
Writing this has given me carpal tunnel.
Ism and I will get everything moved into a git repository and checked for sensitive information/passwords/etc at some point in the discrete future following discussion here. Any additional problem you have with the above, list them, as they are likely to be dealt with long before the site is on GitHub.
29
Proposals / While we (as in forthevin) are moving shit
« on: May 18, 2013, 05:48:14 pm »
Here's a question to think about while we're moving shit.
A lot of functions take specific types of objects as input. This hasn't been a big problem so far, because all objects have been 2D. When users go 3D, the tier [snip]object_planar[/snip] will need swapped out for a hypothetical [snip]object_spatial[/snip], which implements an x, y, and z. We're going to have cast issues out the ass one way or another, but I think it'd benefit us to have some community discussion before anything big happens.
Ideally, we could solve this by moving functions such as motion_add into the object_planar class. But thanks to our friend, [snip=edl]with(){}[/snip], this is, as usual, completely off the table. That said, I think we can still use vtables to help mitigate issues, like so:
If we do this, cast checks can be eliminated for engine code, and errors can be reported for assigning z-motion in a 2D object in debug mode (possibly only when a certain flag is set, like -pedantic or -w-wrong-fucking-dimensionality). Other functions, such as those in extensions, would either have to do cast checking or use the virtual methods from object_positionable to be able to whore the vtable.
By the way, let me make one thing clear: if your code contains [snip]dynamic_cast[/snip], you are doing something wrong. Rule of thumb.
Any thoughts, suggestions, or visions of disastrous issues with the proposed or existing systems are welcomed.
Cheers
A lot of functions take specific types of objects as input. This hasn't been a big problem so far, because all objects have been 2D. When users go 3D, the tier [snip]object_planar[/snip] will need swapped out for a hypothetical [snip]object_spatial[/snip], which implements an x, y, and z. We're going to have cast issues out the ass one way or another, but I think it'd benefit us to have some community discussion before anything big happens.
Ideally, we could solve this by moving functions such as motion_add into the object_planar class. But thanks to our friend, [snip=edl]with(){}[/snip], this is, as usual, completely off the table. That said, I think we can still use vtables to help mitigate issues, like so:
- Class object_spatial and class object_planar extend class object_positionable, which has a virtual $add_motion
- Each child class, object_planar and object_spatial, implement a motion setter for two and three dimensions, but object_planar ignores the given z coordinate.
If we do this, cast checks can be eliminated for engine code, and errors can be reported for assigning z-motion in a 2D object in debug mode (possibly only when a certain flag is set, like -pedantic or -w-wrong-fucking-dimensionality). Other functions, such as those in extensions, would either have to do cast checking or use the virtual methods from object_positionable to be able to whore the vtable.
By the way, let me make one thing clear: if your code contains [snip]dynamic_cast[/snip], you are doing something wrong. Rule of thumb.
Any thoughts, suggestions, or visions of disastrous issues with the proposed or existing systems are welcomed.
Cheers
30
General ENIGMA / Where would you like your objects?
« on: May 16, 2013, 07:06:14 am »
The more I review the idea, the clearer it is that I ought to start moving event code into separate source files. I'm thinking the new pretty printer (which I am using as a gloss word for "that thing that exports all the relevant engine code") should implement this change, just while I'm at it.
The point of this is to make it so that objects do not all need rebuilt every time you run the game. Issue with that is, we need somewhere to store the object files generated by the compiler (eg, GCC). The way I see it, we have a few options:
1) Store them in temp files. Your game will need built from scratch once, every time you reboot the machine.
2) Store them in the same folder as the game. So there'll be a ./game.egm, and a ./bin/game.egm/objects. This will leave object files everywhere, because nothing will ever delete them.
3) Store them in the actual game. This will make games extra fat, and could be problematic when using zipped formats (we can't point the linker to a zipped file).
4) Insert better idea here.
My only better idea is to give ENIGMA a specific spot in appdata / ~ that stores object files by game ID/path+filename, along with a timestamp to let ENIGMA know that it's been two weeks since the objects there have been used, and so they should probably be deleted. Game Maker used to prompt to delete old temp files on start, so I guess it wouldn't be unheard of.
Anyway, thoughts welcome.
Cheers
The point of this is to make it so that objects do not all need rebuilt every time you run the game. Issue with that is, we need somewhere to store the object files generated by the compiler (eg, GCC). The way I see it, we have a few options:
1) Store them in temp files. Your game will need built from scratch once, every time you reboot the machine.
2) Store them in the same folder as the game. So there'll be a ./game.egm, and a ./bin/game.egm/objects. This will leave object files everywhere, because nothing will ever delete them.
3) Store them in the actual game. This will make games extra fat, and could be problematic when using zipped formats (we can't point the linker to a zipped file).
4) Insert better idea here.
My only better idea is to give ENIGMA a specific spot in appdata / ~ that stores object files by game ID/path+filename, along with a timestamp to let ENIGMA know that it's been two weeks since the objects there have been used, and so they should probably be deleted. Game Maker used to prompt to delete old temp files on start, so I guess it wouldn't be unheard of.
Anyway, thoughts welcome.
Cheers