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

2611
Off-Topic / Re: lol
« on: July 30, 2009, 08:42:18 AM »
No, you see, Windows and Linux have trouble communicating sometimes. I wanted to rename the folder because my host thought one of the files was malicious. Trying to rename that directory, though, ended up in what seemed be files that were linked to multiple times. It left a copy of the original folders with nothing inside. Deleting those caused fail.

2612
General ENIGMA / Re: What limitations does Enigma have?
« on: July 30, 2009, 08:35:36 AM »
I meant in execute_string. Pointers have been allowed in full force since R3.

Also, you try that, and I'll take out my knife and shoot you.

2613
General ENIGMA / Re: XOR DOES NOT WORK
« on: July 29, 2009, 01:08:21 AM »
What serp said. Probably a good idea.

2614
General ENIGMA / Re: What limitations does Enigma have?
« on: July 29, 2009, 12:27:19 AM »
a2h--
Realize the simplicity.
Variables users add can be stored in a separate hash map. Think: if the variable, asdfWHATEVERghjkl, isn't referenced in the compiled code, there is no need to keep the compiled vars extensible; only to make sure that they can be accessed from within the string to execute.

Hash maps are a safe way to do that, too. I probably won't allow access to non-primitives in execute_string. Meaning the best you can do is int, double, char, and so on. Structs and pointers would therefore be disallowed, with exception, I imagine, of string. (And of course var)

At the moment I'm ready to go to bed, and am too tired to give it much thought. But thinking about how var and string would be allowed, I could *probably* add support for any predeclared structures; the ones I know at compile time. Dynamic structures, ones defined in execute_string, are probably out of the question, unless they are scopeless... Overall seems like too much work to bother with. Too much room to do something inefficiently.

But as for your basic GM execute_string, it doesn't seem all that hard, really.

2615
Announcements / Re: Subject
« on: July 29, 2009, 12:11:39 AM »
It's worse than int x; x.whatever;

In that code, you at least have four bytes to work with. This offers nothing; the structure has no member by that name, and it certainly can't be treated as an integer, so ENIGMA really has nothing to do with that but error.

2616
General ENIGMA / Re: What limitations does Enigma have?
« on: July 27, 2009, 10:06:53 AM »
Only one millennium.

But yeah. Executing a string will hopefully be possible, too. Really wanna see such a thing put to use in debug mode. But er, execute_string prolly will bite you if you declare something as int.

ENIGMA, being C++, technically has an infinite extensibility; anything C++ can do, it can do. This doesn't mean that I'll offer a help file over everything that C++ offers, as that would be impossible, due to the fact that it's so big. It also doesn't mean that it will always be as easy as a function with a 30-character name that you can guess at.

C++ is a huge language. Putting that at the fingertips of the user removes any limits, so long as you're willing to learn and willing to put some real work into it.

2617
Announcements / Re: Subject
« on: July 26, 2009, 10:51:54 PM »
Today's progress:
Got the syntax map working with basic tokens, and the rest of it is still being planned out.
The simplistic find-and-replace style of the original parser will no longer cut it, due to this trinket:

Code: [Select]
struct type
{
  int value;
  type& operator int() { return value; }
}

type a;
a.value = instace_nearest(x,y,object0); //This sets the 'value' member of 'a'
a.b = c; //This pretends 'a' is an integer, treats it like an id, and thus sets object0.b to the id of whatever the nearest object0 was

Depending on the practicality of your thoughts and your knowledge of C++, you're either saying "oh boy, can't wait", "who cares", or "he'll never pull it off".

Maybe one of you is thinking "good luck," but somehow I don't think so. sadface

That assessment will be based on whether the class you named has a method of casting as int, and whether or not it contains a member by that name. This was a real no-brainer scenario. Not sure what to do if someone says

Code: [Select]
struct a {} b;
b.a=0;

Will probably try to throw a syntax error.

2618
General ENIGMA / Re: Game Maker 8
« on: July 26, 2009, 10:43:33 PM »
Results from incompetence. Maybe they're expanding things as much as I am, and GM9 will support C++ too.
...GAHAHAHAHA

score_under--
We of the ENIGMA team do not support such piracy, yadda yadda, etc, etc. The ENIGMA team, in fact, discourages piracy, and posting pirated software here is prohibited... I'm having a hard time sounding all official on that due to the fact that I honestly don't care. But yknow, don't do that here.

2619
Announcements / Re: Subject
« on: July 25, 2009, 10:30:55 PM »
Luis-- score_under's a C programmer. If he has collisions, it's because what he's doing is so unforgivingly complicated that he needs that many variables.

score_under:
That's the less ugly way. There is an alternative, though, which is what I would have used instead in my example.
Code: [Select]
#ifndef DLL
  #define filearg_if_not_a_dll, char*filename
#else
  #define filearg_if_not_a_dll, char*filename
#endif

void DecodeProc2(FILE* fileM_,
unsigned int narc,
unsigned int FileZoomPos,
char*filename
                 filearg_if_not_a_dll)
{

But overall, people consider that a gruesome mutilation of the language, I imagine.





As for progress, it's anyone's game. Meaning. I'm tossing some ideas back and forth with Ism, who will be gone this week anyway. But basically, what we've done now is isolated which groups of keywords will have to be uniquely tokenized. (This grouping is changing a lot since I'm now supporting C++. When it was just the C basics and some GML, there was no need for this kind of reordering. Now there is.)

2620
Announcements / Re: Progress
« on: July 25, 2009, 12:28:40 AM »
It won't take until next year. I would like it to be before October, but I hate giving dates.
Also, can we not bring old news posts to the top? :P

2621
Announcements / Re: Subject
« on: July 24, 2009, 01:26:55 AM »
Today's standings:
Getting ass raped by preprocessors.
Code: [Select]
var a =
#if somemacro
  0;
#else
  20;
#endif

Don't get me wrong, that's a SHITTY way to do ANYTHING. But because it CAN be done, I have to accommodate it. And that just sucks.
The question left by the above piece of code is, should they not use them, HOW DO I ADD SEMICOLONS TO THAT?
The only way to take care of it is to go all out on my expression evaluator and have it evaluate #if. That way, I don't rely on GCC for that part.

#pragma will result in a PEBKAC exception, or will be moved to the DESIGNATED resource for such bull.
#define will probably be #undefine'd after the piece of code they are used in. This is mostly to remove confusion in cheap hacks, by eliminating them entirely.

And this sort of rage is why I never post progress XD
The general public isn't used to the fact that when I am flaming something like that, it's because I'm enjoying myself and am intrigued by a problem.
Consider it a way of not only venting, but also recollecting based on what's known to not work, process-of-elimination style.
This is nothing I can't handle. (I hope. Just believe it.)

2622
Announcements / Re: Subject
« on: July 23, 2009, 05:38:53 PM »
*facepalm*

global int x = x;
local int x = x;

alternatively

global.x = x;
local.x = x;

But both of those will end up being var.

2623
Announcements / Re: Subject
« on: July 22, 2009, 09:45:44 PM »
Retro:

Debug mode will hopefully utilize that expression evaluator I made.
Currently debug mode will offer some additional error checking, such as adding strings to integers.

I don't understand how casting to the global scope would work, really.
As in GM7, you can declare a global by saying
Code: [Select]
global var a;ENIGMA will just add local to that for things like this:
Code: [Select]
global var a;
local int b;
global double c;


Anyway.
Today's standings:

I've called this function basically every bad word in my vocabulary. It needs to keep track of scope for when you say "using", which totally fucks the simplistic find-replace structure of my parser in the ass.

Parser strips and stores strings now, and successfully removes all whitespace and comments. This was going to be the only major change, and it's proving to be just as big a pain as I thought it would.

The goal of what I'm doing right now is to set up what I call a syntax map, which is a copy of the code kept in a separate string, only where varnames, numbers, statements (such as if), declarators (such as var), etc, are each given a separate letter to represent them.

This is the same thing the original parser did, only I've condensed it, and am doing a couple things slightly different for improved efficiency.

The problem is figuring out whether the current name I've run into is just a name, or if it's a declarator like var. Checking if it is var is easy, but C++ brings classes to the table, so I need to be able to check if the user has declared a class by that name, too. Overall, it is a huge pain in the ass.

2624
General ENIGMA / Re: Game Maker 8
« on: July 22, 2009, 01:19:53 PM »
Didn't think I'd see the day. Pixels over .5 alpha are used in collisions, I take it?

2625
Announcements / Re: Subject
« on: July 22, 2009, 10:47:21 AM »
Next to no part of R3 was the same as R1. R3 didn't have a line of code in the same place as R1, but a diff would have shown that it wasn't more than 30% changed. R4, though... Probably not.

Rusky once called the RX releases 'Proof-of-concept', and I kind of like the term. And as I'm thinking of more concepts to prove, and fixing up the old things... Most of the code just isn't going to last.

ENIGMA used to be C, which means that some of the code still uses malloc() instead of new[]. (And then still fewer frees it with delete[] even after allocating with malloc XD). Things like that didn't make it to R3; only survived R2 because they worked. And I've thought of better ways to do certain things each progressing release (scripts in R1 probably didn't even work. R2's had some glitches, R3's didn't work in with()... R4's will be, so far as I can see right now, flawless).

ENIGMA's such a big project that it's impossible not to get better at things as you work on it. And as you get better, you notice how bad your old code was, you get a great feel for the big picture, and you think of ways to make even trivial things more efficient. I like being able to say I've paid attention to detail as far as efficiency goes. And even though no matter what I do wrong, it'll never be as slow as GM, I want to keep it as fast as possible.


Thinking back to the first release, how disoriented I was hooking everything together... There was so much that interacted with and depended upon so much else... I wanted to just lie down and quit. Couldn't follow it all in my head. I ended up blindly following the original plan without giving any question to what was going on, and it worked. Since then, I have no problem, as you can see, gutting the entire project and putting it all back together. It's even taking less time to do things.