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

1846
Announcements / Re: COmputers SUck
« on: July 02, 2010, 03:09:34 PM »
Clearly it's only slightly retro-compatible <_<"

1847
Off-Topic / Re: Google V8
« on: July 01, 2010, 09:28:07 PM »
Yahoo games only work in Internet Explorer.
...That's why my mother uses it.

1848
Off-Topic / Re: Google V8
« on: July 01, 2010, 03:58:04 PM »
Yep. And I refuse to have any ties whatsoever to VStudio. I figure Google will make it happen eventually.

1849
Off-Topic / Re: Google V8
« on: July 01, 2010, 12:04:25 PM »
GM defaults to the instance scope. local. It also keeps lists of other scopes to check first. The first of those is the script scope, declared with "var". The second is the global scope, declared with "globalvar". Execute_string gets its own script scope, and so won't share a var declared in the calling scope. However, execute_string will also default to the calling instance scope if the variable isn't on either list.

var foo; will print "old".
Just foo="old"; will print new.

1850
Off-Topic / Re: Google V8
« on: July 01, 2010, 01:04:44 AM »
Ah, right. I was focusing on the execute_string() part and managed to totally ignore his means of declaring it in the first place. In either case, the behavior is the same. V8 would have no way of accessing a temporarily created scope. So really, it will show "new" so long as neither have "var", in both ENIGMA and GM. So, yes, retep, that's exactly what it means.

1851
Off-Topic / Re: Google V8
« on: June 30, 2010, 08:10:44 PM »
Luis's example didn't say var...

1852
Announcements / Re: COmputers SUck
« on: June 30, 2010, 07:57:39 PM »
Oh, fuck timing. I'll deal with both of those things, now.

1853
Off-Topic / Re: Google V8
« on: June 30, 2010, 04:50:16 PM »
The global accessor for foo invoked by V8 would access enigma::instance_event_iterator->inst, executing the code-generated fetch for foo, returning this->foo, thus far reading "old", and assign it to "new". The printed result would be "new".

1854
Announcements / COmputers SUck
« on: June 30, 2010, 04:37:53 PM »
It's been a long journey, ENIGMA has. I've picked up a lot of tricks on the road, trying to complete it. The events and workings that transpired while working on R4 were extensive, not that I think most will notice. I've finished my replacements now. Instance System 2, Var4, and Reflex2 are all implemented. With little left to correct. But there are still some problems that I have personally and that ENIGMA has in general. The list is large and foreboding.

1) On Windows Vista, video memory is cleared every time the user presses control-alt-delete. ENIGMA loses its drawing context in the fire, and GM6 loses its surfaces. Yes, GM6 doesn't run on Vista, but I can't speak for 7 and 8 because I can only imagine Mark has corrected that in the meantime. So yes, every time the user presses control-alt-delete, ENIGMA loses the ability to display things. I'm not yet sure how to correct this, but I imagine I can test if it's happened and just ask for a new one.

2) On Linux, input is awful. In fact, much of Linux is glued together where it should be loosely tied with strings. I can't tell you how many times I'll be reading something huge, and will, without thinking, use the middle mouse button to gesture vertical scroll, only to wait for ten minutes for Firefox to finish this conversation with X:
Quote
Oh, you want me to scroll up? One minute.
*Scrolls some three pixels*
Gee, thanks Firefox.
Hey, Firefox, the mouse moved. And that button's pressed.
Oh, so you want me to scroll up? One minute.
*Scrolls some three pixels*
Gee, thanks Firefox.
Hey, Firefox, the mouse moved. And that button's pressed.
Oh, so you want me to scroll up? One minute.
This continues until either
A) No more mouse move events in the queue. This takes approximately enough time for Earth's amoebas to evolve, gain sentience, become this universe's greatest minds, construct their own universe in parallel with our own, live there for some hundred thousand millennia, populate the entirety of it and then begin a siege on ours for more living space.
B) FireFox reaches the end of the page, which causes the conversation to look more like this:
Quote
Hey, Firefo--/Yeah, I know, I'm out of scroll space./Ah, okay./Hey, Firefo--/Yeah, I know, I'm out of scroll space./Ah, okay./Hey, Firefo--/Yeah, I know, I'm out of scroll space./Ah, okay./Hey, Firefo--/Yeah, I know, I'm out of scroll space./Ah, okay.
Causing for near instant completion.
During that time, though, while X is chatting with Firefox, it's too busy to, say, LET ME SWITCH FUCKING WINDOWS. So I've no access to anything to kill Firefox. Gnome-panel is dead, so I can't switch that way or use force quit, and alt-tab/control-alt-delete are non-responsive. Control-alt-f2 also does something very unsavory. I can't remember what.

So, you may be wondering, why the bitchfest on the ENIGMA forum? Well, because ENIGMA inherits all those fun problems. If an input problem surfaces, I never know if it's my fault for screwing up ENIGMA or if it's my cry-blood-inducing, woefully inadequate input drivers.

And speaking of drivers, here on home, sweet 127.0.0.1, my graphics drivers are also parsecs ahead of the latest and greatest human technology. </sarcasm> So basically, it takes ENIGMA (and old Game Maker games that still work with WINE) approximately 11.25 microseconds to draw a single pixel of sprite (A single 128*139 sprite draws at 5fps). No other computer I've tested on has this problem, and GM does it to, so I know it's not my fault directly. The question is, how is Firefox blitting out images at decent framerates? Hell, there's a huge wallpaper rendering on my desktop, and it's not going 0.2 fps. What does it take? I'm not sure. I'll probably need to look into hardware acceleration.

(For the record, draw_rectangle with fantastic gradients works at amazing speeds; it's only sprites that are slow.)


Either way, I imagine those problems will get worked out eventually. Like I said, the instance system, new var, and new reflex (speed, direction, hspeed, vspeed, room, etc) are done. Here's what's coming up to do:

1) Test heredity. This should already work in cases such as instance_nearest, just by nature of the design of my new instance system.
2) Implement depth. This actually isn't all that hard, but may be annoying. Essentially, a new reflexive type will be created for depth. On assign, it moves the instance around in a map of draw events to iterate. In the constructor of each object, depth = <compiler inserts default depth here>; is executed. Or perhaps a separate constructor to avoid checks.
3) Go back over the syntax check and format parse, adding the remaining features.
4) Implement backgrounds. It's about time that got done. Then implement tiles, and add them to the draw depth map by way of instantiating a custom object_basic that does nothing but draw tiles at a given depth.

After that, I'll be content to start adding DND functions. These will be implemented like any other function, by the GM tile name, i.e., action_set_speed(). ENIGMA is healthy enough now that I would recommend and appreciate help implementing those.

1855
Off-Topic / Re: Google V8
« on: June 29, 2010, 04:23:21 PM »
Nay, one's almost entirely code-generated. I have to maintain an extra wrapper function for V8 to use as an accessor.

Luis: Static is for the entire function. No point in burdening the linker.

1856
Off-Topic / Re: Google V8
« on: June 29, 2010, 02:17:54 PM »
I don't simply propose things without thinking them through. I considered everything mentioned here and then some months ago, bouncing ideas off of Luda. It's been necessary since square one that a hash table be kept for each instance if all aspects of GML were to be supported. I statically compile everything I can, yes. R3 in fact did nothing with hash tables; R4 doesn't yet, either. But consider this code:
Code: (GML) [Select]
random(10).flarg = 90;What happens if flarg doesn't exist in the randomly chosen instance? This worked in R3; in R3, a dummy object by the same type was returned. In GM, however, the variable is added to the huge hash map Mark keeps. To simulate GM, a hash table would be used by flarg's accessor. (In R3, the accessor was this bulky thing that copied everything, because the instance system practically relied on it). Note, of course, that accessors can have nasty implications, and so are only used for instance.varname lookups. The other alternative is to scope all variables accessed that way into the parent object, but that wastes some memory in instances not using the variable, too.

The trick is that compiled code knows what variables it's accessing. Only the code-generated accessors would ever work with the hash table. V8 Would call those same accessors (which would be generated indiscriminately for the occasion); not interface with the hash table directly, which would indeed turn the entire operation into a huge mess.

What does turn the operation into a huge mess is having ENIGMA generate a wrapper to the entire C library for the interpreter. I'm surprised that wasn't your first point of attack, it's clearly the most intricate. I'll indicate, though; it is well within my capability using some neat var hacks. V8 requires all called functions take its own interesting argument array type. The array can be iterated for pass to C functions. Casting is the trick; ENIGMA doesn't keep track of argument types. So the solution is indeed an interesting one: Give ENIGMA's own variant a constructor for V8's varargs type. This would be done, via code generation, for all available functions. This is the C++ pseudo code:

Code: (C) [Select]
ofstream wto("interpreter.cpp");
for (fit fname = functions.begin(); it != functions.end(); it++) {
  wto << "static Handle<Value> V8_WRAP_" << fname->first << "(const Arguments& argument) {" << endl;
  wto << "  return (variant)" << fname->first << "(";
  for (int anum = 0; anum < it->second->argcount; it++)
    wto << "variant(argument[" << it << "]),";
  wto << ");" << endl << "}" << endl;
}

Because variant is programmed with macros, magic, and awesome, all that would be required is a cast for each argument to variant and then a cast from the result to variant. Variant::variant(v8::Argument) would handle conversion to a sane value. The magic with which variant is laced will handle conversion to the correct type for each parameter. Variant's magic constructors would then get a workable type out of the return value of the C function. Then variant::operator Handle<Value>() would take care of the cast back to something V8 can use.

1857
Off-Topic / Re: Google V8
« on: June 29, 2010, 01:20:07 PM »
...No? With() already offered such a headache, and the new instance system blows that headache right out of the water. The accessors would just be conscious of the with() scope (which, at its lowest element, is the event scope).

1858
Off-Topic / Re: Google V8
« on: June 29, 2010, 11:19:32 AM »
That's exactly what I said I'd do. And nope, not that lucky.

1859
Off-Topic / Re: Google V8
« on: June 28, 2010, 11:36:15 PM »
What retep said. But I was met with great opposition, as usual. In fact, the thread is still under the Suggestions and Proposals subforum.

You are wrong in one aspect, though; compiling it for Windows is a miserable fucking bitch and a half. I've never pulled it off.

1860
Proposals / Re: LGM Bug
« on: June 28, 2010, 11:31:52 PM »
That's good.

I'm just now realizing I didn't ask; Ism: what's that filename for? I have no insight to provide you in debug mode, only build mode... And I would expect an error, yes, but not an exception...