Almost completing my first game (down to the last 10% crunch!). But I've been going over what I would like my next game to be. To be very brief, characters will be swimming on top of water and I would like a decent, dynamic, water effect (2D).

I've read a few articles on this, including the one on gamedev.net!
http://www.gamedev.net/reference/articles/article718.asp

Being that the area of water will be almost the size of the entire playing field, a nested for-loop will take up a lot of processing time. Should I have a seperate Thread that just continually processes the ripples in water?

In ancient times stuff like that used to be done by manipulating the colour palette instead of re-drawing the screen. You'd have a range of positions in the palette reserved for the thing that is to ripple or rotate through colours, and change those colours globally across the entire screen simply by changing the values in those slots of the palette. Are such means still viable with modern graphics systems or hopelessly out of date?

Quote:Original post by markm
In ancient times stuff like that used to be done by manipulating the colour palette instead of re-drawing the screen. You'd have a range of positions in the palette reserved for the thing that is to ripple or rotate through colours, and change those colours globally across the entire screen simply by changing the values in those slots of the palette. Are such means still viable with modern graphics systems or hopelessly out of date?

Indexed graphics modes haven't been used for quite a long time. =)

At the op:
Have you tried implementing your technique? Maybe it turns out faster than you think. Sounds to me like a case of premature optimization.

Quote:Original post by Madhed
Have you tried implementing your technique?

No, just brainstorming. But I can't imagine a "pool" that takes up about 550x650 pixels (357,500 pixels squared) to be calculated using a nested for-loop for every pixel & then using another nested for-loop to draw every pixel. That would be apprx. 715,000 iterations per frame on just water!

This might turn out to be an afternoon project to compare the maximum fps on my 'puter.

Btw, the 'pool' effect is a top-down view.

What are you using to draw the graphics? OpenGL or software rendering?

I could imagine a somewhat simpler effect: using transparent, growing sprites of water ripples that are inserted at the character's location when moving.

Quote:Original post by Madhed
...OpenGL or software rendering?

Software rendering.

Quote:Original post by Madhed
I could imagine a somewhat simpler effect: using transparent, growing sprites of water ripples that are inserted at the character's location when moving.

I thought of that too, but I'd really much prefer the look & feel of this:
http://www.neilwallis.com/java/water.html
There is an interactive applet there.

My main goal...you're actually on a river. The water is almost crystal clear so you can still see river-rocks on the bottom (as well as fish, etc) below the surface. If I had the effect (like you see in the applet) to a top view game, I think it'll be pretty bangarang.

Well he didn't have too much trouble with that applet.

I don't recommend you touch threading until after you've implemented it without.

That's kinda duh, but, your Java applet probably won't be running on many too slow systems.

Now it is the case that if you pump it up to full screen, 1440x900 or something, the CPU workload's gonna go up fast...

But if that's your goal, the only rational way is to implement it on the GPU as a pixel shader.

You can thread it, and if someone happens to have an 8 core system, it'll be really cool, but there is also a GPU in your computer which is designed to do just this, fast, at a fraction of the cost.

I recommend you first try it at full res, and if it isn't good, process the water at a reduced resolution, in a BufferedImage backbuffer, then use a scaled Graphics.drawImage(...) call.

On the Oracle JRE on Windows, this will be hardware accelerated, and will in effect dump part of the work onto the GPU without having to actually do any pixel shaders, at the expense of some shininess.

Try it first in the EDT as part of the regular paint operation, and if that's not fast enough, you just might have to make some kind of value judgement.

Quote:I recommend you first try it at full res, and if it isn't good, process the water at a reduced resolution, in a BufferedImage backbuffer, then use a scaled Graphics.drawImage(...) call.

So if I'm understanding this correctly:
1. Reduce the buffered image
2. Calculate water ripples
3. Expand the image back to fill the pool dimensions

If I'm not mistaken this would create a more pixelated backdrop?

Let me clarify.

1) Do a naive implementation; just do a full frame effect, by the book, no optimizations. Correctly. See what it does.

It very well might work fine. It worked in the applet you just linked here, and for the framebuffer size you're talking about, it doesn't sound like a computer made in the past 10 years will break a sweat.

But yes, that's my suggestion if indeed it needs to be sped up.

It will indeed make it more pixelated, but if you do it half vertical & horizontal resolution, it cuts he CPU's workload by 75% and on the Oracle JRE will dump the upscaling work onto the GPU. All relevant consumer-grade graphics chips will handle this.

It's a very simple quality vs. speed tradeoff.

Threading also works, but makes some assumptions about what you're running it on that I don't think are good assumptions.

It assumes that the person has a very high-end computer in the first place which can actually run threads concurrently.

Most of your "this is too slow" complaints are going to come from lower-end computers.

Systems consisting of many slow cores are not a common thing on the desktop or laptops, unless you count early generation duallies.

But if your new computer can't do it on a single thread, many early-gen duallies might not be able to even when threading.

If you are in fact targetting the beastier "gamer" rigs, you really need to switch to a system that gives you access to the GPU. The hi-end systems actually accomplish the graphics by using application specific co-processors (GPUs!) to do graphics grunt-work.