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 »
841
Off-Topic / Re: Windows blows egg water
« on: February 23, 2013, 01:10:46 pm »
I enjoy my 750GB HDD. And I have a second-generation Intel i7. Not that the processor is a major need for the purpose of loading OS files into memory; that mostly falls on disk I/O. Ubuntu boots in somewhere between 15 and 20 seconds on it. Windows boots in about 30, and then spends the next five minutes learning to not be a slow whale. Meanwhile, I can be running programs on Ubuntu as soon as it is booted.
Of course, arguing for Ubuntu against Windows isn't quite as easy as arguing for other distributions, many of which are good to go in far less than ten seconds on a HDD. Arch is good about that.
Of course, arguing for Ubuntu against Windows isn't quite as easy as arguing for other distributions, many of which are good to go in far less than ten seconds on a HDD. Arch is good about that.
842
Off-Topic / Re: Windows blows egg water
« on: February 23, 2013, 12:12:42 pm »
It's all fun and games until someone takes the thread seriously.
843
Off-Topic / Re: Windows blows egg water
« on: February 23, 2013, 10:46:48 am »
It hasn't applied to most distros in years. Ubuntu, Fedora, Debian, SUSE... all of them have shipped with a desktop environment and loads of other pre-loaded goodies for ages. The only popular distro that doesn't is Arch, and I suppose Gentoo (if you consider it to be popular).
I think the issue is that it scares people if buttons have more than one purpose, which explains why Windows has no built-in hotkey customization or adequate window manipulation schemes. Of course, you could argue that it just tries to ship as lean as possible, but then, why is it that Ubuntu's ready to rock as soon as I log in, while I have to give Windows five minutes to finish running all its startup bullshit?
I think the issue is that it scares people if buttons have more than one purpose, which explains why Windows has no built-in hotkey customization or adequate window manipulation schemes. Of course, you could argue that it just tries to ship as lean as possible, but then, why is it that Ubuntu's ready to rock as soon as I log in, while I have to give Windows five minutes to finish running all its startup bullshit?
844
Proposals / Overloads in other languages
« on: February 22, 2013, 12:17:22 pm »
This is mostly for TGMG/whoever furthers EGMJS.
That will be able to translate directly to JDI's storage classes. Essentially, some JS interpreter will use reflection to read through and copy those values from each function into the appropriate storage classes in JDI. Not a huge deal.
This is an optional feature of the engine, but the new EDL specification does support user-overloaded functions.
The pretty printer must select the correct overload when outputting code. JDI will provide helper functions to do this.
Code: (JavaScript) [Select]
function my_overloaded_function(x,y) {
// code
}
my_overloaded_function.argc_min = 2;
my_overloaded_function.argc_max = 2;
my_overloaded_function.overloads = [];
my_overloaded_function.overloads[0] = function(x,y,z) {
// code
};
my_overloaded_function.overloads[0].argc_min = 3;
my_overloaded_function.overloads[0].argc_max = 3;
That will be able to translate directly to JDI's storage classes. Essentially, some JS interpreter will use reflection to read through and copy those values from each function into the appropriate storage classes in JDI. Not a huge deal.
This is an optional feature of the engine, but the new EDL specification does support user-overloaded functions.
The pretty printer must select the correct overload when outputting code. JDI will provide helper functions to do this.
845
Off-Topic / Re: Windows blows egg water
« on: February 22, 2013, 10:13:14 am »
There some Linux manual I forgot to print?
Or are you talking about man? Because man's only use is when you forget the arguments to compression programs.
Or are you talking about man? Because man's only use is when you forget the arguments to compression programs.
846
Issues Help Desk / Re: ERROR: Unable to acces jarfile l*.jar
« on: February 22, 2013, 12:21:12 am »
For those who are interested, I have built a new ENIGMA.exe and uploaded it here:
https://dl.dropbox.com/u/1052740/ENIGMA.exe-13-02-21.zip
Let me know how it works out.
I haven't yet decided what to do about the issue, but this should be a decent fix for now. This wouldn't be a serious problem if I could talk Gary or someone into writing a script/cron job/whatever to prepare release zips for us.
https://dl.dropbox.com/u/1052740/ENIGMA.exe-13-02-21.zip
Let me know how it works out.
I haven't yet decided what to do about the issue, but this should be a decent fix for now. This wouldn't be a serious problem if I could talk Gary or someone into writing a script/cron job/whatever to prepare release zips for us.
847
Proposals / Re: Games category
« on: February 21, 2013, 03:17:00 pm »
Yep. We'll talk about your Completed Games board later, after the community (members and code) is more developed. The EDC has a lot of growing to do, and when it is finished, I think it would make such a board obsolete.
I do like your points regarding the WIP board, though.
I do like your points regarding the WIP board, though.
849
Proposals / Re: Games category
« on: February 20, 2013, 07:43:22 pm »
What would the forums offer over the EDC?
I don't want to promote daydreaming about games on the forums. That's something they did on the Stencyl forums back when Stencyl was vaporware instead of just unremarkable. We have a "Teams" subforum for "hey, let's do something neat."
I don't want to promote daydreaming about games on the forums. That's something they did on the Stencyl forums back when Stencyl was vaporware instead of just unremarkable. We have a "Teams" subforum for "hey, let's do something neat."
850
This is a reminder to myself to do two things when I finally get around to writing that C++ pretty-printer:
1) Place [snip]#line[/snip] directives before each piece of code.
2) Have the pretty-printer ensure that the lines of C++ match up with the original lines of EDL.
This will ensure that error reporting by GCC can be indicated in the correct piece of code.
If anyone is interested in a homework assignment, I am interested to know if the table used by GDB is generated according to the [snip]#line[/snip] directive as well. If it is, this means that breakpoints can be set as easily as passing "break object0_event_<whatever>:<linenum>" to GDB. Not certain that is the case, but a little testing should confirm it.
1) Place [snip]#line[/snip] directives before each piece of code.
2) Have the pretty-printer ensure that the lines of C++ match up with the original lines of EDL.
This will ensure that error reporting by GCC can be indicated in the correct piece of code.
If anyone is interested in a homework assignment, I am interested to know if the table used by GDB is generated according to the [snip]#line[/snip] directive as well. If it is, this means that breakpoints can be set as easily as passing "break object0_event_<whatever>:<linenum>" to GDB. Not certain that is the case, but a little testing should confirm it.
851
General ENIGMA / Re: The particle systems extension is complete
« on: February 10, 2013, 10:38:19 am »
> I think it would make sense if each particle system implementation can be restricted to specific graphics systems
Certainly; existing systems name such dependencies all the time. Some might even depend on physics or collision systems, or audio systems. Who knows.
> that a GLSL particle system implementation can only be used together with OpenGL and OpenGL ES graphics systems, and a HLSL particle system implementation can only be used together with a DirectX graphics system
What may be a better idea is to start devising a shader language specifically for ENIGMA which can be compiled to all of HLSL, GLSL, and whatever GLES's GLSL is called (I know little about GLES). This way, a GPU-side particle system could be used with any graphics system which supports compiling ESL, or EASL, or whatever we would call it.
I don't know why there isn't a unified shader language already. My guess is that either there is, and I don't know of it, or there isn't, because shader languages are already so similar that the real issue is with all the other aspects of the graphics API.
Of course, I probably shouldn't be scheming right now given that I barely have the time to write up this post. It's just a consideration (And it happens to be a consideration I've had for some time, though not with regard to particle systems).
Anyway, as far as what you should do next, it's up to you. I'm not very concerned with missing GM functions, at this point, as the missing ones largely depend on features of ENIGMA that just aren't there yet. My goals are a bit lofty, but if you like, I can put them up on the wiki over the course of the next couple days.
Certainly; existing systems name such dependencies all the time. Some might even depend on physics or collision systems, or audio systems. Who knows.
> that a GLSL particle system implementation can only be used together with OpenGL and OpenGL ES graphics systems, and a HLSL particle system implementation can only be used together with a DirectX graphics system
What may be a better idea is to start devising a shader language specifically for ENIGMA which can be compiled to all of HLSL, GLSL, and whatever GLES's GLSL is called (I know little about GLES). This way, a GPU-side particle system could be used with any graphics system which supports compiling ESL, or EASL, or whatever we would call it.
I don't know why there isn't a unified shader language already. My guess is that either there is, and I don't know of it, or there isn't, because shader languages are already so similar that the real issue is with all the other aspects of the graphics API.
Of course, I probably shouldn't be scheming right now given that I barely have the time to write up this post. It's just a consideration (And it happens to be a consideration I've had for some time, though not with regard to particle systems).
Anyway, as far as what you should do next, it's up to you. I'm not very concerned with missing GM functions, at this point, as the missing ones largely depend on features of ENIGMA that just aren't there yet. My goals are a bit lofty, but if you like, I can put them up on the wiki over the course of the next couple days.
852
General ENIGMA / Re: The particle systems extension is complete
« on: February 09, 2013, 05:51:04 pm »
I'm very pleased to hear that, forthevin!
On the subject of the sovereignty of your particle system... How does the idea of a Particle_Systems directory strike you? We'd place it either in the root of SHELL or in the GL folder. Probably the former, since some particle systems may be written which use exclusively draw_* functions, though I'm not sure who would do such a thing.
What I more believe may end up happening in the future is providing a different particle system controller that moves your particle functions to the GPU via GLSL, in the interest of performance. The GPU particle functions would be more limited (a fixed limit of attractors/emitters/etc), so it would still be useful to offer both systems and let users pick the system which better suits their particular game's needs.
Note that I'm not expecting nor even asking you to do any of this personally (especially since the main graphics system still does not utilize any modern GL aspects, least of all shaders), I am merely stating that it is a possibility, and something to consider while we're ahead.
So, thoughts?
On the subject of the sovereignty of your particle system... How does the idea of a Particle_Systems directory strike you? We'd place it either in the root of SHELL or in the GL folder. Probably the former, since some particle systems may be written which use exclusively draw_* functions, though I'm not sure who would do such a thing.
What I more believe may end up happening in the future is providing a different particle system controller that moves your particle functions to the GPU via GLSL, in the interest of performance. The GPU particle functions would be more limited (a fixed limit of attractors/emitters/etc), so it would still be useful to offer both systems and let users pick the system which better suits their particular game's needs.
Note that I'm not expecting nor even asking you to do any of this personally (especially since the main graphics system still does not utilize any modern GL aspects, least of all shaders), I am merely stating that it is a possibility, and something to consider while we're ahead.
So, thoughts?
853
General ENIGMA / Re: Raspberry Pi
« on: February 08, 2013, 10:14:30 am »
I recall Pi being huge on Yoyo's agenda. It was the reason they designed a Linux port. Has this changed?
854
Issues Help Desk / Re: Ever since the newest Java update...
« on: February 08, 2013, 03:02:32 am »
The compiler project is in CompilerSource. You're best letting LGM compile it, though.
ENIGMA.exe is in CompilerSource/stupidity-buffer. This is the shiny thing that runs LGM (but since broke).
The engine project is in ENIGMAsystem/SHELL. Compiling this with C::B will do you no good.
ENIGMA.exe is in CompilerSource/stupidity-buffer. This is the shiny thing that runs LGM (but since broke).
The engine project is in ENIGMAsystem/SHELL. Compiling this with C::B will do you no good.
855
Issues Help Desk / Re: Ever since the newest Java update...
« on: February 07, 2013, 08:49:32 pm »
It takes about .25 seconds to compile ENIGMA.exe. The download should not take that long (ENIGMA is less than 2MB), but in the event that it does, I suppose we can schedule it as a cron job and just offer the zips as they become available.
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 »