1176 replies to this topic

[thatshelby]

Here are some suggestions:

I was playing around with the graphical settings of the code editor, changing fonts and colors. Found something I like. However, I noticed there is not a color setting for the left-hand line number space. I'd like this in, yo.

Also: The ability to change the default drawing font would be excellent. I would like to be able to make it a simple debugging font, that way I don't have to have one in my gm81.

[icuurd12b42]

Here are some suggestions:

I was playing around with the graphical settings of the code editor, changing fonts and colors. Found something I like. However, I noticed there is not a color setting for the left-hand line number space. I'd like this in, yo.

This was fixed in gm:html5

[lewis96]

I think it would be nice if there was some mechanism for placing many of the same tile in a room more quickly. If you're doing a floor for an RPG or something, it would be nice to be able to make a shape (like a rectangle) with those tiles filling the shape like pixels, except with a grid size. Get what I mean?

[TamoNekiTipo]

Are these of wishes ever actually realized?
or is it just to satisfy the community's dreams...

EDIT: Oh yea, I now saw this:

The YoYoGames development team do pay attention to this topic.

EDIT[2]: Since I can't double the post, I'll post my suggestion here.

In d3d_set_projection (normally in d3d_set_projection_ext ofcourse)
what is the [xup,yup,zup] for?
When [xup,yup,zup] should always be perpendicular to [xfrom,yfrom,zfrom,xto,yto,zto]
why not just making a single direction argument instead 3 more?
This would help newbies to better understand 3D.

Also, I would suggest to leave the above suggestion, and instead make a direction-based projection.
Something like this:

d3d_set_prokection_dir(dir,pitch,up,fov)

Where
dir - xy direction
pitch - z direction
up - up direction
fov - field of view (aka. "angle" in current function)

EDIT[3]: as soon someone posts in this topic, I'll post again this there.

EDIT[4]: What does this mean?:

Compilation - Yes, we all know compiled executables are faster. So do those developing Game Maker.

Does that mean that GM actually don't compile the program, but rather add resources to already created program? or what...

Edited by TamoNekiTipo, 16 January 2012 - 01:48 PM.

[Medusar]

When [xup,yup,zup] should always be perpendicular to [xfrom,yfrom,zfrom,xto,yto,zto]
why not just making a single direction argument instead 3 more?
This would help newbies to better understand 3D.

Because the (xup, yup, zup) vector need not be perpendicular to the line of sight. That's what makes it so easy, the up vector can remain the same throughout the game (if you don't want to tilt the camera that is).

Does that mean that GM actually don't compile the program, but rather add resources to already created program?

Yes. True compilation will (or may..?) be added in GM9.

[TamoNekiTipo]

Because the (xup, yup, zup) vector need not be perpendicular to the line of sight. That's what makes it so easy, the up vector can remain the same throughout the game (if you don't want to tilt the camera that is).

They don't cause they are "converted" over the sight vector.
Sight vector and Up vector must not be parallel (or else nothing is drawn), and that's why up vector should always be perpendicular to the sight vector.

Yes. True compilation will (or may..?) be added in GM9.

How could this be! I can't believe it! How did I didn't know this?
God, now everything makes sense...

[icuurd12b42]

Because the (xup, yup, zup) vector need not be perpendicular to the line of sight. That's what makes it so easy, the up vector can remain the same throughout the game (if you don't want to tilt the camera that is).

They don't cause they are "converted" over the sight vector.
Sight vector and Up vector must not be parallel (or else nothing is drawn), and that's why up vector should always be perpendicular to the sight vector.

Yes. True compilation will (or may..?) be added in GM9.

How could this be! I can't believe it! How did I didn't know this?
God, now everything makes sense...

Perpendicular how in relation to the facing vector? There is an infinite number of possibilities for a (non arbitrary) perpendicular vector in relation to the facing vector. If you want a simpler function, you can make one that assumes up is 0,0,1. The need for the up vector to be perpendicular is a bit misleading, it does not need to be perpendicular but somewhat compatible with the facing vector.

the facing vector in GM is obfuscated by the xto,yto,zto agruments. Not a vector but a coord. The facing vector is actually xto-xfrom,yto-yfrom,zto-zfrom, normalized for good measure.

When you look around using your head, your face has a facing vector and the top of your head is pointing perpendicularly to another direction. Tilt you head to the side looking the same direction, the top of your head is pointing another way (the up vector changes), you can choose an infinite amount of tilt between 0-360 degrees (including fractions).

Now you can look elsewhere with your eye without moving your head, your looking vector does not match your facing vector but is still somewhat in the same overall direction and still compatible though no longer exactly perpendicular with the up vector.


There is no way to know the perpendicular vector from a facing vector that would be meaningful to use as the up vector because the facing vector alone does not define the tilt of the camera.

[Erik Leppen]

You know what I'd love to have? A Bézier function.

bezier2(c0, c1, c2, t): quadratic Bézier interpolation, t between 0 and 1

var p01, p12, s, t;
t = argument3; s = 1 - t
p01 = s * argument0 + t * argument1
p12 = s * argument1 + t * argument2
return = s * p01 + t * p12

bezier3(c0, c1, c2, c3, t): cubic Bézier interpolation, t between 0 and 1

var p01, p12, p23, p02, p13, s, t;
t = argument4; s = 1 - t
p01 = s * argument0 + t * argument1
p12 = s * argument1 + t * argument2
p23 = s * argument2 + t * argument3
p02 = s * p01 + t * p12
p13 = s * p12 + t * p23
return s * p02 + t * p13

Especially the cubic (four-point) version. A lot of my games use it, and I'm sure a built-in function would be faster.

Another very common script in my games is an inline if function:

iif(a, b, c)

if argument0 {return argument1} else {return argument2}

However I don't know if such a thing would gain much speed if built-in.

[TamoNekiTipo]

@Erik Leppen
Oh my that is awesome.

[THE_GAME_EDITOR]

Gamemaker doesnt support 256x256 icons! Why?!

[Big J]

if argument0 {return argument1} else {return argument2}

However I don't know if such a thing would gain much speed if built-in.

I don't know if it's actually faster, but I write it like this:

return argument[!argument2];

It's the same, but the arguments are in a different order (TrueResult, FalseResult, Expression)

So, to match Erik's function exactly, it could be written like this:

return argument[!argument0 + 1];

Like that, the arguments are (Expression, TrueResult, FalseResult)

So it's called an "inline if"? That's helpful to know, I was always calling mine a "boolean switch".

[Rusky]

A lot of languages have a ternary operator for that- "expr ? trueResult : falseResult". Another lot of languages just allow if in expressions- "if expr then trueResult else falseResult"

[Dark Matter]

A lot of languages have a ternary operator for that- "expr ? trueResult : falseResult". Another lot of languages just allow if in expressions- "if expr then trueResult else falseResult"

Yeah, that'd be better to have.

[Yal]

I think it would be nice if there was some mechanism for placing many of the same tile in a room more quickly. If you're doing a floor for an RPG or something, it would be nice to be able to make a shape (like a rectangle) with those tiles filling the shape like pixels, except with a grid size. Get what I mean?

You can select multiple tiles from a tile set by holding CTRL and dragging in the image of the background you pick tiles from. It doesn't work properly when the tile set has separation/offset though.

[paul23]

A lot of languages have a ternary operator for that- "expr ? trueResult : falseResult". Another lot of languages just allow if in expressions- "if expr then trueResult else falseResult"

Yeah, that'd be better to have.

Also notice that in (most) ternary operators the "false result" is only executed if "expr" returns "false", this allows for writing statements like:

a =  ( b != 0  ? 8 / b : 0);

Using scripts will fail as when b is "0" 8 / b is infinite.

[Gamer3D]

Also notice that in (most) ternary operators the "false result" is only executed if "expr" returns "false", this allows for writing statements like:

a =  ( b != 0  ? 8 / b : 0);

Using scripts will fail as when b is "0" 8 / b is infinite.

Since you brought that up, YoYo should probably add short-circuit evaluation. This would increase speed (while keeping code easily readable), but might break old code (some of which might depend on GM checking EVERY expression)

[faissialoo]

stop dlls and exts messing with what the exe returns when the exe ends.

[IceMetalPunk]

Also notice that in (most) ternary operators the "false result" is only executed if "expr" returns "false", this allows for writing statements like:

a =  ( b != 0  ? 8 / b : 0);

Using scripts will fail as when b is "0" 8 / b is infinite.

Since you brought that up, YoYo should probably add short-circuit evaluation. This would increase speed (while keeping code easily readable), but might break old code (some of which might depend on GM checking EVERY expression)

Yeah, I've wanted this for a while. It's at the very least useful to replace nested if's with single lines:

if (b!=0) {
  if (variable/b > 10) {
    somevar = variable/b;
  }
}

Becomes

if (b!=0 && variable/b > 10) {
  somevar = variable/b;
}

Not the best example, but there are more compounded cases that would illustrate the point better, which I just can't think of now.

It would also be nice if ds_lists were implemented as doubly linked lists internally instead of normal arrays (i.e. vectors). Index-based functionality would still be supported, for the new programmers, but it could also support iterators which are much more efficient.

I created my own version of doubly-linked lists not too long ago, using constant-sized ds_lists to represent list nodes. They were much more efficient than ds_lists in everything except adding to the end, which I eventually realized is because if GM's arrays are vectors, they double in size whenever they reach the end, whereas my methods require new allocation for each new node. Still, everything else was orders better, so...I think it should be implemented "correctly" (i.e. in a more standard, generally more efficient way).

-IMP

[rwkay]

Short circuit evaluation is coming in GM9, I have wanted to add it for a while now but compatibility reasons stop me from doing it - I may add it as an option in GM:Studio (depends if I have enough time).

Russell

[Rusky]

Can I make a request for short-circuiting behavior? Scripting languages often allow logical operators to evaluate not to true/false, but to whichever object decided their truth/falsehood, which is then treated equivalently by e.g. if statements. This allows for things like default values with ||, or similar checks to the "b != 0" example in more contexts.

For example, to give argument3 a default value, since 0 (or null, that would be nicer) is treated as false, you could say

arg3 = argument3 || my_default

You could also do something like this, using &&, saving the result of some_call in foo:

foo = some_check && some_call()

This even allows for implementing ?: yourself, although it's not very readable:

a = cond && yes || no

Edited by Rusky, 24 January 2012 - 02:03 PM.