Why You Should Not Use Solid, and what you can do instead Options

[jabelar]

This agrees with a theme of mine generally -- I don't like to use any of the built-in game maker events except the Create, Step and Draw. Again it is about control, and with the built-in events you don't have the control you need. The only annoying thing is alarms because there is a game maker bug where you have to have an Alarm event for the alarm to count down, even if the Alarm event has no real action in it!

But I actually do use "solid", but I never use the collision events. Using solid is still useful because you can use all the built-in functions (like move_contact_solid()), but because I don't use collision events game maker never does any automated movement (or automated undoing of movement).

I also suggest people don't use built-in gravity, speed, hspeed, vspeed or friction because again they do things automatically and you can't control them.

[link3000]

I have to disagree with you on a few points, jabelar. First of all, you can control hspeed, vspeed, friction, and gravity as much as you could a variable you set, game maker only adds it to the x/y for you. That shouldn't cause any problems if you know how game maker works. If you use the built-in alarm variables, why shouldn't you use the built-in alarm events that correspond? Using multiple built-in events instead of tons of ifs and switch-cases will help organize your code a ton.

[link2991]

im sure that image_xscale works with lite.

[link3000]

im sure that image_xscale works with lite.

Uhh.. Who said that and are you my clone?

[Desert Dog]

im sure that image_xscale works with lite.

Uhh.. Who said that and are you my clone?

He's talking to SoulRed, i.e. in his first post:

(I think. If I'm wrong and image_xscale doesn't work on lite though, just comment those sections out of the example.)

Edit: Or GmXpert, as he's known on this forum
Edit2: And yes, image_xscale does work with lite. [for the record]

This post has been edited by Desert Dog: Nov 3 2009, 10:19 PM

[lasttea999]

I think this is a really helpful topic! I stopped using solid a while back, and personally it's a big improvement - as gmXpert and the others say, it's about control. You should know exactly how your code works whenever possible.

One question, though: how would one go about replacing GM's collision funtions (like place_free and place_meeting)? In other words, how would one make custom collision-checking functions using GML? I'm not really familiar with programming outside of GM, and don't really know how programmers usually do it.

[Blood Hunts]

Well, not using solid is a pretty good idea,
But i like not using hspeed, vspeed and gravity better.
using your own variables for gravity and using place_free and x+= and such things works pretty neat for me.
So good idea but i think using solid with your own moving system works better.

[Marchal_Mig12]

I think that someone who uses solid check box carefully is the best alternative. Why? Faster. Supporting friction and gravity as well as collision is a lot of work considering that GM does all this for us. Anyone who can uses solid should. I never had problems using it, I still use it and I make great games. The only problem to this point are the slopes and physics involving solid blocks. A quote from the programming industry: "Don't waste your time doing what has always been done."

[link3000]

He's talking to SoulRed, i.e. in his first post:

(I think. If I'm wrong and image_xscale doesn't work on lite though, just comment those sections out of the example.)

Ahh, sorry about that.

@Marchal_Mig12

Yes, don't waste your time doing what has already been done well in a sense that also applies to your project, to extend it. The people here have experienced the preprogramed effects of solid objects, and while they are useful for checking for specific objects, parent objects can essentially dot the same, without the unwanted side effects of built-in solids.

[petenka]

I stopped using solid very early on in my time with game maker. I never liked using it because of how ugly the collisions looked.
Neither did I like pixel based collisions for that matter...
That's why I created MBPE. It has the best physics for a platformer, and its made using game maker.

[Marchal_Mig12]

I may consider using non-solid blocks some when when I want to use a 360 degree platformer physics. But right now, 4 directions physics is much more efficient using solid blocks. And it works fine .

[jabelar]

I have to disagree with you on a few points, jabelar. First of all, you can control hspeed, vspeed, friction, and gravity as much as you could a variable you set, game maker only adds it to the x/y for you. That shouldn't cause any problems if you know how game maker works. If you use the built-in alarm variables, why shouldn't you use the built-in alarm events that correspond? Using multiple built-in events instead of tons of ifs and switch-cases will help organize your code a ton.

Yeah, but you don't control when it adds the x/y for you. That can cause problems in several situations, like controlling views, or if you have moving platforms, etc. In many games I want to only move the player character after the obstacles are moved, otherwise there is potential to get stuck.

You're right that if you know all the fine details of the order of the step events in game maker you can get around this. But if you don't use built-in variables you simply never have to worry about this.

I see many many people ask why their character jitters when it is riding on a moving platform, or why their view jitters when it is following the character, and it always comes down to the order of execution of events, which is something you shouldn't have to worry about.

With gravity, it will move it before you have a chance to tell if it will collide. Certainly you can check the step before, but in some games many other things may have happened since that previous step.

I can go on and on, but using the non-step events and built-in movement variables leads to lots of problems.

[petenka]

I use a few of the built-in variables in my engine and I never get any problems with them. Granted I know the exact execution order of gm and don't use any gm collision or motion checking functions, but still, it works absolutely fine and results in collisions that are beyond pixel perfect (you can zoom in using views and you'll see that the player still collides perfectly).
My conclusion is that using built in variables and such is good for beginners who don't want anything fancy and super perfect.
As well its fine for experts who know exactly what they're doing and how everything works.
It only causes problems for intermediates who want perfection but don't know how everything works yet...