|
|
clipka wrote:
> Chambers <ben### [at] pacificwebguycom> wrote:
>>> So, um... with 1) to 3) done to the SDL, what exactly would *remain* of the
>>> existing one?
>> The imperative nature, plus the current syntax for object (and
>> texture/pattern/et al) creation.
>>
>> Ie, we DON'T need
>>
>> new SDL.Object.Sphere {
>> Radius: 4.0f;
>> Center: new SDL.Unit.Vector3(4.5f,1.5,3.0f);
>> Texture: new SDL.Pattern.Texture {
>> Pigment: new SDL.Pattern.Pigment {
>> Pattern: SDL.Pattern.Predefined.Solid;
>> Color: new SDL.Unit.Vector3(1.0f,0.5f,0.0f);
>> }
>> }
>> }
>
> I take it as understood that we do *NOT* want any such syntax in a POV 4 SDL.
> Yes, indeed, I'd rather stick to the current SDL than use such a monster.
>
> That's why I kept lamenting about the shortcomings of Lua and the like in this
> particular respect.
>
>
lol
Was thinking about this a bit. One could get the same syntax as now,
mostly, or almost, and still get "access" the sorts of things above, but
it requires some compromising on what is possible, and how. As well as
maybe some minor changes to existing code. Here is how:
You have explicit or implicit declaration of objects by name. Explicit
would be something like:
declare my_object as sphere;
declare my_object2 as box;
//Set attributes.
...
Implicit would be something like:
parse(
sphere {...}
box {...}
)
In other words, the "existing" SDL get parsed exactly as it does now,
and all you have to do is either enclose the code in a "parse" command,
or use something like 'parse_file("existing.pov");'. From the standpoint
of people using the SDL that already exists, the result is entirely
transparent.
Now, in the '//Set attributes' part of the first example, you get
basically two things:
sphere.parse_table(list my_table);
and attributes like:
sphere.translation
sphere.rotation
sphere.scale
sphere.{everything else}
The parse_table is the list of things "done to" the object, is
indexable, and you can add to it, and it parses "existing" SDL commands.
The . parts are the "current" result of the matrix operations that took
place in that table. One could have command to "re-run" the table, add
to it, delete things from it, etc. And, from the perspective of
something "coding" SDL, again, functions would exist to "add to" that
table, as though they where using the existing SDL.
This means a tiny bit more overhead in the parse stage, since it has to
build the tables for each object, and track them. But, it also means
that the existing SDL remains basically the same in construct, even if
its used a tad differently, you can nearly add to and change things the
same way, **but** the actual "language" level can work more like a true
program, without the complicated and confusing macro system now used to
do most things, and with animation and other things handled, optionally
as part of the "code" executing, and not via some reparse of the SDL.
Similar tricks would likely be possible for handling textures and other
things. In effect, you get access to the SDL level if you need it,
otherwise, you declare all your "static" objects, either SDL control any
animation, or when possible, do that via the "language" level of the
code. And, there is no conflict between what was **basically** a markup
language, and what is program. Similar to how HTML is "clearly"
distinct, for the same reason, from PHP, Java, or anything else that is
used to "change it" dynamically. In a lot of ways, what little looping
other other functions we do have in the SDL are shoehorned on. That
really isn't going to change, unless you divorce the SDL *from* the flow
control somehow imho.
--
void main () {
if version = "Vista" {
call slow_by_half();
call DRM_everything();
}
call functional_code();
}
else
call crash_windows();
}
<A HREF='http://www.daz3d.com/index.php?refid=16130551'>Get 3D Models,
3D Content, and 3D Software at DAZ3D!</A>
Post a reply to this message
|
|