ENIGMA Development Environment
Website is in read-only mode due to a recent attack.

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

General ENIGMA / Re: Searching In Resources
« on: September 14, 2014, 10:19:18 AM »
But I'll be honest Josh I also think we should have a preference for the object events to be expandable by default even when not searching, users can toggle it from preferences which is also default functionality of Eclipse class files.

I suggested that.
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.

I said a couple of the other things you said, but it sounds like you have the right idea on those, so I won't reiterate.

As for what should happen when you click on an event of an object node, try not to reimplement the object editor in the resource tree. Just open the object editor to that event. You can include groupings in the tree if you really want, but try to avoid code duplication. Showing the code editor won't work when other DND is involved.

As for the icons, I can do that. There's already a wrench icon for use in the JE quick-find; it's not used elsewhere. Go ahead and use it for consistency.

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,

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.

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.

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.

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.

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'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,

Code: (YAML) [Select]
name: object0
: 0
: 0
: |
     // 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

: self

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

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.

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

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?

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.

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.

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.

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.

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. :P

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.