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 »
421
General ENIGMA / Re: Please vote for ENIGMA's new license
« on: March 20, 2014, 08:14:08 pm »
LGPL is too strong. It forces binaries to be separable—ENIGMA would have to be a DLL, and no one likes that. It also makes it legally impossible for us to use link-time inlining. This has proven a problem for MinGW in the past—you'll notice most of the GNU headers don't even use LGPL.
This is in addition to the fact that it offers little more protection for us than MPL.
This is in addition to the fact that it offers little more protection for us than MPL.
422
General ENIGMA / Re: Realtime 3D Shadows, Animations, & Outlined Cel Shading
« on: March 20, 2014, 07:34:56 pm »
You keep speaking of GL and DX as though their state of being separate entities implies the existence of two parallel universes. Let me be more clear.
Look slightly to your left. You should notice that outside of this window, there is a small plastic frame. Follow that frame downward until you see a thick, dark wire. Follow the wire downward. You should see it join to a somewhat small, metal box with lights on it. If you were to open the box, you would find several thin boards with small conductive engravings in them. The board closest to the wire you were just following is special. It contains two even smaller boards which contain hundreds of microscopic boards. Every few nanoseconds, these boards perform a mathematical operation. The mathematical operation that is performed is governed by a piece of software. THIS IS WHAT WE'RE TRYING TO FIND.
I don't know if that software is a driver. I don't know if that software is owned by Microsoft, or if it's part of GL, or what. SOMEONE IS TRANSFORMING THE COORDINATES, because the little box inside your computer ONLY HAS ONE BEHAVIOR. Maybe DirectX is doing that because they always felt the top-left should be the logical (0,0). Maybe GL Is doing that because they want the API to be consistent across all GL devices. I DON'T CARE WHO IS DOING IT. THERE IS MATH BEING DONE, ALREADY. We need to FIND that math. If the math is being done by GL, we need to REPLACE that math or REMOVE that math, if possible. If that math is being done by DirectX, we need to REPLICATE that math.
Once again: the chip in the box connected to the device displaying this text is performing PRECISELY the operations requested of it by the software. THESE TWO PIECES OF SOFTWARE, DIRECTX AND OPENGL, ARE SOMEHOW EFFECTING DIFFERENT BEHAVIORS FOR THE SAME INPUT COORDINATES. Our task is to find out who it is and do the most efficient thing possible to make ours look like DirectX.
The solutions already discussed are not adequate because they require intervention by either the ENIGMA maintainers or by the user. The former is only a problem because we allow the user to write shader scripts just as we do, and so anything we do in the engine, we have to also force the user to do. In the case that DirectX or GL is modifying the shader scripts at compile time to use their preferred coordinate system, we can and should do the same for us and for the user alike. In the case that there is a always a matrix multiply, WHICH WOULD BE CONDUCTED in the aforementioned chip, we need to modify that matrix.
Edit:
The research I have done has been largely inconclusive, but is leading me to the conclusion that all of this is handled in the driver in a way that we cannot touch it. It seems that each vendor is free to choose their implementation, and support the two sampling methods as they see fit, with neither API offering a way to switch between them. I'm going to continue asking around to see if I can get a definitive "no" on the issue. In which case, we run the risk of not only uglying up code, but having generated shader code actually doing operations that cancel each other out. I'm hoping cards optimize such trife out, but I can't be certain at this point.
Look slightly to your left. You should notice that outside of this window, there is a small plastic frame. Follow that frame downward until you see a thick, dark wire. Follow the wire downward. You should see it join to a somewhat small, metal box with lights on it. If you were to open the box, you would find several thin boards with small conductive engravings in them. The board closest to the wire you were just following is special. It contains two even smaller boards which contain hundreds of microscopic boards. Every few nanoseconds, these boards perform a mathematical operation. The mathematical operation that is performed is governed by a piece of software. THIS IS WHAT WE'RE TRYING TO FIND.
I don't know if that software is a driver. I don't know if that software is owned by Microsoft, or if it's part of GL, or what. SOMEONE IS TRANSFORMING THE COORDINATES, because the little box inside your computer ONLY HAS ONE BEHAVIOR. Maybe DirectX is doing that because they always felt the top-left should be the logical (0,0). Maybe GL Is doing that because they want the API to be consistent across all GL devices. I DON'T CARE WHO IS DOING IT. THERE IS MATH BEING DONE, ALREADY. We need to FIND that math. If the math is being done by GL, we need to REPLACE that math or REMOVE that math, if possible. If that math is being done by DirectX, we need to REPLICATE that math.
Once again: the chip in the box connected to the device displaying this text is performing PRECISELY the operations requested of it by the software. THESE TWO PIECES OF SOFTWARE, DIRECTX AND OPENGL, ARE SOMEHOW EFFECTING DIFFERENT BEHAVIORS FOR THE SAME INPUT COORDINATES. Our task is to find out who it is and do the most efficient thing possible to make ours look like DirectX.
The solutions already discussed are not adequate because they require intervention by either the ENIGMA maintainers or by the user. The former is only a problem because we allow the user to write shader scripts just as we do, and so anything we do in the engine, we have to also force the user to do. In the case that DirectX or GL is modifying the shader scripts at compile time to use their preferred coordinate system, we can and should do the same for us and for the user alike. In the case that there is a always a matrix multiply, WHICH WOULD BE CONDUCTED in the aforementioned chip, we need to modify that matrix.
Edit:
The research I have done has been largely inconclusive, but is leading me to the conclusion that all of this is handled in the driver in a way that we cannot touch it. It seems that each vendor is free to choose their implementation, and support the two sampling methods as they see fit, with neither API offering a way to switch between them. I'm going to continue asking around to see if I can get a definitive "no" on the issue. In which case, we run the risk of not only uglying up code, but having generated shader code actually doing operations that cancel each other out. I'm hoping cards optimize such trife out, but I can't be certain at this point.
423
General ENIGMA / Re: Please vote for ENIGMA's new license
« on: March 20, 2014, 07:15:05 pm »
Indeed it was.
424
General ENIGMA / Re: Please vote for ENIGMA's new license
« on: March 20, 2014, 06:42:56 pm »
That's untrue. Even now, you are free to sell your games made in ENIGMA. The catch is that you must provide the full source to the game under the GPL license, thus allowing the free redistribution of it by third parties. That will remain the case until we fix this license issue.
Make no mistake, though. People sell free software—that's the whole reason behind this "Libre" versus "Gratis" deal. Free software is free as in freedom; it is liberated. You can still charge any amount of money per copy, and don't have to distribute the source if you don't distribute a binary. Just be aware that distributing a binary of a GPL program entitles people to its source, and that would make them free to offer it for download, too.
Facing facts, if people want your shit for free, they aren't gonna have to pay. Allowing you to relicense your code just gives you the legal authority to shut down websites distributing your game without your permission.
It's a double-edged sword; you're allowed to go sell copies of ENIGMA to people. But only an idiot would pay you for a copy when they can get it from us for free. And since it's GPL, if you modify it, you have to share your modifications with us. So once again, you'd be stupid to buy it from someone else, unless we simply refused to pull their changes. And if their changes were good enough to warrant you buying their version, that's our loss.
If and when we switch to MPL, we'll lose that benefit. You'll be completely able to keep your game's source to yourself; you'll just have to distribute ENIGMA's source, which is as simple as giving a repository link and revision number, or forking it on GitHub. But on the flip side, people who improve ENIGMA will be able to sell the better versions as their own, and so we'll have to compete with our own product. They'll offer all our features, so the price will be our only leverage. But what's funny is, it'd cost, to be very generous, $200/day to replace this entire team. So if the company did what Yoyo did, for example, and took out a $2M loan, they could pay to match us for around 30 years. Or blow us out of the water for four, at which point we'd be extinct.
Make no mistake, though. People sell free software—that's the whole reason behind this "Libre" versus "Gratis" deal. Free software is free as in freedom; it is liberated. You can still charge any amount of money per copy, and don't have to distribute the source if you don't distribute a binary. Just be aware that distributing a binary of a GPL program entitles people to its source, and that would make them free to offer it for download, too.
Facing facts, if people want your shit for free, they aren't gonna have to pay. Allowing you to relicense your code just gives you the legal authority to shut down websites distributing your game without your permission.
It's a double-edged sword; you're allowed to go sell copies of ENIGMA to people. But only an idiot would pay you for a copy when they can get it from us for free. And since it's GPL, if you modify it, you have to share your modifications with us. So once again, you'd be stupid to buy it from someone else, unless we simply refused to pull their changes. And if their changes were good enough to warrant you buying their version, that's our loss.
If and when we switch to MPL, we'll lose that benefit. You'll be completely able to keep your game's source to yourself; you'll just have to distribute ENIGMA's source, which is as simple as giving a repository link and revision number, or forking it on GitHub. But on the flip side, people who improve ENIGMA will be able to sell the better versions as their own, and so we'll have to compete with our own product. They'll offer all our features, so the price will be our only leverage. But what's funny is, it'd cost, to be very generous, $200/day to replace this entire team. So if the company did what Yoyo did, for example, and took out a $2M loan, they could pay to match us for around 30 years. Or blow us out of the water for four, at which point we'd be extinct.
425
General ENIGMA / Re: Please vote for ENIGMA's new license
« on: March 20, 2014, 12:52:26 pm »
All open-source licenses allow that sort of collaboration, but none of them force it. So no one has to give back to us, or keep their fork of ENIGMA free to use. We want to allow proprietary extensions of ENIGMA that remain exclusively extensions: those that encourage the use of ENIGMA with or without the extension. I want to disallow a proprietary extension of ENIGMA that fixes problems we're facing and forces users to stick with their version, if they don't want bombarded with bugs.
Unexempted GPL makes it harder to sell games, as users are legally entitled to share and distribute them as they see fit. Exempted GPL has the possibility of backfiring if we're not careful, and so behaving like the GPL, but otherwise (in the case of no loopholes) behaves as you'd expect. The MPL behaves as you'd expect, except users have to give us credit for their games, and we're still vulnerable to being outdone with our own code. MIT/zlib/WTFPL/Unlicense behave how you'd expect, and we're completely vulnerable to being outdone with our own code.
Unexempted GPL makes it harder to sell games, as users are legally entitled to share and distribute them as they see fit. Exempted GPL has the possibility of backfiring if we're not careful, and so behaving like the GPL, but otherwise (in the case of no loopholes) behaves as you'd expect. The MPL behaves as you'd expect, except users have to give us credit for their games, and we're still vulnerable to being outdone with our own code. MIT/zlib/WTFPL/Unlicense behave how you'd expect, and we're completely vulnerable to being outdone with our own code.
426
General ENIGMA / Re: Please vote for ENIGMA's new license
« on: March 19, 2014, 01:32:39 pm »
Yes, the whole situation with a custom license is sticky. I think Gary put it best; we want to stop ENIGMA clones that stop ENIGMA clones. Our inability to put that to a license is certainly problematic.
Also, EEE isn't related to standards, but to features in general. Anyone who can offer all ENIGMA's features (by copying ENIGMA) and additional features on top of that (by doing some closed-source development) poses a risk to the project, as they can continue to feed off of any progress we would make, while giving nothing back. We'd be unable to compete, because our changes would be their changes and their changes would be their changes. The point of stopping ENIGMA clones that stop ENIGMA clones is to ensure that our changes are their changes and their changes are our changes. Mutual benefit, where competition between us benefits both of us and the whole community. If we're being outperformed by a proprietary product in every way, the community doesn't benefit, either.
Still, I'm interested in everyone's thoughts on the matter, so by all means, be expressive.
Also, EEE isn't related to standards, but to features in general. Anyone who can offer all ENIGMA's features (by copying ENIGMA) and additional features on top of that (by doing some closed-source development) poses a risk to the project, as they can continue to feed off of any progress we would make, while giving nothing back. We'd be unable to compete, because our changes would be their changes and their changes would be their changes. The point of stopping ENIGMA clones that stop ENIGMA clones is to ensure that our changes are their changes and their changes are our changes. Mutual benefit, where competition between us benefits both of us and the whole community. If we're being outperformed by a proprietary product in every way, the community doesn't benefit, either.
Still, I'm interested in everyone's thoughts on the matter, so by all means, be expressive.
427
General ENIGMA / Re: Realtime 3D Shadows, Animations, & Outlined Cel Shading
« on: March 19, 2014, 01:22:35 pm »
Are textures still upside-down when used in shader scripts? If they are, then someone is doing more work here. Hardware is hardware. The hardware is only doing one thing, so if our behavior differs from DirectX's, we need to find the reason, not have everyone hack around it. Having users say 1-y in a script is a hack. Using 1-y in our functions is a hack. Flipping the textures in memory is a hack. One of the following is true:
1. GLSL does not exhibit this problem.
2. The sampler always multiplies by a matrix.
3. G/HLSL is tweaking the sampler calls at compile time.
Whichever it is, we need to find it and either fix it or replicate.
1. GLSL does not exhibit this problem.
2. The sampler always multiplies by a matrix.
3. G/HLSL is tweaking the sampler calls at compile time.
Whichever it is, we need to find it and either fix it or replicate.
428
General ENIGMA / Re: Cutscenes working in Iji on ENIGMA (experimental)
« on: March 18, 2014, 09:01:07 am »
Very nice. I had looked at Iji a while back, noted all the missing features and incompatibilities, and labeled it a lost cause, as great a target as it is for support (given its large following). I am interested in the success of this endeavor; let me know if you need anything in particular.
429
Issues Help Desk / Re: Odd Var Leak
« on: March 14, 2014, 09:52:39 am »
Not sure how I missed this topic. The strange behavior in room creation code is because the room creation code is not associated with an object; w and h do not exist, so they end up referring to the same address (instead of referring to NULL and giving you a segmentation fault). This shouldn't be happening, though, as I declare missing variables in room creation codes. Probably some sort of regression.
430
General ENIGMA / Re: FYI Linux*100 < Mac÷100
« on: March 13, 2014, 09:46:52 am »
We were going to put the same notice on the Windows page, but it gets too much traffic for it to have lasted.
Truth be told, all these operating systems suck. The policy is "Pick your poison."
Truth be told, all these operating systems suck. The policy is "Pick your poison."
431
Issues Help Desk / Re: 3D functions and capabilities
« on: March 12, 2014, 01:29:01 pm »
Our philosophy is to maintain backward compatibility with GM where doing so is free—that is, where it does not affect the potential or usability of the project. Our target compatibility is GM6, with which our current track record is phenomenal. Where compatibility would hinder progress, we try to offer an option. Where options would be too numerous, we begin to drop compatibility.
As an example, we will never, ever, ever support Dailly's stupid-fuck reference ideas. We may eventually write something that optionally strips them from your game, in the event that doing so will effect the correct behavior. We adopted the audio_ functions because they compliment the sound_ functions. We offer optional compatibility modes for treatment of old GM operators, such as ++, and for treatment of string literals. These will eventually default to the C++ equivalents.
As an example, we will never, ever, ever support Dailly's stupid-fuck reference ideas. We may eventually write something that optionally strips them from your game, in the event that doing so will effect the correct behavior. We adopted the audio_ functions because they compliment the sound_ functions. We offer optional compatibility modes for treatment of old GM operators, such as ++, and for treatment of string literals. These will eventually default to the C++ equivalents.
432
Issues Help Desk / Re: 3D functions and capabilities
« on: March 12, 2014, 09:21:35 am »
I'm sure GM:Studio uses standard everything for their shaders. If not, they do so at their own peril; I would never consent to following them off such an obvious cliff.
433
Issues Help Desk / Re: 3D functions and capabilities
« on: March 11, 2014, 09:45:30 pm »
You'll have to ask Robert about shaders, and Harri why GL3 is broken. Or maybe Robert fixed GL3 in that pull request of his I keep putting off because I hate cherry-picking commits. As for the red/blue problem... does this happen in all games? I don't have an explanation for that, unless someone switched out the old code to use a different glColor 'overload.'
434
Tips, Tutorials, Examples / Re: Conway's Game of Life
« on: March 11, 2014, 10:55:19 am »
An entire Qt port could be made with relatively little effort. It would be an entity in both Platforms/ and Widget_Systems/. It's likely that this could be done without a Qt port of Platforms/, ie, in the same way that I did for GTK, but that wouldn't be my recommendation as, unlike GTK, Qt actually supports OpenGL contexts natively and would therefore be compatible with the GL graphics systems.
435
Issues Help Desk / Re: Problems on old linux again
« on: March 10, 2014, 07:36:28 pm »
Yeah, I think Robert decided that 1.6 was old hat and everyone should have 1.7 by now.
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 »