![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Gleb wrote:
>
> Do you really mean that storage device drivers are more complex in access
> than display ones?
>
This does not have anything to do with device drivers.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Feb. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christoph Hormann <chr### [at] gmx de> wrote:
> Portability is the main concern. As soon as writing binaries includes
> more than just writing single bytes the behaviour will be strongly
> platform dependant.
But writing bytes is all one needs.
--
#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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Christoph Hormann" <chr### [at] gmx de> wrote in message
news:3C7E50DA.A9B7F6F4@gmx.de...
>
>
> Gleb wrote:
> >
> > Do you really mean that storage device drivers are more complex in
access
> > than display ones?
> >
>
> This does not have anything to do with device drivers.
Same question: :is graphic portability more complex thing? Sorry, if the
question looks stupid and/or has well-known
answer. I just want to get the real reason.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Gleb wrote:
>
> > This does not have anything to do with device drivers.
>
> Same question: :is graphic portability more complex thing? Sorry, if the
> question looks stupid and/or has well-known
>
> answer. I just want to get the real reason.
There is no graphics output in Povray, only some versions call API
functions of the OS to display the render in the platform specific code.
This has nothing to do with the rendering program itself.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Feb. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Christoph Hormann" <chr### [at] gmx de> wrote in message
news:3C7E58B5.F6B0933C@gmx.de...
> There is no graphics output in Povray, only some versions call API
> functions of the OS to display the render in the platform specific code.
> This has nothing to do with the rendering program itself.
>
This is exactly what I mean: there is no graphics in Povray, but there is
somehow binary images output
and and input, isn't it?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Gleb wrote:
>
> > There is no graphics output in Povray, only some versions call API
> > functions of the OS to display the render in the platform specific code.
> > This has nothing to do with the rendering program itself.
> >
> This is exactly what I mean: there is no graphics in Povray, but there is
> somehow binary images output
> and and input, isn't it?
Yes, but this is platform independant due to precautions in the image file
format definitions. Simply writing your floats and vectors to a file as
binary with some IO functions would be different.
Christoph
--
POV-Ray tutorials, IsoWood include,
TransSkin and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Feb. 2002 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
In article <3c7e5652@news.povray.org>, "Gleb" <gk1### [at] soton ac uk> wrote:
> Same question: :is graphic portability more complex thing? Sorry, if
> the question looks stupid and/or has well-known answer. I just want
> to get the real reason.
Graphics are completely platform dependant...the only standard interface
is for unstyled text. There is no standard way of drawing a pixel on the
screen, these facilities are provided by the operating system.
There *are* standard interfaces for writing binary files, but there is
no guarantee that a binary file will be readable on platforms other than
the one it was created on. The only way to guarantee that is to write
things byte by byte, so the exact order and format of the data is known.
The POV language isn't really capable of handling this right now...it'd
probably require reworking the file I/O syntax, and because of the
simplifications required by the POV language, it probably wouldn't be
useful for interacting with other programs.
--
Christopher James Huff <chr### [at] mac com>
POV-Ray TAG e-mail: chr### [at] tag povray org
TAG web site: http://tag.povray.org/
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Christoph Hormann" <chr### [at] gmx de> wrote in message
news:3C7E6052.BB0F78AB@gmx.de...
>
>
> Gleb wrote:
> >
> > > There is no graphics output in Povray, only some versions call API
> > > functions of the OS to display the render in the platform specific
code.
> > > This has nothing to do with the rendering program itself.
> > >
> > This is exactly what I mean: there is no graphics in Povray, but there
is
> > somehow binary images output
> > and and input, isn't it?
>
> Yes, but this is platform independant due to precautions in the image file
> format definitions. Simply writing your floats and vectors to a file as
> binary with some IO functions would be different.
>
OK, thank you, the reason is much clear now. Format of floats is really
platform dependent,
but byte strings i/o would be enough in this case, and it is almost there
already.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Christoph Hormann" <chr### [at] gmx de> wrote in message
news:3C7E6052.BB0F78AB@gmx.de...
<snip>
Am I right that this issue is about limiting the portability of scripts, rather
than the pov-application?
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Tom Melly" <tom### [at] tomandlu co uk> wrote in message
news:3c7e640c@news.povray.org...
> Am I right that this issue is about limiting the portability of scripts,
rather
> than the pov-application?
or, more accurately, the portability of the binary output of scripts...
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |