game speed.

[Meiun]

Well it wasn't with D&D...and it was years ago when I made it, so I don't know that I could resurrect a code for you. Either way, I can't assure you my programming skills were all that great at the time, but I can say that GM collisions are very limiting, sometimes buggy, and have enough flaws that I prefer to use DLLs for coding collisions. Just my preference though.

All GM really does is offer a bunch of functions and tools for you to use to create your collision system. The functions work for exactly what they are intended, and really do not have any "bugs" (I've been using GM for something around 9 years now I think? Think you can trust me on that one). How you use them, is (as stated earlier) another story. If you want to get really fancy in terms of your needs and wants for it all then you can just code your own replacements/alternatives and not use their built in, but I wouldn't see why you'd need a DLL for it. In terms of collision stuff theres really nothing a DLL could do that you couldn't just do with coding it in GML (the overhead of the constant DLL calls might even slow it down a bit for such small repetitive calls). But, to each his own. I don't mean to judge :P. But yeah, I think I've had enough of this topic for the time being X_X

[ARTgames]

Jake and Meiun, to be honest, I could not agree more. I'm glade you all can explain this way better than i can.

@Mr Pwnage
Just wondering. What is this DLL you were talking about?

[tehrozzy]

Although i know it wouldnt happen, coz its not really worth the time, it would be cool if there was atleast an option to change between 30 and 60 fps, that way atleast people can decide so if their computer can handle it, then they can change to 60 if they want :P

[Mr Pwnage]

Well it wasn't with D&D...and it was years ago when I made it, so I don't know that I could resurrect a code for you. Either way, I can't assure you my programming skills were all that great at the time, but I can say that GM collisions are very limiting, sometimes buggy, and have enough flaws that I prefer to use DLLs for coding collisions. Just my preference though.

All GM really does is offer a bunch of functions and tools for you to use to create your collision system. The functions work for exactly what they are intended, and really do not have any "bugs" (I've been using GM for something around 9 years now I think? Think you can trust me on that one). How you use them, is (as stated earlier) another story. If you want to get really fancy in terms of your needs and wants for it all then you can just code your own replacements/alternatives and not use their built in, but I wouldn't see why you'd need a DLL for it. In terms of collision stuff theres really nothing a DLL could do that you couldn't just do with coding it in GML (the overhead of the constant DLL calls might even slow it down a bit for such small repetitive calls). But, to each his own. I don't mean to judge :P. But yeah, I think I've had enough of this topic for the time being X_X

Well maybe buggy wasn't the proper wording...more inconvenient. I use DLLs to make things more "user-friendly" to my liking, primarily with 3d collisions. And it doesn't slow the game down if you use them correctly, but that's another story.

[JoEL]

I could only ever see myself using a collision DLL for 3d. But then again, I wouldn't use GM for a 3d game, as I find it extremely limiting, other then that collision DLL's are a waste of memory. As Meiun said though "each to there own" I personally can't see myself coding my own collision events as I absolutely adore the inbuilt collision functions (mixed in with some good o'l coding as well of course).

Now back on topic here, I don't agree that SO should demand more CPU! :O SO2 takes enough out of my good old windows 98 ;)

[Doogie]

Well yeah, but I prefer not to. The way I'm thinking of is checking collision_line() between x,y and xprevious, yprevious.

Well, my current collision system is coded 100% from scratch, using no built in GM functions or even "collision events," so yeah.
[/quote]

Your collision system will hopefully be more effecient for SO3 dude. 'For Loops' for collision detection is very inefficient. I'm trying to look into Separating Axis Theorem for my future games, so I'll probably need someone who's knowledgeable in Geometry and Trig.

In any case, a 60 FPS switch on/off switch, whilst nice would require Meiun to rethink how to handle gravity as getting that to match the gravity of 30 FPS isn't as simple as 1,2,3.

[Jake]

Your collision system will hopefully be more effecient for SO3 dude. 'For Loops' for collision detection is very inefficient. I'm trying to look into Separating Axis Theorem for my future games, so I'll probably need someone who's knowledgeable in Geometry and Trig.

In any case, a 60 FPS switch on/off switch, whilst nice would require Meiun to rethink how to handle gravity as getting that to match the gravity of 30 FPS isn't as simple as 1,2,3.

Isn't Separating Axis Theorem collision detection only helpful when using more complex shapes?

[Doogie]

Isn't Separating Axis Theorem collision detection only helpful when using more complex shapes?

Not really, unless you call a triangle complex. Its the theorem that
'N' uses. http://www.metanetsoftware.com/technique/tutorialA.html

[Jake]

But what are the advantages of using it in a game that only needs rectangular collisions? If anything, it would cause an unnecessary amount of slowdown.

[Doogie]

But what are the advantages of using it in a game that only needs rectangular collisions? If anything, it would cause an unnecessary amount of slowdown.

Yeah I guess, but I put it up for future reference as the new SO might use slopes. In any case, a simple code to check if the player is colliding with the Axis-Aligned Bounding Box (AABB) and snapping them to the top of the floor would be more effecient for collision in the current build of the game, unless that part has been re-written over the years.