 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fa3ien nous apporta ses lumieres en ce 2007/10/04 11:29:
> Alain a écrit :
>
>> You must make sure that the new, revamped SDL remain compatible with
>> the actual SDL, and remain capable to render existing scenes.
>
> That will be a big issue.
>
> Personally, I think that, while it might be possible to keep a good
> amount of compatibility, 100% backwards compatibility shouldn't block
> POV-Ray's evolution. Some things will have to be broken, for the best.
>
> I think (but might be wrong) that writing some kind of converter, to take
> care of what's been broken, should be preferred instead of making an
> half-baked
> SDL for the sake of compatibility.
>
> Compromises...
>
> Fabien.
In a new SDL, you won't be able to maintain 100% backward compatibility.
One possible thing that may be done is to create some external scene converter
to recompose some droped features to the new features set, but that can be
almost impossible in several cases. Ever tried to convert the droped "halo"
feature to something else?
--
Alain
-------------------------------------------------
'Every man has his price. Mine is $3.95.'
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> A library is not the same as a language. Except perhaps in the Lisp
> world... :)
Aaaah, the beauty of LISP.
I thought of proposing LISP as the new POV SDL language, but
I'm too young to die.
(for those who wonders, there's no difference between data and
functions, in LISP)
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain a écrit :
> I don't think that .NET works on anything BUT Windows 2000, XP and
> Vista. Visual Basic is a proprietary Microsoft implementation of Basic,
> and only run on a Windows platform. C# comes from where? Is it from
> Microsoft?
I think that .NET is just to been seen as an *example* of such
interfacing concept, not as the way to go for POV-Ray.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain a écrit :
> In a new SDL, you won't be able to maintain 100% backward compatibility.
Yep.
> One possible thing that may be done is to create some external scene
> converter to recompose some droped features to the new features set, but
> that can be almost impossible in several cases. Ever tried to convert
> the droped "halo" feature to something else?
If the converter manages to do it right in, say, 95% of cases, won't it
already be good enough ? That's a trade-off I would accept readily, in
exchange of more speed and flexibility.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <ele### [at] netscape net> wrote:
> I don't think that .NET works on anything BUT Windows 2000, XP and Vista. Visual
> Basic is a proprietary Microsoft implementation of Basic, and only run on a
> Windows platform. C# comes from where? Is it from Microsoft?
it was just an example. But anyway, yes, you can get .NET to run under
Linux via mono. Of course, be sure to get yourself patent coverage from
the lame Novell/M$ deal... :P
I was just pointing out to Warp that once you get a common binary
infrastructure and get your code compiled to it, documentation is all you
need to call functions written in other languages: name of the function,
arguments, argument types and returned values. It's how you are able to
call C/C++ routines from, say, a Delphi program: in the end it's just
binary routines calling other native binary routines.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I was just pointing out to Warp that once you get a common binary
> infrastructure and get your code compiled to it, documentation is all you
> need to call functions written in other languages: name of the function,
> arguments, argument types and returned values. It's how you are able to
> call C/C++ routines from, say, a Delphi program: in the end it's just
> binary routines calling other native binary routines.
COM is a binary interface too, it's also from Microsoft but I doubt
there is any patent hell about it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Jeff Houck <jho### [at] northrimnet> wrote:
>> Personally, I like the SDL just the way it is... Simple, mostly
>> predictable and easy to use...
>
> ... very limited and very slow.
>
> Also, from core developement point of view, it's quite horrible.
> For example, why do you think there's no eval() function in POV-Ray?
> That is, a function which takes a string and evaluates this string
> as if it was SDL (similar to how an #include "file" would do, but
> with a string instead)?
> Answer: Because the parser is a mess, full of kludges, burdened with
> backwards-compatibility. For example, #macros are handy and powerful...
> too powerful for their own good. #macros are one of the major reasons
> why there's no eval() function in POV-Ray.
>
> Adding new features to the parser is a real pain sometimes (I have
> recent personal experience), mainly due to how the SDL works and is
> parsed. For example, being able to insert a #declare almost anywhere
> may feel handy, but is a nightmare to parse properly.
> One thing I recently tried to achieve was string concatenation using
> the + operator (as an alternative to the concat function). In the end
> it seems that this would be really, really difficult to implement in
> the current parser due to how interpreting # commands (which can appear
> almost everywhere) works.
>
I was unaware that the parser was in such sad shape... I'm more of an
end-user than developer in this case...
I've been trying to follow both of the SDL threads and one thing has
occurred to me, why not expose the core interface API to a language like
Python? It's cross-platform, object oriented and has been used
successfully as a scripting interface to a number of projects.
Currently, we're using Python-Ogre to prototype a game framework and the
implementation works great! Python has a number of programming tools
available across a number of OS platforms, AND, it's not a hard language
to learn or master...
Just a thought...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
nemesis <nam### [at] gmailcom> wrote:
> It's not different from calling precompiled native code from any language,
> including C/C++: the linker is the infrastructure here providing the
> glueing together of binaries compiled from different languages into the
> same native interface.
A precompiled library alone is useless in C/C++. You need the non-compiled
public interface to use the library.
That's exactly the problem: If you create a POV-Ray library using
language X, it must be usable without the need for the user to have
the developement environment necessary to write in language X. It must
be usable from POV-Ray directly, using its native scripting language.
How are you going to use it without an interface?
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jeff Houck <jho### [at] northrimnet> wrote:
> I've been trying to follow both of the SDL threads and one thing has
> occurred to me, why not expose the core interface API to a language like
> Python?
Changing radically the scripting language is not going to be well received.
Personally I dislike python in particular because of its enforced
whitespace interpretation.
--
- Warp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Jeff Houck <jho### [at] northrimnet> wrote:
>> I've been trying to follow both of the SDL threads and one thing has
>> occurred to me, why not expose the core interface API to a language like
>> Python?
>
> Changing radically the scripting language is not going to be well received.
Well, that certainly could be an issue though I don't see how it can be
avoided to some extent. It's all speculation I guess...
On the other hand, I could code up an "unofficial" Python binding
anyway... Just need the source and a little time...
>
> Personally I dislike python in particular because of its enforced
> whitespace interpretation.
That's one of the things I like... to each his own they say.... :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
