Am 07.04.2010 12:00, schrieb Le_Forgeron:

>> The policy is to avoid introducing more keywords where sensible, to
>> avoid unnecessarily breaking legacy scenes that happen to use the same
>> word for a variable.
>
> Nah, wrong solution to a wrong issue.

Not my idea, by the way.

> Current editors made it easy to refactor a variable.

Not as easy as it /could/ be (as Microsoft has shown with its C# 
development environment).

> We might need some java-coding-policy (about Capitalising/small char) to
> avoid such sillyness in the futur... How do you want to extend the SDL
> if you are limited to existing keywords... twisting the syntax is a very
> bad idea, IMHO.

Note that the policy is not "avoid new keywords at all costs", but 
"avoid new keywords where sensible"; Official recommendation is that 
user variables should begin with uppercase letters, while new keywords 
are guaranteed to always be all lowercase, which theoretically should be 
enough to avoid breaking any legacy scenes. But why risk breaking 
noncompliant scenes when there's no real need to?

>>> repeat is currently used in warp, so it might be best to avoid it.
>>
>> Repeat is currently used in warp for pretty much the same purpose as
>> proposed (at least for the 1D repeat): Specifying a vector and distance
>> for repetition (though it has some limitations with warp). So why call
>> the same thing differently?
>>
>>> And it should be a name, which "repeat" is not.
>>
>> Is "translate" or "rotate" a name?
>
> they are not objects, but update of objects.
> Don't push it too far on bad faith, please.

Did you actually /read/ my proposed syntax? In that proposal, "repeat" 
would be nothing more than a /modification/ of the existing "union".

>>> I'm not sure the transformation from 3D filling to cubic would be
>>> obvious (and you might need holes on some places, and it might be better
>>> to code it once for each filling rather than applying specific
>>> transforms all the time)
>>
>> I guess macros should be enough to fill that gap.
>
> I believe it would be quicker and more effective to cover the patterns
> in the C++ code rather than with a transform.

As there are literally infinitely many regular space tilings, you can't 
cover them all natively, and a generic variant will be needed anyway. So 
to keep both code complexity and number of keywords low, I'd be more in 
for making it the only variant supported natively. (Note that low code 
complexity helps keep things speedy, too, by allowing to keep as much of 
the code in CPU cache as possible.)

> I'm still wondering about the number of actual space filling pattern (3
> so far in 3D: 1 with cube, 2 with spheres, and 2 in 2D: square, hexagon)
> Any others you or others know of ?

You can't fill 3D space with spheres - it would leave gaps (unless you 
allow for fractal filling).

2D space can be filled with either squares, regular hexagons, regular 
triangles, or any sheared variation thereof. With tilings derived from 
squares or regular triangles, you also have the option to arrange the 
tiles in rows which are displaced against one another (think classic 
brick tiling).

But you can also tile 2D space with a combination of octagons and 
squares, or a combination of hexagons, squares and triangles. Or even 
trapezoids.

All these tilings have one thing in common: By defining your tiles 
differently, you can map all of them to sheared square tiling.

In 3D space tiling, you have quite a number of options, too; octagons 
and tetrahedrons go together like a charm, for instance.

Again, by suitable re-definition of your tiles, you can map all of them 
to sheared cubic tiling.

Post a reply to this message