So in 1996 and 1997 I wrote a 3D library called Plush. Here is a screenshot from then:

It was written in C, it tried to be very portable (reading through it now, I'd say almost to a fault -- kinda annoying ;). There were some nifty things about it:

• 256 color output with adaptive palette creation and management
• multiple light sources
• piecewise linear perspective corrected texture mapping
• Gouraud shading with color ramps that let you do fakePhong
• optional Z-buffering
• environment mapping
• object hierarchies
• frustum clipping
• cameras
• splines
• matrix functions
• primitive generation
• very basic translucency

The code itself wasn't too bad, some stuff that I had spent ages tweaking and getting to run smoothly would surely be reusable.

So in about 8 hours of work I transformed it into Plush2, which is similar to the above, except simplified in C++, renders to 32 bit per pixel output, integrates with our LICE compositing engine, and supports the following new features:

• 24 bit color output
• multiple COLORED light sources
• Texture mapping (piecewise linear perspective corrected) with optional BILINEAR filtering and support for any sized texture, support for texture transparency.
• Colored Gouraud shading
• Z-buffering
• True surface transparency support
• Multitexture support (one or both textures can be used as environment maps)
• Full control over how pixels are combined at render -- add, mulitply are supported replace, all with alpha control.
• No limits on number of light sources, triangles, etc.

Yes yes I know 3D stuff has all been done a ton, just thought it was interesting bringing things back from the dead to see what would be reusable. Now I'm going to go hug my 2.4ghz multicore processor.

This will be a part of the next WDL release, in case anybody cares, ha ha. It does compile down to pretty small (though not small enough to go making a 4k demo with it)

So while playing with some code to model a resonating spring (F=-k*pos), I discovered that the model I was using produced a very good sine wave approximation. This isn't normally something terribly interesting, as you can approximate sine/cosines very easily, but it was actually quite low complexity -- an iterative approximation with only 2 multiplies and 3 adds per sample. It can also generate the cos() (well, a 90 degree shifted signal) for each point for just one additional multiply.

The error is pretty low for the first few cycles, though after a bit it does drift in relation to the correct wave. I'm not going to spend too much more time on this, but if anybody wants to see if there's some way to correct it, go for it (it may just be rounding error, though, of course).

Here is the code:

// setup:
double cos_sc = PI/period_samples; // PI/n for a period of n
double pos=0; // actually sin(initial_state), 1 for cos(), 0 for sin()
double vel=1/cos_sc; // actually cos(initial_state)/cos_sc, 0 for cos(),1/cos_sc for sin()
double tmp = cos_sc*cos_sc;
double tmp2 = 1.0/(1.0+tmp);
double mul1 = (1.0-tmp)*tmp2;
double mul2 = tmp*2.0*tmp2;

// per-sample calculation
double output_value=pos;
// double cosine_output = vel*cos_sc;


// iterate to next sample
double newpos = pos*mul1 + vel*mul2;
vel -= (pos+newpos);
pos = newpos;

Another tag, yay

Time to request a hearing, as I do not have any "graffiti" but they seem to think I do....

The smiley face was me...

We'll see if this works-- both with the kids and with the city...