ENIGMA Forums

General fluff => General ENIGMA => Topic started by: luiscubal on September 04, 2010, 09:47:34 am

Title: GML
Post by: luiscubal on September 04, 2010, 09:47:34 am
In my understanding, GML only has a two data types: strings and reals. Most variables, such as rooms, objects, etc. are in fact IDs(reals). surface_create does not return a surface, but rather the ID of a surface. The same applies to stacks, etc.

I'm curious about something in the ID system. Are all IDs completely unique or just unique to that data type? (there can be no more than one single stack with any given ID, but can a stack and a queue have the same ID? Same to instances, objects, etc.)
Title: Re: GML
Post by: TheExDeus on September 04, 2010, 11:09:55 am
Most of them have separate id's, but they are connected in one place or another. For example, sprites, fonts and background all have separate id's, but their texture id's are in one list. So adding one sprite, one background and one font, would make a texture list of 3. So every resource has its own id's.
Title: Re: GML
Post by: Brett on September 04, 2010, 11:57:14 am
The id system starts objects with the id of 100,000 and tiles with 10,000,000. I honestly Don't know if they overlap or not, but they're spaced huge distances apart so that your game shouldn't overlap anyways (9,900,000 objects? Good luck.) You could write a simple loop to test this, however if you were worrying about overlapping - don't. I don't know what comes before objects, but I imagine that sprites, backgrounds, rooms and sounds are all below 100,000.
Title: Re: GML
Post by: IsmAvatar on September 04, 2010, 12:19:57 pm
Actually objects start at 0. Instances start at 100,000. Rooms start at 0, etc. If you create a new game, and add 1 of every resource (Sprite, Object, Room, etc), they will all have ID 0. It distinguishes them because you would never use them interchangeably in a function. For instance, it wouldn't make sense to give anything but a sprite to draw_sprite. Likewise, for functions which *could* use them interchangeably, such as creating textures, instead it has different functions for each resource type.
ds_list also starts at 0, because it would never make sense for you to use it interchangeably with another resource.
I don't know why tile IDs start at 10m, but instance IDs have to be separate from resource IDs, because in-code, you may reference an object's variables (e.g. object0.x) or an instance's variables (myInstance.x), which is interchangeable code with completely different expected results.
Title: Re: GML
Post by: TheExDeus on September 04, 2010, 12:26:12 pm
Quote
The id system starts objects with the id of 100,000 and tiles with 10,000,000. I honestly Don't know if they overlap or not, but they're spaced huge distances apart so that your game shouldn't overlap anyways (9,900,000 objects? Good luck.) You could write a simple loop to test this, however if you were worrying about overlapping - don't. I don't know what comes before objects, but I imagine that sprites, backgrounds, rooms and sounds are all below 100,000.
You are thinking instance id, but I think he means resource id. Resource id's are all in different lists and start at 0, and are dependent on the resource lists in the program itself. So if you make 10 backgrounds, then delete first 9 of them, then the id of the remaining one will still be 10. So these id's can match. Thou as I mentioned before, texture ids are in one list, but as it is created on runtime (and can't be overwritten by any function), then you should not have two matching ids ever. When you run your game the texture id list is at first populated by backgrounds, and then sprites and their subimages.
Title: Re: GML
Post by: luiscubal on September 04, 2010, 12:34:33 pm
@HaRRiKiRi Wait, then Game Maker stores textures separately from sprites and tilesets, and just links these resources to it? Like some kind of implicit invisible resource? I always thought images were "embedded" in the sprite. Is the texture ID used by any function of GML(as an argument)?

EDIT: Some more questions. If I create 10 background, delete the first 9, and then create another background, which will be the ID?

Also, a different kind of problem. In GML, I can draw text even without having fonts(it uses some kind of "default font"). After using draw_set_font, how can I reset the font to the default one?
Title: Re: GML
Post by: Josh @ Dreamland on September 04, 2010, 12:42:57 pm
Most of this has been said by now, but I'll reiterate and ad lib.
I'm not sure where Brett got the idea that tile IDs start at 1,000,000... I believe that may be where tile depth starts.

Anyway, resources (sprites, scripts, objects, etc) start at zero and never reset under normal GM situations. Ism added a function to LGM that can defragment them, but basically, the first resource you create is zero, and any resource after that will just keep counting.

Based on the idea that a game will never have gone through 100000 objects, instance IDs start at 100001. Each instance placed in a room has a "hard-coded" (tongue and cheek in a runner) ID. This means that no matter how many times you visit the room, the instances in there at load time will be given the same ID.

From there, created instances use the same methodology as normal resources; adding constantly to the current highest ID.

ds_stacks, lists, maps... files, surfaces, etc., are all given the same system.

As far as GM is concerned, object0 == sprite0 == instance0-100000 == surface0 == file0 == list0.

This was all just Mark's method of removing pointers.
Title: Re: GML
Post by: TheExDeus on September 04, 2010, 01:01:07 pm
Quote
@HaRRiKiRi Wait, then Game Maker stores textures separately from sprites and tilesets, and just links these resources to it? Like some kind of implicit invisible resource? I always thought images were "embedded" in the sprite. Is the texture ID used by any function of GML(as an argument)?
Sprite has several attributes like origin, collision mask etc., and so textures (the sprite image itself) are separate, but I guess one of the sprites attributes is texture id, so it knows what to draw. Texture id is only used when drawing primitives, and so functions like sprite_get_texture and background_get_texture exists.

Quote
EDIT: Some more questions. If I create 10 background, delete the first 9, and then create another background, which will be the ID?
10. Because you would of deleted background 0-8 and the number 9 would remain. And when you add another background then it would be 10.

Quote
Also, a different kind of problem. In GML, I can draw text even without having fonts(it uses some kind of "default font"). After using draw_set_font, how can I reset the font to the default one?
The default GM font is -1. So draw_set_font(-1) does it.

edit:
Quote
As far as GM is concerned, object0 == sprite0 == instance0-100000 == surface0 == file0 == list0.

This was all just Mark's method of removing pointers.
Yeah, and it allows some cool but useless things. Like draw_sprite(object0,x,y) or instance_create(x,y,sprite0).
Title: Re: GML
Post by: luiscubal on September 04, 2010, 01:14:04 pm
Another thing: what is the "then" keyword for? Is it completely useless or is there a use-case for it?
Title: Re: GML
Post by: TheExDeus on September 04, 2010, 01:23:02 pm
Shouldn't you ask these questions in GMC?

Anyway, "then" is used in situations like:
Code: [Select]
if something=true then do_somethingNormally thou, you should write this code as:
Code: [Select]
if (something==true){
do_something;
}
Basicly, its just one of the syntax possibilities by gamemaker. "then" I think comes from visual basic, and maybe from somewhere else as well.
Title: Re: GML
Post by: IsmAvatar on September 04, 2010, 01:46:18 pm
Quote
I'm not sure where Brett got the idea that tile IDs start at 1,000,000... I believe that may be where tile depth starts.
I believe he's actually correct. Tile IDs start with 1,000,000. This is the way I have documented them, and this is the way LGM handles them (with the exception of defragging prior to r453, due to a bug)

Quote
Another thing: what is the "then" keyword for? Is it completely useless or is there a use-case for it?
I'm not aware of any use-case for it. As far as I'm aware, it's basically just to make the syntax compatible with other languages like BASIC (including Q-BASIC and VisualBasic) and Pascal. As far as ENIGMA is concerned, I'm sure it is defined thusly:
Code: [Select]
#define then
Title: Re: GML
Post by: The 11th plague of Egypt on September 04, 2010, 03:28:06 pm
Each instance placed in a room has a "hard-coded" (tongue and cheek in a runner) ID. This means that no matter how many times you visit the room, the instances in there at load time will be given the same ID
Damn it! Is that why the save system goes nuts when you load instances created outside the room editor?

I've seen it trow me errors when I load objects with lists inside. I just don't know ehat the heck is going on inside there.

GM's too obscure. I have to make all kind of backflips to write a simple editor which saves the position of instances inside a .txt file.

Anyway, soon you'll see my solution to RTS and FPS collisions. No sprites involved.
Title: Re: GML
Post by: Brett on September 04, 2010, 03:49:20 pm
@Josh
I got the idea that tile id's start at 10m because GM says so. Create a background, add it as a tile and highlight it. At the bottom of the editor, it will say it's X,Y, Depth and ID. The id's start at 10m.

@Ism
Tile id's start at 10m, not 1m.

And I didn't know that the sprites/backgrounds were stored in seperate lists. (Until I thought about it anyways).


Also, agreeing with flexaplex, I think that he started the tile instances at 10m because both objects (instances) and tiles are stored in the same list. This would make sense, as they have many things in common.
Title: Re: GML
Post by: IsmAvatar on September 04, 2010, 04:05:18 pm
Quote
I've seen it trow me errors when I load objects with lists inside. I just don't know ehat the heck is going on inside there.
No, it's erroring because ds_lists (and other data structures) are not saved, and thus, when you load and try to access your old ds_list, it is now gone. According to the GM Manual in the section for Data Structures (which you've clearly taken the time to read):
Quote
Please note that data structures and their content are not saved when you save the game using the actions or functions for that. If you use data structures and want to allow for saves you have to create your own mechanims for that.
Title: Re: GML
Post by: The 11th plague of Egypt on September 04, 2010, 05:09:41 pm
Quote
I've seen it trow me errors when I load objects with lists inside. I just don't know ehat the heck is going on inside there.
No, it's erroring because ds_lists (and other data structures) are not saved, and thus, when you load and try to access your old ds_list, it is now gone. According to the GM Manual in the section for Data Structures (which you've clearly taken the time to read):
Quote
Please note that data structures and their content are not saved when you save the game using the actions or functions for that. If you use data structures and want to allow for saves you have to create your own mechanims for that.


NOOOOOOOOOOOOOOO!!!!

(http://t3.gstatic.com/images?q=tbn:ANd9GcQgXUOoLLmqRY8xtFt4ihCTWjnMykVkodb6XQqJiM1L8HC0p_Y&t=1&usg=__0tJvB1w109Fgsgfoq0wTXVgBTeg=)

Now I have to make my save system for that too?!
Title: Re: GML
Post by: retep998 on September 04, 2010, 05:12:44 pm
Also, when you create a new resource, it doesn't matter what the highest existing id for that resource is, but rather what it was.
If i create 100 sprites and delete them all except the first one so the highest id is 0, the next sprite i create will not be 1 but rather 100 since the highest ever was 99.
Just clarifying.
Title: Re: GML
Post by: The 11th plague of Egypt on September 04, 2010, 05:15:18 pm
Wait, then making a lot of instances and then destroying them could ultimately lead to a crash?

I create and destroy thousands of lists in a minute. Am I fucked up?
Title: Re: GML
Post by: IsmAvatar on September 04, 2010, 05:53:34 pm
Quote
Wait, then making a lot of instances and then destroying them could ultimately lead to a crash?

I create and destroy thousands of lists in a minute. Am I fucked up?
Instances aren't a concern until you create at least 10m-100k=9.9million of them, at which point they start overlapping tile ids. It's unknown whether this would really be problematic, though, as I've never heard of anyone doing it before.

Realize that if you create 10 thousand instances a minute, it will take 990 minutes, or 16.5 hours, before you reach the 9.9m point.

If you create 10 thousand lists a minute without destroying them, it will take 10 minutes before you reach the 100k point. If you destroy every list you create, you will never exceed the 10 thousand mark for IDs, because the IDs get recycled.
Title: Re: GML
Post by: The 11th plague of Egypt on September 04, 2010, 05:54:49 pm
Yeah, probably it won't be a big deal, but I'm already deal with a lot.

If I make a save system for the map, and one for the units using that map, I'd better dump the GM's save completely.

Thanks God I'm safe with the lists, but I may crash the game since I'll have hundreds of units shooting thousands of bullets.
My collision system has been designed to do exactly that since the beginning, and if I can't use it to its full potential, that's a pity.

Couldn't Enigma fix this mess? To Hell with compatibility, I want to make a serious game!

@Ism
Ok, that makes me feel better, but it's still a stupid limitation. I'd better not make the bullets instances at all. Ray tracing YAY!

EDIT: yeah, I destroy almost every list, and there shouldn't be memory leaks. Plus I already have ray-tracing bullets.
Title: Re: GML
Post by: Josh @ Dreamland on September 05, 2010, 09:48:43 am
Those two functions, game_save and game_load, have been giving me a headache. There doesn't seem to be a good way to implement them in an established C++ environment. I have no idea why Mark doesn't save ds_*'s. That was the -ONLY- reason I thought an ID based data structure system would have any place in ENIGMA. Knowing that he doesn't save them, though... Erg.

Anyway, my plan for game_save and game_load was basically to require that all variables that are to be saved be given a type with one of the following properties:
1) An overload for operator<<(ofstream::operator&, class&) and likewise for operator>>()
2) A member called _game_save(FILE*) and _game_load(FILE*)
3) An overload for enigma::game_save_putter(class&) and enigma::game_save_setter(class&)
4) A structure containing only types meeting the above
5) An overload for a pointer to a type meeting any of the above and a size_t length(void)
6) A standard iterator system (begin(), end(), operator++(int)) returning any of the above as a scalar or an std::pair.

If all types meet those specifications, the entire game can be saved. Is that great, or what?
Title: Re: GML
Post by: Fede-lasse on September 05, 2010, 03:00:27 pm
To Hell with compatibility, I want to make a serious game!
Ditto. Didn't realize IDs were such a problem by the way. Hmm.
Title: Re: GML
Post by: luiscubal on September 05, 2010, 04:07:47 pm
It makes sense to have objects, instances and tiles have different IDs since all of them can have the "x" property applied to them.
Not sure if ENIGMA should care about that, though.

One last thing: is my_object.x = 2 and etc. going to work on ENIGMA? I also use lots of object_index and sprite_index. Are these functions ENIGMA-safe?
Title: Re: GML
Post by: Josh @ Dreamland on September 05, 2010, 08:28:59 pm
ENIGMA supports all of that, Luis.
Title: Re: GML
Post by: The 11th plague of Egypt on September 07, 2010, 05:26:29 am
Does it support the instance_find() function? I'm using it a lot.
Title: Re: GML
Post by: TheExDeus on September 07, 2010, 09:40:57 am
Quote
Does it support the instance_find() function? I'm using it a lot.
Enigma will support everything GM does. The main idea (if it hasn't changed much) of Enigma is to replace GM. After that, it could grow to be much much more (as with C only sky is the limit.. or something else).
Title: Re: GML
Post by: Game_boy on September 07, 2010, 10:27:10 am
@HaRRiKiRi

Non-existent programs can support anything you like, be bug-free and completely awesome.

The real Enigma doesn't even work enough to make Click the Clown work yet.
Title: Re: GML
Post by: TheExDeus on September 07, 2010, 10:56:15 am
Quote
Non-existent programs can support anything you like, be bug-free and completely awesome.
Reread my post. I think you don't understand the meaning of past, present and future tenses.

Quote
The real Enigma doesn't even work enough to make Click the Clown work yet.
I think it did. It was made some time ago, and it worked quite well (at one point it worked too fast thou, because there weren't any fps limit).
Title: Re: GML
Post by: Game_boy on September 07, 2010, 01:55:30 pm
@HaRRiKiRi

I understand you meant future Enigma, but we're so many years later after the initial claims and it is nowhere close to usable. Josh is doing a good job, but as a largely one-man army it's not going to catch up very fast. I'm certain var has been recoded about 10 times now as he thinks of better ways to do it.

And I believe "Catch the Clown" was made because Enigma couldn't "Click" at the time (can it now? If I pull it from SVN will it compile and run CtC on Windows as is?) . That's why I said that specific game. Even the GM example games are so far away at this pace.
Title: Re: GML
Post by: Josh @ Dreamland on September 07, 2010, 01:58:58 pm
*shrug*
I wish I could have finished that C parser a bit faster.
Anyway, watch what happens next, Game_boy. Don't blink.
Title: Re: GML
Post by: The 11th plague of Egypt on September 07, 2010, 02:39:59 pm
It's hard to manage big projects, expecially the first ones.

Chances are I'll post my project tonight, almost a year after the schedules release date.
Title: Re: GML
Post by: Game_boy on September 07, 2010, 05:11:15 pm
@Josh

Will do. I've been following this since you were talking on 64digits...
Title: Re: GML
Post by: The 11th plague of Egypt on September 09, 2010, 02:33:30 pm
I found out how much GM's load system really sucks. 2 more things:

the save/load game command is not executed immediately, but rather at the end of the step

whatever you do after you call the game_load function gets lost