 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
any idea how to add to string or write into file chr(0) ?
it is the only limit to write binary files :-(
(treat it as feature request if it is not possible)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Włodzimierz ABX Skiba" wrote:
>
> any idea how to add to string or write into file chr(0) ?
> it is the only limit to write binary files :-(
>
> (treat it as feature request if it is not possible)
>
> ABX
"\0" writes the null character.
--
signature{
"Grey Knight" contact{ email "gre### [at] yahoo com" }
site_of_week{ url "http://digilander.iol.it/jrgpov" }
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <5m0s7usm1t32sajav9eou78e4tbfr9f21v@4ax.com> , W„odzimierz ABX
Skiba <abx### [at] babilonorg> wrote:
> any idea how to add to string or write into file chr(0) ?
> it is the only limit to write binary files :-(
As you might know, you are not supposed to be able to write binary files...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 28 Feb 2002 12:14:05 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> > any idea how to add to string or write into file chr(0) ?
> > it is the only limit to write binary files :-(
>
> As you might know, you are not supposed to be able to write binary files...
Yes, I suppose there wasn't such idea in design of POV. Anyway I wan't try to
write DF3 file and use it within the same parse. It's just the 3d version of
image function and I found it useful in my current task.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 28 Feb 2002 11:10:41 +0000, Grey Knight <s16### [at] namtarqubacuk>
wrote:
> "\0" writes the null character.
#write(DF3,"\0" <----ERROR
Parse Error: Illegal escape sequence in string.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oh dear. What exactly was \0 put in for if you can't write it to a file?
It's not like it makes any sense to put it in a text string...
"Włodzimierz ABX Skiba" wrote:
>
> On Thu, 28 Feb 2002 11:10:41 +0000, Grey Knight <s16### [at] namtarqubacuk>
> wrote:
> > "\0" writes the null character.
>
> #write(DF3,"\0" <----ERROR
> Parse Error: Illegal escape sequence in string.
>
> ABX
--
signature{
"Grey Knight" contact{ email "gre### [at] yahoocom" }
site_of_week{ url "http://digilander.iol.it/jrgpov" }
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 28 Feb 2002 12:03:09 +0000, Grey Knight <s16### [at] namtarqubacuk>
wrote:
> Oh dear. What exactly was \0 put in for if you can't write it to a file?
> It's not like it makes any sense to put it in a text string...
From documentation: "Depending on what platform you are using, they may not be
fully supported for console output. However they will appear in any text file
if you re-direct a stream to a file."
When I tried it with #warning it produced the same error message.
So, does it means bug ? Should I repost it into beta-test ?
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <9h7s7uovnvah261sdpgrhgoar29fd73o4m@4ax.com> , W„odzimierz ABX
Skiba <abx### [at] babilonorg> wrote:
> From documentation: "Depending on what platform you are using, they may not be
> fully supported for console output. However they will appear in any text file
> if you re-direct a stream to a file."
>
> When I tried it with #warning it produced the same error message.
>
> So, does it means bug ? Should I repost it into beta-test ?
Well, whatever the documentation wants to say with this, a "\0" is converted
to a backslash in at least 3.1 and 3.5. It is obvious that "\0" cannot be
supported because C strings use it as terminator, so it should probably be
removed from the documentation altogether.
BTW, note that the quote you provided only talks about output streams, not the
file #write directive!
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 28 Feb 2002 13:28:42 +0100, "Thorsten Froehlich" <tho### [at] trfde>
wrote:
> Well, whatever the documentation wants to say with this, a "\0" is converted
> to a backslash in at least 3.1 and 3.5. It is obvious that "\0" cannot be
> supported because C strings use it as terminator, so it should probably be
> removed from the documentation altogether.
Worse luck!
> BTW, note that the quote you provided only talks about output streams, not the
> file #write directive!
Yes, I noticed. But of course I tested it with #warning before quoting.
The solution I choosed is to limit range to 1-255. I hope it will be
sufficient.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <tho### [at] trfde> wrote in message
news:3c7e10ff@news.povray.org...
> As you might know, you are not supposed to be able to write binary
files...
By the way, why there is such a limitation? It should be useful.
Gleb
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 28 Feb 2002 13:57:06 -0000, "Gleb" <gk1### [at] sotonacuk> wrote:
> > As you might know, you are not supposed to be able to write binary files...
>
> By the way, why there is such a limitation? It should be useful.
You know, POV-Ray is a raytracer not... everything.
It is supposed to take script as input with SDL and produce image as output.
Writing binary files with SDL is like writing viruses with it - erhaps
possible but more efficient with external, specialized tool.
For example in my case I can export all values as text and produce proper df3
file with external tool written in any free compiler. The problem is my
laziness :-)
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Gleb wrote:
>
> > As you might know, you are not supposed to be able to write binary
> files...
>
> By the way, why there is such a limitation? It should be useful.
>
Portability is the main concern. As soon as writing binaries includes
more than just writing single bytes the behaviour will be strongly
platform dependant.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"W?odzimierz ABX Skiba" <abx### [at] babilonorg> wrote in message
news:ctds7u8u46hhf0crd5uaond5jsb9so71l9@4ax.com...
> You know, POV-Ray is a raytracer not... everything.
> It is supposed to take script as input with SDL and produce image as
output.
Well, I agree, maybe it was before, but now it is almost... everything.
Now it takes not only a script as input, but also some binary files
(images, dencity) and possibility to interact with them (trace).
Moreover, POV SDL has almost unlimited abilities for creation such a files
with unique effects.
> Writing binary files with SDL is like writing viruses with it - erhaps
> possible but more efficient with external, specialized tool.
The danger of viruses is not a point at all, you know, there are pure
text-looking ones.
From the other point, for example, possibility of reading
binary data into array and loading a "binary image" of
once parsed huge complex object would save a lot of time and/or space.
> For example in my case I can export all values as text and produce proper
df3
> file with external tool written in any free compiler. The problem is my
> laziness :-)
I do appreciate this, but again, to create some files one need POV or
similar
engine. By the way, a binary file produced with your recent beta-test code
looks very interesting when interpreting as an image.
I like POV as it is, but imho tendency of the development itself
will take it's own anyway.
Regards,
Gleb
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3C7E4A40.365ADF05@gmx.de...
> Portability is the main concern. As soon as writing binaries includes
> more than just writing single bytes the behaviour will be strongly
> platform dependant.
Do you really mean that storage device drivers are more complex in access
than display ones?
Gleb
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christoph Hormann" <chr### [at] gmxde> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christoph Hormann" <chr### [at] gmxde> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c7e5652@news.povray.org>, "Gleb" <gk1### [at] sotonacuk> 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] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christoph Hormann" <chr### [at] gmxde> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christoph Hormann" <chr### [at] gmxde> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tom Melly" <tom### [at] tomandlucouk> 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
|
|
| |
| |
|
|
|
|
| |
