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

2236
Announcements / Re: Summary
« on: March 26, 2010, 10:16:13 PM »
> anyway, what all is left for R4? also, are there gunna be any native binaries of this example?
Finishing scopes in the GML formatter and syntax checker; not imperative but still desirable. Formatting with() and implementing improved switch().

That's enough work until Sunday.

Then all that's left is setting up communications between LGM and ENIGMA, including better resource translation and error reporting/lookup.

2237
Announcements / Re: Summary
« on: March 26, 2010, 09:51:38 PM »
Car is significantly easier to type than engine...

2238
Proposals / Collaboration by Timestamps
« on: March 26, 2010, 09:50:48 PM »
Serp remarks that GM is unsuitable for collaboration due to resources all being in one file.

I think a nice fix for this would be to store a time of creation (milliseconds-since-Jan-1970 style) as well as a time of last modification and time of last splice in with every resource.

LGM could then offer a splice function that would check each of the three things, like so:
If the resource exists in A (true, we're iterating)
{
  If it doesn't in B (!B)
  {
    Keep A
  }
  else, it does exist in B (B)
  {
    If the time stamps of creation are the same (A.created == B.created)
    {
      If the time stamp of modification of A matches the time stamp of last splice of A (A.modified == A.spliced)
      {
        If the time stamp of modification of B does NOT match the timestamp of splice of B (B.modified != B.spliced)
          Assume B is newer, and copy B to A
        Else
          Continue to the next resource; they should be the same.
      }
      else
      {
        If the time stamp of modification of B matches the timestamp of splice of B (B.modified == B.spliced)
          Assume A is newer; keep it
        Else (B.modified != B.spliced and A.modified != A.spliced)
          I have no idea what to do here. Ask the user, show a Diff somehow. This is what requires work.
      }
    }
    else, they are different resources entirely (A.created != B.created)
    {
      If the names are the same, both users may have been thinking the same thing (A.name == B.name)
        If on prompt for action the user says to skip it
          Continue to next resource
      Increment the id of B to the next available resource ID.
    }
  }
}

2239
Proposals / execute_string via Google V8
« on: March 26, 2010, 09:25:32 PM »
GML's consistency with C++ is nothing compared to that with JavaScript. I could add a newline after everything and not have to worry about adding semicolons. Hell, I could put everything in parentheses, too; I wouldn't even need a lexer. V8 is amazingly fast, and it compiles the JS Just-in-Time.

I believe I mentioned earlier that JavaScript even has a with().

I'm vaguely familiar with the workings of V8, and it would not be difficult to use some basic accessors to simulate odd effects of GML, such as speed/direction - hspeed/vspeed correlations.

Functions are also amazingly simple to add to either language across V8.

2240
Proposals / Debug mode: Tracking array bounds on scalars
« on: March 26, 2010, 09:20:20 PM »
Var makes it so users don't have to worry about their array bounds. Scalars allocated in bulk do not.

The idea of present is abstract and unresearched. Basically, we create a structure to proxy for each scalar*, such as int* or double*. A second proxy (or perhaps just the class of the first) will be used with calls to new[], having that operator overloaded.

So, in int_allocator::operator new[] (size_t sz), we do something like this:
value = new int[sz+1];
*value++ = sz;

Treating the struct as an int* will work just like a regular int*, but more operators could be overloaded to ensure correct performance.
#define is also an option; this is just a debug mode.

Upon access via the other class, int_proxy, the allocator class will be decremented and dereferenced for a bounds check.

2241
Proposals / Rules
« on: March 26, 2010, 09:11:27 PM »
The rest of the forum's rules apply here, too. Go figure.

Anyway, the rules here vary according to the mood of the moderators. Your topic may be praised one day and locked the next on the grounds that it is "stupid."

This forum was made mostly as a notepad that I don't have to leave open all the bloody time. Bonus: Other people can read, comment, build onto, and suggest, not only on my ideas, but on each others'.

That said, no "stupid" ideas. But do feel free to make suggestions.

Your suggestions are subject to being flamed to hell before ever being considered. Being flamed to hell does not mean that your suggestion has not nor will not be considered.

I still encourage such suggestions, however. Especially the useful ones.
This IS a place for debate.

Something about tacos.

2242
Announcements / Re: Summary
« on: March 26, 2010, 08:59:08 PM »
> Just curious, but shouldn't an error like that be reported in a more typical fashion, rather than crashing to hell?
We can have a debate over this if we need, but basically I think it's best to leave errors for the testing phase and let the fast code be fast on its own.
The goal is to incorporate some sort of tracker for bounds overflows, but that can be difficult when a scalar type is used. Also, that's really something for debug mode. :P

2243
Announcements / Re: Collisions
« on: March 26, 2010, 08:17:07 PM »
For as many as you like.

2244
Announcements / Re: Summary
« on: March 26, 2010, 07:43:43 PM »
Heh, don't worry, guys, it wasn't an ENIGMA bug. Just an error with how the particle system was designed (specifically when I started using double instead of var).

Those who are interested can download the fix (and some extra-hoursepower builds, three total):
http://dl.dropbox.com/u/1052740/SHELL.zip

2245
Announcements / Re: Collisions
« on: March 26, 2010, 07:30:34 PM »
min(x,y,z) = min(x,min(y,z))

2246
Announcements / Re: Collisions
« on: March 26, 2010, 07:02:16 PM »
*doesn't see difference between collision_polygon and collision_triangle*
Would take an extra five lines of code.

I was thinking about just writing a wrapper to Box2D, really. Would take care of most such needs. Luda had started working on an engine that allowed for several polygon-based collisions...
I'm more concerned with bitmasks for GM-simulation purposes (Can't really think of a time where a quad wouldn't cut it that Box2D wouldn't be favorable).

Also, 1337th post in Announcements.

2247
Announcements / Re: Collisions
« on: March 26, 2010, 06:25:41 PM »
Luda was just remarking about how easy that'd be to implement. He doesn't feel like signing on right now, though. *shrug*

2248
Announcements / Collisions
« on: March 26, 2010, 05:05:17 PM »
Luda is back!

He offered to take up collisions again today, which is good news for the project. Luda wrote the original system used in R3, which I implemented rather poorly (no collision event), but it has since been over a year and it is safe to say we're both "on top of shit."

He apparently has hatched a plan for improving collisions to operate in O(n*log n) rather than O(n**2) like most systems. I'm not sure what time GM operates in, but frankly, who gives a crap; Luda's were faster than Mark's last time. (At least, as far as I can tell. I thought Mark was supposed to be an expert on collisions?)

Anyway, I'm personally tickled pink. Luda learned not long after making the original system that he could improve it by using integers instead of bytes (somehow that wasn't common knowledge at the time, now it's so obvious...), and with his new Quad Tree idea, we should be cooking with gas.

Also, I'd like to remind everyone that DLLs are also part of the equation now. These systems are the two things that everyone concurred are all that's left to set ENIGMA and GM apart. Let's hope we don't blow this, eh?

2249
Announcements / Re: Summary
« on: March 26, 2010, 12:19:23 PM »
I'm hoping to improve var's speed from R3's. Have a newer version lying around somewhere. Other than that, not that I can tell. I ran a best-case version of this with beyond-perfect general-purpose optimization, and it ran the same speed. So, I think this is as good as we're getting from lines.

Loading time will increase slightly with sprites, but it shouldn't require a "Loading" form.

I'm just glad it consistently performs faster than GM, with some seven times the particles. XD

2250
Off-Topic / Re: Who hear is from the GMC?
« on: March 26, 2010, 10:44:18 AM »
:troll: