Jump to content


Photo

Game Maker Suggestions


  • This topic is locked This topic is locked
1176 replies to this topic

#961 thatshelby

thatshelby

    GMC Member

  • GMC Member
  • 3823 posts
  • Version:GM8

Posted 08 January 2012 - 12:22 AM

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.
  • 0

#962 icuurd12b42

icuurd12b42

    Self Formed Sentient

  • GMC Elder
  • 16281 posts
  • Version:GM:Studio

Posted 08 January 2012 - 05:19 AM

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
  • 0

#963 lewis96

lewis96

    GMC Member

  • GMC Member
  • 117 posts
  • Version:GM8

Posted 13 January 2012 - 09:38 PM

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?
  • 0

#964 TamoNekiTipo

TamoNekiTipo

    Centurion

  • Banned Users
  • 51 posts
  • Version:GM8

Posted 16 January 2012 - 01:01 PM

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? :huh:
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.


#965 Medusar

Medusar

    GMC Member

  • GMC Member
  • 1228 posts
  • Version:GM:Studio

Posted 16 January 2012 - 02:39 PM

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.
  • 0

#966 TamoNekiTipo

TamoNekiTipo

    Centurion

  • Banned Users
  • 51 posts
  • Version:GM8

Posted 16 January 2012 - 05:47 PM

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.

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

#967 icuurd12b42

icuurd12b42

    Self Formed Sentient

  • GMC Elder
  • 16281 posts
  • Version:GM:Studio

Posted 16 January 2012 - 09:27 PM

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.

:o 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.
  • 0

#968 Erik Leppen

Erik Leppen

    GMC Member

  • GMC Member
  • 2615 posts
  • Version:GM:Studio

Posted 19 January 2012 - 07:13 PM

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.
  • 0

#969 TamoNekiTipo

TamoNekiTipo

    Centurion

  • Banned Users
  • 51 posts
  • Version:GM8

Posted 19 January 2012 - 10:19 PM

@Erik Leppen
Oh my that is awesome.

#970 Alvare

Alvare

    Allrounder

  • GMC Member
  • 1370 posts
  • Version:GM:Studio

Posted 19 January 2012 - 11:40 PM

Gamemaker doesnt support 256x256 icons! Why?! :woot:
  • 0

#971 Big J

Big J

    GMC Member

  • GMC Member
  • 2852 posts
  • Version:GM8.1

Posted 20 January 2012 - 12:09 AM

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". :P
  • 0

#972 Rusky

Rusky

    GMC Member

  • GMC Member
  • 2492 posts

Posted 20 January 2012 - 04:26 AM

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"
  • 0

#973 Dark Matter

Dark Matter

    RPG Expert

  • GMC Member
  • 3196 posts
  • Version:GM:Studio

Posted 20 January 2012 - 06:52 AM

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.
  • 0

#974 Yal

Yal

    Gun Princess

  • Global Moderators
  • 9145 posts
  • Version:GM:Studio

Posted 20 January 2012 - 09:14 AM

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.
  • 0

#975 paul23

paul23

    GMC Member

  • Global Moderators
  • 3918 posts
  • Version:GM:Studio

Posted 20 January 2012 - 07:54 PM


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.
  • 0

#976 Gamer3D

Gamer3D

    Human* me = this;

  • GMC Member
  • 1819 posts
  • Version:GM:Studio

Posted 23 January 2012 - 07:47 PM

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)
  • 0

#977 faissialoo

faissialoo

    I get high on orange

  • GMC Member
  • 1240 posts
  • Version:GM8.1

Posted 23 January 2012 - 08:08 PM

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

#978 IceMetalPunk

IceMetalPunk

    InfiniteIMPerfection

  • GMC Elder
  • 9478 posts
  • Version:GM:Studio

Posted 24 January 2012 - 04:10 AM


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
  • 0

#979 rwkay

rwkay

    YoYo Games CTO

  • YoYo Games Staff
  • 2576 posts
  • Version:Unknown

Posted 24 January 2012 - 11:06 AM

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
  • 4

#980 Rusky

Rusky

    GMC Member

  • GMC Member
  • 2492 posts

Posted 24 January 2012 - 02:01 PM

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.

  • 0

#981 rwkay

rwkay

    YoYo Games CTO

  • YoYo Games Staff
  • 2576 posts
  • Version:Unknown

Posted 24 January 2012 - 03:25 PM

Most of the issue with that behaviour is down to how the '=' is interpreted in GML as it is not only the assignment operator but also the equality operator this is the reason that the a = b = c; does not work properly (as the b=c is interpreted as an equality not assignment) due to this the behaviour of short circuiting would not be very good.

Now I know that is a bit woolly but it is buried within the language definition and due to the nature of GML it is problematic - currently the parser enforces that the && || ^^ MUST have boolean arguments (the left and right of the operator) this stops the type propagation which is what you are desiring - in the long term for type safety I think this is a good idea (though I would like to hear the arguments for and against).

Russell
  • 0

#982 Rusky

Rusky

    GMC Member

  • GMC Member
  • 2492 posts

Posted 24 January 2012 - 03:51 PM

It is currently possible to do something like "a = b && c" as a statement, so I'm not entirely sure what the problem is parser-wise.

I do wonder how possible it would be to enforce == without confusing people though (or if it would even be beneficial).
  • 0

#983 rwkay

rwkay

    YoYo Games CTO

  • YoYo Games Staff
  • 2576 posts
  • Version:Unknown

Posted 24 January 2012 - 04:08 PM

In GM9 you will need to use == as it simplifies things so much at the parser

Trust me when I say that the Delphi parser it is complicated to do the propagation - for HTML5 and Studio it is a bit easier and I will investigate how to propagate the type correctly from left and right arguments of || && and ^^ - the problem is when you have 2 types that are not the same (say <int> && <boolean>) then the propagation rules have to make sense and be easily understood - some of C's more basic problems originally stemmed from arbitrary and ill understood edge case rules for things like this...

I will need to sit down and think about them when finalising GM9's GML

Russell
  • 0

#984 IceMetalPunk

IceMetalPunk

    InfiniteIMPerfection

  • GMC Elder
  • 9478 posts
  • Version:GM:Studio

Posted 24 January 2012 - 05:57 PM

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

I don't understand that second one at all...why would some_call() necessarily be stored in foo? With an && operator, both must be true to evaluate to true, so why is some_call() stored instead of some_check?

-IMP
  • 0

#985 Rusky

Rusky

    GMC Member

  • GMC Member
  • 2492 posts

Posted 24 January 2012 - 11:26 PM

If some_check evaluates to false, foo gets some_check. If some_check evaluates to true, foo gets some_call(). It doesn't matter what some_call() evaluates to at that point because if it evaluates to true, it will evaluate to true again; if it evaluates to false, it will evaluate to false again.

@rkway: I was thinking it would be pretty simple for && and || just to evaluate to the operand that decided their result, the way e.g. Lua, Python, JavaScript, Ruby, Lisp... do. There's no need to bring in C-like type coercion, and since GML is dynamically typed the result doesn't need to be coerced either.

Edited by Rusky, 24 January 2012 - 11:29 PM.

  • 0

#986 paul23

paul23

    GMC Member

  • Global Moderators
  • 3918 posts
  • Version:GM:Studio

Posted 25 January 2012 - 12:06 PM

If some_check evaluates to false, foo gets some_check. If some_check evaluates to true, foo gets some_call(). It doesn't matter what some_call() evaluates to at that point because if it evaluates to true, it will evaluate to true again; if it evaluates to false, it will evaluate to false again.

@rkway: I was thinking it would be pretty simple for && and || just to evaluate to the operand that decided their result, the way e.g. Lua, Python, JavaScript, Ruby, Lisp... do. There's no need to bring in C-like type coercion, and since GML is dynamically typed the result doesn't need to be coerced either.

So.. the TYPE of returned value may differ depending on the first operand? :yucky: That's even more places where you have to watch runtime behaviour. Ah well, I suppose it's not clever to feed strings to a place where you expect booleans anyways.
  • 0

#987 Rusky

Rusky

    GMC Member

  • GMC Member
  • 2492 posts

Posted 25 January 2012 - 02:35 PM

I don't see how that's a problem, especially with dynamic typing. The value will behave exactly the same when used in a boolean context with or without this behavior, and instead of throwing out information it just keeps it around to enable some useful idioms.
  • 0

#988 paul23

paul23

    GMC Member

  • Global Moderators
  • 3918 posts
  • Version:GM:Studio

Posted 25 January 2012 - 05:01 PM

I don't see how that's a problem, especially with dynamic typing. The value will behave exactly the same when used in a boolean context with or without this behavior, and instead of throwing out information it just keeps it around to enable some useful idioms.

I've never been a fan of dynamic typing. Weak typing is nice, however when a variable changes it's type of their life I frown upon that heavily. Just a trivial example of a "bug":
var i, s;
i = 10;
s = random(1000) < 1 && "hello world";
s += i;
That's a 1 in 1000 chance the program will crash.
  • 0

#989 Dark Matter

Dark Matter

    RPG Expert

  • GMC Member
  • 3196 posts
  • Version:GM:Studio

Posted 25 January 2012 - 06:56 PM


I don't see how that's a problem, especially with dynamic typing. The value will behave exactly the same when used in a boolean context with or without this behavior, and instead of throwing out information it just keeps it around to enable some useful idioms.

Just a trivial example of a "bug":

Well then, you make sure your code is better written than that, don't you?
  • 0

#990 Rusky

Rusky

    GMC Member

  • GMC Member
  • 2492 posts

Posted 25 January 2012 - 11:37 PM

I've never been a fan of dynamic typing. Weak typing is nice, however when a variable changes it's type of their life I frown upon that heavily. Just a trivial example of a "bug":

var i, s;
i = 10;
s = random(1000) < 1 && "hello world";
s += i;
That's a 1 in 1000 chance the program will crash.

You can crash a program the same way with or without this feature, and this feature can exist with or without dynamic typing. It's a completely separate issue.
  • 0




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users