So obviously you don't bother to store the object anywhere, you just hammer out the triangles when you generate them, and you don't worry about not re-generating the same points over and over again (to go round and draw at the same time) and you don't worry about linking the triangles at the other end of the circle. Of course you don't, because you don't need to 
Correct, correct and correct :-)
I dont use display lists as its 3 more OGl calls which is too much for me. So yes thats right I dont store the objects but regenerate each iteration. It limits me on how curvy the objects can be (too many points to calculate). In the 4k version, I "wasted" the bytes to create display lists. No I dont worry about joining the end points as they will have the same normal. Again its a performance thing only and in 1k we cant care too much.
Your normals aren't quite on a sphere, but they're damned close, more like an object with 2 circular based cones stuck together on their bases, but who cares because it doesn't matter!
No, they really are on a sphere. Maybe its definition. The normal at any point on a sphere centered at (0,0,0) as you know is just the point itself.
So I centered the object at 0,0,0 (with the y*2-1) and then used the point for the normal. It really is using spherical normals.
And for your rotating plate with the shrinking/growing vases you just vary the range of s or t to make more or less of the object.
lol they are meant to be candlesticks not vases - my wife complained they didnt look like candlesticks either :-). I guess have only 16 co-ordinates is a bit too much of a compromise.
When you make the exe, do you use special options for gcc and a special packer afterwards? Or can ld really produce such tiny (and non-standard!) PE files directly?
It goes...compile the C-> convert to a .com -> compress. It uses the framework from auld
http://in4k.untergrund.net/index.php?title=Aulds_1k_Framework which in turn uses dropper2.0 and apack. Nothing clever here by me, its all done by others.
We used to have a kind of bezier interpolation we used in some of our games which was something like
-a + 9b + 9c -d
where a,b,c,d would be neighbouring points (heights on a height map). The big advantage of using those weights instead of normal bezier ones is
a x 9 = lea eax,[eax+eax*8]
and
-1 + 9 + 9 -1 = 16
so when you divide by 16 to do your final scale it's just
shr eax,4
That made it really fast and really tiny.
I'm in the middle of trying to write tiny bezier triangle patches and that is a very very useful trick. Thanks for sharing it (Karma++)! OK as you shared this I'll share my curve equation for the objects. You'll laugh. Lets say I have 5 points in the object I run t (the upward interpolator) from 0..5 and use the fractional part to interpolate between the two vertices Im currently interested in. Then I square this! Yeah that dumb and simple.
in pseudo code:
interp=fractional(t);
x=lerp(p1x,p2x,t*t);Almost embarressingly simple. Which is very good at 1k :-).
One slightly cool side effect of this technique is we get more detail where the surface is highly curved (we get the same number of vertices generated between each pair of points so if points are closer together, we get more detail in that area). One downside is no continuity across points, meaning if you have the same x value on the surface on any two points, the interpolator returns a straight line. However for the candlesticks this was actually useful.
