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

Proposals / Re: Thoughts on forum registration...
« on: November 03, 2010, 11:55:14 PM »
Actually, bots kept getting past the first question, which indicated to me that they're either smart enough to segment the domain name based on its - location, or they had enough time to guess any relevant keyword turned up by Google (or available on that page). Really, it seems more likely to me that a paid hand got through it by being smart enough to read the logo atop the page (which seems ridiculously unlikely considering ENIGMA's small pagerank: how can any human have just happened upon this site?). The filter was designed to stop not only bots, but uninterested humans.

GM's language, its tileset pseudonym, and ENIGMA's own language were all acceptable answers. Needless to say, we haven't had any bots since. (In fact, we've had two new users, yourself included, and neither has said anything about sterling silver or real estate).

I'm going to give this a week, and if no bots join, I'll try it with just yellow fruit, for which there are a bazillion acceptable answers.

Some things use bboxes, sure; it would be horrible to have collision tests done on every face of every landform and every character. But to treat each object as a simple box isn't always a great idea. Often a simplified mesh is used for collisions instead of just a box. The meshes are, of course, composed of triangles.

A good game, though, will use more than just meshes and boxes, anyway. Since most games are not designed to use the kind of general-purpose collision functions Game Maker offers (namely, place_free(): the number one most whored function in GM), each "object" will be treated uniquely by the controller (possibly the player). I intend to offer a number of functions for resolving primitive and mesh distances. More variety = more efficiency.

r9k's triangles are rotated. As far as 3D detection goes, I don't intend to use bboxes for 3D; I'll be skipping right to polygon meshes.

General ENIGMA / Re: DnD Functions
« on: November 02, 2010, 12:41:34 PM »
Ideally. At this point, options are still a YAML clusterfuck. But after we have it so you're able to switch out APIs, I don't see why not.

General ENIGMA / Re: DnD Functions
« on: November 02, 2010, 12:34:26 PM »
variant::operator bool() { return dval > .5; }

General ENIGMA / Re: DnD Functions
« on: November 02, 2010, 09:33:06 AM »
bool(-1) = 0 in GML

I have something that checks bboxes in ENIGMA, yes. Non-rotated. It's just called collision_bbox_rext(); it's like a less accurate place_free.

Also, r9k's been working on triangle/polygon collisions. Those'll be done sometime in the not-so-distant future.

General ENIGMA / Re: DnD Functions
« on: November 02, 2010, 12:31:06 AM »
If it's not the case that action_if is a substitute for "if", then it should be defined as inline bool action_if(double x) { return x >= .5; } (bool(x != 0) is redundant, anyway).

General ENIGMA / Re: DnD Functions
« on: November 01, 2010, 08:20:16 PM »
LGM should handle action_if itself, without writing action_if.
I am unsure of the function of action_if in a GML script. Can someone verify it?

Mmmyes. Wonder which one the code uses.

Can't test/fix now; off to class.

Worst case scenario: It's broken and we have to add svx*g-> to each xx and cvx * g->y to each yy...

> Even then thou, I think it was faster than GM.
It probably was. Or, at least, just as fast.

> Also, what would be the best way to load fonts on the fly?
If I knew that, I'd have done it years ago.

Function Peer Review / Re: GML: All draw_text functions (WIP)
« on: October 30, 2010, 09:53:19 AM »
Oh, perhaps you took a different approach than I would have. ...Actually, looking at your code, your approach is exactly what I was about to suggest, only your precalculations are fewer than they could be. Also, I don't understand something...

      ulcx = xx + g.tx * xscale * cvp + g.ty * yscale * cv2;

      ulcy = yy - g.tx * xscale * svp - g.ty * yscale * sv2;

Why are you subtracting the texture coordinate from it? the texture coordinate is between 1 and 0...
From what I can tell. ulcx should just be xx...

Also, you do a lot of xscale * cx... this is the sort of thing that I was going to precalculate, and here's why:
Your method is very close to what I think is the fastest. When you draw text, even rotated, the text is still following a linear pattern: You can trace a line across the tops of the glyphs. So all we really need is a sort of slope calculation based on trig.

This is about as efficient as I can see making the function:

Code: (C) [Select]
void draw_text_transformed(double x,double y,string str,double xscale,double yscale,double rot)
  if (currentfont == -1)
  font *fnt = fontstructarray[currentfont];
  if (cur_bou_tha_noo_sho_eve_cha_eve != fnt->texture)
    glBindTexture(GL_TEXTURE_2D, cur_bou_tha_noo_sho_eve_cha_eve = fnt->texture);
  float xx = (float)x, yy = (float)y;
  float w, h = fnt->height*yscale;
  rot *= M_PI/180;
  const float sv = sin(rot), cv = cos(rot),
    svx = sv*xscale, cvx = cv*xscale, hi = h * -sv,
    sw = fnt->height/3 * cvx, sh = fnt->height/3 * svx;
  for (unsigned i = 0; i < str.length(); i++)
    if (str[i] == '\r')
      xx = x, yy += hi, i += str[i+1] == '\n';
    else if (str[i] == '\n')
      xx = x, yy += hi;
    else if (str[i] == ' ')
      xx += sw,
      yy -= sh;
      fontglyph &g = fnt->glyphs[(unsigned char)(str[i] - fnt->glyphstart) % fnt->glyphcount];
      w = (g.x2-g.x), h = (g.y2-g.y);
        glTexCoord2f(g.tx,  g.ty);
          glVertex2f(xx,  yy);
        glTexCoord2f(g.tx2, g.ty);
          glVertex2f(xx + w * cvx, yy - w * svx);

        const float lx = xx + h * svx;
        const float ly = yy + h * cvx;
        glTexCoord2f(g.tx2, g.ty2);
          glVertex2f(lx + w * cvx, ly - w * svx);
        glTexCoord2f(g.tx,  g.ty2);
          glVertex2f(lx, ly);
      xx += g.xs * cvx;
      yy -= g.xs * svx;

Also, don't sweat string manipulation. The only way the user could tell the difference between escaping # at compile time or treating it special at run time is to use chr(whatever) and concatenate. Other than that, if they try += "#", they'll just be saying += "\r\n", etc, etc.

Function Peer Review / Re: GML: All draw_text functions (WIP)
« on: October 29, 2010, 07:20:32 PM »
1) It is \r\n
2) The \r is optional in everything not strictly Microsoft (IE, not Notepad).

Function Peer Review / Re: GML: All draw_text functions (WIP)
« on: October 29, 2010, 06:32:09 PM »
Please don't do that.
ENIGMA lets you choose how to escape string literals. There are two settings, though you can't yet switch between them:
1) GML. "Quote inside quote looks like " + '"this."' + " Newlines are escaped from '#' automatically."
2) C++. "Quote inside quote looks like \"this.\" Newlines must use \\r\\n, like this: \r\n ^ line ^ \r\n # does nothing."

Function Peer Review / Re: GML: All draw_text functions (WIP)
« on: October 29, 2010, 06:18:36 PM »
First off, I'm quite impressed at how quickly you got on this; I haven't even announced that fonts were in.

More importantly, I have to express some concerns before I adopt these:
1) Trig functions and multiple multiplication operations are performed in each loop iteration for the transformed font functions. That is a costly move compared to what could be accomplished with a simple precalculation (considering none of them are dynamic, as far as I know).
2) I was not quite done with linear fonts at the time of commit. For example, look what happens to the "I" in this screen shot. It's not the spacing that concerns me as much as the fact that "I" is only one pixel wide. I fear the worst.

Your work is, of course, appreciated greatly nonetheless. Neither of those are a serious detriment; I will just need to go over them when I have a few more answers.

Good work.

Also, I was looking into regex for ENIGMA, but the best interpreter out there for C++ is apparently Boost, and they totally fucking overkill everything. I just want a damn preg_match and preg_replace for ENIGMA; it shouldn't be 65 source files and it shouldn't have a fucking config file. Damn it.

And one more thing: in case you're wondering where that screenshot came from, it started out as an example someone posted on the GMC, which I stumbled upon looking for an explanation of the parameters to font_add_sprite().