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

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

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

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

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

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

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

1627
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?

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

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

1630
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)
    return;
 
  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;
 
  glBegin(GL_QUADS);
  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;
    else
    {
      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;
    }
  }
  glEnd();
}

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.

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

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

1633
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().

1634
Function Peer Review / Re: move_towards_point + move_snap
« on: October 25, 2010, 08:40:20 pm »
#define motion_set(newdirection,newspeed) (direction=(newdirection), speed=(newspeed))
Is the STRICT EQUIVALENT to inline double motion_set(double newdirection,double newspeed) { return (direction=(newdirection), speed=(newspeed)); }. There is NO context under which the inline would work, and the macro I specified would not.

Furthermore, if ENIGMA's source is full of more complicated inline functions than this one, compile time will be a disaster.

Again, the reason to write a function for this instead of a macro is to save some trig in assigning hspeed and vspeed.

1635
Function Peer Review / Re: move_towards_point + move_snap
« on: October 25, 2010, 06:22:45 pm »
Because with macros, you can seamlessly manipulate locals such as direction and speed.
...An inline function would be more efficient, though, as hspeed and vspeed would only need to be edited once.