Correct me if im wrong please..If im not mistaking, in a fluid simulator, i think its more like pixels affecting each other, as opposed to specified particles...physics simulation where every pixel in a specified field are all affected by each other.The parts that look like particles moving away at diagonals are actually "disturbed" into certain directions...with specific forces applied in 4 (perhaps 8?) directions away from the mouse position.

Correct me if im wrong please..If im not mistaking, in a fluid simulator, i think its more like pixels affecting each other, as opposed to specified particles...physics simulation where every pixel in a specified field are all affected by each other.The parts that look like particles moving away at diagonals are actually "disturbed" into certain directions...with specific forces applied in 4 (perhaps 8?) directions away from the mouse position.

Almost correct!It's definitely different from "real" fluid simulations. But I guess there are two schools. One where you use particles and one where you use a grid (such as mine).I'm trying to not look at how others do so.., If you want to do it "correctly" then don't listen too much to how I do it

I'm practicly doing 2 things:First I'm diffusing the pressure, and this is what makes this simulation so interesting... Instead of spreading out high pressure to low pressure I'm doing the opposite. In practice this means that high pressure wants more pressure and low pressure does the same. This makes everything behave like it has lots of surface tension.

The second thing I do is to advect the field. I'm saving two buffers, one has the velocity of every pixel and the second has the density/pressure, the stuff being moved.In the diffusion of pressure (that I just described) it doesn't just move the pressure but also changes the velocities of the grid. The idea is to fill a low pressure field and distribute out from the high pressure ones. Advection is done by adding whatever stuff you have in a cell to the cell that the original cells velocity is pointing towards. Since the velocity vector might be pointing to a position that's inbetween 4 cells then some math is needed to distribute that evenly. This means that stuff diffuses alot in strange ways.

I'm actually applying all directions from the mouse, I think it looks very much not like it but I guess that's because I'm adding it in a square shape with the mouseposition as center. This means that the distribution of force isn't circular but squareish.., hence the clover like pattern (my guess).

Shader would be faster, but interaction with a GLBasic program would be extremely limited(cest la vie for glbasic and shaders).You can only pass data as single chunks to a shader with glbasic...you can pass a vector, but in 3 separate vars...then you rebuild your triplets in shader code(this is a slowdown)

You can use all OpenGL calls in GLBasic with INLINE. So if you want you can pass big arrays of data, if you need help with this write me a message and I help you with this. (all Desktop only, cant use shaders on mobile devces).If there is a need I can write a lib to give you better and easier shader support in GLB, but would need some time to do so.

But using shader is not faster in every case, especially not when doing complex calculations per vertex and mixing it with GLBasics fixed pipline. Shader are more powerful, but not always faster. For fluid simulations it could be useful to use compute shaders, but this is very advanced stuff (which I have never done, only vertex and fragment/pixel shaders) and limited to really new hardware.

With INLINE you can pass everything into the shader, e.g. I have done it with textures, matrices, vec3 and arrays of any of them. There are no limitations, as long as you accept that you can only do this on desktop platforms.