Josh @ Dreamland

Note that this is not a normal GM function. I mean if this were a normal function,

array_init(myarray, etc.)


would try to read the value from the variable myarray and then execute the function on its value. However what is meant is using the name myarray. Actually, it is more like

Ism was merely using the same parameter format forwarded by Mike with dim(i,20). It's clear that either he intends to change that behavior to accept references (which would be rather interesting), or he was speaking in a less literal sense.

I'd like to second the notion of array_init; Dim() breaks a long-standing convention, most people don't live long enough to type variable_local_array_set every time they want something done, and `dim' shadows a BASIC instruction.

That said, I'm also with Rusky on the proposal to allow i = [1, 2, 3], or for that matter, shamelessly steal from MATLAB and allow i = [1..20], or, though I can't imagine it, i[0..20] = 0. I'm not fond of the latter proposal, but i = array(20,0) would be fine. The first issue I believe you'll run into is that GM doesn't have default parameters, so the 0 must be explicit or the system must be modified. It also doesn't allow setting arrays... perhaps you could consider defining a new operator for array copy. Really, I'm just throwing out some ideas.

As for your script parameters, what I have done is this:
1) Move argument0 and co. into the script scope, as you seem to have already taken for granted,
2) Allow an unlimited number of parameters (any reference to argument# will be accounted for),
3) Default all used arguments to zero (so if they are passed, only necessary copying is done, while if they are not, no unused variables are set).

That introduces one vulnerability, namely, if you use only argument0 and argument256, you will end up with 256 parameters of useless slag. Considering how queer a scenario that is, I choose to ignore it completely and assume no one will ever notice.

"Windows is EXTREMELY good at scaling textures."
No, graphics cards are. Windows is not involved.

"It doesn't matter what the size of the textures are, so long as they are to the power of two."
Larger texture = slower render. Larger polygon = slower render. More polygons = slower render.

"So, if you had one big polygon, with a texture in the middle, that would render faster than say, a low-res texture plastered over a high-poly wall."
Yes, that much is obvious. But that isn't the lie you've been spreading; this is:

Yes they [the sprites] are [made of polygons]. In fact, all 2-D sprites/backgrounds/textures you see on the screen in a Game Maker game are 2-polygons textured with the sprite/background.

Waste of processing power if you ask me. We both know that using the drawing co-ordinates in a polygon wisely can lead you to drawing a single triangle, while keeping all of the sprite texture in the middle (This method draws half the polygons that the normal draw_sprite(...) function does)

Your latter posts have been nothing but red herring after red herring. Your original point was some blasphemy about how using quadrilaterals was a waste of "processing power," and that time could be saved by drawing a large triangle instead. I gave four different problems with that idea, and you're defending yourself by throwing examples where the concept fueling your idea actually applies. Any idiot can observe that games use high resolution textures with small polygon counts. It saves math for the GPU when blitting pixels. But this doesn't apply to sprites, which I have proven above to reduce the speed when drawn as a single, large polygon.

You can tell me time and time again that I don't understand <incredibly simple concept>, but the fact stands that your argument is that a large triangle to draw sprites is faster than two small ones, and the fact still stands that the idea is wrong.

Now stop looking for excuses to say that GM could be faster if it used one triangle for sprites. In other words, stop spreading lies.

Is that your argument against the results? Understand that the polygon count is irrelevant when the single polygon is twice the size of the two small polygons added together.
Render the same model in the same projection at 32*32 and at 512*512. The larger one will take longer, even with the same polygon count. It's not a difficult concept.

I ran a benchmark, first Using quads, then Using triangles. Also, for kicks, I corrected the position in your method, which further reduced the FPS.

The code was as follows, using a library of mine offering GML-esque events and functions, in the draw event:

draw_sprite(sprite0,0,0,0); // Set the bound texture to sprite0
draw_set_color(c_white); // Make sure we can see our sprite!

repeat 20000
{
  int xx = random(640), yy = random(480); // Pick a spot
  
  xx -= 32; yy -= 32; // This was added afterward to demonstrate detriments of one aspect of compensation for your method.
  glBegin(GL_TRIANGLES);
    glTexCoord2d(-1,1);
    glVertex2d(xx,yy+64);
  
    glTexCoord2d(1,1);
    glVertex2d(xx+64,yy+64);
    
    glTexCoord2d(1,-1);
    glVertex2d(xx+64,yy);
  glEnd();
}
room_caption = string(fps);

draw_sprite(sprite0,0,0,0); // Set the bound texture to sprite0
draw_set_color(c_white); // Make sure we can see our sprite!

repeat 20000
{
  int xx = random(640), yy = random(480); // Pick a spot
  
  glBegin(GL_QUADS);
    glTexCoord2d(0,0);
    glVertex2d(xx,yy);
    
    glTexCoord2d(1,0);
    glVertex2d(xx+32,yy);
  
    glTexCoord2d(1,1);
    glVertex2d(xx+32,yy+32);
    
    glTexCoord2d(0,1);
    glVertex2d(xx,yy+32);
  glEnd();
}
room_caption = string(fps);

As you can see, the quad version operated 50% faster, roughly. I also shifted the clown gif up and left one pixel to demonstrate the concept I described to you above. I assume you can find the error. Correcting it requires a transparent border. Adding another pixel around the image will cause some cards to default to software rendering, which would slow the drawing horrendously, so to account for it, the dimensions would have to be rounded up to the next power-of-two, quadrupling the VRAM usage.

Even if the edge were transparent, which could be attained if GL offered GL_SAMPLER as a clamping mode, the pixels would still be drawn, and the speed would not change.

Now stop spreading lies.

...

Understand that a single triangle instead of two forming a square is going to be twice as large as the original square, which must logically fit in the middle.

A larger polygon means more pixels drawn. The graphics card will not stop at the texture edge just because you think it should so you can save a poly. I gave two methods above that would fix that, but in both cases, the net result was less efficient than just drawing a quad.

The number of pixels you are filling in matters every bit as much as the number of polygons, if not more.

...And again, that number is twice as much.