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 »
91
Announcements / Google Summer of Code
« on: February 07, 2015, 11:56:23 am »
Hello, everyone; long time, no see.
Google Summer of Code signups are around the corner. Are we, as a group, interested in participating? I am considering sponsoring either ENIGMA or NaturalGM, or even both, depending on which project is able to generate an workable list of tasks for contributors.
The problem with ENIGMA's participation is that its contributor base is already mostly college-level help, so the majority of tasks that would be easy to delegate to new help are already completed, while the remaining work requires more skill and background info on what ENIGMA is and what it is supposed to be.
That said, looking over the wiki page from last year, some of the workpoints seem nearly feasible. The problem is that no one has started any of them. If we want help, we have to be serious about having room for participants to actually contribute code. We can't be allocated a new contributor and expect them to figure out what ENIGMA is and just start tacking entire new systems on. Work points such as "Implementation of an Asynchronous Networking System" are entirely too much work for someone who is unfamiliar with the project. Does the Network_Systems folder even work like the other systems folders? How will a new contributor even know they are on the right track?
If we are to participate, we need tasks that begin with ten lines of code and end with implementing an entire system. There needs to be room for a contributor to start small and grow in the project. I can't endorse ENIGMA with such course-grain tasks. This is the reason I stayed out of the GSoC planning last year, and if we can't generate a better task list this year, we'll hit the same fate.
We can improve the "Implementation of an Asynchronous Networking System" task by creating a reference list of what we actually expect this system to look like, and offering an example game which, given these functions, should be able to be played over a network. We can't expect a new contributor to write the game that tests his or her new functions. That's way too much work for someone who has never heard of the project.
Related: Do we even have a simple dev wishlist, anymore? I occasionally hear about X huge thing that is completely broken and everyone has been working around, but I have essentially no idea what people want to see out of this project right now, aside from a new compiler. It seems to me that we have no little tasks; the project is waiting on someone to "just go through and fix everything." Does anyone care to prove me wrong?
To be brief, if we want to participate in GSoC, we have to make sure we have tasks that are actually suited to someone who has never heard of the project. Otherwise, I guess we can sit this one out.
Google Summer of Code signups are around the corner. Are we, as a group, interested in participating? I am considering sponsoring either ENIGMA or NaturalGM, or even both, depending on which project is able to generate an workable list of tasks for contributors.
The problem with ENIGMA's participation is that its contributor base is already mostly college-level help, so the majority of tasks that would be easy to delegate to new help are already completed, while the remaining work requires more skill and background info on what ENIGMA is and what it is supposed to be.
That said, looking over the wiki page from last year, some of the workpoints seem nearly feasible. The problem is that no one has started any of them. If we want help, we have to be serious about having room for participants to actually contribute code. We can't be allocated a new contributor and expect them to figure out what ENIGMA is and just start tacking entire new systems on. Work points such as "Implementation of an Asynchronous Networking System" are entirely too much work for someone who is unfamiliar with the project. Does the Network_Systems folder even work like the other systems folders? How will a new contributor even know they are on the right track?
If we are to participate, we need tasks that begin with ten lines of code and end with implementing an entire system. There needs to be room for a contributor to start small and grow in the project. I can't endorse ENIGMA with such course-grain tasks. This is the reason I stayed out of the GSoC planning last year, and if we can't generate a better task list this year, we'll hit the same fate.
We can improve the "Implementation of an Asynchronous Networking System" task by creating a reference list of what we actually expect this system to look like, and offering an example game which, given these functions, should be able to be played over a network. We can't expect a new contributor to write the game that tests his or her new functions. That's way too much work for someone who has never heard of the project.
Related: Do we even have a simple dev wishlist, anymore? I occasionally hear about X huge thing that is completely broken and everyone has been working around, but I have essentially no idea what people want to see out of this project right now, aside from a new compiler. It seems to me that we have no little tasks; the project is waiting on someone to "just go through and fix everything." Does anyone care to prove me wrong?
To be brief, if we want to participate in GSoC, we have to make sure we have tasks that are actually suited to someone who has never heard of the project. Otherwise, I guess we can sit this one out.
92
Third Party / Re: Porting GMOgre
« on: February 04, 2015, 12:00:22 am »
Unless there's a debug build of GMOgre, there's not much of a chance of figuring out what the problem is with GDB.
93
Developing ENIGMA / Re: New Portable
« on: January 11, 2015, 08:36:58 am »
Slipped my mind. In the perfect world of Josh, LGM has a build script that does that for us.
Up now: https://github.com/enigma-dev/Calico-Icon/releases/tag/201501110900ET
Up now: https://github.com/enigma-dev/Calico-Icon/releases/tag/201501110900ET
94
Proposals / Re: Disabling Automatic Semicolons
« on: January 01, 2015, 12:06:53 pm »
The question isn't "should we have a setting to teach users to add semicolons themselves," the question is "should we have a setting that offloads the responsibility of producing accurate C++ code to users because ENIGMA apparently can't." The answer to the former is yes; I've had dozens of requests to warn on missing semicolons and badly-formed code. The answer to the latter is certainly no; that's a pretty pitiful thing to do. But I won't stop you—the current parser is primarily duct tape as it is; what will an extra roll or two hurt?
95
Proposals / Re: Disabling Automatic Semicolons
« on: December 30, 2014, 12:57:23 am »
A setting to disable that is a bad idea unless we can accurately report errors on it. Your reason to disable it is that you can't accurately determine whether a semicolon is required.
97
Works in Progress / Re: [OGL3] Shader Test
« on: December 28, 2014, 12:14:28 pm »
I see. I thought you were asking me to add a function to fetch "the normal matrix," which just isn't a common entity (it only exists in our default shader—there's no guarantee that other shaders calculate one).
Anyway, thanks for the patch! If you like, you can file it through GitHub, here.
Anyway, thanks for the patch! If you like, you can file it through GitHub, here.
98
General ENIGMA / Re: Improving rooms editor
« on: December 28, 2014, 12:04:51 pm »
We will split the page into multiple subpages as individual sections become large enough to qualify. For now, just document to your heart's content on one page.
99
Finished Games / Re: Christmas Run - Merry Chistmas to You!!!
« on: December 27, 2014, 12:30:15 am »
Not a bad start. One point of advice: check if a sound is playing before playing it again ([snip=edl]sound_isplaying(snd_jump)[/snip] should give you what you want). Alternatively, if you prefer, stop the sound before playing it again. It will prevent the sound from adding in on itself until it's loud to the point of clipping.
100
Proposals / Re: Error reporting
« on: December 27, 2014, 12:18:11 am »
The #file and #line directives will translate to GDB, too. With them in place, you'd literally tell gdb, break object0.create.edl:5, or whatever pseudonym is generated for event files. At worst, the compiler would spit out something like this:
Code: (cpp) [Select]
#file object_index.event_index.event_id.edl
#line 0
and so you'd have to say break 0.0.0.edl:5.
101
Proposals / Re: Error reporting
« on: December 25, 2014, 09:32:20 pm »
I was going to have the new parser preserve token line numbers in the code dump so that we could use the #file and #line directives. Actually, I guess the parser already does that, so the pretty printer just needs to leverage them during output. I never started the pretty printer, because the compiler wasn't mature enough. Even the parser's only like 85% done. The big block was that the newest JDI changed the lexer interface, which created some problems during port, so I tried refactoring the lexer to be more modular. This exposed some issues in the way I handle macros, so I started recoding that, and then got involved in other things (ENIGMA-related and otherwise). Maybe I'll resume work on that tomorrow night or the morning after.
102
Issues Help Desk / Re: Build options appear grayed out on Windows XP [SOLVED]
« on: December 25, 2014, 03:41:36 pm »
I don't understand the difference between hard-coding it and changing it in the config files, except for the former requires recompilation and so is less desirable. What is the difference in behavior? If it's a problem with differentiate between host platform and target platform when choosing settings. If that's the case, we need to update the configuration file's schema to support both behaviors. We should also find a way to override settings in a way that gitignore can help prevent being committed, if his changes are not good for everyone.
103
Issues Help Desk / Re: I'm a noob and I can't build a project
« on: December 25, 2014, 09:30:42 am »
Well, that's a little scary. I might ask you to explain the rationale behind that hard coding, later, Robert.
104
General ENIGMA / Re: Animated GIFs
« on: December 17, 2014, 11:55:54 pm »
Left you a couple comments in the interest of efficiency, but didn't catch the segfault hazards. I'll give it another look tomorrow; I'm pretty beat, at the moment.
105
General ENIGMA / Re: Animated GIFs
« on: December 14, 2014, 11:11:07 am »
I wasn't talking about timing animation, but rather about animation compression. This is done by compositing frames, and leaving large regions between frames transparent. It gave us some trouble when we wrote the APNG importer in LGM. I'm not sure how bad GIF is about it, but APNG supports some fifty million methods. (It's not actually that bad; it just caught us by surprise and was not a welcome work task.)
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 »