 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Has anyone tried to compile a version of pov which works as a Win32 console
application? I am trying to do so at the moment with the Unix source code,
but am running into problems with unix.c.
Also: Has anyone yet made PVMPov work with Windows? I know there is a
version of PVM for windows and suggestions that it is easy to do, but have
not seen any results yet. That is why I am trying to make the console app, I
figure the slaves dont need a GUI.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 3 Nov 1999 01:50:10 -0800, Chris Jeppesen wrote:
>Has anyone tried to compile a version of pov which works as a Win32 console
>application? I am trying to do so at the moment with the Unix source code,
>but am running into problems with unix.c.
You can probably safely leave unix.c out of the mix. The other thing you'll
have to do is edit config.h to not have any Unix-specific stuff in it - it's
best to start with the "unix" target rather than the "svga" or "xwin" targets
in this pursuit, as it should already be fairly generic.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Jeppesen wrote:
>
> Has anyone tried to compile a version of pov which works as a Win32 console
> application? I am trying to do so at the moment with the Unix source code,
> but am running into problems with unix.c.
>
> Also: Has anyone yet made PVMPov work with Windows? I know there is a
> version of PVM for windows and suggestions that it is easy to do, but have
> not seen any results yet. That is why I am trying to make the console app, I
> figure the slaves dont need a GUI.
I do not want to burst your bubble, but: within the last 8 months I got
about 4 mails from different people, which told that they would do the
win32-port of PVMPOV. After all there wasn't anybody, successfully
porting PVMPOV to win32.
I'd look forward to your PVMPOV port to win32, Chris
- Jakob Flierl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yay! I got it to work! Except...
It doesnt read povray.ini
it doesnt use a "precision timer" (whatever that is)
it doesnt read environment vars
but at least it compiles and traces!
And I got rid of 607 warnings with a simple #define float double
Still trying with pvm.
Chris Jeppesen <chr### [at] digiquill com> wrote in message
news:3820055d@news.povray.org...
> Has anyone tried to compile a version of pov which works as a Win32
console
> application? I am trying to do so at the moment with the Unix source code,
> but am running into problems with unix.c.
>
> Also: Has anyone yet made PVMPov work with Windows? I know there is a
> version of PVM for windows and suggestions that it is easy to do, but have
> not seen any results yet. That is why I am trying to make the console app,
I
> figure the slaves dont need a GUI.
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3820f651@news.povray.org> , "Chris Jeppesen"
<chr### [at] digiquillcom> wrote:
> And I got rid of 607 warnings with a simple #define float double
I presume you are using Visual C? Just tell it to ignore the possible loss
of "data" warning. Basically the warning is nonsense (it is a _wanted_
lowering of _precision_) and by forcing float to be double you just make
rendering slower. If you dig in the online help you will find where the
option to manually deactivate single warnings is (I don't remember the
option right now, sorry).
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 03 Nov 1999 22:09:22 -0600, Thorsten Froehlich wrote:
>In article <3820f651@news.povray.org> , "Chris Jeppesen"
><chr### [at] digiquillcom> wrote:
>
>> And I got rid of 607 warnings with a simple #define float double
>
>I presume you are using Visual C? Just tell it to ignore the possible loss
>of "data" warning.
To do this, add one or more of the lines below to the appropriate place
in config.h.
/* disable truncation warning */
#pragma warning(disable: 4305)
/* disable precision warning */
#pragma warning(disable: 4244)
/* disable signed/unsigned warning */
#pragma warning(disable: 4018)
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
> On Wed, 03 Nov 1999 22:09:22 -0600, Thorsten Froehlich wrote:
> >In article <3820f651@news.povray.org> , "Chris Jeppesen"
> ><chr### [at] digiquillcom> wrote:
> >
> >> And I got rid of 607 warnings with a simple #define float double
> >
> >I presume you are using Visual C? Just tell it to ignore the possible loss
> >of "data" warning.
>
> To do this, add one or more of the lines below to the appropriate place
> in config.h.
>
> /* disable truncation warning */
> #pragma warning(disable: 4305)
>
> /* disable precision warning */
> #pragma warning(disable: 4244)
>
> /* disable signed/unsigned warning */
> #pragma warning(disable: 4018)
>
Just note that this will hide the problem, but is not a really good solution
engineering-wise. Especially 4018.
But, there's not a simple fix, since most of those come up due to the use of
macros. It might take a lot of engineering effort to correct all those in a
manner that is cross-platform and also "correct". In POV_Ray, most of the
precision and truncation warnings are due to known conversions that are
desired, thus the warnings are less important (just remember that I said "most"
and not "all possible"). Of course, any new code writen will be nice and clean
and not have any of this, right? :-)
Go ahead and put on the band-aid, but remember that it is such.
--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 04 Nov 1999 06:33:49 -0800, Jon A. Cruz wrote:
>Just note that this will hide the problem, but is not a really good solution
>engineering-wise. Especially 4018.
Oh, absolutely. And I don't actually disable any of them in my own
code, either, but fixing them is fairly impractical.
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
>
> In article <3820f651@news.povray.org> , "Chris Jeppesen"
> <chr### [at] digiquillcom> wrote:
>
> > And I got rid of 607 warnings with a simple #define float double
>
> and by forcing float to be double you just make rendering slower.
That's not true. By amazing coincidence, the FPU (at least for intel arch)
is the same size as a Visual C++ double. So if your code is using floats,
they have to be converted to doubles before stuffing in the FPU (and
converted back to float on the way out of the FPU). So you lose precision
and take a performance hit by using floats.
No comment on the #define float double solution though. ;)
It's also interesting that since the '486, FPU mul/div is faster than
integer mul/div.
--
_,--"
dik `-._ ________-_______ "----
_----'--'--------------------------------'--'----_
//_| | \ dic### [at] buckosoftcom / | |_\\
(_____|_|__= Guilford CT +1.203.458.0389 =__|_|_____)
_\_____=___ http://www.buckosoft.com ___=_____/_
\/-(o)-~~-(o)-~~-(o)-`------'-(o)-~~-(o)-~~-(o)-\/
Early Net Poetry:
Wustl, Wustl, ERR RIP MIT BOOT, BIND Wustl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 23 Nov 1999 13:34:36 -0500, Dick Balaska wrote:
>Thorsten Froehlich wrote:
>>
>> In article <3820f651@news.povray.org> , "Chris Jeppesen"
>> <chr### [at] digiquillcom> wrote:
>>
>> > And I got rid of 607 warnings with a simple #define float double
>>
>> and by forcing float to be double you just make rendering slower.
>
>That's not true. By amazing coincidence, the FPU (at least for intel arch)
>is the same size as a Visual C++ double. So if your code is using floats,
>they have to be converted to doubles before stuffing in the FPU (and
>converted back to float on the way out of the FPU).
Not really. FLD with a 32-bit real operand is 20 clocks, as opposed to the
64-bit version at 25 clocks. FST is 44 vs. 45 clocks. FMUL is 27-35 clocks
for a float, or 32-57 for a double. FDIV is 89 or 94. So floats are faster,
under ideal conditions, but not by any significant amount. (This data is for
the 386. Other processors vary, of course. Intel no longer seems to publish
this data, for the obvious reason that pipelining and other optimizations
make it useless.)
--
These are my opinions. I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
