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 »
466
Proposals / Re: Embed SWF?
« on: February 01, 2014, 11:58:19 pm »
SimpleMacines disables the flash tag by default (as well as the successful operation of the flash tag) because embedding arbitrary flash can be a security risk. A youtube tag is doable.
467
Developing ENIGMA / Re: Window Alpha and Message Box
« on: February 01, 2014, 04:42:24 pm »
They've already broken GML to the point where EDL will not at all be following suit. For instance, they now have some five types of reference characters for a pointerless language. The most absurd C++ implementations I've ever seen have four: *, &, && (C++11), %. And each of those represents a unique type of pointer or reference.
There's a difference between syntactical divergence and API divergence, but the point is that we at very least have to handle the former. The latter may as well be done on top of that.
Now, as to whether we embrace a byte for alpha or a float, I am unbiased. Robert prefers bytes for the sake of cards with terrible memory bandwidths, which ENIGMA should ideally cater to as well. A byte allows us to batch all four color components in a single word, instead of one word per component. The cost of this, of course, is conversion GPU-side (the color components have to be divided by 255f before they can be used). However, in the case of vertices with many different colors, this is in fact more efficient—the GPU can do thousands of these divisions at once. Obviously, your mileage may vary, there. When the color is only set once, as in the case of draw_set_color, it's better to do the division CPU-side where your clock is 3GHz and you're only doing it once.
There's a difference between syntactical divergence and API divergence, but the point is that we at very least have to handle the former. The latter may as well be done on top of that.
Now, as to whether we embrace a byte for alpha or a float, I am unbiased. Robert prefers bytes for the sake of cards with terrible memory bandwidths, which ENIGMA should ideally cater to as well. A byte allows us to batch all four color components in a single word, instead of one word per component. The cost of this, of course, is conversion GPU-side (the color components have to be divided by 255f before they can be used). However, in the case of vertices with many different colors, this is in fact more efficient—the GPU can do thousands of these divisions at once. Obviously, your mileage may vary, there. When the color is only set once, as in the case of draw_set_color, it's better to do the division CPU-side where your clock is 3GHz and you're only doing it once.
468
Programming Help / Re: Using external resources (loading/unloading)
« on: February 01, 2014, 03:32:41 am »Quote
7z would extract and save the result to disk, then later called by *_add to load them in memoryThat's exactly the problem. Using 7zip externally, your resources have to be read from disk (compressed, by 7z), written to disk (uncompressed, by 7z), then read from disk (uncompressed, by you). Using a 7zip library instead would allow you to read the resources once, compressed, and unpack them in memory.
I had not intended to allow users to specify their own formats for automated resource loading. A long time ago, I was going to allow users to specify their own encryption routines. There isn't much point to it, as anyone with a debugger can call your own load method to unpack your files; it will just make modding your games a science instead of an art. If your game can read it, so can your users.
A 7zip extension for ENIGMA would not take much effort to code. There hasn't been any interest in the proposition. For a while, ENIGMA used zlib on its resources. That's since been removed in favor of just letting users zip their modules, which produces better file sizes.
You can call C++ functions in ENIGMA the same way you call any other function. Just [snip=EDL]system("7zip your-options your-file")[/snip] will suffice.
I don't know of any antivirus that targets all programs that make shell calls. They'd probably not sell well. Game Maker was targeted for using ASProtect to unload an encrypted executable into memory—that's the kind of sneaky behavior antivirus programs look for.
469
Programming Help / Re: Using external resources (loading/unloading)
« on: February 01, 2014, 02:15:26 am »
You might be interested in reading my remarks on the matter from the Wiki To-do page. I'd consider .pak files to be a viable bundling mechanism.
You can easily call 7zip using execute_shell. If that function is not implemented, you can instead use C++'s system() function, which is a bit hacky, but viable. Using 7zip externally, however, will cost you additional disk operations, so I wouldn't personally recommend it.
You can easily call 7zip using execute_shell. If that function is not implemented, you can instead use C++'s system() function, which is a bit hacky, but viable. Using 7zip externally, however, will cost you additional disk operations, so I wouldn't personally recommend it.
470
Developing ENIGMA / Re: Window Alpha and Message Box
« on: February 01, 2014, 12:27:04 am »
...
(1) ISO RGB does not concern alpha. Maybe you meant to quote something from ISO that includes the letter "A" or specifically mentions phrases such as "alpha" or "opacity."
(2) We are in no way obligated to follow ISO on matters not related to our working set. The only standards we answer to are C++ (which they govern) and, here, Win32 (which they do not).
Win32 uses a byte, and that's a reason to prefer it ceteris paribus. Except for a few functions Yoyo has introduced in the last year, all of GM's functions which deal with opacity accept floats—even where all other attributes are unsigned byte.
I'm not opposed to the switch, but I'll be damned if I'm going to stand by and pretend it's anything but a switch. And if other members are opposed, that is a consideration.
Moreover, Game Maker never used ARGB. It has always been BGR internally and RGB in function notation. ENIGMA added a layer atop that which works with RGBA, which is more common. Their propensity to break existing traditions isn't a concern of mine—I assign it virtually no weight.
(1) ISO RGB does not concern alpha. Maybe you meant to quote something from ISO that includes the letter "A" or specifically mentions phrases such as "alpha" or "opacity."
(2) We are in no way obligated to follow ISO on matters not related to our working set. The only standards we answer to are C++ (which they govern) and, here, Win32 (which they do not).
Win32 uses a byte, and that's a reason to prefer it ceteris paribus. Except for a few functions Yoyo has introduced in the last year, all of GM's functions which deal with opacity accept floats—even where all other attributes are unsigned byte.
I'm not opposed to the switch, but I'll be damned if I'm going to stand by and pretend it's anything but a switch. And if other members are opposed, that is a consideration.
Moreover, Game Maker never used ARGB. It has always been BGR internally and RGB in function notation. ENIGMA added a layer atop that which works with RGBA, which is more common. Their propensity to break existing traditions isn't a concern of mine—I assign it virtually no weight.
471
Developing ENIGMA / Re: Window Alpha and Message Box
« on: January 31, 2014, 02:55:28 pm »
The point here is consistency. If the windows function you are using accepts a byte, then fine, but otherwise, there is no point to breaking the trend.
A blue ball icon is easy. Issue is, without the white E, it looks like this:
Conventionally, engines are represented with a gear. But it's not very flattering; it looks like this:
If you're feeling fancy, I'd recommend something more like this:
And if you insist on the icon being a controller, at least use something like this:
/
A blue ball icon is easy. Issue is, without the white E, it looks like this:
Conventionally, engines are represented with a gear. But it's not very flattering; it looks like this:
If you're feeling fancy, I'd recommend something more like this:
And if you insist on the icon being a controller, at least use something like this:
/
472
Developing ENIGMA / Re: Window Alpha and Message Box
« on: January 31, 2014, 10:17:24 am »
Regarding alpha:
I don't care how you feel about using a float for alpha. If you don't use a float, you're wasting three bytes of alignment, anyway.
Regarding the controller icon:
Even worse. I don't care what you make the icon; don't make it anything that even remotely implies we are supporting a brand. Especially not that brand. The icon I made that was nothing but circles reminded you of .NET, so you replaced it with a goddamn XBox controller. Let me tell you, the XBox reminds of of .NET.
I don't care how you feel about using a float for alpha. If you don't use a float, you're wasting three bytes of alignment, anyway.
Regarding the controller icon:
Even worse. I don't care what you make the icon; don't make it anything that even remotely implies we are supporting a brand. Especially not that brand. The icon I made that was nothing but circles reminded you of .NET, so you replaced it with a goddamn XBox controller. Let me tell you, the XBox reminds of of .NET.
473
Developing ENIGMA / Re: Window Alpha and Message Box
« on: January 31, 2014, 08:47:33 am »
Not bad. Conventionally, alpha is a float. And why is the game icon a sixaxis controller?
474
Works in Progress / Re: Dungeon Blabber
« on: January 28, 2014, 11:09:34 am »
Have you considered just rendering a few of your models in that contrast? You seem to be attached to the way it makes some things look, while ignoring the fact that other objects into unrecognizable meshes of light black and white. The final render you posted looks beautiful; the two before it can't be understood visually. The skulls in particular look good with the high contrast, as it brings out the texture.
475
Issues Help Desk / Re: Is there any way of picking the C++ code before it is passed to the compiler
« on: January 26, 2014, 01:49:35 pm »
C++ code is always generated, and can be sent to any compiler. You won't want to edit the generated code; it is not pretty.
The compilers the code can be sent to are listed under Compilers/PLATFORM/*.ey. If you like, you can create a new one for a different compiler. You can then select your preferred compiler from Enigma Settings, under the API tab.
The compilers the code can be sent to are listed under Compilers/PLATFORM/*.ey. If you like, you can create a new one for a different compiler. You can then select your preferred compiler from Enigma Settings, under the API tab.
476
Issues Help Desk / Re: There was an issue loading the project
« on: January 25, 2014, 04:36:23 pm »
If creating a duplicate object manually fixes the problem, then there's likely an issue in the code LGM is sending ENIGMA. So there's an invisible problem in the code that was imported.
477
ALLCAPS BOARD / Re: High Contrast - Skulls Dungeons - Bryce 7 - and my confession !
« on: January 25, 2014, 02:43:24 pm »
I see you telling him too much contrast is "terrible," but aside from that I really don't see any aggression. He did, on another post in this board, ask you to stop replying to him, which isn't exactly polite, but falls quite short of this outright flame war you are trying to brew. You aren't going to get along with everyone you meet; that isn't justification for starting a topic dedicated to bashing them pointlessly.
478
ALLCAPS BOARD / Re: High Contrast - Skulls Dungeons - Bryce 7 - and my confession !
« on: January 25, 2014, 02:28:40 pm »
The only one calling anyone else names is you, Jimmy. I don't care if you think he's done something to deserve you openly flaming him; it reflects poorly on you. I'd recommend for both of your sakes that you not do so.
479
ALLCAPS BOARD / Re: High Contrast - Skulls Dungeons - Bryce 7 - and my confession !
« on: January 25, 2014, 12:41:20 pm »
Jimmy, don't be an ass. It does not behoove you. And in general, it isn't very flattering.
480
General ENIGMA / Re: HTML5 based IDE
« on: January 22, 2014, 10:17:03 am »
A static page is doable; JDI can generate that, no sweat.
As for Bison... you might be better off just emscripten'ing the piece of the compiler that actually builds the AST. If that succeeds, the code at least checks out from a context-free perspective.
I think a good approach to those server models is to code the libraries as though they are to be used natively (ie, application→library), then instead, code a new library that calls a remote application to work with them (application→networking library → server application→library), so that the actual code for the file and ENIGMA server isn't actually aware it's ever remote.
Also, keep plans for multiple ENIGMA servers at heart—if a server is doing the compiling, there's no reason not to have a farm of (virtual) servers running each OS. That way you can build for all, on-demand.
As for Bison... you might be better off just emscripten'ing the piece of the compiler that actually builds the AST. If that succeeds, the code at least checks out from a context-free perspective.
I think a good approach to those server models is to code the libraries as though they are to be used natively (ie, application→library), then instead, code a new library that calls a remote application to work with them (application→networking library → server application→library), so that the actual code for the file and ENIGMA server isn't actually aware it's ever remote.
Also, keep plans for multiple ENIGMA servers at heart—if a server is doing the compiling, there's no reason not to have a farm of (virtual) servers running each OS. That way you can build for all, on-demand.
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 »