[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Nel] 3DSMax 4.2 + STLport 4.5 support

From: Vincent Caron
Subject: [Nel] 3DSMax 4.2 + STLport 4.5 support
Date: Wed, 07 Aug 2002 20:42:41 +0200
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530


This is a rather lengthy patchset, the target is : VC7 build + 3DSMax 4.2 support + STLport 4.5. I have split this up in several parts with some comments. The patches try to be conservative, ie. they should not break the Max3.1 + STLport 4.1 build.

VC7 build

My IDE being VC.NET, I only worked on the .sln and .vcproj files. Besides little tweakings, I modified the output paths of the .dll, .dlu and .dlm files. In order to avoid hardcoded paths 'C:\3dsmax3_1\...' in the build files, I used the following scheme :

- all shared binaries goes in code/nel/lib7/ (like NeL regular libs and DLLs), here's the manifest :


- 3DSMax has a 'plugin.ini' that let you add your own plugin path, mine looks like :

  Standard MAX plug-ins=C:\3dsmax42\StdPlugs
  Additional MAX plug-ins=C:\3dsmax42\plugins
  NeL plug-ins=D:\src\nel\code\nel\lib7

- Note that I added the very same lib7 path to my PATH global environment variable, in order that any NeL app/plugin links properly from a single DLL repository (thus I removed the postbuild rules which were copying files around at fixed places in C:\3dsmax3_1). This is very handy, and MS-portable :

- I also removed per-projet (.vcproj) MAXSDK include and lib paths, the documentation suggests those being set in the global VC paths, which is a good idea. I also solved the 'include order/minmax' compilation pb, see next section.

- I provide a 'compilation_notes_vc7.txt' which describes the whole build setup using VC7 and the conventions I briefly sum up here.

Of course, it won't interfere with the VC6 build.

MaxSDK vs. STL conflict

<Max.h> includes <windows.h> which defines the 'min' and 'max' macros, and they interfere with std::min and std::max. I needed a way to workaround this pb without modifying MaxSDK's code, since submitting a patch now to Discreet would hardly benefit to users in less than a year :)

I can't use the NOMINMAX macro (if defined before including <windows.h>) which prevent the spurious macros to be defined. Sadly, <box2.h> uses two occurences of the 'min' macro. The solution was to add this blurb in NeL once per Max-depedent lib, after the Max includes, but before the NeL includes :

#ifdef min
#undef min
#ifdef max
#undef max

In all cases but one (nel_patch_converter), this has been done in "stdAfx.h". This shouldn't affect the Max 3.1 build, while it will bulletproof other MaxSDK builds.

Unsupported STL code

Snippet from nel_patch_lib/path_mesh_alloc:

  typedef std::list< std::auto_ptr<CArrayElement<T> > > ListArray;

The remarks :

 - an auto_ptr<> can't be a container (you don't own its scope)
 - auto_ptr has been removed from the STL specs :)

I removed the auto_ptr<>, a provided a simple destructor that does the cleanup. This should be functionnaly equivalent (the allocated vectors can't be released sooner IMHO), while being correct code.

Template specialisation

Don't put template specialisation implementation in .cpp. While it seems a good idea, it's actually forbidden by Mr Stroustrup, and VC6 erroneously supports it (VC7 don't). The last time I encountered this kind of code under MSVC6, the code in the .cpp was simply blatantly ingored. Depends on the link stage actually.

I have corrected the CEditableRange<T> in object_viewer and its derivative classes, ie. moved the code in the .cpp and replaced forward declarations by includes of the templates. This is portable and C++-ly correct.

    Updates object_viewer/CEditableRange<T> users.
    Resolve min/max macros vs. std:: counterparts conflict
    Removed auto_ptr<> usage where it's forbidden
    Seems that the DLL naming convention applied was half applied here
    Adds mandatory methods from MaxSDK 4.2 (4.x?) when subclassing
    New files:
      .vcproj collection
      VC7 build documentation


To apply the patches from a Windows box, here is a Win32 native port of GNU patch :  (59 KB)

To apply them, use the 'code' module root :

  $ cd code
  $ patch -p0 < patchfile.patch

Thanks !

reply via email to

[Prev in Thread] Current Thread [Next in Thread]