Waves, with sines but no ALLEGRO_FLIP_VERTICAL
A. van Patmos

Basically it's this; ALLEGRO_FLIP_VERTICAL does not work with this code. So I'm doing something wrong.
I try to let the water stream any any direction needed. Water moving RtL is just the math for LtR then do ALLEGRO_FLIP_HORIZONTAL. That seems to be OK.
The horizontal sines move jerkily but the vertical movement is without any accelleration, which I did not expect.
If you're interested maybe you can compile to see what I mean. It's hard to explain.

Edgar Reynaldo

I can't compile it. All the == and other operators are missing. There are spaces where they used to be. Try saving as UTF-8.

A. van Patmos

Yes, /* and */ were missing too. Strange. Here's a new save in ASCII and one in UTF-8.

edit: You'll have to rename water.png to MAR0DST192.png or change the code.

Edgar Reynaldo

I'm too tired to look tonight. What exactly is the unintended behavior you're witnessing? Computers only do what you tell them to.

Peter Hull

Based on looking at the code only, I saw 2 things

1. I don't think you need al_lock_bitmap - that's for when you want direct pixel access to the bitmap's memory (Edgar can confirm this, I can't remember!)
2. You're setting uitslag_y and uitslag_x to the same (lines 47 & 48) - is this correct?

Pete

A. van Patmos

Ok, maybe I misunderstood how to use al_lock_bitmap.

Yes I set both amplitudes to 18.
If you set line 37 to be
float h_afstand = 0, h_snelheid = 0, v_afstand = 0, v_snelheid = 0;// edit: snelheid is speed, afstand is distance
everything stays where it is.

You can see a few things:
The vertical sines move with a steady speed (no accelleration)
The horizontal sines move 'jerkily'. sometimes the sine works with the flow (speed up) and sometimes against. (I meant that in my first post)
You can see why I made the png with a black graph on one end and red on the other: if black moves red stands still and vice versa. That makes sense.

I expected the vertical movement to be the same.

edit some more: I attached a pic.

Edgar Reynaldo

I don't understand what effect you're trying to achieve. It looks pretty cool to me. :?

EDIT
Yeah, you don't need to lock the bitmaps to draw them. That causes a memory transfer, and you don't want to leave them unlocked either. Lock, update, unlock.

EDIT2
This kind of program would be best with a shader. You could easily replicate the effect. All you're doing is adding sin(x) to the x and y coordinates in the proper direction.

EDIT3
I whipped up a simple shader program. It does mostly what you want, but doesn't 'keep flowing' in the same direction. Maybe this will give you an idea on how to make it work the way you want it to.

Download Wavy.7z here

Here's the fragment shader I used.

#SelectExpand
1#version 110 2 3uniform sampler2D tex; // 0 4uniform float time; // effect elapsed time 5 6uniform vec2 surface; // texture resolution 7 8void main() 9{ 10 float width = 1.0/4.0;/// In texels 11 float factor = 0.05;/// Factors from 0.01 to 0.1 seem okay 12 factor = factor*sin(time); 13 vec2 uv = gl_TexCoord[0].xy; 14 15 float power = 1.0; 16 17 float xfact = (1.0 + sin((2.0*3.14159265*uv.x/width) + time))/2.0;/// [0,1.0) 18 xfact = pow(xfact , power); 19 20 float yfact = (1.0 + cos((2.0*3.14159265*uv.y/width) + time))/2.0;/// [0,1.0) 21 yfact = pow(yfact , power); 22 23 /// Modify x value by sin(2PI*x/50.0) and y value by sin(2PI*y/50.0) 24 uv = vec2(uv.x + factor*yfact , uv.y + factor*xfact); 25 gl_FragColor = texture2D(tex, uv); 26}

Thread #617556. Printed from Allegro.cc