In article <web.47055ba7bcc3cc02773c9a3e0@news.povray.org>, 
nam### [at] gmailcom says...
> Warp <war### [at] tagpovrayorg> wrote:
> >   A precompiled library alone is useless in C/C++. You need the non-com
piled
> > public interface to use the library.
> 
> That's a problem with C/C++ and their reliance on header files for functi
on
> prototypes AFAIK.  Besides, even then, with documentation about functions
> written in other languages, even in a C/C++ enviroment you can call these
:
> just write the proper header files by prototyping the functions as
> documented.
> 
> Say you write a class in JRuby and bytecompile it.  You can use that clas
s
> from a regular Java problem without worries.
> 
> > It must
> > be usable from POV-Ray directly, using its native scripting language.
> > How are you going to use it without an interface?
> 
> I agree povray *must* have its own scripting language.  And if it's JITte
d,
> only the better.  I was just pointing out that it is possible to interfac
e
> with compiled code given a common binary format, documentation and suppor
t
> from the infrastructure (compilers, linkers, runtime).
> 
Hmm. If I get what you are saying, then I may agree with you. Make the 
POVRay system into a library, which is of a type capable of easily being 
integrated into any other language, while "still" keeping an internal 
language for the scene. In other words, make similar to what it would be 
if you wanted to use IE using COM:

a = createobject("explorer.application")
if typename(a) = "explorer" then
  a.load("c:\Mydocs\fred.html")
end if

The language you use to tie the engine into shouldn't care what the 
engine was written in, as long as the library is one that can be easily 
linked/instanced/whatever. For the current version this is pointless, 
since there are issues with having to have it announce its copyrights, 
etc. (which I suggested one possible solution to, at least under 
windows), but 4.0 is supposed to be a lot nicer about that sort of 
thing, allowing it to be more closely integrated.

This however says *nothing* about what the SDL itself should be doing, 
nor about how anything, beyond the functions/events supported in that 
interface, allow for integration of plugins or any other elements that 
are "specific" to the engine, and thus "not" part of the application its 
been embedded into.

-- 
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