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.
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.
]]>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.
]]>I'm too tired to look tonight. What exactly is the unintended behavior you're witnessing? Computers only do what you tell them to.
]]>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
]]>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.
]]>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.
Here's the fragment shader I used.
]]>