- use char rather then STR_String for the event printer.
- added option to build WITH_GHOST_DEBUG for cmake
- renamed WITH_SDL_GHOST --> WITH_GHOST_SDL
Note: AA is still disabled due to AA creating problems for selection tools. If you must, set AA to 2 or 4 in wm_window.c where the GHOST window is created (line 317).
This nice patch by Matt D. (matd in #blendercoders) adds three nice features that can be seen already in the other supported OSes:
* minimum window size: to prevent some bugs with the window manager of Blender, system windows cannot be resized smaller than the minimum size.
* Continuous Grab is finally in Windows! Default settings since alpha 0 already have the feature enabled by default, so grab a new build and enjoy :)
* GHOST support for drag and drop added. This prepares Blender for drag and drop from OS -> Blender. Currently not very useful, since wm needs to be readied for that. But it does work (do BF_GHOST_DEBUG=1 build and drag a file onto a Blender window).
Thanks Matt D.!
- replace libtiff by calls to Cocoa services to load/save tiff files
(Libtiff, dynamically linked is not distributed with OS X, and would have had to be shipped for all four architectures)
The imb_cocoaLoadImage & imb_cocoaSaveImage are generic towards the bitmap format, and thus can handle TIFF, GIF, JPG, JP2000, BMP and raw camera formats (read-only for these), even if today only TIFF is used as the other formats are already handled.
- CMake updated
- scons updated (Thx to Jens Verwiebe)
Fixed gcc-4.0 compile error (cocoa)
Updated scons to build cocoa (32bit & 64bit) (Thx Jens Verwiebe for the patch):
- make sure right python is unzipped to app-bundle ( printing information at the end of compiling )
- make sure arch-setting appends needed flags ( depending on OSX-version obsolete sometimes but harmless )
- link correct frameworks depending on gfx-api ( cocoa/carbon)
- conscript prepared for cocoa objC-files
- link to openAL-framework, using the headers from blender-lib + the symbols in framework
Usage instruction:
The default build is Cocoa 32bit.
To change it, copy config/darwin-config.py to user-config.py in the blender folder, and edit:
- WITH_GHOST_COCOA & MACOSX_ARCHITECTURE variables to select cocoa/carbon, and the arch (i386, X86_64, ppc, ..)
- the libs options as usual
* bring back 'player' libtype, after investigation with ideasman.
scons/mingw works nicely, for some reason msvc fails to link still, will look further into it.
* add preliminary support for building Blender on 64bit Windows with _msvc_. The SConstruct should automatically detect if you are on a 64bit Windows and if you have that 64bit build is assumed. If you're not, 32bit build is assumed.
NOTE: this is still very much wip, so your mileage may vary. Do please report on b25 taskforce ML in case of trouble.
NOTE2: many of the libs are being linked in statically
NOTE3: hopefully I didn't break anything for other build platforms (mingw, linux, osx).
NOTE4: comes after NOTE3
I did a very drastic cleanup for the different libgroups, there's now only a few left. It compiled with scons/msvc, will be testing in a bit on linux, too.
If you get any problems, please reply to this commit message on the taskforce ML.
svn merge https://svn.blender.org/svnroot/bf-blender/trunk/blender -r12987:17416
Issues:
* GHOST/X11 had conflicting changes. Some code was added in 2.5, which was
later added in trunk also, but reverted partially, specifically revision
16683. I have left out this reversion in the 2.5 branch since I think it is
needed there.
http://projects.blender.org/plugins/scmsvn/viewcvs.php?view=rev&root=bf-blender&revision=16683
* Scons had various conflicting changes, I decided to go with trunk version
for everything except priorities and some library renaming.
* In creator.c, there were various fixes and fixes for fixes related to the -w
-W and -p options. In 2.5 -w and -W is not coded yet, and -p is done
differently. Since this is changed so much, and I don't think those fixes
would be needed in 2.5, I've left them out.
* Also in creator.c: there was code for a python bugfix where the screen was not
initialized when running with -P. The code that initializes the screen there
I had to disable, that can't work in 2.5 anymore but left it commented as a
reminder.
Further I had to disable some new function calls. using src/ and python/, as
was done already in this branch, disabled function calls:
* bpath.c: error reporting
* BME_conversions.c: editmesh conversion functions.
* SHD_dynamic: disabled almost completely, there is no python/.
* KX_PythonInit.cpp and Ketsji/ build files: Mathutils is not there, disabled.
* text.c: clipboard copy call.
* object.c: OB_SUPPORT_MATERIAL.
* DerivedMesh.c and subsurf_ccg, stipple_quarttone.
Still to be done:
* Go over files and functions that were moved to a different location but could
still use changes that were done in trunk.
Basic support for normal pressure sensitivity is implemented, adding other features like tilt etc. shouldn't be too difficult, now that basic support is there.
Tested with WACOM Volito on Windows XP using the pressure sensitivity with texture paint to change size of the brush .
Added additional include dir to scons, and MSVC 7 project files - other build systems might have to be updated.
* These changes bring cross-compiling Blender for Windows on Linux one step
closer to reality. The 'biggest' change is in makesdna SConscript to make
sure a linux native makesdna is built, that can be run, too. Next to that
proper checks for env['OURPLATFORM']=='linuxcross' are added in various
places.
Switch change in pluginapi.c was necessary, and AFAIK it should work like
that also on WIN32, if not, slap me.
Note: everything *compiles* now nicely, it is just that the final *linking*
doesn't work (yet). Anyone who fixes this will be the
hero of cross-compilers :)
+ 'scons blenderplayer' builds blender AND blenderplayer now (tested on Linux
only, but was only linking issue, so should work on other platforms too).
NOTE: I noticed some compileflags for GE specific libs that were left out -
I re-enabled them in the SConscripts, but I'm going to do a test build my-
self now, so if there are problems with them on win32, I probably already
know about them :)
