Dear PovRay developers,

I'm already PovRay 3.5 and now 3.6 to Win64, specifically I use Itanium,
(that's was not easy :) maybe some bugs is still there). Thanks god, that
GUI works without text editor control written on C++Builder!

But since you announce and release PovRay for AMD64 (why BTW only for AMD64?
Nocona already lunched), you have done this porting as well. So I just want
to be in track with main line sources, why don't you just made Win64 clean
sources available?

I can provide you with binaries for IA64 (compiled by Intel compiler) to
place on your site, I read you asked in some thread, and for x86-64 as
well.

So, how can I get you Win64 source code, is it available on CVS somewhere?

Thanks,
Max

Post a reply to this message

MaxLock wrote:
> [...]
> 
> But since you announce and release PovRay for AMD64 (why BTW only for AMD64?
> Nocona already lunched), you have done this porting as well. So I just want
> to be in track with main line sources, 

AMD64 stands for the 64bit extensions of the x86 instruction set 
introduced by AMD.  All processors sold by Intel with 64bit extensions 
(except the Itanium of course) make use of the same extensions (which 
does not mean that we can guarantee it also runs on those but if not 
that is Intel's fault).

> why don't you just made Win64 clean
> sources available?
> 
> I can provide you with binaries for IA64 (compiled by Intel compiler) to
> place on your site, I read you asked in some thread, and for x86-64 as
> well.

There have not been any changes in the core code in relation to this 
port (the core code was already fully 64bit compatible before).  The 
changes were only in the windows frontend and i assume they will be part 
of the 3.6.1 source release.

We probably won't offer an official Itanium version of POV-Ray unless 
someone on the team decides to buy an Itanium (which is pretty unlikely) 
or someone donates one to us (which is pretty unlikely as well).  You 
are welcome to offer an unofficial version of course.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote:
> There have not been any changes in the core code in relation to this
> port (the core code was already fully 64bit compatible before).  The
> changes were only in the windows frontend and i assume they will be part
> of the 3.6.1 source release.

Undoubtedly, but again, is it possible _now_ to obtain somehow current
source code of front-end, with which Win64 version was compiled?

Thanks,
Max

Post a reply to this message

On Fri, 13 Aug 2004 13:21:36 EDT, "MaxLock" <nomail@nomail> wrote:
> Christoph Hormann <chr### [at] gmxde> wrote:
> > There have not been any changes in the core code in relation to this
> > port (the core code was already fully 64bit compatible before).  The
> > changes were only in the windows frontend and i assume they will be part
> > of the 3.6.1 source release.
>
> Undoubtedly, but again, is it possible _now_ to obtain somehow current
> source code of front-end, with which Win64 version was compiled?

There are a few changes to the 3.6.0 windows code thought basically it's the
same code. AFAIK more than changes within source code is to use correct
compiler and correct instalation procedure to be treated as true 64bit
application.

As usually be patient, release of source code will happen when it will be
ready :-)

ABX

Post a reply to this message

>
> There are a few changes to the 3.6.0 windows code thought basically it's the
> same code. AFAIK more than changes within source code is to use correct
> compiler and correct instalation procedure to be treated as true 64bit
> application.

E.g. released binary for AMD64 doesn't crash on gaussianblob.pov but current
source code compiled for any platform by any compiler - crashs on it. So
changes are not only 64-bit related ;)

But I'm particularly interesting only in Win64 frontend "code cleaning"
changes, I've already done it by myself long time ago and now just wnat to
check if everything correct, as long as you released Win64 binary!

> As usually be patient, release of source code will happen when it will be
> ready :-)

Could plz. tell some date, when 3.6.1 is expected to be released?

Thanks a lot,
Max

Post a reply to this message

> E.g. released binary for AMD64 doesn't crash on gaussianblob.pov but current
> source code compiled for any platform by any compiler - crashs on it. So
> changes are not only 64-bit related ;)

	Could you be more precise than "for any platform by any compiler" ?
	I have a binary for AMD64 on Linux which compiles perfectly well
and renders gaussianblob.pov without a glitch.

	- NC

Post a reply to this message

In article <web.411d3db923dfc44e33111f80@news.povray.org> , "MaxLock" 
<nomail@nomail> wrote:

> E.g. released binary for AMD64 doesn't crash on gaussianblob.pov

The scene gaussianblob.pov is defective by design.  It is unfortunetely
still included with 3.6.1.

> but current
> source code compiled for any platform by any compiler - crashs on it. So
> changes are not only 64-bit related ;)

This is not correct.

>> As usually be patient, release of source code will happen when it will be
>> ready :-)
>
> Could plz. tell some date, when 3.6.1 is expected to be released?

The source code will be released when the archives are ready.  There is
nothing else to be said.

    Thorsten

____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

The 3.6.1 windows source will be released shortly. However note
that it is not the source for the AMD64 version. That was developed
in a different revision control system branch and has not been merged
back into the main one yet. The differences to the windows code are
significant including a rewrite of the editor shim DLL (about 4000
lines of code in that). I can't say when I will merge these back and
release them but it won't be too far in the future.

-- Chris

Post a reply to this message

Chris Cason wrote:

> ...The differences to the windows code are
> significant including a rewrite of the editor shim DLL (about 4000
> lines of code in that)...

(Hi, Chris - nice editor.)

Suppose I wrote a modeller that supported a sketch output, and when the user
wants to render they hit a render button.

The simple way is, of course, to call system("your editor /RENDER").

I want to have better access to your editor.

The current lifecycle is:

  work the modeller & watch the sketch output ->
     edit the POV file wrapper (add clouds, light, etc) ->
         fast render to spot-check things ->
             slow render to make the poster

I personally can do each -> by banging around on the various interfaces. If
I wanted to streamline that working cycle, but keep your editor in the loop,
can you publish the DLL interface to your editor?

Publishing an API is a lot of thankless work, and it would constrain you to
not change things. So you could simplify by only "publishing" (meaning
documenting and productizing) only those functions who participate in a
lifecycle like the one I sketched.

-- 
  Phlip
  http://industrialxp.org/community/bin/view/Main/TestFirstUserInterfaces

Post a reply to this message