Question - Code Data types...

[Braffolk]

So now since we are in beta, maybe we can hear about some plans.

So, will GM:S 2 get proper data types at one point? (ints,doubles,bytes,floats,bools,etc)

 

[Mike]

We're not looking (or even thinking) about this stuff just now. We obviously still have a LOT to do, not least get the final product out.

 

[kraifpatrik]

No pls don't screw up GML with some C++ crap.

 

[Braffolk]

No pls don't screw up GML with some C++ crap.

Game Maker already has data types. It's just that it has a very few and very limited ones.

This isn't crap either, this is what every normal programmer expects from a language. Every single proper language has data types. There's absolutely nothing special about it.

This wouldn't change much for the more newbie users.
Hence, we already have things like is_int64() int64() ptr() is_ptr() is_real(), etc.
I'm simply suggesting to add more functions such as is_byte(), byte(), double(), real(), short(), etc.

This would change absolutely nothing for you if you aren't interested in it.

 

[hdarren]

A variable can either be a number or a word. What more do you need?

 

[kraifpatrik]

[JOKE]
GMC: GML is not a real programming language for normal programmers! Let's make it more like C++ so that GM is finally understood as a real game engine, not just a kid's toy!
TheRestOfTheWorld: Programming games in C++ is a pain in the ass! Let's code the game logic in Lua instead!
[/JOKE]

Adding support for multiple languages to GMS2 could be nice, but not messing up GML.

 

[RujiK]

A variable can either be a number or a word. What more do you need?

Good thinking. We also have way too many data structures. Since we already have arrays and variables, lets get rid of all those stupid ds_whatever functions. Too many is scary.


Simple explanation: Data types allow for larger projects and faster calculations. A 10,000 x 10,000 ds_grid/array currently takes 2.3 gigabytes. Since there are no data types, this size is non-negotiable and makes large grids unrealistic. If we had simple 0-255 int's, that 10,000 x 10,000 grid could be as small as 100 megabytes, or 4% the size that ds_grids currently are.

 

[rwkay]

Use buffers if you require smaller data structures of specific size, we are not planning on reducing the size of variables - though we are planning on adding optimisations at runtime so that counters will only use ints etc.

In short for data structures where you require a lot of them and control on the size, then use buffers and index into them.

Russell

 

[csanyk]

There's trade-offs, like with anything. GML data types keep things simple enough that it's attractive to non-programmers and beginner programmers.

Obviously, it's possible to do a lot with GMS as-is. Just look at all the great games that have been made.

Having more data types makes it possible to expose more of the power of the computer hardware, at the expense of making it harder for non-programmers to understand how to make use of that power.

Personally, I think that there are enough languages that have the features that "real programmers" want, that probably "real programmers" should just use those languages.

GML has its limitations and constraints, but you don't need to wait for GML to "grow up" to go beyond them. You can already use C or C++ if you want a "serious" programming language. You can write a DLL and do your fancy data-typey stuff that you can't do in GML, and use that DLL in your project.

If GML goes sophisticated, what differentiates it from C++? If GML goes sophisticated, what options are there for causal game development by people who aren't primarily programmers?

I think GML occupies a niche and serves a market that is otherwise underserved, and it would be a shame if it stopped being what it is, to become something that everything else already is.

 

[HammerOn]

Explicit primitive types are unnecessary.

In short for data structures where you require a lot of them and control on the size, then use buffers and index into them.

But none of the two methods makes it easy to work with groups of data without some short of named structures in GML.
Something like

struct Skill {
    name = "Kick logic out and go beyond the impossible";
    level = 1;
    damage = 1000000000;
    mp = 15;
}
var skill = Skill();
skillSystemScript1(skill)
skillSystemScript2(skill)
skillSystemScript3(skill)
....

It's incredible hard to code things that need to manipulate complex data in GML without it.

 

[Shadowblitz16]

@HammerOn this structs would go great with empty objects and functions
I'll add it to my suggestion

 

[ThewDev]

At the very least, I'd love to see proper Booleans in GML. It seems really strange that they're stored as Doubles.

 

[Opticrow]

At the very least, I'd love to see proper Booleans in GML. It seems really strange that they're stored as Doubles.

But then we wouldn't be able to do

Indent = true;
x = 50 + Indent*20; //for example

which is mighty convenient sometimes!

 

[FrostyCat]

The biggest problem with GML's data types right now is the loose handling of its newest additions, especially int64 and Booleans. Int64s still get casted back to doubles and lose precision upon arithmetic operations, and certain Boolean operators still accidentally return undefined.

While the olden days with just reals and strings present limitations, at least it is well-tested and self-consistent. It all fell apart after YoYo rushed in new types without formally evaluating their interactions with operators and existing functions. And what's worse, they still aren't done with it yet.

While static typing probably won't be coming to GML, having a dynamic typing system that developers can count on isn't too much to ask for. Both 1.x and 2.x need this back in order, and I mean it.

 

[Hyomoto]

While I really like the simplicity that GM offers, that's really one of it's best features, I do agree with FrostyCat that we should expect some ambiguity in data types to be cleaned up. Bools is a big one since they don't exist and you get examples like Opticrow where you are relying on a flaw in the system for a desired output.

x = 50 + ( Indent ? 1 : 0 ) * 20;

With ternary operations you can already use this lose interpretation but in a way that no longer causes any ambiguity. And if you need indent to be a number, you should be using a number anyways as that once again removes any ambiguity. It's hardly a burden on the user to say bools are bools, since sometimes all you need is a bool. Which sort of begs an answer to the question, does:

1 == 1

Evaluate to 1? I never really thought about it before but that's the poster child for proper boolean handling. And to top that off, Mike and Russell have said a lot of GM2 ( and GM:S ) stuff is in the name of compatibility, but right now people expect their games may not fully work when ported and might need some changes. This is the perfect time to add proper booleans. If you wait until afterwards we might be left waiting until GM3 for a feature that was suggested in the GM1 manual. As for other data types, I agree their usage and implementation should be cleaned up and solidified, a case of if you are going to do something then just do it (hi booleans!), but I'm not personally too worried about additional data types simply because I'm not doing some of the crazy things other people are. That said, I think GM is amazingly powerful and fun to use because it is so easy to just code and have things work, and while I know I could get used to performing those declarations, I honestly prefer not to.

 

[ThewDev]

But then we wouldn't be able to do

Indent = true;
x = 50 + Indent*20; //for example

which is mighty convenient sometimes!

Convenient? Sure. Extremely poor practice? Definitely.

You could easily achieve the same result with a simple If statement based on that Boolean. Personally, I'd rather save 7 bytes of memory per Bool rather than not have to write an If statement, but I understand that most people prefer GameMaker keep a relaxed syntax.

 

[FrostyCat]

Convenient? Sure. Extremely poor practice? Definitely.

You could easily achieve the same result with a simple If statement based on that Boolean. Personally, I'd rather save 7 bytes of memory per Bool rather than not have to write an If statement, but I understand that most people prefer GameMaker keep a relaxed syntax.

This is only a poor practice when you're wired to "modern" programming. It is fine in lower-level languages such as C or Assembly, as well as certain higher-level languages such as pre-1.3 versions of GML. In particular, shader languages strongly favour multiplication over ifs because branching is more expensive than Boolean arithmetic, and would multiply whenever possible.

Either way is fine, the only thing I don't want to see is inconsistent behaviour. Return a numeric 1 or 0, or return a typed true or false. Don't float between the two options, and definitely don't return undefined out of the blue.

 

[stainedofmind]

Explicit primitive types are unnecessary.


But none of the two methods makes it easy to work with groups of data without some short of named structures in GML.
Something like

struct Skill {
    name = "Kick logic out and go beyond the impossible";
    level = 1;
    damage = 1000000000;
    mp = 15;
}
var skill = Skill();
skillSystemScript1(skill)
skillSystemScript2(skill)
skillSystemScript3(skill)
....

It's incredible hard to code things that need to manipulate complex data in GML without it.

You can achieve this with ds_maps:

var skill = ds_map_create();

skill[? "name"] = "Kick logic out and blah blah bleh...";
skill[? "level"] = 1;
skill[? "damage"] = 10000000;
skill[? "mp"] = 15;

skillSystemScript1(skill);

 

[JamCamAbreu]

The only thing that's unfortunate about lacking data types in GML, is that it doesn't teach new programmers about that important concept. On a positive side though, abstracting it away allows a new programmer to get started a little easier. As far as the data structures, I also think a struct would be really nice because using objects as structs is very inefficient with all the overhead in an object.

However, the biggest problem I've run into with the GML language has been with the lack of pointers. Sure, you can use something.id to get an id of an object, essentially meaning that there IS pointers to objects. But there's not pointers to variables. That means referencing things often requires the use of objects (store data in an object, then reference that object to access those members), which can be terribly inefficient. There's just so much overhead with objects it makes for very challenging optimization in the design process.

I really hope they are able to allow pointers to variables, but doubtful considering that would probably require an overhaul of the system from the ground up.

 

[Mike]

pointers will never be added, they are an evil you shouldn't (really ever) "need". If you need something that is a reference you can hand around, use data structures or arrays.

 

[Mick]

As far as the data structures, I also think a struct would be really nice because using objects as structs is very inefficient with all the overhead in an object.

You can use a ds_map to emulate a struct like @stainedofmind suggested in his post above. Another way of emulating structs is using an enum + array:

enum Skill {
  name,
  level,
  damage,
  mp
}

skill[Skill.name] = "Kick logic out and blah blah bleh...";
skill[Skill.level] = 1;
skill[Skill.damage] = 10000000;
skill[Skill.mp] = 15;

skillSystemScript1(skill);

Enums are global so you can define them in a script at game start or something similar.

 

[Alice]

Perhaps ability to make custom data types would be too much to ask for at the moment...

...but can at least maps/lists/stacks etc. have a type of their own, rather than being an integer? So that I can simply check is_ds_list/is_ds_map etc. and avoid all that confusion? Like, in my history of using GM, the only time keeping data structures as numbers (that can be shared by other data structures, or just number values...) was useful was in the one-script challenge, to use a simple hack to check for 0-th map or such. On the other hand, there were numerous occasions were I'd really have liked to tell the structures and numbers apart) but couldn't.

 

[stainedofmind]

While I agree it would be nice to have data structures with their own unique data type, even that can be simply worked around by always keeping an extra value on hand to track what type it is.

 

[csanyk]

Maybe another way to do this would be:

using int;
using float;
using double;
using char;
using bool;

Then advanced developers could import whatever data types they needed. If you don't import them, GML would use it's usual standard data types (number and string).

That could work, I think. If it's feasible to implement...

 

[ParodyKnaveBob]

Consistency on typing would be good, yes (like e.g. where sometimes a Boolean has broken, whoops).

However, what's stricken me over the years is that so much of the WWW is built on PHP -- and I don't hear the naysayers of GML's type-shortcuts complain about PHP as their example. They just talk about "real programming languages." Sad that PHP's not a real language, eh? $;^ b Anyway, I love boolval * intval shortcuts as much as anyone who's fine with high-level, abstracting languages, but fwiw there've been those times in debugging, in homemade error-catching, in taking input from non-GML sources, et in cetera where I wished I had (boolval === true) (PHP's == vs. === operators for general truthiness vs. also matching exact type) and instead just made do.

Regards,
Bob

 

[2DKnights]

We're not looking (or even thinking) about this stuff just now. We obviously still have a LOT to do, not least get the final product out.

Understood,but I think It would be cool if there were a setting you could use to set the data type for numerics, maybe my game only needs 8 bit ints, or 16 bit floats etc.

 

[Juju]

can at least maps/lists/stacks etc. have a type of their own, rather than being an integer?

Yes. I've heard rumours that YYG have plans for this...

In the meantime, there is a reasonably stable workaround available:

///ds_create( type, [width, height] )
//
// 2016/11/11 @jujuadams

if ( argument_count < 1 ) return undefined;

var _ds, _type = argument[0];
switch( _type ) {
    case ds_type_grid:     _ds = ds_grid_create( argument[1], argument[2] ); break;
    case ds_type_list:     _ds = ds_list_create(); break;
    case ds_type_map:      _ds = ds_map_create( ); break;
    case ds_type_priority: _ds = ds_priority_create(); break;
    case ds_type_queue:    _ds = ds_queue_create(); break;
    case ds_type_stack:    _ds = ds_stack_create(); break;
    default: return undefined; break;
}

return _ds + 0.1*_type;

///ds_destroy( ds )
//
// 2016/11/11 @jujuadams

var _ds = argument0;

switch( ds_get_type( _ds ) ) {
    case ds_type_grid:     ds_grid_destroy( _ds );     break;
    case ds_type_list:     ds_list_destroy( _ds );     break;
    case ds_type_map:      ds_map_destroy( _ds );      break;
    case ds_type_priority: ds_priority_destroy( _ds ); break;
    case ds_type_queue:    ds_queue_destroy( _ds );    break;
    case ds_type_stack:    ds_stack_destroy( _ds );    break;
}

///ds_get_type( ds )
//
// 2016/11/11 @jujuadams

return frac( argument0 ) * 10;

Data structures get cast as ints internally so no other action is needed.

 

[zbox]

Yes. I've heard rumours that YYG have plans for this...

In the meantime, there is a reasonably stable workaround available:

///ds_create( type, [width, height] )
//
// 2016/11/11 @jujuadams

if ( argument_count < 1 ) return undefined;

var _ds, _type = argument[0];
switch( _type ) {
    case ds_type_grid:     _ds = ds_grid_create( argument[1], argument[2] ); break;
    case ds_type_list:     _ds = ds_list_create(); break;
    case ds_type_map:      _ds = ds_map_create( ); break;
    case ds_type_priority: _ds = ds_priority_create(); break;
    case ds_type_queue:    _ds = ds_queue_create(); break;
    case ds_type_stack:    _ds = ds_stack_create(); break;
    default: return undefined; break;
}

return _ds + 0.1*_type;

///ds_destroy( ds )
//
// 2016/11/11 @jujuadams

var _ds = argument0;

switch( ds_get_type( _ds ) ) {
    case ds_type_grid:     ds_grid_destroy( _ds );     break;
    case ds_type_list:     ds_list_destroy( _ds );     break;
    case ds_type_map:      ds_map_destroy( _ds );      break;
    case ds_type_priority: ds_priority_destroy( _ds ); break;
    case ds_type_queue:    ds_queue_destroy( _ds );    break;
    case ds_type_stack:    ds_stack_destroy( _ds );    break;
}

///ds_get_type( ds )
//
// 2016/11/11 @jujuadams

return frac( argument0 ) * 10;

Data structures get cast as ints internally so no other action is needed.

dear lord hahahaha

points for creativity

 

[Juju]

Some call me a poet

 

[Alice]

That indeed is pretty creative... but won't work with JSON-loaded data structures (as they have their indices assigned automatically, and after that there's no telling maps, lists and integers apart), and doesn't allow telling some real fractional numbers apart from data structures, either.

Well, full disclosure, that can be worked around by throwing the built-in system out of the window and using one of custom JSON systems. Still, it's not exactly a native solution and probably depending on the specific custom system there are some caveats of its own and besides, why have some half-hearted JSON API with type setters only, when you can make it complete by adding the long-awaited type getters.

 

[Juju]

I came across this particular solution whilst making an XML interpreter so, yes, limitations do exist. Generally with JSON, you know the structure beforehand so it's not too rough. No substitute for a proper ds_whatever datatype.

 

[JamCamAbreu]

pointers will never be added, they are an evil you shouldn't (really ever) "need". If you need something that is a reference you can hand around, use data structures or arrays.

Hey Mike, thanks for your reply. I don't quite understand why pointers would be seen as an unnecessary evil. For instance, they are so lightweight passing them around instead of passing around data structures. The size of a pointer is much smaller than the size of most data structures, and INFINITELY smaller than an object instance in game maker. Do you just mean that they are evil because they are intimidating towards higher-level programmers? Personally, GML was my first programming language, and then I moved on to C and C++. After taking computer science classes and learning about the uses of pointers, I suddenly felt so capable of writing any kind of code I needed. Then I went back to game maker and realized I didn't have that power, aside from confusing workarounds that are memory inefficient and confusing. In that case and other cases, it seems like I've "hit the ceiling" on using GML as a capable game programming language. Game maker will always be a great prototype making tool, to quickly get game designs running and testing. But with missing important tools like pointers, designing memory efficient code for release projects just seems difficult and not worth it. Especially when other popular game engines DO give us those tools.

Additionally, arrays and data structures are secretly pointers. So why would giving us more control over how the pointers work be "evil"?

Thanks for helping me understand.

 

[Mike]

Pointers probably the single biggest issue of hard crashes with any bug time. A rouge or out dated pointer be handed around to something that's be moved or freed is almost always what causes hard crashes, and that's not something I ever want to have in the runtime. What you actually want is some kind of "handle" to whatever it is you're after so that if it's freed or moved, the handle can change and reflect the changes.

Even then, I don't think you need this, you can do it in loads of ways - a ds_map for example would allow you to save an instance id and a name, and you can specify a variable directly, or... now that variable get/set is back, you can just store the variable into the instance directly without all this pointer stuff.

Pointers are nasty, and if I could write code without them, I would/will. I may have had to change my method with GameMaker, but I've never hit a ceiling - there's always a way.

 

[Jobo]

Every single proper language has data types.

Is JavaScript not a proper language? Is Lua not a proper language? Is Python not a proper language? Is Perl not a proper language? Is PHP not a proper language? ... GameMaker Language has data types - you just don't have to be syntactically explicit. C# has supported implicit typing at variable declaration with the 'var' keyword for a decade.

This wouldn't change much for the more newbie users.

It wouldn't change much for more advanced users either. Say you write a script that takes a number parameter - you don't care if that number is an int16, a uint64 or a double or float. All you care about is getting a number. Now imagine you had strong typing in GML and you download a Marketplace script collection, where it's not unlikely that a person who feels (or wants to feel) advanced has required uint16s, bytes and other stupid types where a number is needed and no benefit comes from it. That just leaves you with the headache of converting all your variables to the right type and do bounds checking. Or maybe they update their script collection and change a few types because they just learned about them. That doesn't sound like much of an improvement to me...

 

[Lewa]

Is JavaScript not a proper language? Is Lua not a proper language? Is Python not a proper language? Is Perl not a proper language? Is PHP not a proper language? ... GameMaker Language has data types - you just don't have to be syntactically explicit. C# has supported implicit typing at variable declaration with the 'var' keyword for a decade.

Just because C# has the ability to use "var" as a declaration doesn't mean that it's usage is a good idea in the first place. It can be convenient, but it can open a whole can of worms.
Example:

var  test = "I am a String!"; //Easy: var is now a string.

var test2 = GameEntity.getVelocity(); // WTF IS VELOCITY?

What is a Velocity? Is it a struct (with seperate x and y velocity)? an object? is it a single float value (the speed of the velocity)?
Also, Javascript, PHP and Python do have their own problems when it comes to that sort of stuff. (They should by no means be taken as the languages which "do it the right way".
I would never in my life choose pure javascript over Java or C# when it comes to game development on more complex/advanced projects. (And there is a reason for that.)

It wouldn't change much for more advanced users either. Say you write a script that takes a number parameter - you don't care if that number is an int16, a uint64 or a double or float. All you care about is getting a number. Now imagine you had strong typing in GML and you download a Marketplace script collection, where it's not unlikely that a person who feels (or wants to feel) advanced has required uint16s, bytes and other stupid types where a number is needed and no benefit comes from it. That just leaves you with the headache of converting all your variables to the right type and do bounds checking. Or maybe they update their script collection and change a few types because they just learned about them. That doesn't sound like much of an improvement to me...

I would consider myself a more advanced user and i have to say that it would change A LOT for me.
I actually do care what type the given variable has. There are multiple reasons for that:

1. I could optimize the memory usage (please don't use the argument that "todays computers have enough memory so that this isn't an issue."). There is a BIG difference in initialising an (3D) 1024³ byte array and an 1024³ 32 bit int array when it comes to memory consumption.
2. (in the case of GM which stores all numbers in floating point format) if i assume/require a variable to be a non-floating point number, i would simply create an int instead of a float. If i do some mathematical calculations (like dividing 5/2 which would result in 2.5 in GMs case) and pass this value to a function which assumes the number to be in a rounded (non floating point format) it could lead to wrong results as i (as the developer) assume that the value is in a rounded format. (int a = 5/2 would result in a 2!) Of course i could round the value after each operation manually, but this is really tedious and unsafe. (Had this issue with PHP a lot of times...)
3. No errors due to passing wrong types to a function/method which could lead to either A) undefined behaviour or B) straight up crashes. As an example: Accidentally screwing up and passing a string (or object ID ) nto a function which requires a floating point value. (It can happen that those errors don't crop up immediately. It may not crash, but it can lead to strange bugs. > Had this happen in GM.) >>> TYPE SAFETY
4. You can't accidentally overwrite a variable with a different type. like
   

   int A = 512;
   A = "YAY, i can't do that!";  // not possible (which is a good thing)

I could go on but those are those things which immediately come to my mind.
Type safety is important. You can catch bugs immediately and be sure that the code/values behave in the exact way you (as the programmer) inteded them to do so. Especially if you work in a team (where you have to work with code which someone else has written.)

Now imagine you had strong typing in GML and you download a Marketplace script collection, where it's not unlikely that a person who feels (or wants to feel) advanced has required uint16s, bytes and other stupid types where a number is needed and no benefit comes from it.

Just because "someone" doesn't feel (or doesn't want to feel) "advanced" enough doesn't mean that type safety (or explicit typing) should be completely thrown out of the window.
(Types also exist for a reason. They aren't in any way "stupid".)

That just leaves you with the headache of converting all your variables to the right type and do bounds checking.

It's quite the opposite. Everytime i use scripts (and it's not clear what exactly it does/returns) i have to delve into them and look what exactly they are returning (is it a string?, an integer?, an object?, etc...)
It's also really tedious to be very careful and do those indirect casts (as an example from float to int by rounding those values) or type checks (like is_array(), is_sring(), etc...) manually... (Casts are completely fine. But they should be done properly.)

Or maybe they update their script collection and change a few types because they just learned about them.

So... we should assume that everyone who is using GM is a complete idiot and isn't able to learn the difference between a boolean, an integer and a float?
Types are already present in GM. (albeit a bit limited.) The sooner people start learning about the fundamentals of programming, the better. (Helps the code mantainability, predictability, workflow and overall knowledge about the underlying computer system.)

I understand that YYG wants to keep it simple and beginner friendly. But sacrificing features which are important for more advanced users (and more complex projects) is (in my opinion) not the right path to take.
Of course, Game Maker is owned by YYG and it's their decision as to what they do with their software and how they approach the further development. (They know pretty well what they want to do with their software and who the target audience for GMS is.)

Now, i hope you don't interpret this as an attack on you or on YYGs. I just express my concern and my standpoint on this topic as someone who has worked in multiple languages (Java, C#, Javascript, Actionscript (Flash), PHP, Python, GML, a little bit simplified assembly and a little bit C++), who works on a larger project in GMS 1.4 and has seen/experienced the advantages and disadvantages on such topics like implicit/explicit variable types and type safety.
I want Game Maker to become better. (Both for beginners AND for more experienced users.)

I love the simplicity which GM offers to us, but i would be more than happy to have more control over this stuff. (GML in its current form leaves a lot to be desired.)
One positive thing that i can say is that i've heard from rwkay in a different topic (which sadly was closed as it derailed in an offtopic flamewar) that there might be something coming sometime in the future. (And i'm looking forward to whatever is planned for GML. )
It's still a beta after all.

 

[RichHopefulComposer]

Preach, Lewa. The "our userbase is too stupid to handle standard programming practices, so we're going to make things easier for newcomers by making things more of a pain in the ass for advanced users" answers Yoyo staff constantly give out don't sit right with me, either. By all means, keep GM's entry barrier low, Yoyo. Give your power users some power, though. 99% of the features Yoyo shuts down for being too advanced could easily be added as options for advanced programmers and then ignored by new users if they wanted to learn crappy programming practices. "Easy to learn, difficult to master" isn't a bad thing. Any programmer that sticks around past their "Click the clown and ty sonic clone" phase will appreciate the added depth. Hell, Yoyo is already slapping their twelve year old fans in the mouth with the new $100 price tag, anyway. Now's the best time to add some of these features we old-timers have been asking for for the last three or four years. "Not until GMS2.0" isn't an excuse anymore, guys! I've been waiting a long time for GM's second coming - please take our favorite engine to the next level! =)

 

[ParodyKnaveBob]

When any IDE doesn't supply type safety for a language, well applied Apps Hungarian will.

inb4 Systems Hungarian confusion

 

[Kahvana]

No pls don't screw up GML with some C++ crap.

C actually.

I really would like to see them, as I dislike the idea that any number value is a double precision floating-point number.

csanyk's idea would be a good one!. But, I wouldn't like the idea to include them in every script .

 

[csanyk]

C actually.

I really would like to see them, as I dislike the idea that any number value is a double precision floating-point number.

csanyk's idea would be a good one!. But, I wouldn't like the idea to include them in every script .

Right, the using idea would be best done in a way that you only need to declare them once, and they're in effect globally once declared. Given how instance variables are all public, and therefore accessible from anywhere else in the project, I'm not sure you could have it work if data types were declared on a per-object basis.

 

[Mike]

Preach, Lewa. The "our userbase is too stupid to handle standard programming practices, so we're going to make things easier for newcomers by making things more of a pain in the ass for advanced users" answers Yoyo staff constantly give out don't sit right with me, either. By all means, keep GM's entry barrier low, Yoyo. Give your power users some power, though. 99% of the features Yoyo shuts down for being too advanced could easily be added as options for advanced programmers and then ignored by new user.....blah blah...blah....

Gonna call bollocks to this.....

I live to consider myself an advanced programmer..... I've coded with, and without pointers, from basic that has none to assembler that only has them, from C/C++ where you again need them for even the simplest thing, to C# where you can "mostly" get along without them, then back to JavaScript where you again don't have them. While they might actually make you feel more in control and more of a power user, they are - as I said above - probably the BIGGEST causes of random crash bugs you get. You don't have to be a beginner to get these, and in fact beginners tend not to use them so won't really get them, so it'll be medium to advanced users that get this most. There is always a way around things... holding reference to something can be done via an array with an ID and variable ref, or map or something - or a global map with "id_var" as a string - whatever.

If you really want pointers, allocate a buffer... pass that pointer into an extension and do whatever you like in there. Inside GML there is no reason to have them, you can currently do everything you need without it.

 

[Lewa]

Gonna call bollocks to this.....

I live to consider myself an advanced programmer..... I've coded with, and without pointers, from basic that has none to assembler that only has them, from C/C++ where you again need them for even the simplest thing, to C# where you can "mostly" get along without them, then back to JavaScript where you again don't have them. While they might actually make you feel more in control and more of a power user, they are - as I said above - probably the BIGGEST causes of random crash bugs you get. You don't have to be a beginner to get these, and in fact beginners tend not to use them so won't really get them, so it'll be medium to advanced users that get this most. There is always a way around things... holding reference to something can be done via an array with an ID and variable ref, or map or something - or a global map with "id_var" as a string - whatever.

If you really want pointers, allocate a buffer... pass that pointer into an extension and do whatever you like in there. Inside GML there is no reason to have them, you can currently do everything you need without it.

I think there is a slight misunderstanding here. Neither I nor RichHopelessComposer were referring to pointers.

I was talking about data types, type safety as well as explicit typing. (Not pointers.) And those problems definitely don't apply to those topics.

 

[RichHopefulComposer]

Gonna call bollocks to this.....blah blah blah blah blah

Read more carefully next time, and you won't have to summon any bollocks. Like Lewa says, neither of us were talking about pointers.

 

[JamCamAbreu]

Again, my only argument about pointers, which is not being addressed (no pun intended , is that pointers are more efficient with memory. They take up a drastically smaller amount of space when being passed around then data structures and object instances. The allowing of pointers, yes, would open up users to making mistakes and having pointer errors, but it would promote one of the most important concepts of game programming: memory efficiency.

I have seen countless game maker games that run terribly even on fast computers. This inefficiency is in many ways unavoidable because the structure of GML forces passing around large data types, such as data structures or object instances. I don't know about you'all, but if I load up a game that has a bad frame rate, I immediately lose interest. A game needs to "feel" smooth, without framerate spikes. Are there certain games that don't need to pass around data structures and object instances that can run great in game maker? Sure. But some games need to pass around references to large amounts of data, and since that can only be done with data structures and object instances, the game can slow down greatly. This is why C and C++ after all these years are STILL used to build game engines. This is the design choice of the the makers of C and C++. Efficiency is priority. Does that mean that gamemaker and other high-level languages are bad? No, not at all. But since memory efficiency is so important to making a game run smooth, exact control over how data is passed around is STILL relevant.

I'm fine with gamemaker choosing to not give that amount of control, and sacrificing that to making a more error-less/easy to use system. Like I said, some great games and game prototypes can be made very quickly, which is extremely fun! But I wouldn't expect a game with a lot going on under the hood to ever run efficiently in a system like that. Consider a game like dwarf fortress. With the insane amount of calculations that are done every second and systems that keep track of all the entities and data, a game even a fraction of that complexity would never run well on a system using the current GML. Is it possible to build that system using GML? Yes, I believe so. Would it run efficiently with a good frame rate on an average computer, I highly doubt it. Thus, SOME game types are great to build in game maker, and other more complex game systems would be best made using other programming languages.

 

[JamCamAbreu]

And the same argument can be made about data-types as well. Passing around an int is much more efficient than passing around a double. If you know that you just needed an int (such as an ENUM for instance), you don't want to carry all that memory space for defining a double). In a complex game system that has a massive amount of processing, even these small amounts of memory usage can be the difference in a polished smooth running game and a laggy slow frame rate game.

 

[makas]

To be honest if you are experiencing lag with a game in 2d, is mostly because is poorly optmized in other fronts, (texture pages, shaders, surfaces, particles,etc), what is the most resource intense game made in gamemaker? hyperlight drifter??

 

[Nocturne]

I dislike the idea that any number value is a double precision floating-point number

Why? It does the job... Been using GM for years now and I've never once to thought to myself "Damn, but it's a shame that variable is a double precision floating point number!".

And the same argument can be made about data-types as well. Passing around an int is much more efficient than passing around a double. If you know that you just needed an int (such as an ENUM for instance), you don't want to carry all that memory space for defining a double). In a complex game system that has a massive amount of processing, even these small amounts of memory usage can be the difference in a polished smooth running game and a laggy slow frame rate game.

I've only seen one or two games that really push GM to it's limits (HLD for example) and when that happened YoYo Games added in streamed audio, texture prefetching and fast collisions (amongst other things). They didn't add in different data types because that wasn't the issue. In GMS2 we've been given layers and an improved render pipeline using DX11 as well as a load of other things under the hood and performance has increased again, and again without data types. I can understand the argument for different types when it comes to shifting huge amounts of information around using things like data structures, but in general I feel that most GMS users don't really care about these micro optimisations and wouldn't benefit from them anyway - all they want to do is get their head down and work on their game, which GML permits them to do incredibly quickly and without any fuss.

So, all of GameMaker's optimisations come from other things that aren't anything to do with the language itself (directly) and I would think that until we get people regularly pushing the limits of what GMS can do we shouldn't even be considering making this kind of change to the language as it impacts everyone and YYG have to consider the whole (incredibly wide) range of users and not just those that have some other programming background or that consider themselves "power" users. If you really want it, then make a quality game that pushes the limits and requires it and then petition YYG, just like Vlambeer or other devs have done.

 

[RichHopefulComposer]

So, all of GameMaker's optimisations come from other things that aren't anything to do with the language itself (directly) and I would think that until we get people regularly pushing the limits of what GMS can do we shouldn't even be considering making this kind of change to the language as it impacts everyone and YYG have to consider the whole (incredibly wide) range of users and not just those that have some other programming background or that consider themselves "power" users. If you really want it, then make a quality game that pushes the limits and requires it and then petition YYG, just like Vlambeer or other devs have done.

Data types wouldn't have to impact all users. GM could automatically convert any unspecified variables to huge bloated doubles or whatever it does now, and only deviate from its current behavior when a user explicitly casts a variable. Maybe Yoyo should hire me. That head-scratcher was real easy to solve! =)

And lol @ "we shouldn't improve the engine until we get more people who push GM to its limits on board." We don't have many of the type of people who push engines to their limits specifically because GM doesn't have things like type-casting. Why would anyone who wants to squeeze every ounce of optimization out of an engine choose GM over Unity or Unreal?

Also, HLD ran like complete garbage on my old computer. The computer was ancient, but it ran 3D Xbox-360 level games with no problems. That seems a little strange to me.

 

[xot]

Also, HLD ran like complete garbage on my old computer.

Any engine can be used to make a game that runs like complete garbage.

 

[RichHopefulComposer]

Any engine can be used to make a game that runs like complete garbage.

But not any engine can be used to make a game that runs well.

Nocturne was using HLD as an example of a game that "pushed GM to its limits," so much so that the developer got special treatment from YoYo. I thought it was obvious that my point was that even YoYo's help wasn't enough to make a relatively simple 2D game made in GM run as well as the exponentially more complex 3D games made in other engines I had on my old computer.

 

[xot]

If I couldn't keep a stable 3000 FPS at that resolution, I'd be feeling like I had failed.

1. You simply couldn't do that with a project remotely like HLD. A virtually empty project with two 640x480 passes by simple shaders doesn't even hit a stable 2000 fps on this reasonably powerful workstation.

2. I worked on HLD and I can tell you it is vastly more resource intensive than you are imagining. Could it have been better engineered? Were there aesthetic decisions made that greatly impacted it's rendering speed? Yes. Would making those same choices in Unity or Unreal significantly change its performance? I very much doubt it.