Author here. The water effect is a simple 2D heightfield simulation, which is explained pretty well at http://www.matthiasmueller.info/talks/GDC2008.pdf. It essentially just moves each vertex toward the average height of its neighbors, which turns out to propagate waves that look like water ripples.
The caustics are also pretty simple. Basically you take your heightfield mesh that represents the water surface and project each vertex independently along the ray refracted from the light through that vertex (using the vertex normal) and onto the pool floor. So you now have a mesh that is completely on the pool floor and contains lots of tiny triangles. To render caustics, just make triangles that got smaller brighter and ones that got bigger dimmer. I think I used the ratio of the projected area to the original resting area.
The reflection and refraction raytracing is all hard-coded for the geometry in the scene, which makes it really easy. It's just a simple sphere and box intersection test. The "ambient occlusion" is done by making parts of the objects darker when they get near each other.
State of the art for real-time water uses a full 3D volumetric representation for the water like in this paper: http://www.matthiasmueller.info/publications/tallcells.pdf. This lets you get waves that can fold over themselves like real waves. I haven't seen any other realtime methods that have caustics as good as the ones in my demo though.
> It essentially just moves each vertex toward the average height of its neighbors, which turns out to propagate waves that look like water ripples.
If you look at the equations that govern the liquid surface, the assumptions that this model is based on are not that bad. Reality is a bit more complex, but the average-of-neighbors seems like a good start. Pretty simple too, which is always good computationally.
> The reflection and refraction raytracing is all hard-coded for the geometry in the scene, which makes it really easy.
Which reminds me...
Back in the days of 386 CPUs, I did a real-time 3D ray-tracer that drew a few spheres rotating around each other, with a fixed light source, and correct illumination depending on incidence angle at any point on the spheres. All on a 30 MHz 386 CPU, nothing pre-rendered, no assembly code, no GPU, running at high frame rate. Bricks where shat when people saw it.
The reality was that the math was highly optimized for that specific scene. I massaged the equations until I worked out of them all the expensive functions. No sin() or cos(). I think the worst thing I had was a sqrt(), and even that was used sparingly.
> The "ambient occlusion" is done by making parts of the objects darker when they get near each other.
You're basically modelling Le Sage's theory of gravitation, with surface illumination representing "pressure" from the "corpuscles".
I implemented a basic water simulation a very long time ago. The water was approximated using a matrix of vertices where each vertex behaved like a spring and affected its neighboring vertices. So for example clicking a spot in the water would pull the closest vertex down and it would spring back creating a domino affect with its neighbors, their neighbors' neighbors, etc. It looks like this is using a similar technique which is why you occasionally see those steep "spikes".
This is cool. Could somebody please explain how this works? From what I can currently guess, the .midi image encoding with the 2D array of color values, when changed to an .com executable becomes assembly code that generates graphics? Thanks.
Initially is a 2d array but when saved without a image header to give it width and height (and other meta data) it becomes just an array of bytes. A color is encoded in 3 bytes, so with each pixel he can write one, two or three opcodes. If you google opcode tables you'll find plenty of examples of how assembly instructions are encoded in bytes.
For example (this is 16 bit but for the sake of demonstration) byte A1 (10100001) means ADD AX, BX. 101(add)00(ax)001(bx).
And even a cooler one with windows exe description (not DOS .com as he used) http://i.imgur.com/tnUca.jpg Look at the right side of the image where it sais x86 Assembly where it colors and explains each byte. His .com was only that part since .com didn't need headers and imports and it was just code.
I know that Microserfs is a classic, but when I read it yesterday, it was strangely relatable and realistic, yet so different from the way our industry depicts itself today.
Nice looking game... but, I can jump and move about with the arrow keys, but pass straight through diamonds (floating in the air), and can't drill through the rock. I tried other keys on the keyboard, but nothing happens. How should I be playing?
