|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] maccom> wrote in
news:pan### [at] maccom:
>
>> It was already done many times for 3.1 Hard to say about 3.5 since they
>> are not release yet but when it will be available I'm pretty sure many
>> people will try it.
>
> One problem with 3.5 will be that the scene and include files don't
> conform to the 8.3 filename limit. I doubt there is anything to prevent
> POV-Ray from running, but you won't get a full working distribution.
DJGPP programm supports LFN (if only run under OS supporting it, like Win98
dos-box).
--
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Arthur Flint <mra### [at] chesapeakenet> wrote:
> Some people like the low overhead that DOS
> offers...
As much as I hate saying this, the Windows version works faster than the DOS
version.
I once thought that as in DOS POV-Ray has the whole machine to itself while
in windows it has to share resources and time with other processes, it would
be much faster in DOS.
Then one day I decided to test it in practice. To my big surprise POV-Ray
for Windows outperformed POV-Ray for DOS in almost every case. (And this was
with pov3.1, ie. no superoptimized intel compile available...)
So don't make the mistake of thinking that POV-Ray will be faster in DOS
just because there are less processes. That's not the only affecting thing.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote in news:3d189012@news.povray.org:
> So don't make the mistake of thinking that POV-Ray will be faster in
> DOS
> just because there are less processes. That's not the only affecting
> thing.
You where DJGPP and some-win32 compiler versions, based on same GCC
version ?
Older DJGPP was based on GCC 2.9x that was quite slower (less optimization)
then Win32.
--
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
> You where DJGPP and some-win32 compiler versions, based on same GCC
> version ?
I used the official versions, plus a version for DOS compiled with DJGPP.
The latter was the slowest of all three.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote in news:3d18aee0@news.povray.org:
> Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
>> You where DJGPP and some-win32 compiler versions, based on same GCC
>> version ?
> I used the official versions, plus a version for DOS compiled with
> DJGPP.
> The latter was the slowest of all three.
I think that if You would use most up-to-date version of DJGPP (and
ofcourse set -O3, loops unroling, inlines etc) this would be as fast as
win32. In adition - ther is afair some other model of memory allocation in
DJGPP that is faster (but results in faster memory fragmentation).
Btw - can I find somwhere ready-to-comile in DJGPP sources of POV ?
--
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
> set -O3, loops unroling, inlines etc
-O3 already sets those, so why set them again?-)
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25 Jun 2002 11:12:04 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote:
> Christopher James Huff <chr### [at] maccom> wrote in
> news:pan### [at] maccom:
>
> >
> >> It was already done many times for 3.1 Hard to say about 3.5 since they
> >> are not release yet but when it will be available I'm pretty sure many
> >> people will try it.
> >
> > One problem with 3.5 will be that the scene and include files don't
> > conform to the 8.3 filename limit. I doubt there is anything to prevent
> > POV-Ray from running, but you won't get a full working distribution.
>
> DJGPP programm supports LFN (if only run under OS supporting it, like Win98
> dos-box).
>
> --
There is a command line replacement for DOS called 4DOS that supports the full LFN
file names too, even when booting to full DOS mode, but I am not 100% sure if programs
that are LFN aware will also recieve those names under it. May be a good thing to
check
out though. I would have it installed on mine, but have too many other things I
desperately
need to pay the shareware fees on already. lol But it is very a very nice replacement
even
if it doesn't help with the file names.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp <war### [at] tagpovrayorg> wrote in news:3d18bda4@news.povray.org:
> Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
>> set -O3, loops unroling, inlines etc
> -O3 already sets those, so why set them again?-)
_all_ loops with compile-time-known-length are unrolled in -O3 ?
--
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 25 Jun 2002 09:09:41 -0400, Arthur Flint <mra### [at] chesapeakenet>
wrote:
>What I ment was that in DOS you are not running
>many background tasks due only to the OS. i.e. low overhead
That's what I meant, too, plus the better memory and HDD management of
Linux.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This way I can run POV-Ray using a simple telnet client. Then I'll just need
a very narrow bandwidth internet connection to run POV-Ray on a remote
render farm or something!
--
Apache
POV-Ray Cloth experiments: http://geitenkaas.dns2go.com/experiments/
Email: apa### [at] yahoocom
ICQ: 146690431
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |