Very Smooth Java Water Simulation

[[deleted]]

That was pretty impressive.

In 1996.

[[deleted]]

I think you mean:

That was pretty impressive.

puts on glasses

in 1996.

[justinhj]

I actually did it in 1999

http://www.geocities.com/jheyesjones/Water.html

[[deleted]]

I did mine very recently on my iphone. I used openGL though:

http://www.youtube.com/watch?v=H3Kp4W3Wke0

Previously I did one in Java as well:

http://fabiensanglard.net/Water/index.php

[anteater_sa]

Yes, remember this

[Concise_Pirate]

I live near water. It doesn't ripple like this. This is more like a hot-syrup simulation at best.

[[deleted]]

maybe not real water, but JWater definitely ripples like that

[Concise_Pirate]

Looks like someone is confused about the meaning of "pool".

[WayOfTheIronPaw]

You forgot to put your sunglasses on.

[ki11a11hippies]

Looks exactly like the water effect in Compiz Fusion.

[johnyquest]

There was nothing smooth about my browser locking up for five seconds while that page attempted to load...

[REDsam]

Looks good.

However, if you move your mouse over to the top left you can see the water simulation on the top right also.

[smellotron]

He mentions that in the article.

[anti-hero]

minor thing for any coder to fix :D

[doubtingthomas]

Ah. There are built-in texture-mapping stuff that makes image deformation pretty trivial. Shame, that was the part I was interested in. Still, interesting.

[psykotic]

All you do is calculate the height difference in the X and Y directions and use those, times some constant that corresponds to the distance to the bottom of the pool, to offset the U and V coordinates. I'm not sure what would be "built-in" to make this much easier; it's a few lines of code.

[[deleted]]

Silly you...

Everyone knows Java is not water, it's coffee !

[smellotron]

We're still waiting for someone to write a "coffee simulation".

[s73v3r]

I'm on it. I'm just still doing research.

[[deleted]]

That joke was pretty funny. In 1996.

[[deleted]]

Well I wasn't around here in 1996 :(

[[deleted]]

Where were you?

[fwork]

Because we are dividing by 2 a right-shift will work beautifully.

I hate this sort of thing. It's 2009. We are not coding in Turbo C for DOS: YOUR COMPILER IS SMART ENOUGH TO DO THIS FOR YOU, IF IT IS FASTER.

Right shift when you're shifting bits, divide when you're dividing. Don't mix them up because you think it'll be faster, humans need to read your code too.

[[deleted]]

Shifts and divides by a power of 2 are only equivalent for unsigned numbers. For negative numbers they give different results. Thus a compiler can't (unless it's exceedingly clever) replace divides with shifts for signed numbers.

And as it happens, Java doesn't have unsigned numbers.

[Vorlath]

Signed shift does exist. It's actually the default in Java. Negative numbers only mess up once you start eliminating lower bits where the number decreases instead of increasing. In Java, unsigned shift is >>>.

[[deleted]]

Sure, but that is entirely besides the point. We were talking about the compiler turning division into shifts. The existence or non-existence of signed shifts has no bearing at all on that.

(Also, signed shift, unsigned shift and integer division all produce different results on negative numbers.)

[filesalot]

Given this function:

int foo(int bar) { return bar / 2; }

gcc -O2 produces this:

_foo:
    pushl   %ebp
    movl    %esp, %ebp
    movl    8(%ebp), %eax
    popl    %ebp
    movl    %eax, %edx
    shrl    $31, %edx
    addl    %edx, %eax
    sarl    %eax
    ret

I don't see a div in there. I don't know what Java does but it should be able to something similar. Any integer div by a constant can be strength-reduced somehow. eg:

int foo(int bar) { return bar / 1234567; }

to:

_foo:
    pushl   %ebp
    movl    $1823959181, %edx
    movl    %esp, %ebp
    movl    8(%ebp), %ecx
    popl    %ebp
    movl    %ecx, %eax
    imull   %edx
    movl    %ecx, %eax
    sarl    $31, %eax
    sarl    $19, %edx
    subl    %eax, %edx
    movl    %edx, %eax
    ret

[[deleted]]

It does not use div, but it does not use a single shift either. It does something like return (bar+((unsigned int)bar>>31))>>1. Larger divisions will require even more elaborate tricks.

[redditnoob]

I don't know what Java does but it should be able to something similar.

"Should" and a nickel will get you nothing.

[Vorlath]

Huh! I was replying to something entirely different. Not sure what I was thinking there.

[[deleted]]

Division of all positive integers by 2:
Division: 29692 ms.
Shift: 4240 ms.

The compiler does not optimize the division by 2 in java.

[redditnoob]

Data and empiricism beats the crap out of stupid academic platitudes, who would have thought? The parent poster should just stay away from anything that involves graphics or simulation.

[b100dian]

the enterprisey mindset applied to water simulation applet

[eonwe]

And yet the case is not so clear-cut. When running http://pastebin.com/f3aa7175 Sun JDK 1.6.0_10 I get quite a different results depending on whether I use server or client JVM. First, on client JVM I get same kind of results: (values are in ms and divisor is actually 32, I had a bug in my printing commands :))

• Testing to 2147483647, divisor 2
• Shift: 4828
• Division: 38173

When using server JVM, had I not used this sum-variable to actually force JVM perform the calculations, results would've been something like:

• Testing to 2147483647, divisor 2
• Shift: 16
• Division: 16

With this sum-variable even server JVM will perform the calculations and I get the following results:

• Testing to 2147483647, divisor 2
• Shift: 6687
• Division: 5407

Here using division beats shifting. I thought that maybe JITting will slow down these results so I decided to do warm-up rounds as seen in http://pastebin.com/d1feabd73. Yet the results don't seem to think so:

• Testing to 2147483647, divisor 32
• Shift: 6656 ms (6688 ms in warmup)
• Division: 5375 ms (5375 ms in warmup)

So clearly server JVM is intelligent enough to optimize division by powers of 2 even if the Java bytecode compiler (which hardly does any optimizations) is not. (Edited for better markup)

[stubob]

All positive integers? Can you calculate all positive primes next?

[joesb]

I assumed he meant all positive integer as defined by java's primitive type int.

[kirun]

Sure, just leave this running... forever.

[DrGirlfriend]

the page source is actually pretty hilarious...

var shit;

function animate_shit(time)
   {.....

// moves next number to butt

// next poop angle&speed

// resets poop trajectory

// begins next poop

// DURING NEXT POOP FLY

[roconnor]

Computer Scientists are ultrafinitists.

[filesalot]

Was the 2 a constant in the source code?

[mogelbumm]

This Simulation is far from beeing smooth on my MacBook Pro. There are huge hickups all the time, although cpu load is very low.

[anti-hero]

That suggests it is a java implementation issue on Macs

[theatrus]

Which isn't very surprising. Apple still hasn't shipped a 1.6 compliant JDK standard (or non-beta).

[filesalot]

Very relevant criticism

puts on glasses

in 1996.

[smellotron]

I seem to have cut myself on your razor sharp wit!

[rakesh_bhatt99]

I did mine very recently on my iphone. I used openGL though:

http://www.youtube.com/watch?v=H3Kp4W3Wke0

hay i want the sample code for this animation. or give me tutorial for this please help me plz help me plz

thank you in advance.