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

Announcements / Re: Victory
« on: November 28, 2009, 11:37:36 AM »
Fede's going a little stir-crazy over the amount of time since I've made a release. Maybe someone will take the incentive to splice R3 and R4... hehehe. Right.

Announcements / Victory
« on: November 27, 2009, 03:24:50 PM »
Code: [Select]
No error.
Parse time: 380 milliseconds

Macros (518) [+]
Variables [+]
Define: acos
  acos:  Function with 1 parameters, returning double  Dereference path: (params = 1)</group>

After I had what I thought to be the basics down, all the Windows C headers parsed without error. The Linux ones, however... It was a constant uphill battle.
Math.h employs such faggotry as calling __CONCAT on itself, which only works if it's called internally as an alias. For example, the first code works, the second does not:

Code: [Select]
#define __CONCAT(a, b) a ## b
#define TRIPLE_CONCAT(a,b, c) ALIAS_CONCAT( __CONCAT(a,b),c)
#define ALIAS_CONCAT(a, b) __CONCAT(a,b)
Code: [Select]
#define __CONCAT(a, b) a ## b
#define TRIPLE_CONCAT(a,b, c) __CONCAT( __CONCAT(a,b),c)

I'm not entirely sure why, really, and I don't care. Both work for me, and I see no reason to change it just because GCC only likes the first.

Anyway, more work to do. (Along with two research papers and a "scientific" paper to write). I'm a bit swamped, as usual.

Issues Help Desk / Re: Compiling on Linux... Possible?
« on: November 25, 2009, 10:34:33 PM »
Sure. R3 had a mechanism for using GCC ad-hoc, if you liked. (Search compile.h or whatever it was for the specifics).

Not sure what you want to do. If you have GCC installed already and don't want to download the core, that's the reason it was divided into two segments. However, I later realized what a bad idea that was since most people just want an easy-to-install package.

If you intend on getting it to work for Linux, it already does for R4, and getting R3 to do it would be a trick (though feasible for those who can work SVN and C++ enough to download and install ENIGMA's Linux port from the repo).

Off-Topic / Re: What does ENIGMA stand for?
« on: November 22, 2009, 09:58:41 PM »
For open source, C++ DLLs, they can just be included, yes.

I was thinking about asking Ism to incorporate a DLL resource (I believe GM5 had something similar to that, but I was too young to use it at the time.) Basically, the resource would do implicitly what the code does, but at compile time to (potentially) save speed later. I'm unsure of the actual speed difference caused by conditionally pushing things onto the stack, as is necessary in making DLL calls of undefined argument counts of variable-sized objects. (Namely double (8 byte) and char* (4 byte) ). Considering the fact that the calls could be hard coded, I imagine you could see a speed difference of almost 2x, but that's just for call. Extensive functions you call would render the difference in call time insignificant.

Such a resource, therefore, could save on number of lines of code in the case that a DLL's source is unavailable, and can potentially save on speed. So you may see that come along in the not-so-distant future.

It means "Josh was too fackin' lazy to do the easy part first."

While the G-Java teams decided to tackle the project on a more manageable basis, starting with DND, I imagine that was because we were all younger then. They didn't know how to write a parser at the time, hadn't heard of Yacc or the like. Incidentally, I wrote their first parser, in GML. Haha. It was terrible, but it worked for the most part. Unlike my newer ones, it wasn't very structured. It only got the job done because GML is such a small language.

Anyway, enough reminiscing. Long story short, I did code first because I didn't feel like taking a shortcut and alienating the most useful resource. In R4, Ism converts DND tiles to their respective action_ codes before she sends it to me. Until R4 is out though, stick with code.

General ENIGMA / Re: C++ Socket Based Networking
« on: November 22, 2009, 09:49:39 PM »
My vision for MPlay was to take Ism's code and add a loose-fitting wrapper to it. By loose-fitting, I mean that half the functions won't do anything. Like session ID and the related functions. Honestly, I wrote an MPlay library for GM once, and the terminology was so vague and preposterous I never managed to give it my own naming convention.

Not to mention the fact that, as far as I can tell, GM's MPlay hardly works for anyone. Seems to me to be for a couple reasons. Number one, those who use MPlay do so because they don't understand 39Dll or don't have a registered GM. These are the people that don't understand that MPlay isn't designed to turn their routed network into an MMO server.

Everyone that does understand that concept moves onto 39Dll. Except me, I suppose. ...Okay, so some people have made games with it, but honestly, I've never seen an MPlay game that was truly worth porting anywhere. All the good ones are 39Dll (Do correct me if I'm wrong, I'd be happy to believe MPlay was a sound system)

So ideally, MPlay will "work," but it will work in the same sense that it is understood: Superficially.

Off-Topic / Re: What does ENIGMA stand for?
« on: November 22, 2009, 10:48:58 AM »
As opposed to compiling it at, say, compile time. It'd probably be too much effort to re-reference that stuff at load time if he precompiled it. ...It'd still be pretty easy, though.

The GML frontend is a thin layer over C++. Not to mention the project is open source. Anyone can extend ENIGMA's functionality who knows even a little C++, and with the new parser, you can include C++ headers.

Indeed a play on Game Maker. ENIGMA doesn't have a bloaty format with a slow interpreter, it passes the code to a very capable compiler with a long-developed optimizer.

Game Maker-
That program that I'm considering disowning.

To augment is to change, specifically to add to, or intensify. ENIGMA adds C++'s syntax goodies to the mix, such as ++ and, well, typing, templates, you name it. Not to mention the possibility mentioned in E of including any C++ library.

Announcements / Re: stdio.h
« on: November 16, 2009, 10:31:43 PM »
It's a wrapper to ShellExecute. It's not implemented due to uselessness.

Because I ground all COW into BEEF.

Announcements / Re: stdio.h
« on: November 15, 2009, 09:49:54 PM »
It may turn out that Ism will have to start saving ENIGMA files in the format we use to communicate between the two apps, depending on how many of EINGMA's non-GM features we can cram into GMK format.

As for arrays by reference, your question is inapplicable. Ha.
var::operator double() will return the first element.
var::operator =(const var&) will ideally "copy" the entire array by reference as std::string does. This will be O(1). Editing an element from that point until the freeing of the first var will be O(N) for the first time, then O(1) from the second edit on. (The array is only physically copied when necessary).

For example.
Code: [Select]
  var array;
  //do some stuff to array
  return array;

//Step event:
  var a = script0();
  a[1] = 10;
Everything in that code operates in O(1), constant time.

Code: [Select]
  var array;
  //do stuff to array
  var b = a; //copies reference to array, operates in O(1)
  b = 1; //sets b[0] to 1, operates in O(N)
  b[5] = 2; //Obvious what it does. operates in O(1)
  var c = b; //operates in O(1) once more
  if (c) //operates in O(1)
   b[5] = 0; //operates in O(N)
  b[3] = 2; //operates in O(1) if c[0] != 0, otherwise operates in O(N)
Hopefully that clears it up rather than confusing people.

Current var doesn't do that, but minor modification will make that possible. This is planned, and easy to do.

Edit: Progress
As it happens, Linux stdio takes advantage of all those nice things I said still needed testing. So I've been working my ass off to get those to work. Also, apparently __const is a GCC keyword. Along with asm, __asm, and apparently __asm__, thanks score_under. v..v"

Furthermore, I'm tired, and still have psychoblah homework to do. Guess I'll do it tomorrow morning.

Announcements / Re: stdio.h
« on: November 15, 2009, 11:11:16 AM »
I suppose you could consider it peripheral. It has to be done at some point, however. It probably won't help GM conversion directly, but indirectly it will be able to parse the headers itself. What that means is that it can enable selection of which headers to include for later.

Basically, it brings the system closer to C++. Var is no longer just a type, it's a structure. And that structure has a method for casting to int, which can be used to identify an instance. It makes for a more intelligent parse that will make life easier down the road.

That being the case, although it doesn't directly help pure-GM games, it's not something I want to put off.

Announcements / Re: stdio.h
« on: November 12, 2009, 05:45:55 PM »
That question is actually pretty vague, considering how ENIGMA works. I am 90% positive GCC supports them, though I've never used one myself. I was considering an implementation of my own format for them to make syntax checking faster, but really, I'm not sure if there's a point. Ideally ENIGMA would be loaded as a DLL, and could do a lot of precompiling at start, which would save time later at the cost of startup time. However, it's really not that much time anyway... parsing those headers takes significantly less time than actually compiling them, obviously.

So, assuming you are talking about my parser, I might implement my own precompilation, but probably not right away, and almost definitely not GCC's. (Being able to work with GCC's output would void the point of parsing this myself.)

As for using precompiled headers in GCC to speed up compile time, that was something I intended to look into. I have no plan for it yet.

Announcements / stdio.h
« on: November 12, 2009, 10:37:36 AM »
Hello, all.

I'm happy to say stdio.h parses correctly, which means it's all uphill from here. (That saying makes no sense. Isn't going up hill more difficult than going down?) Okay, how about, it's smooth sailing from here.

Now, note that stdio is by far not the most difficult header to parse. Overall, it probably only tests 70% of what needs testing. The C++ headers will present plenty of challenge, as scopes will turn into my worst enemies. However, having stdio compile means that I can rely on some very basic things working as I tackle the more complicated problems. I can't really think of an analogy for what that means.

I'm very confident that quite soon, map<var,var> will be ENIGMA-parser-friendly.

Anyway, I'm going to move on to other C headers first, as there are some aspects of C that I've not yet focused on. These include the following, for those who are literate in the language:

Code: [Select]
#define concat(x,y) x##y This appears in many headers stdio includes. It's a wonder stdio actually works, unless I've implemented it and forgotten, which is a distinct possibility.

Code: [Select]
int (*blah)(int,int)[];Not sure how it will handle the parentheses around blah, or no identifier being named after int. It will probably bitch about both, so I'll run some isolated tests on that before I parse anything else. Do note that the system was designed with those in mind.

...Actually, that's it. Everything else should follow once those are done. Then we move on to templates (mostly implemented), class (needs to be integrated into the piece of code that handles struct), scope operator (see below) and tacos.

Scope operator (from bits/stl_tree.h):
Code: [Select]
pair<typename _Rb_tree<_Key,_Val,_KeyOfValue,_Compare,_Alloc>::iterator,bool>
In honesty, that was just to scare people. Like I told that one guy that none of you have ever heard of, that line doesn't look so scary when read character by character at millions of chars per second.


General ENIGMA / Re: Hardware Acceleration
« on: November 10, 2009, 08:37:35 AM »
I was originally. Now my idea is to use first my NVidia to get everything working nice, and then my ass-sore Intel chip that's never heard of GL to get it just working.

General ENIGMA / Re: Hardware Acceleration
« on: November 08, 2009, 09:42:47 PM »
Except implementing those for general purpose use will be a bitch. Try to run a valve game on the typical GM user's computer, I dare you. And hell, Valve's games are DX, which at least guarantees SOMETHING. Older users can tell you, surfaces errored for half the people that downloaded them.

Don't worry though, with the right extensions, they'll run great on *decent* cards, and they'll at least work on the rest.

Announcements / free()
« on: November 02, 2009, 09:14:04 PM »
Today I had to turn in Paper 3 for English 101. It was a 4-5 page requirement. I also had to turn in a 10-12 page essay on a self-help book for psychology. In both cases, I barely scraped the minimum requirement. I just hope I manage a good grade for them. Truthfully, I did the entire psych essay yesterday. All ten pages, including reading the book. THAT is an accomplishment. Unsurprisingly I am ending the venture as a slightly more religious person than when I began.

It is a nice feeling, to move that self help book and the accompanying essay to ~/Hell. I won't miss it.


Um. I can't remember. My brain is full of psychology and English fluff. Moment... Ah, yes. __asm. Totally forgot.

Code: [Select]
int returns_one() __asm(":mov $1, %eax");
That particular piece of code threw a parse error. After some WUTs, I fixed the problem. That's when I took a look at my psychology essay requirement and realized it was 10 pages. So I will be continuing now...

Also, we seem to be having some server trouble today. Don't worry, they're on it.