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.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »
436
General ENIGMA / Re: Realtime 3D Shadows, Animations, & Outlined Cel Shading
« on: March 09, 2014, 10:02:57 pm »
Harri:
That means you're going to be rewriting all the ENIGMA functions, then modifying all the user-coordinate functions to take 1-y for them. That's pointless. In GL1, there's already a matrix multiply going on; it doesn't matter whether the matrix is the identity or if it effects y = y*-1 + 1. In GL3, it's still in our interest to keep this in the sampler code, even assuming there is no sampler matrix multiply by default (which I am just assuming—the sampler is a very static entity).
Darkstar:
IsmAvatar released a LibMaker for LGM which should be able to import LIB. Robert dug it up here.
That means you're going to be rewriting all the ENIGMA functions, then modifying all the user-coordinate functions to take 1-y for them. That's pointless. In GL1, there's already a matrix multiply going on; it doesn't matter whether the matrix is the identity or if it effects y = y*-1 + 1. In GL3, it's still in our interest to keep this in the sampler code, even assuming there is no sampler matrix multiply by default (which I am just assuming—the sampler is a very static entity).
Darkstar:
IsmAvatar released a LibMaker for LGM which should be able to import LIB. Robert dug it up here.
437
General ENIGMA / Re: Realtime 3D Shadows & Animations
« on: March 08, 2014, 09:27:28 pm »
[snip=CPP]#define globalbar global var[/snip]
And as I've said, surfaces being upside-down is an easy fix. If that's what you're on about.
Step one: stop making all the textures upside-down.
Step two: bind the sampler matrix.
Step three: glScalef(1,-1)
Step four: ? ? ? ? ?
Step five: profit
And as I've said, surfaces being upside-down is an easy fix. If that's what you're on about.
Step one: stop making all the textures upside-down.
Step two: bind the sampler matrix.
Step three: glScalef(1,-1)
Step four: ? ? ? ? ?
Step five: profit
438
General ENIGMA / Re: Linking Exception Draft
« on: March 05, 2014, 09:59:03 am »
That's the issue; we're gambling on ENIGMA's future. Specifically, how much traction it gains. If it gains none, we can BSD it and be like the other 500 BSD game engines no one uses. If it gains a little, someone can steal it and gain a lot. If it gains a lot, we can be the Mozilla of the game engine world. Or just another LÖVE.
I wouldn't ask contributors to sign away their IP rights. But we couldn't if I wanted to, I believe; we aren't a legal entity.
I wouldn't ask contributors to sign away their IP rights. But we couldn't if I wanted to, I believe; we aren't a legal entity.
439
General ENIGMA / Re: Linking Exception Draft
« on: March 03, 2014, 10:59:58 am »
To use your example, Rezolyze, no one is going to want anything to do with the plans for my wobbly chair, when they can purchase a non-wobbly chair with arm rests for a nominal fee. Everyone will know my chair as the wobbly one, and everything there was to possibly like about my chair, except the ability to distribute its plans, is available pre-built and with more features from another company. And I know it's easy to say that can't happen because we're free, we're not selling anything. That's why I pay out of pocket to run this place. In the event that you were successfully selling my chair to others with all these improvements I lack time to make, I would not continue to design my chair. Its plans would fall into antiquity. A million free CRT plans will not help you when you can buy a flat panel display for $200, to use an exaggerated example.
The other scenario you describe is the reason that we are trying to hammer this exception out now, rather than later. We want to make it so that anyone can contribute or run their own version of ENIGMA so long as they allow people to do exactly the same. That's the entire principle behind a viral license and the free software movement. We want to allow more ENIGMAs if and only if they in turn allow more ENIGMAs; the complication stems from the fact that we want users to have autonomy with their game's licenses. The MPL is a quick fix for users' needs. It puts us in jeopardy of becoming antique.
And yes, I am very aware that the GPL is not conducive to the app store, and being able to choose a license for combined work that is not free to redistribute is important. That has nothing to do with the license of the original source of the engine, however.
And I don't wish to appear as a protective parent. It isn't that I want my code to be mine, but that I want game engines to be everyone's. This movement was founded on the idea that software should be free. Unlike many who believe in that principle, I can respect the desire to control who can use and distribute your software (eg, people who pay to do so). But I'm not interested in allowing people to control who has the better version of this software. No matter who extends ENIGMA in what way, I want users to be able to make their games in it for free. Knowing a bugfix should not entitle someone to more control over the project than anyone else has.
However, I can see the users' perspective on the issue. It is good for a user to be able to feel comfortable in using the engine for his or her purposes. So maybe when the new compiler is integrated and I can devote more time to ensuring no one gets ahead of us in terms of features and bug fixes, I will embrace the MPL for my own code. I won't promise anything, but I consider it to be an option.
The other scenario you describe is the reason that we are trying to hammer this exception out now, rather than later. We want to make it so that anyone can contribute or run their own version of ENIGMA so long as they allow people to do exactly the same. That's the entire principle behind a viral license and the free software movement. We want to allow more ENIGMAs if and only if they in turn allow more ENIGMAs; the complication stems from the fact that we want users to have autonomy with their game's licenses. The MPL is a quick fix for users' needs. It puts us in jeopardy of becoming antique.
And yes, I am very aware that the GPL is not conducive to the app store, and being able to choose a license for combined work that is not free to redistribute is important. That has nothing to do with the license of the original source of the engine, however.
And I don't wish to appear as a protective parent. It isn't that I want my code to be mine, but that I want game engines to be everyone's. This movement was founded on the idea that software should be free. Unlike many who believe in that principle, I can respect the desire to control who can use and distribute your software (eg, people who pay to do so). But I'm not interested in allowing people to control who has the better version of this software. No matter who extends ENIGMA in what way, I want users to be able to make their games in it for free. Knowing a bugfix should not entitle someone to more control over the project than anyone else has.
However, I can see the users' perspective on the issue. It is good for a user to be able to feel comfortable in using the engine for his or her purposes. So maybe when the new compiler is integrated and I can devote more time to ensuring no one gets ahead of us in terms of features and bug fixes, I will embrace the MPL for my own code. I won't promise anything, but I consider it to be an option.
440
General ENIGMA / Re: Linking Exception Draft
« on: March 02, 2014, 01:41:28 pm »
@11th
That's the very scenario I was describing, although I used removing the entire function and recoding an independent version in user code. It makes maintenance much less of a deal, especially since you can #include whatever you need without violating MPL. In the event that the code is volatile or hard to rewrite, consider macroing the top half of the function with [snip]#define top ...\ ...\ ...\ ...\ ...[/snip] and then doing the same for the bottom; your MPL code is only really changed by two lines and a symbol for each line, while your own code is something like this:
I didn't see anything in the MPL even remotely protecting against such. In the event that macros were ugly or over-the-top, preprocessors could be used. [snip]#ifdef TOP_HALF ... #endif[/snip], [snip]#ifdef BOTTOM_HALF ... #endif[/snip],
The point is that there are a multitude of ways to sneak around this, and Mozilla does not need to worry about them because they have a bigger team than any competition would be able to easily scrape up to outdo them. If we had a larger developer base, we could do the same thing.
@TKG
Lots of Moutain Dew. Or coffee.
That's the very scenario I was describing, although I used removing the entire function and recoding an independent version in user code. It makes maintenance much less of a deal, especially since you can #include whatever you need without violating MPL. In the event that the code is volatile or hard to rewrite, consider macroing the top half of the function with [snip]#define top ...\ ...\ ...\ ...\ ...[/snip] and then doing the same for the bottom; your MPL code is only really changed by two lines and a symbol for each line, while your own code is something like this:
Code: (cpp) [Select]
void collision_replacement(int whatever) {
top_half
// new code here
bottom_half
}
I didn't see anything in the MPL even remotely protecting against such. In the event that macros were ugly or over-the-top, preprocessors could be used. [snip]#ifdef TOP_HALF ... #endif[/snip], [snip]#ifdef BOTTOM_HALF ... #endif[/snip],
Code: (cpp) [Select]
void collision_replacement(int whatever) {
#define TOP_HALF
#include "original.cpp"
// new code here
#define BOTTOM_HALF
#include "original.cpp"
}
The point is that there are a multitude of ways to sneak around this, and Mozilla does not need to worry about them because they have a bigger team than any competition would be able to easily scrape up to outdo them. If we had a larger developer base, we could do the same thing.
@TKG
Lots of Moutain Dew. Or coffee.
441
General ENIGMA / Re: Linking Exception Draft
« on: March 02, 2014, 09:55:23 am »
> I don't really follow what you're written. Clearly, you're much more logically-minded than I am. The following is from the GPL exception, Approved Interfaces 2.ii and is what I was referring to.
I was just showing that the clause changes two cases: it prevents a third party from selling a bug fix to users; they can only reasonably sell it to an ENIGMA developer or take up a collection. And it prevents a user from hoarding a fix to the engine—they have to share it with everyone first. I will grant that this may discourage use of the engine by some people, but it will only discourage the people who weren't looking to contribute to the community. And it will discourage development by third parties, but only the third parties who were not willing to share without any possibility of royalties. From the perspective of this community, we have literally lost nothing of value in those cases.
> I took this to mean that a game developer couldn't try to fix or workaround a problem with the engine in their own code. It appears that's not how you meant it, but that's how I understood it. I took issue with it because I've had to workaround a few issues in the engine within my own game code.
If that clause worries you, it can be elided; it is how I attempted to handle the "code in namespace enigma" thing originally. Now, I agree: it seems to be saying too much. Working around a bug might be as simple as not using a particular function, and that is, of course, completely permissible. I assume that is what you meant by workarounds in your games, and that is how the typical user works around things. There'd be no way to prove that such a workaround had occurred, anyway. The better metric is whether the workaround was made using only namespace enigma_user: if you're editing things in namespace enigma, that's a good indicator you've modified code that should be public.
> How would it cease to exist?
In the same way as the others; we offer a whole lot of nice features, but a paid version offers all of our features and more, with bug fixes. Users will pay for the bug fixes, then become dependent on the new features. Then ENIGMA falls out of the picture. A less drastic example is WINE and Crossover Office. If WINE had been GPL, crossover office would either be free and donation based, or would not exist. The latter case might bother you, but it doesn't bother me, as I refuse to pay for a souped up WINE, not because I don't have the money, but because they're trying to sell me other people's work along with theirs. In WINE's case, that was not the intention. You can tell this wasn't in the spirit of the licensing because they then changed the licensing to prevent being leeched off of further. It's uncertain if ENIGMA would be so lucky, but to use an old cliché, I'd prefer to err on the side of caution.
> I don't want this project to die because of copyright issues someday. Even worse would be that game developers don't use the engine because they don't trust the chosen license to protect their code.
I don't see the demise of this project over copyright issues as a concern, namely because if someone is around to enforce the GPL, that person can be contacted to amend the license. As for game developers, they mostly go with the crowd: to my knowledge, only four users, yourself included, have taken the initiative to bring up the licensing at all. That isn't something we can rely on in the event that there certainly is a licensing issue, as there is now, but it is something we can lean on when the license is still in its infancy. MPL was new, once, too. Do you suppose Yoyo is using a conventional license for Game Maker? Or perhaps people trust them more because some of them already had to fork over money to use Game Maker?
> If anything, I see this project as a potential wielder of EEE tactics.
I agree. It may seem that I am being a hypocrite, but consider why EEE is bad. It's bad because it gives one organization control over a userbase, by making it so the users have no choice but to continue to use the product after they switch. In the case of a free-software project, this control goes away, because there's no longer one central authority that owns the code. This is in jeopardy if we don't choose a good license; ENIGMA could become such an entity if either us or a third party is able to control the software.
> What if someone wants to make a level editor separate from their game. I would define that as an application, but your definition might not allow for such a thing.
I am not sure how a level editor constitutes a related product; a level editor is related loosely to the IDE, but ENIGMA is a compiler and an engine. It has nothing to do with IDEs on its own; it simply goes well with one. But again, the manner in which we define a related product will be the crux of the entire operation. It prevents someone from distributing ENIGMA + features and bug fixes as a separate, proprietary product. This particular example also begs the question of whether this level editor would be distributed. If the level editor is for internal use by a company or organization (or just an individual), then they are free by both licenses to do whatever they want. Only when distributing this level editor to third parties would the question of "Is this a related product" enter into the equation, and our definition would say "no." I could easily pay a lawyer to write a definition for us.
> You can never be sure how someone will one day want to use the software you've created.
Again, we can always add rights, and never subtract them (except in later versions). If a user asks us, "Is this legal?" and the answer is "no," that's a relatively easy fix. If a third party finds a loophole and starts developing ENIGMA at full throttle as a proprietary application, we won't last long.
I was just showing that the clause changes two cases: it prevents a third party from selling a bug fix to users; they can only reasonably sell it to an ENIGMA developer or take up a collection. And it prevents a user from hoarding a fix to the engine—they have to share it with everyone first. I will grant that this may discourage use of the engine by some people, but it will only discourage the people who weren't looking to contribute to the community. And it will discourage development by third parties, but only the third parties who were not willing to share without any possibility of royalties. From the perspective of this community, we have literally lost nothing of value in those cases.
> I took this to mean that a game developer couldn't try to fix or workaround a problem with the engine in their own code. It appears that's not how you meant it, but that's how I understood it. I took issue with it because I've had to workaround a few issues in the engine within my own game code.
If that clause worries you, it can be elided; it is how I attempted to handle the "code in namespace enigma" thing originally. Now, I agree: it seems to be saying too much. Working around a bug might be as simple as not using a particular function, and that is, of course, completely permissible. I assume that is what you meant by workarounds in your games, and that is how the typical user works around things. There'd be no way to prove that such a workaround had occurred, anyway. The better metric is whether the workaround was made using only namespace enigma_user: if you're editing things in namespace enigma, that's a good indicator you've modified code that should be public.
> How would it cease to exist?
In the same way as the others; we offer a whole lot of nice features, but a paid version offers all of our features and more, with bug fixes. Users will pay for the bug fixes, then become dependent on the new features. Then ENIGMA falls out of the picture. A less drastic example is WINE and Crossover Office. If WINE had been GPL, crossover office would either be free and donation based, or would not exist. The latter case might bother you, but it doesn't bother me, as I refuse to pay for a souped up WINE, not because I don't have the money, but because they're trying to sell me other people's work along with theirs. In WINE's case, that was not the intention. You can tell this wasn't in the spirit of the licensing because they then changed the licensing to prevent being leeched off of further. It's uncertain if ENIGMA would be so lucky, but to use an old cliché, I'd prefer to err on the side of caution.
> I don't want this project to die because of copyright issues someday. Even worse would be that game developers don't use the engine because they don't trust the chosen license to protect their code.
I don't see the demise of this project over copyright issues as a concern, namely because if someone is around to enforce the GPL, that person can be contacted to amend the license. As for game developers, they mostly go with the crowd: to my knowledge, only four users, yourself included, have taken the initiative to bring up the licensing at all. That isn't something we can rely on in the event that there certainly is a licensing issue, as there is now, but it is something we can lean on when the license is still in its infancy. MPL was new, once, too. Do you suppose Yoyo is using a conventional license for Game Maker? Or perhaps people trust them more because some of them already had to fork over money to use Game Maker?
> If anything, I see this project as a potential wielder of EEE tactics.
I agree. It may seem that I am being a hypocrite, but consider why EEE is bad. It's bad because it gives one organization control over a userbase, by making it so the users have no choice but to continue to use the product after they switch. In the case of a free-software project, this control goes away, because there's no longer one central authority that owns the code. This is in jeopardy if we don't choose a good license; ENIGMA could become such an entity if either us or a third party is able to control the software.
> What if someone wants to make a level editor separate from their game. I would define that as an application, but your definition might not allow for such a thing.
I am not sure how a level editor constitutes a related product; a level editor is related loosely to the IDE, but ENIGMA is a compiler and an engine. It has nothing to do with IDEs on its own; it simply goes well with one. But again, the manner in which we define a related product will be the crux of the entire operation. It prevents someone from distributing ENIGMA + features and bug fixes as a separate, proprietary product. This particular example also begs the question of whether this level editor would be distributed. If the level editor is for internal use by a company or organization (or just an individual), then they are free by both licenses to do whatever they want. Only when distributing this level editor to third parties would the question of "Is this a related product" enter into the equation, and our definition would say "no." I could easily pay a lawyer to write a definition for us.
> You can never be sure how someone will one day want to use the software you've created.
Again, we can always add rights, and never subtract them (except in later versions). If a user asks us, "Is this legal?" and the answer is "no," that's a relatively easy fix. If a third party finds a loophole and starts developing ENIGMA at full throttle as a proprietary application, we won't last long.
442
General ENIGMA / Re: Linking Exception Draft
« on: March 01, 2014, 11:18:28 pm »
The only developer I am concerned about reaching is forthevin. The others are still active in the community and are likely to have already read a good fraction of this topic; these include Robert, polygone, IsmAvatar, Harri (TheExDeus), and possibly Rusky and Aetherspawn. Other contacts include SirXemic and serprex, who essentially donated their code; they gave it to me for use under my own choice of license without any public record. I will contact them, but as it stands, they do not technically own enough code to make a claim.
Aside from them, RexHunter may own code in ENIGMA, and there's a small chance DatZach still owns code, but I think all of his was eventually rewritten. It was incorrectly licensed, anyway, and needed either deleted or dealt with, but he has since washed his hands of this project.
Now, for your other questions and concerns:
> Loopholes are more likely to be found and exploited. This risk could scare away potential users or developers of ENIGMA.
The idea is that if a loophole is found, ENIGMA is the more likely party to be screwed. There are a handful of developers and potentially hundreds of users; which of these parties is more likely to find and exploit a loophole? We are the ones who are more likely to take fire from this proposition; we are the ones who should be afraid of it.
> Every engine has bugs that need to be fixed. Waiting for an ENGIMA developer to find and fix the problem could take too long or never happen. What is a game developer supposed to do in that case? They may not have the skill to track down and fix a bug in the ENIGMA engine.
Let's assume no first-party developer knows the solution, and that all third-parties are not interested in running their own ENIGMA. There are then four possibilities, given as the Cartesian product of two options in two groups: Either a user or third-party developer can know the fix, and the license can either permit or deny the fix being proprietary.
0. User finds, license permits: The user enacts the fix; this is not a relevant scenario to this problem.
1. User finds, license denies: The user can contribute the bugfix to the ENIGMA project. It will be pulled under exempted GPL, and the user is free to use it.
2. Third-party finds, license permits: The third-party enacts this fix and sells it to the user. Hopefully the user needed this fix as bad as he or she thinks upon purchase. This is the case I disagree with.
3. Third-party finds, license denies: The third party can contribute the fix for free in an open-source manner, or offer to sell it to us directly. Otherwise, they sit on it for life. This is the case you disagree with, as it discourages people who are looking to make money off of people from "contributing."
> (Approved Interfaces 2.i) This is shortsighted and could slow or kill the growth of the project. Developers may ... change any number of things we can't predict.
Yes, it's true that this reduces the bus factor to a potentially significant degree; however, the worst-case of this is the GPL. It's easy to grant rights; it's impossible to take them away.
> How do you define a game? How does that definition differ from the definition of a game engine, framework or library?
The word "game" was used mostly to convey simplistic meaning; the phrase "any related product" is where we'd legally derive most of the power.
> requires free advertising of the ENIGMA project. Anyone who redistributes part or all of the ENIGMA project is required to share the project's source code. Anything that tells more people about this project is a very good thing.
This is the number-one bitch about Studio's licensing. Users don't want to signal to anyone that the code in their game might not be theirs; it makes people think they did less work. While we don't require graphical attribution, users in general don't want to share the details of the tools they used. It's a little unreasonable, yes, but it's human nature; most users are more willing to give credit when they are not forced to do so, out of pride instead of legal obligation.
> My point is: So what if they did?
If they did, ENIGMA could cease to exist. Look into the Embrace, Extend, Extinguish policy. It claimed many projects for the Microsoft Overlords™®; it only failed on Java because Sun came to the holy war prepared.
> Everyone needs to remember that ENIGMA is a community project and NOT a competing product.
Competition drives every market, especially the free software market. We have a lot of categories to compete in; I don't mind being outdone as long as both products are free.
> Publicity, users and volunteer developers are the life blood of ENIGMA; not money and control.
We've demonstrated a lack of interest in either of those things; what I am personally interested in is securing the freedom of our users to utilize our engine freely. We poured work into this project to see it succeed as an open-source development platform for all. Not to be consumed by a group willing to spend more money to make some money.
> If you've taken offense to anything I've written, I'm sorry. That was not my intention. I have a vested interest in ENIGMA as a game developer. I want to help give it the best chance to become the engine of choice among other game developers. Thanks for taking the time to read this.
I deal in facts, not emotion. I see the MPL as a promising candidate, but the fear of EEE is a reality against which Mozilla is much better fortified.
Perhaps it would be a good idea to dual-license the engine, with MPL being an alternative if and only if the combined work is not a "related product." We would focus our efforts on defining this related product, and any group which did not fall into this category could feel safe in the knowledge that their version is MPL-covered.
For the record, I have finished my edits. I accidentally pressed the "Post" button by hitting tab and then enter, as some sort of reflex.
Aside from them, RexHunter may own code in ENIGMA, and there's a small chance DatZach still owns code, but I think all of his was eventually rewritten. It was incorrectly licensed, anyway, and needed either deleted or dealt with, but he has since washed his hands of this project.
Now, for your other questions and concerns:
> Loopholes are more likely to be found and exploited. This risk could scare away potential users or developers of ENIGMA.
The idea is that if a loophole is found, ENIGMA is the more likely party to be screwed. There are a handful of developers and potentially hundreds of users; which of these parties is more likely to find and exploit a loophole? We are the ones who are more likely to take fire from this proposition; we are the ones who should be afraid of it.
> Every engine has bugs that need to be fixed. Waiting for an ENGIMA developer to find and fix the problem could take too long or never happen. What is a game developer supposed to do in that case? They may not have the skill to track down and fix a bug in the ENIGMA engine.
Let's assume no first-party developer knows the solution, and that all third-parties are not interested in running their own ENIGMA. There are then four possibilities, given as the Cartesian product of two options in two groups: Either a user or third-party developer can know the fix, and the license can either permit or deny the fix being proprietary.
0. User finds, license permits: The user enacts the fix; this is not a relevant scenario to this problem.
1. User finds, license denies: The user can contribute the bugfix to the ENIGMA project. It will be pulled under exempted GPL, and the user is free to use it.
2. Third-party finds, license permits: The third-party enacts this fix and sells it to the user. Hopefully the user needed this fix as bad as he or she thinks upon purchase. This is the case I disagree with.
3. Third-party finds, license denies: The third party can contribute the fix for free in an open-source manner, or offer to sell it to us directly. Otherwise, they sit on it for life. This is the case you disagree with, as it discourages people who are looking to make money off of people from "contributing."
> (Approved Interfaces 2.i) This is shortsighted and could slow or kill the growth of the project. Developers may ... change any number of things we can't predict.
Yes, it's true that this reduces the bus factor to a potentially significant degree; however, the worst-case of this is the GPL. It's easy to grant rights; it's impossible to take them away.
> How do you define a game? How does that definition differ from the definition of a game engine, framework or library?
The word "game" was used mostly to convey simplistic meaning; the phrase "any related product" is where we'd legally derive most of the power.
> requires free advertising of the ENIGMA project. Anyone who redistributes part or all of the ENIGMA project is required to share the project's source code. Anything that tells more people about this project is a very good thing.
This is the number-one bitch about Studio's licensing. Users don't want to signal to anyone that the code in their game might not be theirs; it makes people think they did less work. While we don't require graphical attribution, users in general don't want to share the details of the tools they used. It's a little unreasonable, yes, but it's human nature; most users are more willing to give credit when they are not forced to do so, out of pride instead of legal obligation.
> My point is: So what if they did?
If they did, ENIGMA could cease to exist. Look into the Embrace, Extend, Extinguish policy. It claimed many projects for the Microsoft Overlords™®; it only failed on Java because Sun came to the holy war prepared.
> Everyone needs to remember that ENIGMA is a community project and NOT a competing product.
Competition drives every market, especially the free software market. We have a lot of categories to compete in; I don't mind being outdone as long as both products are free.
> Publicity, users and volunteer developers are the life blood of ENIGMA; not money and control.
We've demonstrated a lack of interest in either of those things; what I am personally interested in is securing the freedom of our users to utilize our engine freely. We poured work into this project to see it succeed as an open-source development platform for all. Not to be consumed by a group willing to spend more money to make some money.
> If you've taken offense to anything I've written, I'm sorry. That was not my intention. I have a vested interest in ENIGMA as a game developer. I want to help give it the best chance to become the engine of choice among other game developers. Thanks for taking the time to read this.
I deal in facts, not emotion. I see the MPL as a promising candidate, but the fear of EEE is a reality against which Mozilla is much better fortified.
Perhaps it would be a good idea to dual-license the engine, with MPL being an alternative if and only if the combined work is not a "related product." We would focus our efforts on defining this related product, and any group which did not fall into this category could feel safe in the knowledge that their version is MPL-covered.
For the record, I have finished my edits. I accidentally pressed the "Post" button by hitting tab and then enter, as some sort of reflex.
443
Works in Progress / Re: Platform/bullet hell aesthetic demo
« on: March 01, 2014, 01:25:12 pm »
Very cool. The terrain is the same color as the background in places because chunks of the terrain are missing, TKG.
Is your terrain a big background, or some kind of grid structure? And have you considered making it destructible?
Is your terrain a big background, or some kind of grid structure? And have you considered making it destructible?
444
General ENIGMA / Re: Linking Exception Draft
« on: March 01, 2014, 12:58:02 pm »
Reading over the license, here's what I like:
2.4. Subsequent Licenses: I like that modifications to this license cannot magically grant additional rights; the GPL does not state this, to my knowledge; we just trust it will always be viral and open-source.
3.5. Application of Additional Terms: Overall good idea to mention.
5.2: I am glad to see some "liberty or death" in the mix.
General: The license is very clear about the differences in compliance requirements when using it internally within your organization vs distributing it externally; the GPL is also clear about that, but as my exception extends the GPL, it does not mention this, which is why TGMG was concerned above.
What I don't like, of course, remains the same.
Important bug fixes or replacement systems are, as they say, "encouraged" to be open-source, but are not required. We have no protection over the internals of the project; they can be used or replaced to circumvent major problems without causing the fix to be MPL. For instance, say there's a bug in one of our internal collision system functions that's causing issues in the whole collision system. A separate entity can delete that function at fault from the MPL-covered source code, then create a proprietary replacement in the same way a user creates proprietary game source code. They could then sell it along with ENIGMA as a bundle. If the fix was important enough and tricky enough to find, or if they did this for multiple issues, they could effectively maintain a paid version of ENIGMA with bug fixes. The saving grace is that they would have to provide the modified source to ENIGMA (identical to our source, but with the defective functions elided) to all users. And if I'm not mistaken, they could do this by mailing us the source code on a flash drive for the cost of the drive and the postage. But that would just be petty, and isn't really material to the problem.
The problem applies to any license not specifically tailored to our purpose. To demonstrate, the exception I wrote handles it in two ways.
The first is by voiding itself when the combined work is a game engine. This means that users are aware the code they are using is part of the ENIGMA engine, and is freely available and free to use and redistribute. If they are using a rebranded redistribution, they may not be aware of those rights.
The second way this is handled is by disallowing third-party code from accessing anything in namespace enigma.
The root of the problem is the separation of a game, an add-on system (as an extension or library), and a patch for an existing system. I don't personally mind individuals selling new systems, but I do mind them selling bug fixes. New systems—even paid ones—help ENIGMA: they give users options and in so doing encourage the community to grow. Paid bugfix versions of ENIGMA hurt ENIGMA. I wouldn't have as much of a problem with a paid bugfix that did not deliberately try to dilute or hide ENIGMA's community; Embrace, Extend, Extinguish style.
In fact, Sun's licensing is quite brilliant; Microsoft was unable to kill them because in order to call yourself Java, you must meet the complete standard and be compatible with the others. The basic idea behind this was the reason for those clauses I explained above. The more I think about it, the more I am convinced that (5) should not have been included at all, and (4) is the crux of the entire problem.
That said, the MPL seems to address most of our problems, and with the need for a new project to provide the modified source of ENIGMA, we at least alleviate the possibility of being totally buried; we can now only be mostly buried (A "request source code" form hidden within a big website). Of course, this whole issue isn't a problem at all for Mozilla, as they are, at this point, a trusted brand name, with money to pay people to fix bugs in the open-source version. We aren't... at the moment. So someone selling a version of ENIGMA with bug fixes is still a possibility, as opposed to someone trying to sell a fixed-up Firefox. By contrast, most browsers are free; most game engines are paid.
That said, you know my issues. If they do not strike anyone else (particularly other developers) as a big problem, I am also willing to compromise. The MPL seems to take care of the majority of our needs, replacing my clauses with an unexceptional need for our users to make ENIGMA's source available to their users. I suppose this is an acceptable burden to place on either party.
While I will not myself jump to embrace MPL as our new license, if the other developers are interested (their consent is strictly required), then this license (the MPL) has my support.
2.4. Subsequent Licenses: I like that modifications to this license cannot magically grant additional rights; the GPL does not state this, to my knowledge; we just trust it will always be viral and open-source.
3.5. Application of Additional Terms: Overall good idea to mention.
5.2: I am glad to see some "liberty or death" in the mix.
General: The license is very clear about the differences in compliance requirements when using it internally within your organization vs distributing it externally; the GPL is also clear about that, but as my exception extends the GPL, it does not mention this, which is why TGMG was concerned above.
What I don't like, of course, remains the same.
Important bug fixes or replacement systems are, as they say, "encouraged" to be open-source, but are not required. We have no protection over the internals of the project; they can be used or replaced to circumvent major problems without causing the fix to be MPL. For instance, say there's a bug in one of our internal collision system functions that's causing issues in the whole collision system. A separate entity can delete that function at fault from the MPL-covered source code, then create a proprietary replacement in the same way a user creates proprietary game source code. They could then sell it along with ENIGMA as a bundle. If the fix was important enough and tricky enough to find, or if they did this for multiple issues, they could effectively maintain a paid version of ENIGMA with bug fixes. The saving grace is that they would have to provide the modified source to ENIGMA (identical to our source, but with the defective functions elided) to all users. And if I'm not mistaken, they could do this by mailing us the source code on a flash drive for the cost of the drive and the postage. But that would just be petty, and isn't really material to the problem.
The problem applies to any license not specifically tailored to our purpose. To demonstrate, the exception I wrote handles it in two ways.
The first is by voiding itself when the combined work is a game engine. This means that users are aware the code they are using is part of the ENIGMA engine, and is freely available and free to use and redistribute. If they are using a rebranded redistribution, they may not be aware of those rights.
The second way this is handled is by disallowing third-party code from accessing anything in namespace enigma.
The root of the problem is the separation of a game, an add-on system (as an extension or library), and a patch for an existing system. I don't personally mind individuals selling new systems, but I do mind them selling bug fixes. New systems—even paid ones—help ENIGMA: they give users options and in so doing encourage the community to grow. Paid bugfix versions of ENIGMA hurt ENIGMA. I wouldn't have as much of a problem with a paid bugfix that did not deliberately try to dilute or hide ENIGMA's community; Embrace, Extend, Extinguish style.
In fact, Sun's licensing is quite brilliant; Microsoft was unable to kill them because in order to call yourself Java, you must meet the complete standard and be compatible with the others. The basic idea behind this was the reason for those clauses I explained above. The more I think about it, the more I am convinced that (5) should not have been included at all, and (4) is the crux of the entire problem.
That said, the MPL seems to address most of our problems, and with the need for a new project to provide the modified source of ENIGMA, we at least alleviate the possibility of being totally buried; we can now only be mostly buried (A "request source code" form hidden within a big website). Of course, this whole issue isn't a problem at all for Mozilla, as they are, at this point, a trusted brand name, with money to pay people to fix bugs in the open-source version. We aren't... at the moment. So someone selling a version of ENIGMA with bug fixes is still a possibility, as opposed to someone trying to sell a fixed-up Firefox. By contrast, most browsers are free; most game engines are paid.
That said, you know my issues. If they do not strike anyone else (particularly other developers) as a big problem, I am also willing to compromise. The MPL seems to take care of the majority of our needs, replacing my clauses with an unexceptional need for our users to make ENIGMA's source available to their users. I suppose this is an acceptable burden to place on either party.
While I will not myself jump to embrace MPL as our new license, if the other developers are interested (their consent is strictly required), then this license (the MPL) has my support.
445
General ENIGMA / Re: Linking Exception Draft
« on: March 01, 2014, 10:09:55 am »
Sorry for the delay; I was securing a career, and dealing with family matters. At first glance, the MPL sounds like exactly what we want. I'll read over the full text and get back with you on that.
I'll also see about posting the compilation sequence for you on the Wiki. But yes, I had every intention of leaving the compiler (and its parsers) under the unamended terms of the GPL.
To answer your compilation question as it pertains to licensing, code added to your code by the compiler is legally considered your code, in the way that code generated by InkScape is. I don't have control over the code it generates; only the engine code. I am trying to see to it that the new compiler allows you to choose the license that is placed atop these files.
Cheers
I'll also see about posting the compilation sequence for you on the Wiki. But yes, I had every intention of leaving the compiler (and its parsers) under the unamended terms of the GPL.
To answer your compilation question as it pertains to licensing, code added to your code by the compiler is legally considered your code, in the way that code generated by InkScape is. I don't have control over the code it generates; only the engine code. I am trying to see to it that the new compiler allows you to choose the license that is placed atop these files.
Cheers
446
General ENIGMA / Re: Self-Extracting ENIGMA Portable
« on: February 25, 2014, 02:44:47 pm »
To reiterate what has already been stated (or at least attempted), the point of bundling a standalone zip on Windows is so that users don't have to scour the Internet for ENIGMA's build dependencies. On all other operating systems, these dependencies can be installed from one place.
On GNU and BSD systems, you have access to a package manager on which one line of code can install all dependencies, a second line of code can obtain ENIGMA, and a third can obtain LGM. On these platforms, we will be (in the near future) distributing packages that do all of this for you via your package manager.
On Mac, the XCode installer comes with all ENIGMA's dependencies, as would be expected—the installer is in the "multiple gigabytes" size range.
So on Linux, we will be distributing packages sooner or later, but this package will be under a megabyte in size and will instruct the package manager on how to obtain all dependencies. On Apple, it's not legal for us to redistribute XCode, and tacky to try to use anything else, so we are sticking with the XCode install followed by regular checkout. On Windows, the installer's the best we can do until such a time as, eg, MinGW-get is operational, or we support codegen to some intermediate format (eg, LLVM or CIL). The latter is not scheduled to happen very promptly, and the former has been a rumor for years.
On GNU and BSD systems, you have access to a package manager on which one line of code can install all dependencies, a second line of code can obtain ENIGMA, and a third can obtain LGM. On these platforms, we will be (in the near future) distributing packages that do all of this for you via your package manager.
On Mac, the XCode installer comes with all ENIGMA's dependencies, as would be expected—the installer is in the "multiple gigabytes" size range.
So on Linux, we will be distributing packages sooner or later, but this package will be under a megabyte in size and will instruct the package manager on how to obtain all dependencies. On Apple, it's not legal for us to redistribute XCode, and tacky to try to use anything else, so we are sticking with the XCode install followed by regular checkout. On Windows, the installer's the best we can do until such a time as, eg, MinGW-get is operational, or we support codegen to some intermediate format (eg, LLVM or CIL). The latter is not scheduled to happen very promptly, and the former has been a rumor for years.
447
Developing ENIGMA / Changes in the new compiler
« on: February 24, 2014, 08:36:47 pm »
I never make changelogs; this is a personal mistake I'll attempt to work on. I am using this thread to document notes for developers and changes to the new compiler framework. I will place these changes in the Wiki after the fact. Excuse the Wiki list notation in the meantime; there's no sense in my formatting it with SMF's syntax if it's just going to be * in the end.
Notes:
* Files in the CompilerSource/JDI folder are meant to be read-only. This is a verbatim copy of the JDI repository; please make any changes there. We might end up renaming this to JDI-read-only to comply with the precedent set by other projects.
Changes:
* EnigmaStruct is no longer the main argument to compiler functions; it has been wrapped in a new class, compile_context.
** This class also contains the global object parsed_object *EGMglobal; the other parameter to most compile routines.
** This class also contains FILE *gameModule, the other parameter passed to most resource writing routines.
* There is now a separate resource_writer class to handle—you guessed it—writing resources. This is not only so we can support multiple languages, but also so we can support multiple resource export schemes (eg, internal, external). This is generated by the compile() method of the corresponding language adapter.
* Compile functions are now all snake_case, not some_SnakeCamel_Bastardization
Changing:
* The way JDI interfaces lexers and contexts needs changed—these are independent concepts.
Notes:
* Files in the CompilerSource/JDI folder are meant to be read-only. This is a verbatim copy of the JDI repository; please make any changes there. We might end up renaming this to JDI-read-only to comply with the precedent set by other projects.
Changes:
* EnigmaStruct is no longer the main argument to compiler functions; it has been wrapped in a new class, compile_context.
** This class also contains the global object parsed_object *EGMglobal; the other parameter to most compile routines.
** This class also contains FILE *gameModule, the other parameter passed to most resource writing routines.
* There is now a separate resource_writer class to handle—you guessed it—writing resources. This is not only so we can support multiple languages, but also so we can support multiple resource export schemes (eg, internal, external). This is generated by the compile() method of the corresponding language adapter.
* Compile functions are now all snake_case, not some_SnakeCamel_Bastardization
Changing:
* The way JDI interfaces lexers and contexts needs changed—these are independent concepts.
448
General ENIGMA / Re: Linking Exception Draft
« on: February 24, 2014, 07:46:47 pm »
"Bump."
My idea for (5):
My idea for (5):
Quote
5. The combined work is not itself a binary library intended for linking
into other software applications, except where this linking is done by the
operating system as its primary method of loading all software applications.
In such a case, this exception does not apply and may not be preserved:
all code is to be considered GPL.
449
Issues Help Desk / Re: Sprite_add crashes
« on: February 23, 2014, 02:46:21 pm »
We use APNG to store sprites. Or at least we did. It hasn't picked up.
450
Issues Help Desk / Re: How to use cyrillic fonts?
« on: February 19, 2014, 02:55:26 pm »
I think our best bet, then, is to use the "sparse ranges" storage method I named above, and let users choose the characters.
I'll point out that unicode contains logical groupings of common symbols. For example, A0-FF contain the Latin-1 symbols, which encompasses some of TKG's wishlist.
Latin-1 block: ¡¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ.
The bullet character is in with "General Punctuation," the block of unicode 2000 - 206F. These include a whole range of obscure punctuation marks, including the somewhat comical interrobang, and the common ellipsis.
The infinity character is in with the math symbols, unicode 2200 - 22FF. This contains every mathematical operator you can name, and a few that you can't.
Those three blocks total almost 500 characters. So we could allow checking an enable box for those ranges, but they'd bloat quickly, especially as users got checkmark happy.
What we could allow instead is a box for users to input characters they need. We'd then build a map from the chars in those boxes. But having checkable ranges is a good perk, nonetheless.
I'll point out that unicode contains logical groupings of common symbols. For example, A0-FF contain the Latin-1 symbols, which encompasses some of TKG's wishlist.
Latin-1 block: ¡¢£¤¥¦§¨©ª«¬®¯°±²³´µ¶·¸¹º»¼½¾¿ÀÁÂÃÄÅÆÇÈÉÊËÌÍÎÏÐÑÒÓÔÕÖ×ØÙÚÛÜÝÞßàáâãäåæçèéêëìíîïðñòóôõö÷øùúûüýþÿ.
The bullet character is in with "General Punctuation," the block of unicode 2000 - 206F. These include a whole range of obscure punctuation marks, including the somewhat comical interrobang, and the common ellipsis.
The infinity character is in with the math symbols, unicode 2200 - 22FF. This contains every mathematical operator you can name, and a few that you can't.
Those three blocks total almost 500 characters. So we could allow checking an enable box for those ranges, but they'd bloat quickly, especially as users got checkmark happy.
What we could allow instead is a box for users to input characters they need. We'd then build a map from the chars in those boxes. But having checkable ranges is a good perk, nonetheless.
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 »