This is just an FYI for folks who are waiting for the source: it's just
about ready, I have to write build notes for the Windows code and have
folks test it. Windows requirements are Visual Studio v8 (free edition
ought to work) plus at least Windows 2000. If anyone wishes to volunteer
and is willing to report the exact steps needed to fix anything that didn't
work first time, please reply here.

thanks,

-- Chris

NB this applies to both Windows and Linux.

Post a reply to this message

On Tue, 05 Feb 2008 22:30:05 +0100, Chris Cason  
<del### [at] deletethistoopovrayorg> wrote:
> This is just an FYI for folks who are waiting for the source: it's just
> about ready, I have to write build notes for the Windows code and have
> folks test it. Windows requirements are Visual Studio v8 (free edition
> ought to work) plus at least Windows 2000. If anyone wishes to volunteer
> and is willing to report the exact steps needed to fix anything that  
> didn't work first time, please reply here.

I suppose I could give it a go.
I have access to VS2k5 on Windows XP and I also have two Gentoo Linux  
machines (one x86, the other x86-64).



-- 
FE

Post a reply to this message

Thanks for keeping us updated.

By the way, I'd like to have MinGW officially supported...

Post a reply to this message

If you'd like me to give it a shot on Visual Studio .NET 2003 Enterprise Edition, or
on Visual C++
2005 Express Edition, let me know.  I could download 2008 Express Edition also.  My OS
is Windows XP
Pro.

Post a reply to this message

Nicolas Alvarez wrote:
> Thanks for keeping us updated.
> 
> By the way, I'd like to have MinGW officially supported...

You might even see a patch from me eventually if there is support for 
MinGW. Some of us do not have enough online time to download a rather 
over-bloated version of VS.

Sam

Post a reply to this message

stbenge escribió:
> Nicolas Alvarez wrote:
>> Thanks for keeping us updated.
>>
>> By the way, I'd like to have MinGW officially supported...
> 
> You might even see a patch from me eventually if there is support for 
> MinGW. Some of us do not have enough online time to download a rather 
> over-bloated version of VS.

MinGW works with the 3.6 makefile.gcc, after some tweaking; what I mean 
is that the POV-Team doesn't consider "it officially supported", so it's 
not maintained, and complaints could (and did) get replies like "use a 
supported compiler".

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> This is just an FYI for folks who are waiting for the source: it's just
> about ready, I have to write build notes for the Windows code and have
> folks test it. Windows requirements are Visual Studio v8 (free edition
> ought to work) plus at least Windows 2000. If anyone wishes to volunteer
> and is willing to report the exact steps needed to fix anything that didn't
> work first time, please reply here.

I have VS 2008 express, and run Vista64 and XP64.

Tom

Post a reply to this message

I decided that prior to releasing the windows source I would do more work
on the migration settings, rather than release more or less what beta 25
had. As a recap, betas up to beta 24 read their settings from pvengine.ini,
as per previous versions, and additionally shared the same pvengine.ini as
the installed version of POVWIN 3.6. (The editor does not use pvengine.ini;
it uses the registry, but also shared the 3.6 editor's settings).

Beta 25 made no change to the editor settings but moved the settings that
used to be in pvengine.ini into the registry, but still was under the 3.6
registry branch.

Additionally, betas 25 and lower used the same window class name as 3.6
(this is relevant in that it is used to identify if another copy of POVWIN
is running).

The new code (labeled beta 25a mainly to differentiate it from earlier
versions - it is not a formal release at this point) has the following
changes to the above:

  1. The registry location for both the editor and pvengine has been moved
     to a 3.7-specific branch. [For those wanting to poke around with
     regedit, check out HKCU\software\POV-Ray\v3.7].

  2. The window class handle has been changed to a 3.7-specific value.
     This means that 25a will no longer count pre-25a betas or v3.6 as
     being a 'running instance'. This really only matters if you have the
     'keep single instance' option set, and/or you are passing parameters
     to an already-running instance of POVWIN.

  3. Migration code has been added that will attempt to clone the version
     3.6 settings as much as possible. For pvengine settings for which it
     makes sense (e.g. the secondary render INI file), if the old path
     refers to a location within the old home dir, and the same file/dir
     exists in the new home dir, the path will be changed to suit. Other
     paths (open edit files, last rendered file, etc) are copied but
     otherwise left alone.

  4. The code now expects a help file named povwin37.chm (which doesn't
     yet exist, unless you want to do a copy/rename of the old one).

Additionally, I have updated to the latest version of the boost libraries
(this will make it much easier for folks to build the source since POVWIN
previously used a slightly customized version).

Note that one possible downside to the above boost change is that I can
no longer set the stack size on a per-thread basis. This can make a
difference to render threads since of course POV-Ray can be heavily
recursive. To compensate I have set a new default stack size and changed
some other threads (e.g. the editor syntax threads) to manually request a
smaller stack. However, it needs testing to ensure that the new stack size
is sufficient

Prior to releasing the source for testing I'd appreciate a sanity check of
the new code. If anyone wants to check it, it's available (for a short
time) via http://www.povray.org/temp/povwin-beta25a-test.zip.

If you want to put it into your 3.6 install dir, make a new subdirectory
(e.g. called POV-Ray for Windows v3.6\bin37) and put the exe and DLL's
there. [The location does matter since the code that infers the home dir
for installing the new registry settings looks at the path and if it
doesn't find some of the standard dirs present it will complain].

If you want to create a new 3.7 structure (recommended), you should at the
least clone the include, renderer, insert menu, sounds, and tiles dirs.

As per version 3.6, if you wish to make the inferred home path setting
permanent, you can run pvengine with the /INSTALL switch.

Please let me know of any issues. Source will be released on Sunday barring
any major problems.

-- Chris

Post a reply to this message

I presume no-one had problems with this EXE?

-- Chris

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> I presume no-one had problems with this EXE?

I'd be glad to be of any help, but I'm running Linux.

Post a reply to this message

nemesis wrote:
> Chris Cason <del### [at] deletethistoopovrayorg> wrote:
>> I presume no-one had problems with this EXE?
> 
> I'd be glad to be of any help, but I'm running Linux.

no problem, there have been a few folks who did download it, and I guess no
news is good news :/

-- Chris

Post a reply to this message

Chris Cason <del### [at] deletethistoopovrayorg> wrote:
> I presume no-one had problems with this EXE?

I'm probably too late but I just found the Tools menu empty and couldn't get
"reloaded" until I moved the pvtools.ini to the location being asked for.
Here's what the messages said, before and after:

Loaded 0 tools from C:\Users\Bob\AppData\Roaming\POV-Ray for Windows\pvtools.ini
into Tool Menu.
Loaded 8 tools from C:\Users\Bob\AppData\Roaming\POV-Ray for Windows\pvtools.ini
into Tool Menu.

So I'm not sure if this was a problem or something unfinished or...?

I did the pvengine /install from a command line and that seemed to do what was
intended. Have the 3.7 registry entries. What I had done was to create a
duplicate folder renamed POV-Ray for Windows v3.7, containing everything from
the v3.6 folder.

Also renamed the help file as suggested and it works, too.

Post a reply to this message

Sorry, I neglected to give system info:

Vista Home Premium
AMD Turion 64 X2

And just now realized the SSE2 does crash when drag'n'drop is done. Error is
access violation exception generated at address 0x0060b9d4
Regular pvengine.exe doesn't crash.

Post a reply to this message

sorry again, not thinking!
That SSE2 wasn't part of this beta 25a, so of course you already knew that. I
wasn't paying attention to what all I copied over to the new v3.7 folder I
made.

Post a reply to this message

On Mon, 11 Feb 2008 02:18:57 +0100, Chris Cason  
<del### [at] deletethistoopovrayorg> wrote:
> I presume no-one had problems with this EXE?

I did a fresh install of 3.6.1c, verified that it works, and then tried  
the beta exe:

When launched from a subdirectory of \POV-Ray\bin, I get "ERROR: Cannot  
find Home entry in registry (and cannot infer it)."

When launched from the \POV-Ray\bin directory, I get an access violation  
exception.

The machine in question is running a Core2Duo E6600 (2.4 GHz) with 2 GB  
RAM on WinXP Pro.


-- 
FE

Post a reply to this message

Fredrik Eriksson wrote:
> When launched from the \POV-Ray\bin directory, I get an access violation  
> exception.

yes, I just found this myself, which is why I put off the source release a
day or so. thanks for the report.

-- Chris

Post a reply to this message

Frederik, Kyle, Tom - you should have received email from me by now with a
link to the source code preview. If not, please check your spam filter.

-- Chris

Post a reply to this message

On Wed, 13 Feb 2008 10:06:07 +0100, Chris Cason  
<del### [at] deletethistoopovrayorg> wrote:
> Frederik

Hmpf!



Some preliminary remarks:

Building the editor dlls requires that you have the ATL libraries and  
headers installed. They are included in the default installation options  
of VC2k5, but can be deselected. Not a big deal, but worth mentioning in  
the build instructions.

Using the 'DEVELOPMENT' macro to make POV-Ray search for the editor dlls  
in the 'codemax' directory (as described in the readme) does not work,  
because it looks for them in the wrong place. POV-Ray looks for  
'"..\\codemax\\" BINDIRNAME "\\" EDITDLLNAME', but it should be  
'"..\\..\\codemax\\" BINDIRNAME "\\" EDITDLLNAME'.

The linker fails to link in the debug info in 'vc80.pdb' because it is not  
in the same directory as 'povcore-debug.lib' (one is in 'Win32 Debug', the  
other in 'bin32'). I have not yet investigated what impact this has on  
debugging.


Compilation produced no errors though, and the resulting executable seems  
to work fine. I have not attempted to add OpenEXR yet.


-- 
FE

Post a reply to this message

Chris,

I sent you an email reply outlining my results.  Let me know if you don't get it.

Kyle

Post a reply to this message

On Wed, 13 Feb 2008 22:49:19 +0100, "Fredrik Eriksson" <fe79}--at--{yahoo}--dot--{com>
wrote:


>Building the editor dlls requires that you have the ATL libraries and  
>headers installed. They are included in the default installation options  
>of VC2k5, but can be deselected. Not a big deal, but worth mentioning in  
>the build instructions.

As a side note, the ATL libraries and headers are not included in VC++ 2005 Express
Edition.  The
header files are in the Windows platform SDK, but the atlthunk.lib library isn't.  I
found a
workaround that seems to have worked here...

http://www.codeproject.com/KB/wtl/WTLExpress.aspx

Post a reply to this message

Kyle <hob### [at] gatenet> wrote:
> Chris,
>
> I sent you an email reply outlining my results.  Let me know if you don't get it.
>
> Kyle

I've done the same.

Tom

Post a reply to this message

Fredrik Eriksson wrote:
> Using the 'DEVELOPMENT' macro to make POV-Ray search for the editor dlls  
> in the 'codemax' directory (as described in the readme) does not work,  
> because it looks for them in the wrong place. POV-Ray looks for  
> '"..\\codemax\\" BINDIRNAME "\\" EDITDLLNAME', but it should be  
> '"..\\..\\codemax\\" BINDIRNAME "\\" EDITDLLNAME'.

strange ... it works here (I built from the same zip you used, loaded the
EXE, then used process explorer to confirm that the local copy of the DLL's
was loaded). note that visual studio (at least, VS 2005) sets the working
directory to that of the project, rather than that containing the EXE.

if you add the '/debug' switch to the command-line options in the project
settings, and then run pvengine, you should get a c:\povdebug.txt file,
containing something like the following:

  CWD is d:\Temp\povwin-src-3.7\windows\vs 2005

What does your one give?

-- Chris

Post a reply to this message

On Thu, 14 Feb 2008 12:02:17 +0100, Chris Cason  
<del### [at] deletethistoopovrayorg> wrote:
> strange ... it works here (I built from the same zip you used, loaded the
> EXE, then used process explorer to confirm that the local copy of the  
> DLL's
> was loaded). note that visual studio (at least, VS 2005) sets the working
> directory to that of the project, rather than that containing the EXE.

That explains it. I was running pvengine.exe directly from the 'bin32'  
directory.

Another thing I noticed:
Since the executable name and path is identical for all configurations  
(Debug, Release and SSE2), it is rather cumbersome to switch between them.  
It would be preferable to have separate names and/or paths.


-- 
FE

Post a reply to this message

On Thu, 14 Feb 2008 13:00:06 +0100, Fredrik Eriksson  
<fe79}--at--{yahoo}--dot--{com> wrote:
> Another thing I noticed:
> Since the executable name and path is identical for all configurations  
> (Debug, Release and SSE2), it is rather cumbersome to switch between  
> them. It would be preferable to have separate names and/or paths.

I just noticed that the SSE2 executable did indeed have a different name,  
but I think the debug version should too.


-- 
FE

Post a reply to this message

Fredrik Eriksson wrote:
> On Thu, 14 Feb 2008 12:02:17 +0100, Chris Cason  
> <del### [at] deletethistoopovrayorg> wrote:
>> strange ... it works here (I built from the same zip you used, loaded the
>> EXE, then used process explorer to confirm that the local copy of the  
>> DLL's
>> was loaded). note that visual studio (at least, VS 2005) sets the working
>> directory to that of the project, rather than that containing the EXE.
> 
> That explains it. I was running pvengine.exe directly from the 'bin32'  
> directory.

ah, I see. the macro is really intended for use when running from the IDE,
particularly if you want to debug the editor code itself.

I really ought to clean the whole project layout up - I've done it for the
version 3.6 project but that was after I did the 3.7 branch. all the
project files should be in the VS 2005 directory, and the DLL's should end
up in the bin32 directory, rather than where they are now.

> Since the executable name and path is identical for all configurations  
> (Debug, Release and SSE2), it is rather cumbersome to switch between them.  
> It would be preferable to have separate names and/or paths.

this is intentional - probably a reflection of the way I tend to develop, I
found the standard Visual Studio habit of separating the EXE's into their
own dir was a hassle, as I'm constantly switching between various builds,
and I simply want my various shortcuts (desktop, objectdock, keyboard
launchpad) to always point at the EXE I most recently built. back when I
had them separate, I too many times ran a multi-hour test render only to
find that I'd launched the wrong EXE :-(

thanks for the feedback anyhow. I have added an additional check for the
codemax DLL's in ..\..\ as well as ..\.

-- Chris

Post a reply to this message

Tom York wrote:
> Kyle <hob### [at] gatenet> wrote:
>> Chris,
>>
>> I sent you an email reply outlining my results.  Let me know if you don't get it.
>>
>> Kyle
> 
> I've done the same.

Got both, thanks.

-- Chris

Post a reply to this message

Thanks to Tom, Kyle and and Fredrik for their assistance - it resulted in
some significant changes and improvements to the presentation of the source
and its readme.txt.

The source is now available - please see the announcement in this group.

-- Chris

Post a reply to this message