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 »
181
General ENIGMA / Re: Searching In Resources
« on: September 13, 2014, 09:19:46 pm »
If you could show events in the resource tree... wow. I never even considered how powerful that'd be. I'd recommend putting it in a different view which can be toggled, though, as I believe common users would be annoyed by the expandability of objects. I hate in Eclipse that if I try to recursively expand, I get a whole bunch of shit I don't care about (because it's all text files). But that'd be a super cool feature, especially for search.
Yoyo's execution is poor; their results page looks bloated (it's wide and tall; why?) and ugly (it doesn't even expand the whole way; looks like poor CSS). And unless you can float it, or it's always on top, it looks easy to lose. If it's always on top, then it's just annoying because it's always in the way. Copying results to the clipboard could be useful, but the results are overly verbose, too. I'd go resource:line:position: full text of line with terms highlighted, eg,
And you may as well keep them in a separate window, unless you can get the total space down (possibly by putting the options all in a single column and the results to the right, or in a row—search box spanning above—with results to the bottom).
Now that I've said that, let me again state that I LOVE the idea of the Eclipse feature. If I may...
Tell me that doesn't look nice.
Now, let me pitch you this: do what I did for JoshEdit: Have a QuickFind dialog which searches in anything, with a wrench to configure advanced settings. Have a small button that does the full-text search, and a small wrench icon that configures it. You can even have that configuration dialog offer a plain-text results list, but I think that's overkill.
Good luck on the implementation; this feature sounds killer.
Yoyo's execution is poor; their results page looks bloated (it's wide and tall; why?) and ugly (it doesn't even expand the whole way; looks like poor CSS). And unless you can float it, or it's always on top, it looks easy to lose. If it's always on top, then it's just annoying because it's always in the way. Copying results to the clipboard could be useful, but the results are overly verbose, too. I'd go resource:line:position: full text of line with terms highlighted, eg,
shader0:vertex:2:11: something whatever passthrough whatever
shader0:fragment:2:11: something whatever passthrough whatever
object0:Create:1:0: this line literally just says "ass", you ass
And you may as well keep them in a separate window, unless you can get the total space down (possibly by putting the options all in a single column and the results to the right, or in a row—search box spanning above—with results to the bottom).
Now that I've said that, let me again state that I LOVE the idea of the Eclipse feature. If I may...
Tell me that doesn't look nice.
Now, let me pitch you this: do what I did for JoshEdit: Have a QuickFind dialog which searches in anything, with a wrench to configure advanced settings. Have a small button that does the full-text search, and a small wrench icon that configures it. You can even have that configuration dialog offer a plain-text results list, but I think that's overkill.
Good luck on the implementation; this feature sounds killer.
182
General ENIGMA / Re: Need some advice on fullscreen + views
« on: September 10, 2014, 10:52:51 pm »
I'm actually annoyed by the ill-defined, uncustomizable behavior of the engine when the screen size changes. There's no reason to force rendering on a fixed-size canvas to up- or down-scale. I believe GM allowed options to scale or render at (0, 0), which is stupid; why can't we center it? Why can't we allow users to let the card scale the textures and draw the lines as normal? Why can't we offer threshold scaling, eg, take the largest fitting of .5x, 1x, 2x, 3x..., then render it centered? Why not just let the user define the render logic around the drawing size? There are a lot of modes that make sense.
Handling view boundaries for users complicates this, because we logically need to be in charge of that until the user manually assigns to the view variables, which we don't facilitate. So we have the classic UI problem of "how do we scale these widgets?" (here, views). Once we've scaled to get accurate view coordinates, we then have the problem of how we want to project the world onto this space. GM's answer is surfaces; ENIGMA originally let the user handle that, but now, as I understand, also uses surfaces. It's annoying.
Anyway, that concludes my rant. The short version is, I don't have an answer for you because the current answer is ill-specified and generally lousy. Sorry.
Handling view boundaries for users complicates this, because we logically need to be in charge of that until the user manually assigns to the view variables, which we don't facilitate. So we have the classic UI problem of "how do we scale these widgets?" (here, views). Once we've scaled to get accurate view coordinates, we then have the problem of how we want to project the world onto this space. GM's answer is surfaces; ENIGMA originally let the user handle that, but now, as I understand, also uses surfaces. It's annoying.
Anyway, that concludes my rant. The short version is, I don't have an answer for you because the current answer is ill-specified and generally lousy. Sorry.
183
Developing ENIGMA / Re: Android
« on: September 08, 2014, 10:37:40 am »
It seems that to work around problems of the C:/Documents and Settings/John Doe/My Documents/My Games/super cool game/game.exe ilk, ld just takes EVERYTHING after -o to be the output name. So that's one issue.
I can't tell from what you told me over IRC if it's finding all the objects correctly or not. It'd help to have a dump of the OBJECTS variable.
I can't tell from what you told me over IRC if it's finding all the objects correctly or not. It'd help to have a dump of the OBJECTS variable.
184
Off-Topic / Re: CPGCL - Cross Platform Game Creation Language
« on: September 07, 2014, 04:26:13 pm »
Please don't create duplicate accounts for the sake of self-promotion.
185
Developing ENIGMA / Re: The benefits of Visual Studio's compiler?
« on: September 07, 2014, 09:52:25 am »
That's not a reason to not support it. The reason to not support it is that no developers own it, or even the express version, for those reasons.
That said, the vast majority of ENIGMA -should- compile with Visual Studio. We -are- using GNU extensions in places, but the ones we use are largely going to be included in C++14 or are already supported by virtually all compilers.
How easy is it to set up ENIGMA's other basic dependencies in VS? It might be the dumb answer to all our dumb questions.
That said, the vast majority of ENIGMA -should- compile with Visual Studio. We -are- using GNU extensions in places, but the ones we use are largely going to be included in C++14 or are already supported by virtually all compilers.
How easy is it to set up ENIGMA's other basic dependencies in VS? It might be the dumb answer to all our dumb questions.
186
Issues Help Desk / Re: Error updating to new "room" format (with pre-creation code)
« on: September 06, 2014, 03:36:02 pm »
That's fine, Ism; EGM needs some formatting overhaul, anyway. We use that EEF format I made up to store objects, as I understand it, and in hindsight that was my dumbest EGM suggestion. We were better off solving the YAML problem at hand—that is, the problem where code whitespace might not be preserved—by inserting a comment before the code, eg,
My suggestion for rooms is just an SVG-like blob of points.
We can be more meta if we want to save space and do something more like SVG does:
For reasons of beauty, redundancy, and capacity, you could extend the shorthand space to a..z..A..Z..aa..az..ba..bz...Aa..Az...ZZ..., give precedence to shorthand identifiers, and allow just naming objects. So "obj_player 320 240 w 0 0 w 32 0 w 64 0 w 96 0..." would be completely fine as long as w is bound to obj_wall. In the case where there's an object named a, the shorthand gets precedence. You can be cutesy and assign shorthands based on the first character (or first character after object/obj_).
Just my 2¢, broadcast as usual.
Code: (yaml) [Select]
name: object0
events:
-create:
id: 0
subid: 0
code: |
// User code begins here
var haha; // This is the first line of actual user code
var i_started_this_code_at_an_indent_of_2;
return 0; // This is the last line of actual user code, which has less indent than the rest of the code, but won't trip the YAML parser because of our comment above
applies-to: self
-destroy:
...
My suggestion for rooms is just an SVG-like blob of points.
Code: [Select]
instance-format: object-name, x, y
instances: obj_player 320 240 obj_wall 0 0 obj_wall 0 32 obj_wall 0 64
We can be more meta if we want to save space and do something more like SVG does:
Code: [Select]
objects:
a: obj_player
b: obj_wall
c: obj_bat
instance-format: object-name, x, y
instances: a 320 240 b 0 0 b 0 32 b 0 64 ... b 0 32 c 128 128 c 416 128
For reasons of beauty, redundancy, and capacity, you could extend the shorthand space to a..z..A..Z..aa..az..ba..bz...Aa..Az...ZZ..., give precedence to shorthand identifiers, and allow just naming objects. So "obj_player 320 240 w 0 0 w 32 0 w 64 0 w 96 0..." would be completely fine as long as w is bound to obj_wall. In the case where there's an object named a, the shorthand gets precedence. You can be cutesy and assign shorthands based on the first character (or first character after object/obj_).
Just my 2¢, broadcast as usual.
187
Programming Help / Re: Windows 8 touch support
« on: September 06, 2014, 10:38:42 am »
I hate to suggest this, but, we could easily make mouse_x and y a var, and then assign multitouch points to the other indices. The less icky approach is just to create functions to fetch pointer information by index, and query the number and validity of pointers. Pointer information includes pressure and sometimes rotation (such as on the Wii). Validity isn't always a dense function—any of the four Wii remotes can be off-screen, and it would not surprise me if later tablets distinguish between fingers and one or more styluses.
188
Works in Progress / Re: Iji is now in Beta! Please test~
« on: September 03, 2014, 09:14:30 am »
I used to actually bundle that DLL into the executable. Apparently that's changed...
189
Issues Help Desk / Re: Error updating to new "room" format (with pre-creation code)
« on: September 03, 2014, 09:02:48 am »
The point of EGM is that, since it is completely text based with named attributes, it should be incredibly hard to break. Are rooms being stored as binaries?
190
Works in Progress / Re: Iji is now in Beta! Please test~
« on: September 01, 2014, 09:23:32 am »
Excellent news!
A curiosity is that I don't technically own the ENIGMA logo, myself. I suspect you won't encounter any problems using it, though; its author gave it to me and, in fact, doesn't like it anymore from what I can tell. So go for it. No credit is necessary, of course, though we (or at least I) appreciate it.
In the end, was any modification to the original Iji source required? I'm also interested in trying to make sure your changes to the engine continue working, moving forward. We can deal with that after the launch, though. Congrats! Well done.
A curiosity is that I don't technically own the ENIGMA logo, myself. I suspect you won't encounter any problems using it, though; its author gave it to me and, in fact, doesn't like it anymore from what I can tell. So go for it. No credit is necessary, of course, though we (or at least I) appreciate it.
In the end, was any modification to the original Iji source required? I'm also interested in trying to make sure your changes to the engine continue working, moving forward. We can deal with that after the launch, though. Congrats! Well done.
191
General ENIGMA / Re: OSX Trials and Tribulations
« on: August 31, 2014, 08:57:13 pm »
The JDI bug... concerns me, vaguely. Do you know what JDI git revision ENIGMA master is on? This is probably something I've already fixed. If not, I'll ask you to send me a preprocessed version of the engine so I can triage it.
192
Announcements / Re: Licensing, the ultimatum
« on: August 31, 2014, 06:05:13 pm »
I haven't heard back from them, which isn't really indicative of anything. I sent the email out June 1. Their system greeted me and gave the usual disclaimers on June 2. Last time I contacted them, I wrote them on July 1 and received a human reply Friday, September 13. The reply was very generic, however; I believe I shared it or the tone of it here at some point. It was not very inviting nor encouraging, which is why I opted to write them again. The fact that it's taking longer this time is probably a good thing.
193
General ENIGMA / Re: A few suggestions of features I feel I would work better with
« on: August 28, 2014, 08:12:12 am »
On the JavaScript interpreter—that's correct, but the real core of the problem is that we don't include symbols in compiled games. Meaning you can't get your code back in any way, shape, or form from an ENIGMA executable. To allow you to access those things from JavaScript transpiled EDL, we'd need to include them, which is a security risk and would have to be made an option. That in itself is a ton of effort, and so we're just not doing it right now.
Windows Phone isn't on the radar, though dazappa (here daz) has been working to get Android working from Windows, which is a huge step in that direction. We're unlikely to ever let you code on a Windows phone. Android is at least feasible, since someone will eventually get arbitrary swing applications working on Android devices. In the meantime, support for mobile editing isn't planned outside of laptops or full Linux distributions on tablets.
Windows Phone isn't on the radar, though dazappa (here daz) has been working to get Android working from Windows, which is a huge step in that direction. We're unlikely to ever let you code on a Windows phone. Android is at least feasible, since someone will eventually get arbitrary swing applications working on Android devices. In the meantime, support for mobile editing isn't planned outside of laptops or full Linux distributions on tablets.
194
General ENIGMA / Re: OSX Trials and Tribulations
« on: August 26, 2014, 09:20:32 pm »
Expert timing, TGMG. Nice to see you're still alive!
FWIW, uname -s works on the two operating systems you're trying to get install.py to support.
Anyway, cheeseboy moved those preprocessor_etc files since TGMG wrote the OS X port. It's probably a simple matter of figuring out where they end up on OS X and updating paths in the XCode project. I wouldn't own an Apple, so I can't be much help.
FWIW, uname -s works on the two operating systems you're trying to get install.py to support.
Anyway, cheeseboy moved those preprocessor_etc files since TGMG wrote the OS X port. It's probably a simple matter of figuring out where they end up on OS X and updating paths in the XCode project. I wouldn't own an Apple, so I can't be much help.
195
Developing ENIGMA / Re: Iji on ENIGMA
« on: August 24, 2014, 10:06:07 pm »
Doesn't the original Iji executable work in WINE? I mean, the thing isn't lost to the world; it just doesn't build for Linux. Isn't it relatively easy to compare the ENIGMA feel to the original? Or do I misunderstand you?
(I've never played Iji through, so forgive me if there was an obvious joke there)
(I've never played Iji through, so forgive me if there was an obvious joke there)
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 »