In article <471d231d$1@news.povray.org>, 
nic### [at] gmailisthebestcom says...

> >>
> > Sigh.. Your just getting it at all. The ***existing*** SDL assumes that
 ...
> 
> "You really don't understand why the current one is the way it is, do you
?"
> 
Umm. There hasn't been a single post on this subject for some time. And 
yes, I know damn well why its the way it is *now*, its based on DKBTrace 
from ages ago, has maintained compatibility clear back that far (more or 
less) and **never** was designed to be used to do complex animations, 
without external methods to run them. No one ever built in a language 
flexible enough to bypass the need for dozens of external applications, 
to do all the stuff it can't.

What exactly is the point of harping on a few sentences out of dozens of 
things I have posted on this, ***after*** I already admitted, had you 
bothered to read anything other than this post, that my idea was flawed, 
you could still get what I was looking for in a way that isn't too 
dissimilar from what Warp was suggesting instead and that the other 
people had a point about storing the stuff the way I suggested being a 
bad idea? Other than, that is, to be a bigger ass than I made myself 
look with the comment you are quoting?

Besides, we are not discussing why the holy book of POVRay demands that 
all things continue to work as they do, we are talking about what 
changes *may* be useful to make it easier to do things, and having 
better object handling, and a better script system, is a major 
improvement over the mess we have now, where the internals are hard to 
add to, the script language barely qualifies as a script, the import 
features only handle bitmaps and comma deliminated text (which nothing 
in **any** other application that produces text data uses), and where 
we, more often than not, have to rely on some third parties closed 
source application to *partly* convert from A to B, so that we can use a 
plugin for that, also closed source, which hasn't changed since POVRay 
1.0, to *export* the now binary format back into a text format POVRay 
can use, only it can't, since its missing 50% of everything that wasn't 
possible to export to POVRay 1.0, along with things it exported wrong, 
and things that can't be exported at all, in that way, because they 
don't work the same way any more (triangles in a mesh, for example, 
which overlap, so the *current* versions delete as deleterious to the 
object, even though it leaves huge holes in it without them).

The point is to talk about how to improve this, not what reasons there 
are/where for why it works as it does now. Even if I could quote the 
entire code base for the engine layer by rote it wouldn't change the 
basic fact that we need to adjust how some things in it work, if we want 
to be taken seriously, instead of looked at as a bunch of fools that 
still sit in their basement, doing the equivalent of making the first 
8080 based computer play Jingle Bells, by flipping mechanical switches 
to program it.

-- 
void main () {

    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