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

1306
Issues Help Desk / Re: Failure to start Enigma from SVN on Ubuntu
« on: July 14, 2011, 09:55:23 AM »
I forgot how long ago I made that fix. There's a possibility something else broke it in the meantime. Anyway, it's part of my testing suite now, so it's unlikely to go unnoticed if it breaks again.

1307
Issues Help Desk / Re: Hai halp me 2 fix mah gml plox.
« on: July 12, 2011, 03:53:38 PM »
[Warning: viewing the above game may cause cerebral infarction. View at your own risk.]

1308
General ENIGMA / Re: Questions on EDL and ENIGMA
« on: July 11, 2011, 08:42:47 PM »
I'll remove the parser for you after I finish pasting the audio system back on right-side-up.

1309
General ENIGMA / Re: Questions on EDL and ENIGMA
« on: July 11, 2011, 03:50:31 PM »
Using a PE header that I would normally not hesitate to strip? ...

Anyway, if that's the case, it seems you don't even need any cooperation on my part to get the engine hooked up to your fork. Even our definitions resource would work well with it.

Although I'm not seeing how LLVM would discern the contents of a C structure without being told.

1310
Issues Help Desk / Re: Failure to start Enigma from SVN on Ubuntu
« on: July 11, 2011, 02:18:26 PM »
How are you running the Jar? Last I checked, Ubuntu doesn't run jarfiles from within their own directories; you may want to try opening the terminal in that dir and invoking Java yourself.

1311
General ENIGMA / Re: Questions on EDL and ENIGMA
« on: July 11, 2011, 12:24:15 PM »
I don't much fancy the concept of making anything impossible in the language. I also don't fancy bounds checking. So if there's going to be any anti-segfault measure on this, it's going to be one that pulls a glibc and catches signals to inform the user of what blew up where, instead of preventing the explosion.

So, then, the engine and game codes would be separate. I suppose you want them dynamically linked, with the engine as the DLL. Or, knowing you, you want every piece of the engine as the DLL, and then some sort of go-between to be generated that lays out the functions, yes?

I have dedicated the last five minutes to thinking of the implications of using LLVM for the game and C++ for the engine. We'd miss out on structures for communicating between the C++ functions and the LLVM ones. There'd be a major segregation between the two. Getting arbitrary C functions defined to LLVM would be difficult and likely inconsistent.

1312
General ENIGMA / Re: Questions on EDL and ENIGMA
« on: July 11, 2011, 12:00:47 PM »
The reason G++ is incapable of performing optimizations on var is because it does not recognize it as a plain datatype. The same optimizations cannot be made for variant as for double, because it doesn't understand to treat the class as a plain datatype. Implementing it in LLVM would fix that. Otherwise I'd have to do it myself.

As far as having C++ features without being tied to C++, I don't actually have a retort to that, even if you're trying to pass that off as a benefit.

I also like how you just pretend that C++ is this horribly unstable language while LLVM is the pinnacle of perfection. It reminds me of 4chan threads.

Let me ask; what would the engine be written in when we switched to LLVM? You're apparently implying it's not that bad, old C++.

1313
General ENIGMA / Re: Questions on EDL and ENIGMA
« on: July 11, 2011, 10:05:11 AM »
You're always welcome to fork the project. Maybe the two of you could team up and work on an LLVM version.
Of course, we'd probably have to sacrifice our C++ features, or at very least the lexical optimization that would otherwise come with LLVM. And to utilize the full extent of those optimizations, we'd need to hard-code rules about var into our grammar as though it were a formal, POD type; how much code would we be discarding here, do you suppose?

Maybe you can implement this optimization I've been contemplating for a while using the current, compiler-independent configuration; I'd like to inline calls to small graphics functions such as draw_line and draw_point, and remove the if() for recurring calls to them. If you can get it to inline them, LLVM should be able to do this itself.

1314
How on earth does valign have any effect on draw_text? O_o
If it just centers the text around the given y coordinate, then there's no need to fork again. Just set the initial yy to valign == fa_top ? y : valign == fa_middle ? y - string_height(str)/2 : y - string_height(str).

And yeah, it's "though." But no one really cares if you abbreviate, even unintentionally. :P

1315
Yep. That way, string_width is never called for simple left-aligned text.

1316
Quote
Could you elaborate? You mean having separate drawing functions for all six alignments? Then how will that be backwards compatible with GM? Or how will draw_set_halign/valign actually work in that case?
No, just put the original function in a big if for align being top-left, and then put the rest of the code in the else with whatever hackery is required, that way you don't have to iterate the string for draw_text() when the aligns are default.

Quote
Also, why do I need this: ...
Otherwise, \r\n will put two newlines, or if you place ", u+= str[i]=='\n';" at the end of the proposed replacement, '\n\n' will be treated as one line.

1317
General ENIGMA / Re: Questions on EDL and ENIGMA
« on: July 09, 2011, 02:17:38 PM »
Not all of the DND functions are implemented, no. A good deal of them are; they're just not a major priority as we are trying to get the actual function base implemented first.

You certainly can use C++ functions in EDL, as well as its types and classes. At the moment, functions and classes must be declared in ENIGMA Settings->Definitions, but we will be adding a separate resource for that shortly.

We're trying to minimize differences while adding features. Most of the differences at the moment are just a matter of which features are missing from GML, and which are new to EDL.  The biggest stumbling blocks at the moment are that in the latest 'stable' tag, = is exclusively an assignment, and == is the only comparison operator. We have modified the trunk to default to Game Maker's behavior, and made the settings panel actually work in it.

In the trunk, the biggest difference is the behavior of booleans. In GM, (-1) is considered false because it's not greater than zero; in EDL, (-1) is true because it is nonzero.

If you would like to just pick a set of functions we haven't implemented and write them, that would always be appreciated.

As far as compiling to C++ first, it is in our benefit to do so. By letting the GCC take care of compilation for us, we gain a large number of powerful optimizations. We also gain access to a source that we can examine to find lapses in the compiler's understanding of the code; it's much cleaner that way.

1318
That code doesn't consider newlines. Not having the code as fa_left fucks everything up, efficiency wise. You're best to fork up front.

1319
Function Peer Review / Re: "Choose" statement
« on: July 08, 2011, 03:16:40 PM »
Ah; you've stumbled on a way to make ENIGMA honor max() having unlimited parameters. :P
That's... typically kind of dangerous, but I guess it's as good a hack as any. For the time being, you can implement those functions like this:

Code: (C) [Select]
variant choose(...);
int choose(const enigma::varargs& args) {
   return args.get(rand() % args.argc);
}
#define choose(x...) choose((varargs(), x))

You must declare and implement choose before defining it. In the source, you may be wise to #undef choose, then implement it. DO NOT implement choose(...); it's too segfault-prone. This way, worst-case scenario is link error, not random abort().

1320
He was bitching at me about the fonts being misaligned last revision, so I think whatever is broken is unique to this one. I fixed font_add_sprite() for him a while back.