Show Posts

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.

Messages - Josh @ Dreamland

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?

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.

Proposals / Re: Improving object selection
« on: December 28, 2014, 10:37:15 PM »

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.

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.

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 (sound_isplaying(snd_jump) 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.

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: (C++) [Select]
#file object_index.event_index.event_id.edl
#line 0
and so you'd have to say break 0.0.0.edl:5.

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.

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.

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.

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.

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.)

General ENIGMA / Re: Compile to JavaScript
« on: December 14, 2014, 11:04:57 AM »
We've done so, actually. A long time ago. Unfortunately, the contributor base is spread too thin, as it is. The bigger problem at the time was that the compiler made it difficult to support C++ and JavaScript concurrently. That's since been mostly corrected, and I have been pushing out changes lately that improve the situation. I wouldn't get my hopes up for a JavaScript port renaissance in the near future, though.

General ENIGMA / Re: Animated GIFs
« on: December 13, 2014, 10:26:37 PM »
First thought is that the image_load function shouldn't crash, no matter what's in the file. Super slow isn't ideal, yes, but (a) it's better than nothing, and (b) it's an image loader; it shouldn't be called that frequently. Third thought: how did you handle the many GIF compositing methods? Or does it just not support animation?

My other thoughts are of decreasing relevance. Looks good! Thanks!

General ENIGMA / Re: Code Action Comments
« on: December 13, 2014, 11:41:22 AM »
The question isn't about a tag so much as an actual GUI field—Something users would be able to find without looking for it. But whatever.

Any of ///, //!, /** */, or /*! */ are perfectly valid ways of specifying a formal comment. JoshEdit supports highlighting them correctly. By default, the first sentence (up to the first period or pair of newlines) is used as the brief. Otherwise, the tag is @brief, or \brief in vanilla Doxygen. The explicit tags extend the brief to as many sentences as you like; it ends at the first pair of newlines (or end of the comment).

JoshEdit already knows where block boundaries are (strings, comments, etc), so you can either ask it, or just recompute them yourself (which is pretty simple).

To clarify:
Code: (EDL) [Select]
/// This is a function that
/// does some stuff. This
/// text elaborates on it.
The brief of the above is "This is a function that does some stuff."

Code: (EDL) [Select]
 * This is a function that does some stuff and
 * was written by someone who just has no
 * concept of what a period is
 * This text elaborates on it
The brief of the above is "This is a function that does some stuff and was written by someone who just has no concept of what a period is." Note that the behavior is not affected at all by the existence of asterisks.

Code: (EDL) [Select]
 * @brief This is a function that does some
 *     stuff. Really well, actually. (Thanks for asking.)
 * This text elaborates on it.
The brief of the above is the entire paragraph, "This is a function that does some stuff. Really well, actually. (Thanks for asking.)."

Code: (EDL) [Select]
/// \brief This is a function that
/// does some stuff. It's also pretty
/// serious with Doxygen.
/// \param foo  the first parameter
The brief of the above is "This is a function that does some stuff. It's also pretty serious with Doxygen."

As long as I'm repeatedly adding information to this post, I'll point out one more thing: Normally a Doxygen comment precedes a function or variable. If we are REALLY shooting for Doxygen compliance, the "correct" way to do this terrible hack is to leverage the @file tag, or create a new @action tag.

This is the only way to denote to Doxygen that a comment applies to the file, not to a function or other object.