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 »
106
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.
107
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!
My other thoughts are of decreasing relevance. Looks good! Thanks!
108
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:
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.
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.
109
Issues Help Desk / Re: Compile Error (C++ Bad Reloc)
« on: December 13, 2014, 09:21:02 am »
Apparently room_last and room_first aren't actually being written, even though the engine expects them to be. I guess he just stopped using them.
110
General ENIGMA / Re: Extension Depends on Extension?
« on: December 13, 2014, 09:19:46 am »
I don't think I coded such a system, no. Just let it go for now and make people aware of the issue. Otherwise, well, dependency resolution on purely optional extensions is pretty easy to write. Probably easier than hacking up one fucking extension to include the other.
111
Proposals / Re: Improving tiles editing
« on: December 13, 2014, 09:15:07 am »
If we're writing a wish list, I've always wanted tile and object grouping. I think Robert was working on something where you could assign non-ID ordering to objects, but it'd probably help him just to have the ability to group strings of identical objects in that tree view. (Or is it a list view? I forget if Swing distinguishes.)
112
Issues Help Desk / Re: Symbols???
« on: December 13, 2014, 09:12:19 am »
"Written correctly" here isn't well-defined. You probably wrote a completely correct CP-1252 copyright symbol. But the rest of the world has moved on; apparently, even pieces of Windows Exploder. Could you paste a hex dump of the file you go that "Legal Copyright" line from? I'm not sure if you'll have the CP-1252 or UTF-8 version (I sincerely hope you have the former), but whichever it is, we'll need to change it or specify encoding options to the resource compiler.
113
General ENIGMA / Re: Code Action Comments
« on: December 08, 2014, 12:25:57 am »
It's a cheap hack compared to actually allowing you to name it in a field, which I'd recommend doing since EGM and GMX are extensible. Why Dailly didn't do that, I'll never know.
114
Off-Topic / Re: what if Atari bought GM instead?
« on: December 07, 2014, 09:52:41 pm »
If he'd done that, ENIGMA wouldn't exist. I don't know if GM would be so good that I'd still use it, but it would at least be substantially better, or it would be dead. Atari is a big enough, wise enough corporation that it would either make GM great, or drop it. It wouldn't have a perfect PR record, either, but it wouldn't be the publicity trainwreck GM became. And yes, maybe the development scheme would have been slow, but face facts: it's been seven years.
Still, no sense dwelling on what might have been.
Still, no sense dwelling on what might have been.
115
Developing ENIGMA / Re: Switch to C++11?
« on: December 07, 2014, 05:12:32 pm »
After attempts to glean more information, I believe the best course of action is to wait for more problems or assume this is solved. Ignore me.
116
Ideas and Design / Re: In need of a Sonic fangame engine for Enigma
« on: December 07, 2014, 12:30:08 pm »
We've merged a number of pull requests recently. What fix are you waiting for?
117
Developing ENIGMA / Re: Switch to C++11?
« on: December 07, 2014, 12:10:07 pm »
We're getting users with build errors because something isn't correctly configured to use ISO 11. On Windows, if I'm not mistaken. Is there an INI somewhere they can add --std=c++11 to?
118
Issues Help Desk / Re: Trying something different... (Fedora 20 Install)
« on: December 06, 2014, 10:28:53 am »
Hi there,
I've pushed a commit that removes the affected lines from the repository. You should be able to build, now, after you update (git pull). The only file which depended on stropts was the Linux Joystick API. I was basically being pedantic and making sure I wasn't passed partial data, which the API should already be doing. The Linux joystick driver is ancient and venerable and lacks support for a lot of modern features, but it isn't so bad it'll send us garbage.
Anyone who is so inclined can test out Linux joysticks using this test game.
Cheers
I've pushed a commit that removes the affected lines from the repository. You should be able to build, now, after you update (git pull). The only file which depended on stropts was the Linux Joystick API. I was basically being pedantic and making sure I wasn't passed partial data, which the API should already be doing. The Linux joystick driver is ancient and venerable and lacks support for a lot of modern features, but it isn't so bad it'll send us garbage.
Anyone who is so inclined can test out Linux joysticks using this test game.
Cheers
119
General ENIGMA / Re: Busy busy, like a bee
« on: December 06, 2014, 10:23:08 am »
Oh, that's awesome. I'm going to sit this LD out. I entered a few of them with ENIGMA in the past. One of these days I'll take vacation on Friday and join in, again.
Anyway, best of luck!
Anyway, best of luck!
120
Proposals / Re: Allow me to use C++ in EDL
« on: December 02, 2014, 12:35:15 am »
You'd have to access those objects the same way you access them in other C++ functions. Ie, using instance_event_iterator.
The main reason you can't use vector with the current compiler is that it's terrible at coercing types. It was always bad at it, but it's actually gotten worse over time. Originally, you could access vector like an array, but couldn't call functions because the type resolution wasn't good enough to get accurate function information from template types, so I never bothered coding checks for member function calls. I fixed the template types issue in JDI, but in the meantime, someone broke it to the point that it doesn't even realize anything in the code is not a var, anymore. No idea why. Don't feel like investigating.
The main reason you can't use vector with the current compiler is that it's terrible at coercing types. It was always bad at it, but it's actually gotten worse over time. Originally, you could access vector like an array, but couldn't call functions because the type resolution wasn't good enough to get accurate function information from template types, so I never bothered coding checks for member function calls. I fixed the template types issue in JDI, but in the meantime, someone broke it to the point that it doesn't even realize anything in the code is not a var, anymore. No idea why. Don't feel like investigating.
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 »