• Hello [name]! Thanks for joining the GMC. Before making any posts in the Tech Support forum, can we suggest you read the forum rules? These are simple guidelines that we ask you to follow so that you can get the best help possible for your issue.

 Initial thoughts on GM from an experienced hobbyist

F

Flab

Guest
First of all, fairly experienced coder and general gamedev hobbyist. So I tried GM(free version), not very much so far, but I'll mention a couple of things.

Documentation, naming and convention is somewhat lacking, but some of that is preference.
The available (official) tutorials aren't exactly great and some can't be used with GM free.

At some point I noticed something called YYC, which is supposedly a compiler. This is not in the free version. I cannot say anything about it, I do not know if it's functional. Related to this, it appears to me that the interpreter/vm whatever is quite slow (I'm coming from mostly c/c++ land here). Related to performance would be things like explicit/specific typing and so on. So that's a problem with a few factors that as free/trial user I simply have no real confidence about.

I also (think) I noticed a couple of strange (to me) oversights. I'll give an example, I made an object_a that has a collision event with other object_a, so what I did was add ' If (self.id < other.id) return; ' and ' If (self.id > other.id) return; ', this confirmed that the collision event was triggered twice. It also made me realize collision events (and the associated collision detection I guess) are incredibly slow, which bothers me as I used to code this sort of thing.

So while I like gamemaker so far, some of it seems pointless and there's a bunch of basic stuff which I simply find bizarre and a bunch of what I'd call basic functionality missing, performance is pretty poor.

I can't actually publish anything with the free version either, so this makes understanding developing for multiple platforms and even testing kind of pointless. Ultimately, it means I have to pay $99 (I think?) just to be able to test properly on windows. Some of that seems counterproductive to me, considering.

So yeah, it's perhaps a bit harsh, but those are criticisms I have initially.
 

DukeSoft

Member
Its true! GM is very slow - especially the VM. Accessing memory and basic calculatoins are really slow compared to C++. On top of that every instance has a huge list of events / code thats its running through (collision, movement etc) and it builds up quickly.

3000fps on a simple room with 2 objects in the VM is considered very fast.

The thing is, the VM doesn't really compile - it uses a runner and the GML gets parsed JIT. What the YYC does - is compile the GML to C++, and then compile the C++ to a binary. I can confirm that this takes away a LOT of the overhead. Mainly when accessing a lot of memory / doing a lot of calculations (so no drawing stuff / GPU related tasks) you can expect speed increments of up to 1000%. Compiling takes a tad longer, but it does run much faster as its compiled from C++. That same empty room with 2 instances runs at 12000fps on my machine. (thats including redraws of the screen!).

My specs; i7700k + 1060

Overall I must say, if you code properly (and check out the profiler every once in a while), GM will suffice. I have a pretty intense project with a lot of stuff going on, and its running smoothly > 500fps on my machine, mid-game. And thats on the VM. the YYC will boost it up to 900fps.
 

2Dcube

Member
I enjoy Game Maker precisely because I don't have to think about explicit/specific typing and things like that. I can focus on trying to make a fun game.
It would be nice if the performance increased under the hood, sure.
 
F

Flab

Guest
Thanks for the reply. Your game looks pretty cool, I like shooting so...

Could I perhaps bother you for like general optimization tips, things to avoid and so on? It'd be appreciated. A really annoying thing would be to use certain methodologies and then later realizing it doesn't scale so well.
 

DukeSoft

Member
I enjoy Game Maker precisely because I don't have to think about explicit/specific typing and things like that. I can focus on trying to make a fun game.
It would be nice if the performance increased under the hood, sure.
I disagree with that. I'd LOVE to have proper namespacing, exceptions, type hinting, more than 3 datatypes. And there's a lot of people that would love the same. The thing that makes this tool so powerful is the ease of compilation on different targets and the entire boilerplate stuff for graphics and sounds on different platforms. You don't have to worry about compatibility with different setups - it pretty much always runs.

And sure @Flab - can I suggest you join the /r/GameMaker Discord group? Here's a link: https://discord.gg/By6u9pC
There's a lot of helpful (and skilled) people around that are happy to help with quick questions.
 
F

Flab

Guest
I enjoy Game Maker precisely because I don't have to think about explicit/specific typing and things like that. I can focus on trying to make a fun game.
It would be nice if the performance increased under the hood, sure.
Yeah, it's nice to do that. But it also lends to ambiguity. Even in C you can often kinda just polymorph with pointers.

BUT, for something like GM, perhaps with explicit special usage, prioritizing a chunk of memory, making it fixed or static, and operations on it, that sort of thing. Though it may be less of an issue with the compiler. As I understand it, things generally happen with double precision, which is kind of a big thing. I also have no idea about other internals so far. I know it gets complicated and is kinda beyond the scope of my criticism, since I'm talking of opinionated ideals.
 

Ruimm

Member
I work mostly on mobile games and I do disagree. I find the performance to be quite good for a high level engine. I've used other well known engines and GM has the best performance out there specially when using YYC. I like specially that there is no garbage collector so you don't have to worry about a lot of optimisations that other engines do.
It is also the fastest engine I've tried to prototype and get a working project out there. These are actually the main reasons I use GM, its fast to develop and powerful enough to use in production.
 
F

Flab

Guest
Oh, another thing. The online login requirement (especially with the free version) is annoying, to be kind. I happen to have a garbage connection that often doesn't function so well, but whatever.

Aside from that, I mean, if I'm a time traveler and my windows date is 2047, the SSL/TLS stuff doesn't even work.
 

rIKmAN

Member
Ultimately, it means I have to pay $99 (I think?) just to be able to test properly on windows
You can get the Creators Edition which will allow you to export to Windows (or Mac if you buy the Mac version) for $39.
Oh, another thing. The online login requirement (especially with the free version) is annoying, to be kind. I happen to have a garbage connection that often doesn't function so well, but whatever.
Once you have logged in once, you can use the software offline with no connection to the internet for 30 days before you need to login online again to validate the licence.
Aside from that, I mean, if I'm a time traveler and my windows date is 2047, the SSL/TLS stuff doesn't even work.
Why would you be a time traveller or have your date set to 2047?
That would cause problems with lots of things, not just GMS2.
 

GMWolf

aka fel666
this confirmed that the collision event was triggered twice. It also made me realize collision events (and the associated collision detection I guess) are incredibly slow, which bothers me as I used to code this sort of thing.
The event triggering twice can be useful for code organization:
You may like your bullet object to destroy when it hits anything, and your player object to loose health when it hits a bullet object.
Having an event in both the player and bullet object is useful in that regard.
Also note that just because the event is triggered in both instances, does not mean the collision checks happen twice.

If you are using GMS1.x, collisions can be greater sped up by turning on the fast collision system in the game option (it uses spacial partitioning).
Make sure your masks are not set to precise either.

On top of that every instance has a huge list of events / code thats its running through (collision, movement etc) and it builds up quickly.
That's not really true.
An event will not be processed if the object does not have the event.
For instance, the collision checks are only performed if the object has the coresponding collision event.
 
F

Flab

Guest
The event triggering twice can be useful for code organization:
You may like your bullet object to destroy when it hits anything, and your player object to loose health when it hits a bullet object.
This is specifically about self-collisions though, I just kinda slipped the mention in there because it could possibly be non-obvious to some GM users and useful to some. But yes, I understand it doesn't necessarily mean collisions happen twice, but it is very slow imo (gm2 free/vm), as it looks like it's pretty much doing AABB collision detection, at the simplest/fastest I could set it. No idea of the spatial partitioning it uses.
 

GMWolf

aka fel666
This is specifically about self-collisions though, I just kinda slipped the mention in there because it could possibly be non-obvious to some GM users and useful to some. But yes, I understand it doesn't necessarily mean collisions happen twice, but it is very slow imo (gm2 free/vm), as it looks like it's pretty much doing AABB collision detection, at the simplest/fastest I could set it. No idea of the spatial partitioning it uses.
It's not quite AABB collisions, as the masks can rotate.
It's also not quite self collision, it's collision with another instance.
Having the event trigger in one instance but not the other would be tedious.
 
F

Flab

Guest
It's not quite AABB collisions, as the masks can rotate.
It's also not quite self collision, it's collision with another instance.
Having the event trigger in one instance but not the other would be tedious.
Well whatever it is, it doesn't match OBB collisions, so I dunno what it is. And yes with self-collisions I mean self-collisions in terms of type, instances of the same type colliding with each other.

In the case of dealing with two of the same type of instances colliding, in many simulations, there could be fair reason to not have duplicate responses. But anyway.
 
F

Flab

Guest
You can get the Creators Edition which will allow you to export to Windows (or Mac if you buy the Mac version) for $39.
Once you have logged in once, you can use the software offline with no connection to the internet for 30 days before you need to login online again to validate the licence.
Why would you be a time traveller or have your date set to 2047? That would cause problems with lots of things, not just GMS2.
1. I read something about 5 seat minimum and it's for 12 months, wth.
2. That's good to know.
3. Don't ask.
 

rIKmAN

Member
1. I read something about 5 seat minimum and it's for 12 months, wth.
2. That's good to know.
3. Don't ask.
$39 is for a single licence to export to Windows (or Mac if you buy the Mac version) and is valid for 12mths - which is what you want to do and is cheaper than the $99 you were complaining about.
If you decide to upgrade to the full Desktop Licence during the 12mth period then the cost of Creators is deducted from the price of Desktop.

Not sure where you are reading about "5 seat minimums" unless you are looking at the educational versions for schools etc?
 
Last edited:
F

Flab

Guest
Not sure where you are reading about "5 seat minimums" unless you are looking at the educational versions for schools etc?
Yes, sorry, I did read something about the educational versions so I probably recall that.
 
M

MishMash

Guest
At some point I noticed something called YYC, which is supposedly a compiler. This is not in the free version. I cannot say anything about it, I do not know if it's functional. Related to this, it appears to me that the interpreter/vm whatever is quite slow (I'm coming from mostly c/c++ land here). Related to performance would be things like explicit/specific typing and so on. So that's a problem with a few factors that as free/trial user I simply have no real confidence about.

I also (think) I noticed a couple of strange (to me) oversights. I'll give an example, I made an object_a that has a collision event with other object_a, so what I did was add ' If (self.id < other.id) return; ' and ' If (self.id > other.id) return; ', this confirmed that the collision event was triggered twice. It also made me realize collision events (and the associated collision detection I guess) are incredibly slow, which bothers me as I used to code this sort of thing.

So while I like gamemaker so far, some of it seems pointless and there's a bunch of basic stuff which I simply find bizarre and a bunch of what I'd call basic functionality missing, performance is pretty poor.
YYC is a lot faster than the VM as far as your own compiled code goes, however engine-level stuff wont really change as that is already handled in the back-end in C++ anyway. There is however a lot you can do to make your games run fast. I understand you are experienced, however people can often take the raw power of C++ for granted and neglect to think about general optimisation.
Personally, after having written my own engine in C++ and being experienced with optimisation, it is more difficult than you might think to make optimisations hold when your engine is doing lots of things. Sure, on a single, small test, a manual C++ implementation will win every time, however when you consider all of the rendering optimisations GM is doing and tbh, I think the collision system is proportionally quite fast. Having implemented a quad-tree based spatial partitioning system with collision events between all objects, it can get slow with 1000s of objects, even in C++ unless you are careful.

On that note, I think the two-way collision event is preferable. Given that each object is going to want to react to a collision in potentially a different way, it is beneficial to have it run in the context of both instances. I guess it may be considered odd if two of the same things run the event twice, however this is for consistency sake, as the same happens between two objects of different types.

I'd be interested to hear in what areas you see performance as being poor? I mean, i've found GM sufficient for most games, even my own project which is very heavy on the processing gets by without YYC (though YYC makes it buttery smooth and more than triples the FPS). It is always a trade-off for ease-of-use over performance. C++ is very time consuming to develop in, GM is proportionally very fast, so those time savings have to be made up somewhere. Also regarding the rendering pipeline, I tend to find it quite fast, often faster than many custom openGL renderers I see people make when you consider lots of moving objects, dynamic batching, render state management etc; Obviously its always possible to make C++ go faster, but when considering the difficulty you may have to go to.

I will say however that doing any sort of tree-based operation is painfully slow because there is no real data scheme that supports it. It may also be worth noting that should you desperately need performance, you can always write extensions in C++ for the heavier parts of a project if you needed it. Whilst still maintaining the general ease-of-use for everything else.

I work mostly on mobile games and I do disagree. I find the performance to be quite good for a high level engine. I've used other well known engines and GM has the best performance out there specially when using YYC. I like specially that there is no garbage collector so you don't have to worry about a lot of optimisations that other engines do.
It is also the fastest engine I've tried to prototype and get a working project out there. These are actually the main reasons I use GM, its fast to develop and powerful enough to use in production.
This is also a really valuable reply, memory management in GM is really lovely imo. It is very reminiscent of C/C++ style manual memory management when it comes to data structures and instances. This means you do get gains from being able to manage your own memory in that area. I have a friend who always likes to use Java and it tends to get to the point where the apps use up so much idle memory (for 3D projects) that the garbage collector creates a horrible stutter. The only thing in GM that is garbage collected are arrays, however I think those are simply unloaded on re-assignment.

For me, the main benefit of GM is that it saves me so much time and is completely sufficient for my needs. You do get into habits of knowing where the performance holes are, just like with any other language. It's just a question of how worth-it the rapid prototyping and production is to you vs other engines which may be more grounded with more common language features, but a slower development cycle. On a personal note, i've started to hate developing in languages like C#, simply because whilst it has more control over things like types, I hate the lack of manual memory control which I find to be really important these days.
 

GMWolf

aka fel666
Garbage collection is fine. You just need to know about it and design around it.
The use of a pool is very important for resources.
Keeping temp objects around for maths makes a difference too.
 

DukeSoft

Member
Oh, another thing. The online login requirement (especially with the free version) is annoying, to be kind. I happen to have a garbage connection that often doesn't function so well, but whatever.

Aside from that, I mean, if I'm a time traveler and my windows date is 2047, the SSL/TLS stuff doesn't even work.
Thats how SSL works xD

That's not really true.
An event will not be processed if the object does not have the event.
For instance, the collision checks are only performed if the object has the coresponding collision event.
The collisions won't get calculated but the events do get triggered (namely the step events). Thats where issues like these arose from for me: https://forum.yoyogames.com/index.php?threads/vertex_submit-creating-massive-unknown-overhead.37034/
 
GM:S checks every event on every object active in a room, but the event is not processed if there is no gml in the event. Also built in variables are updated every step even if they are not needed. This is because GM:S was created with beginners in mind to cover as many bases as possible so that anyone can just dive in and start creating without much thought. Currently deactivating objects or making them not visible are the only ways to speed up this pipeline, but not all is lost. If you take a look at the road map there are lightweight objects listed and I hope that this is the solution we're all looking for here.

Also the engine does do garbage collection, we just don't have access to it. But that's coming too :)

https://help.yoyogames.com/hc/en-us/articles/231719448-RoadMap
 
F

Flab

Guest
Thanks for all the responses, the GDC game jam developer trial thing and all that. I did end up trying YYC after a rather annoying msvc download/install of their community version (which I don't recommend, it's absolutely massive even for just a minimal install). Anyway, I'm not very impressed after some quick testing, doubt I'll bother with gamemaker any further.
 
F

Flab

Guest
So I did very little with GMS, but something, anyway. So uhm, can someone explain to me why colliding one type of object vs another of the same type, produces 4 collision events? Wth?

Actually, I could probably take some guesses, though I can't say for sure and I haven't tested much. It seems to be some sort of grid partitioning, meaning entries into muliple cells, then, collision list generated from that (without cleaning up that collision list's duplicates or checking for duplicates when adding), meaning lots of duplicate collision events.

Or, rethinking that, it could actually be checking collision twice and generating 4 events (2 for each instance).

The point is, it's generating 4 events (who knows how many collisions or entries in the spatial partitioning?) for what should (at least optionally) be one collision test and associated event.
 
Last edited by a moderator:

DukeSoft

Member
If you have object A and object B, and you put a "collision with Object B" into object A, only 1 event should fire once, in 1 step, which is in Object A.

Can you share what you did, so we can see where your numbers are coming from? I'm assuming you have a collision event in both objects (with each other) and maybe they are overlapping for more than 1 frame / step.
 
F

Flab

Guest
Object A and B are of the same type. It's very simple to test. Reset a collision counter somewhere, every frame. Make collision event with same type, in event simply increase the counter by 1. Read the counter.
 

GMWolf

aka fel666
So I did very little with GMS, but something, anyway. So uhm, can someone explain to me why colliding one type of object vs another of the same type, produces 4 collision events? Wth?

Actually, I could probably take some guesses, though I can't say for sure and I haven't tested much. It seems to be some sort of grid partitioning, meaning entries into muliple cells, then, collision list generated from that (without cleaning up that collision list's duplicates or checking for duplicates when adding), meaning lots of duplicate collision events.

Or, rethinking that, it could actually be checking collision twice and generating 4 events (2 for each instance).

The point is, it's generating 4 events (who knows how many collisions or entries in the spatial partitioning?) for what should (at least optionally) be one collision test and associated event.
My guess is you messed up somewhere.
If instance A and B are overlapping, you will be getting two events per step; A colliding with B, and B colliding with A.

Make sure you are only looking at one step, and that you only have two instances.
 
F

Flab

Guest
My guess is you messed up somewhere.
If instance A and B are overlapping, you will be getting two events per step; A colliding with B, and B colliding with A.

Make sure you are only looking at one step, and that you only have two instances.
My guess is no, but it's just a guess.

This is literally it:

obj_enemy has collision event with obj_enemy.

global.g_colhits is reset to 0 every frame.

In collision event:
global.g_colhits+=1;

Edit:
I dunno, it seems to me that it's doing the check or at least generating the collision result once for each object separately and then adding that, for both objects. So, obj0 vs obj1 AND obj1 vs obj0. Then, generates events for both obj0 and obj1, twice.
 
Last edited by a moderator:

GMWolf

aka fel666
My guess is no, but it's just a guess.

This is literally it:

obj_enemy has collision event with obj_enemy.

global.g_colhits is reset to 0 every frame.

In collision event:
global.g_colhits+=1;
very strange. I dont seem to be able to reproduce.
Care to share the project file?
 

GMWolf

aka fel666
Sure, here you go, just remade it absolutely minimally, dunno where else to upload, whatever, scan it or something I guess:

http://s000.tinyupload.com/index.php?file_id=89865167957065840948

I get 4 collision hits there.

Edit: If you tell me that doesn't generate 4 hits (or 2, if you do self.id<=other.id, return), let's just say I'd be even less impressed.
I do get 4 collision hits.
I am looking into it. Its the firs time I have seen anything of the sorts.

Ok, this is 100% a bug! Its an urgent one too. I filed it.
Its such an important bug I wonder if tagging a dev isnt warented.

not the best first impression huh?
 
Last edited:
F

Flab

Guest
I do get 4 collision hits.
I am looking into it. Its the firs time I have seen anything of the sorts.

Ok, this is 100% a bug! Its an urgent one too. I filed it.
Its such an important bug I wonder if tagging a dev isnt warented.

not the best first impression huh?
The thing is I really do have quite a bit of experience with coding geometry/collision detection/physics and engine related stuff (wrote multiple 2d and 3d engines), so I notice these things.

I could b*tch about some other things too...the collision shape (at its simplest), though I haven't tested it (I will soon), looks to be simply AABB vs AABB based on the extents of the OBB, I can't be sure, but it kinda looks like that. There's a quite a lot about the collision stuff that really annoys me in how lacking it is.
 

GMWolf

aka fel666
I could b*tch about some other things too...the collision shape (at its simplest), though I haven't tested it (I will soon), looks to be simply AABB vs AABB based on the extents of the OBB, I can't be sure, but it kinda looks like that. There's a quite a lot about the collision stuff that really annoys me in how lacking it is.
The collision Shapes can be rotated, it's not simple AABB.
You can also have ellipses, and full on sprite masks, for when you need high accuracy (most games use boxes and spheres..)
 
F

Flab

Guest
The collision Shapes can be rotated, it's not simple AABB.
You can also have ellipses, and full on sprite masks, for when you need high accuracy (most games use boxes and spheres..)
Ok firstly, check this out, it is probably simple AABB. But, the AABB is generated (enlarged) from the OBB.

You can test this very easily by rotating one of those boxes in the project I uploaded by about 45 degrees. Thank you, come again.
 
F

Flab

Guest
Well, I'm trying to help people and GMS. Like, I identified some issues. My attitude could be described by vulgarities.
 

GMWolf

aka fel666
Ok firstly, check this out, it is probably simple AABB. But, the AABB is generated (enlarged) from the OBB.

You can test this very easily by rotating one of those boxes in the project I uploaded by about 45 degrees.
Interesting. I have more than once used rotated rectangle colliders with no issues. Was this changed @Jobo ?
 
F

Flab

Guest
Interesting. I have more than once used rotated rectangle colliders with no issues. Was this changed @Jobo ?
This is actually not that bad, because assuming that there's a function for AABB vs OBB, you could do a relative transform and test for it manually after the AABB vs AABB test, but ideally you should be able to choose AABB or OBB per object before the events are generated, that way you could still have the flexibility and a function for manually doing AABB vs OBB at the expense of extra events.

Edit:
What I mean is, you could have AABB vs AABB (based or not on OBB extents) with more events, or AABB/OBB vs OBB (which is AABB vs OBB after transform) with less events, but still a function for AABB vs OBB for manual tests.
 
Last edited by a moderator:

rwkay

GameMaker Staff
GameMaker Dev.
This is not a bug per se as events for collisions both objects get the collision event, now for backward compatibility we have left the behaviour as it was (when we inherited GMS).

So what is happening is that we have 2 instances colliding of the same type instance A and instance B

collision for A -> B - instance A collision event is called, instance B collision event is called
collision for B -> A - instance B collision event is called, instance A collision event is called

So the 4 calls to the same collision event occur as instance A and instance B are the same object.

Russell
 

GMWolf

aka fel666
This is not a bug per se as events for collisions both objects get the collision event, now for backward compatibility we have left the behaviour as it was (when we inherited GMS).

So what is happening is that we have 2 instances colliding of the same type instance A and instance B

collision for A -> B - instance A collision event is called, instance B collision event is called
collision for B -> A - instance B collision event is called, instance A collision event is called

So the 4 calls to the same collision event occur as instance A and instance B are the same object.

Russell
But his is super unintuitive, no?
When you have two different objects, only 2 events are called.

Surely the collision system should be type agnostic.
Won't this cause really annoying bugs too? Imagine calling ds_list_destroy in such an event. Best case scenario you get an error. Worst case it deletes another list and you never realize it!
 

rwkay

GameMaker Staff
GameMaker Dev.
I do not believe it is unintuitive it is just how Mark Overmars defined the collision system way back when he added it, for any collision between instances that have collision events defined in the object.

It is type agnostic as it does not matter what the types are this is how collisions are propogated, it may not quite match your mental model but this is what happens.

Russell
 

GMWolf

aka fel666
I do not believe it is unintuitive it is just how Mark Overmars defined the collision system way back when he added it, for any collision between instances that have collision events defined in the object.

It is type agnostic as it does not matter what the types are this is how collisions are propogated, it may not quite match your mental model but this is what happens.

Russell
collision for A -> B - instance A collision event is called, instance B collision event is called
collision for B -> A - instance B collision event is called, instance A collision event is called
This only happens when A and B are of the same type.
If we have two different objects (oA and oB), both with collision event against each other (oA collision with oB, oB collision with oA) this does not happen, the collision event is only called once per instance.

Why is it that having the object index be the same (but otherwise identical events in both instances) that we get the collision event triggering twice per instance (for a total of 4 times)?
 

GMWolf

aka fel666
Hmmm OK the moral of this story is don't look at this while suffering from jet lag and sitting in an hotel room, I will take a look further when I get back to the UK as this is a little odd... and only seems to be happening when both objects are of the same type...

Russell
oh, what about the rotate rectangles thing? I though I remembered rotating rectangles before and it working fine in GMS1.x. Is this no longer the case in GMS2?
 

YellowAfterlife

ᴏɴʟɪɴᴇ ᴍᴜʟᴛɪᴘʟᴀʏᴇʀ
Forum Staff
Moderator
Ok firstly, check this out, it is probably simple AABB. But, the AABB is generated (enlarged) from the OBB.

You can test this very easily by rotating one of those boxes in the project I uploaded by about 45 degrees. Thank you, come again.
About this bit, if a sprite's collision mask is set to Rectangle-Fast, it's strictly AABB/OBB, and rotation merely influences collision bounds.

Setting to Precise will calculate a bit mask compile-time and consider rotations; for a rectangle will not be noticeably slower, as it'll only ever perform a single iteration with all "pixels" within collision bounds counting as "solid".
oh, what about the rotate rectangles thing? I though I remembered rotating rectangles before and it working fine in GMS1.x. Is this no longer the case in GMS2?
It was always like this, the thing was that GM8.1 and earlier would default to "Precise" mask type for new sprites, while GMS1 started to use "Rectangle". Still, the effect is not very apparent unless you have overly long/narrow bounding boxes.
 

GMWolf

aka fel666
About this bit, if a sprite's collision mask is set to Rectangle-Fast, it's strictly AABB/OBB, and rotation merely influences collision bounds.

Setting to Precise will calculate a bit mask compile-time and consider rotations; for a rectangle will not be noticeably slower, as it'll only ever perform a single iteration with all "pixels" within collision bounds counting as "solid".

It was always like this, the thing was that GM8.1 and earlier would default to "Precise" mask type for new sprites, while GMS1 started to use "Rectangle". Still, the effect is not very apparent unless you have overly long/narrow bounding boxes.
Well, we should get more options:
Bounding box AND rectangle.
 
Last edited:
F

Flab

Guest
Hmmm OK the moral of this story is don't look at this while suffering from jet lag and sitting in an hotel room, I will take a look further when I get back to the UK as this is a little odd... and only seems to be happening when both objects are of the same type...

Russell
Hi, well basically, could you add an option for generating single collision events between object types? Even one event for each object is unnecessary in many if not most of those cases (at least, I've never WANTED duplicate responses in stuff I've coded as it tends to degeneracy, especially in collision response), but I can understand why it can be preferable in some cases, depending.

The way I see it though, less events, less processing, less unnecessary, possibly broken behaviour. So yeah, options would be nice.
 

GMWolf

aka fel666
Hi, well basically, could you add an option for generating single collision events between object types? Even one event for each object is unnecessary in many if not most of those cases (at least, I've never WANTED duplicate responses in stuff I've coded as it tends to degeneracy, especially in collision response), but I can understand why it can be preferable in some cases, depending.

The way I see it though, less events, less processing, less unnecessary, possibly broken behaviour. So yeah, options would be nice.
I have never had issues with events firing in both instances rather than just the once.
Even hypothetically I cannot think of any cases where it would be preferential.
Most of the time you are looking at collisions between different instances anyways so the event will only fire in the instance with the event.

Also, this would cause issues when parenting is used. All of a sudden, you would ether break your projects, or have the event firing in each instance, as opposed to firing just in one of the istances.

I also cannot think of any physics engines that only generate collisions for the one instance. Though, most of them actually use manifolds, but thats not really compatible with GM's instance model (What instance should get the manifold?).

The most important Issue is deciding on what instance should get the event.
If you have a bullet colliding with an enemy: your bullet now needs to know about every response an enemy can have to being hit by a bullet, because it could be recieving the event, and not the enemy,

As you can see, single events rather than events in each instances cause a few problems.
 
Top