1. Hey! Guest! The 35th GMC Jam will take place between November 28th, 12:00 UTC - December 2nd, 12:00 UTC. Why not join in! Click here to find out more!
    Dismiss Notice

Liquid Physics - New Video Tutorial Added

Discussion in 'Tutorials' started by GMLWaffle, Sep 30, 2016.

  1. GMLWaffle

    GMLWaffle Member

    Joined:
    Sep 4, 2016
    Posts:
    38
    Last edited: Oct 1, 2016
    zircher and HanProgramer2000 like this.
  2. chance

    chance predictably random Forum Staff Moderator

    Joined:
    Apr 22, 2016
    Posts:
    799
    This works fine. But there's a few things worth pointing out.

    First, there's no particular need to define the particle group and all the particle flags each time a new particle is created in the DRAW event. You could just as well move the group definition code to the CREATE event. That way you can set the particle radius, damping, gravity, etc. just once. Same for the flags. Just use (0,0) for the group location, and remove the var from flag, so it can be referenced in the physics_particle_draw().

    Then in the DRAW event, just say: physics_particle_create(flags,mouse_x,mouse_y,0,0,your_color,1,2);

    For that matter, you don't really need to define a group at all. Just set the particle properties and the flag variable in the CREATE event, without a group definition or a group flag.

    Interestingly, there's no significant performance penalty for defining the particle properties each step. It's just more intuitive to define them once in the CREATE event.

    Second, you can remove the background and set the sprite color with the sprite editor. That way you don't have to use the blend modes in the DRAW event. However, the blend modes do create a nice effect.

    Third, you don't need the parent objects that perform the collision checking. They aren't necessary. The wall objects are already defined as static physics objects, so the water particles collide with them just fine.

    All that said, there's nothing particularly wrong with your approach. I just think it over complicates things.
     
    Last edited: Sep 30, 2016
    makas likes this.
  3. GMLWaffle

    GMLWaffle Member

    Joined:
    Sep 4, 2016
    Posts:
    38
    If you read the post, you'll see issue two which is "Second, the particles or "liquid (i.e. water in this one)" when they do manage to overlap each other, don't have any blend mode set for them. So the result is a circular sprite being drawn over the same circular sprite over and over which causes this small black outline around the sprite. This causes you to be able to see each individual circle, and it totally ruins the effect."

    This is why the blend modes are necessary. Test it first with a png circle Sprite, and then with mine.

    As for everything else, yes it could possibly be a bit simplified and shortened but what's there is there as a safety precaution when I was first creating it. Once it got to a working state, I didn't feel the need to revise it.
     
    chance likes this.
  4. chance

    chance predictably random Forum Staff Moderator

    Joined:
    Apr 22, 2016
    Posts:
    799
    I understand the reason for the blend mode. As I mentioned in my comments, it does create a pleasing effect. I was just afraid your comments left the impression that the background couldn't be removed without them.

    As for the other issues I mentioned, I understand your concern. So I'm not asking you to revise anything. But with tutorials, it's important for people to experiment with the ideas. So I felt it was worth pointing out alternatives to re-defining the group for each particle, or for even using a group definition approach at all. Same for the collisions.
     
  5. GMLWaffle

    GMLWaffle Member

    Joined:
    Sep 4, 2016
    Posts:
    38
    Absolutely, and I do agree that I should go through and simplify things a bit to also make it more efficient. Especially if you want to use smaller sprites for a more realistic effect, as they could begin to slow things down in very large numbers(not particularly here where they are all that's being created in the physics world, but for an in-game solution with many objects and different things happening).

    Also the parent objects are more for if you were adding several different physics objects to the world, in order to make it an easier processing for identifying how they should act. I started this in a rag doll example I made a few days ago and just removed those parts.

    EDIT: oh forgot to mention, the Sprite thing is mentioned in the readMe, so hopefully that takes away any confusion as to whether or not you can use a regular circle Sprite or not.

    EDIT 2: also going to change the way water behaves a bit to make it more realistic. I'll also add other liquid types and go over the different flags you can set for physics particles.
     
    Last edited: Sep 30, 2016
  6. How much FPS its going to run on 4000 instances?
     

Share This Page

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice