My latest patch can be considered as tutorial about adding new types of spline
to POV sources and about adding new tokens recognition. It is available at:

http://abx.art.pl/pov/patches/sorspline.php

ABX

Post a reply to this message

ABX wrote:

> My latest patch can be considered as tutorial about adding new types of
> spline to POV sources and about adding new tokens recognition. It is
> available at:
> 
> http://abx.art.pl/pov/patches/sorspline.php
> 
> ABX

Thanks for that, it gave me a useful insight into POV's internals.
It also made me wonder if in some future version of POV the parser could be 
data driven from an XML file so that it was extensible without having to 
recompile. The XML file would supply the token information and a reference 
to a loadable object or plug-in.
I know this can't work for all things you may need to patch, but for adding 
new geometry, functions and patterns etc. it should work.
Such a method would let everyone try out new ideas immediately so that they 
were well tested and could be more rapidly incorporated into the POV source 
code (for speed?) at the next major release.
 
-- 
Your connection failed because: short leg on process table

Post a reply to this message

In article <172### [at] 3-enet>, Daniel Matthews <dan#@3-e.net> 
wrote:

> Thanks for that, it gave me a useful insight into POV's internals.
> It also made me wonder if in some future version of POV the parser could be 
> data driven from an XML file so that it was extensible without having to 
> recompile. The XML file would supply the token information and a reference 
> to a loadable object or plug-in.

This has the same problem as any other plug-in idea, it is platform 
dependant. You can't dynamically load code in a platform independant 
way, and the plugins would only work for the platform they are compiled 
on. If you could, you wouldn't need the XML representation of the syntax.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:

> In article <172### [at] 3-enet>, Daniel Matthews <dan#@3-e.net>
> wrote:
> 
>> Thanks for that, it gave me a useful insight into POV's internals.
>> It also made me wonder if in some future version of POV the parser could
>> be data driven from an XML file so that it was extensible without having
>> to recompile. The XML file would supply the token information and a
>> reference to a loadable object or plug-in.
> 
> This has the same problem as any other plug-in idea, it is platform
> dependant. You can't dynamically load code in a platform independant
> way, and the plugins would only work for the platform they are compiled
> on. If you could, you wouldn't need the XML representation of the syntax.
> 
Oh, I see, but how does some Linux multimedia software such as mplayer uses 
Windows codecs to decode and encode Video and Audio files?

-- 
Your connection failed because: Mail server hit by UniSpammer.

Post a reply to this message

Daniel Matthews <dan#@3-e.net> wrote:
> Oh, I see, but how does some Linux multimedia software such as mplayer uses 
> Windows codecs to decode and encode Video and Audio files?

  Emulation. It uses a piece if WINE in order to do it.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

In article <119### [at] 3-enet>, Daniel Matthews <dan#@3-e.net> 
wrote:

> Oh, I see, but how does some Linux multimedia software such as mplayer uses 
> Windows codecs to decode and encode Video and Audio files?

The processor and machine are the same, so they just have to reimplement 
some stuff to run the code under Linux. It is impossible on Linux 
distributions for machines that can't run Windows, such as LinuxPPC 
(making an emulator for an entirely different architecture is not a 
simple task, and the result will be pretty slow). For POV, you would 
have to write an emulator for every supported platform to emulate every 
other supported platform, and that still doesn't work for plugins that 
use OS specific API's.

And finally, that is Linux software running under Linux. You can't just 
compile it under Mac or Windows. There is no cross-platform way to 
dynamically load plugins like that, each platform would have to 
implement its own version.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
>In article <119### [at] 3-enet>, Daniel Matthews <dan#[at]3-e.net>
>wrote:
>
>And finally, that is Linux software running under Linux. You can't just
>compile it under Mac or Windows. There is no cross-platform way to
>dynamically load plugins like that, each platform would have to
>implement its own version.

But once its done, then its done, if fact its already been done as dlcompat,
I think the licence is MIT/BSD.

It seems a shame to deny povray users useful extra functionality just to
avoid a little bit of one off effort. I've actually got the source for a
dlfcn 'port' for BeOS open now, under a MIT/BSD licence, its under 300
lines of well spaced out, well commented code. The fink project has
dlcomplat for OSX, it can also be found for open darwin, I would be
suprised in you couldn't find it somewhere under its orginal licence.

That just leaves the thorny subject of compiling the plugins for the
appropriate plaforms, which is only  a problem for closed source plugins,
for open source ones its just requires one person who wants the plugin or
that plaform to create a binary distribution.


Dave

Post a reply to this message