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
Off-Topic / Re: Perfect low-level game framework
« on: July 02, 2010, 06:18:06 PM »
Sure, it's not detrimental, but it's little things like that which ultimately pile up. I'm just saying that the superior choice, however more or less convenient it would be, is to make the user explicitly switch context. Like surface_set_target in GM.

And yes; I was planning on making some GUI functions in ENIGMA that would potentially allow you to switch the current context to a new window. The only reason I'm making it, though, is for other pieces of ENIGMA to use; it's not really helpful in games. I just figure I may as well offer it up for use.

1847
Off-Topic / Re: Perfect low-level game framework
« on: July 02, 2010, 03:31:14 PM »
Our ideals are only slightly off.
"The API would be object-oriented."
By this, I figure you mean
Code: [Select]
Gaming.Engine.Code.Functions.Drawing.Images.SpritesInParticular.Rendering.DrawSprite(
  resources.images.sprites.byIndex(0),
  self.locals.drawing.images.sprite.index,self.locals.position.mouse.x,self.locals.position.mouse.y
);
But I'll be damned if I'd put up like that in anything other than Java*. Yes, now that I see your example code, I've noted that you're content with just DrawUtils::DrawRect. But eh, I vastly prefer draw_rectangle, personally.

"BMP, PNG, WAV, OGG and OGV"
I'd not settle for anything not supporting XM. And MP3 is a major plus.

"Contexts: Having many contexts at the same time. Then one'd just apply the functions(begin, end, etc.) to a different context and it'd "just work". OpenGL isn't very context-friendly, since you can only have one active context at any given time."
Easily implemented, major efficiency damper. Each draw function would have to check that the correct context is bound, and the user would have to specify that context every single time. That's annoying to user and GPU.

I don't know what you've used that you're acting as though video is some magically aloof resource that can't be treated as a texture. Must have been one fucked up little library. Happens when libraries do too much for you, I imagine. I can't think of a reason any respectable video renderer wouldn't have FBO's/contexts usable as textures.

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

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

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

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

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

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

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

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

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

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

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

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

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