http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/ray_linn/GCC-4.7.0-with-ada/mingw-w64-gcc-4.7.0-runtime-2.0.1-static-ada-20120330.7z/download
Other builds may also work but due to the constantly changing nature of the compiler this cannot be guaranteed. I often had to change compilers while building the libraries and this one is the one that did the job for most of them.
This first support is experimental and considered "advanced". To enable pass -DWITH_MINGW64 during cmake configuration. Also make sure to extract the compiler on C:/MinGW and that MinGW/bin is in your path. To build check out lib/mingw64.
Initially the support is lacking until I get every library compiled correctly. For now you should disable WITH_CYCLES(sorry, I know some people are dying to do benchmarks, but still a few libs to go), WITH_IMAGE_OPENEXR, WITH_OPENCOLLADA, WITH_LIBMV and WITH_CODEC_FFMPEG(links but hangs on startup).
Still the tools are working, the memory limit is increased and due to the experimental nature of the setup, full optimization with SSE2 is available, which makes the build quite fast. Also the compiler and especially, the linker are way faster than regular MinGW.
The wiki docs have also updated. Happy testing!
- ignore MSVC warnings when FREE_WINDOWS is defined to quiet warnings.
- the CMake flags were not being set correctly making blender have weirdo colors (no -funsigned-char).
* Convert all code to use new functions.
* Branch maintainers may want to skip this commit, and run this
conversion script instead, if they use a lot of math functions
in new code:
http://www.pasteall.org/9052/python
- variables that shadow vers declared earlier
- Py_Fatal print an error to the stderr
- gcc was complaining about the order of initialized vars (for classes)
- const return values for ints and bools didnt do anything.
- braces for ambiguous if statements
This problem is caused by discontinuities in the conversion
orientation matrix -> euler angles: the angle sign can
switch and thus the direction of the rotation produced
by the dRot Ipo.
To avoid this bug, the matrix->euler conversion must be
avoided during the game. I took the following approach that
is compatible with Blender (identical effect in the game and
in the 3D view):
- no change in Add mode: Rot and dRot are treated as additional
rotation to the orientation at the start of the Ipo. There is
no matrix->euler conversion and thus no discontinuities.
- Rot Ipo are treated as absolute rotation. All 3 axis should
be specified but if they are not, the startup object orientation
will be used to set the unspecified axis. By doing a matrix->
euler conversion once at the start, the discontinuities are
avoided. If there are also dRot curves, they are treated as
delta of the corresponding Rot curve or startup angle.
- dRot Ipo are treated as Add mode in Local axis.
Note about Add mode: Rot and dRot curves are treated identically
during the game. However, only dRot curves make sense because
they don't interfere with the object orientation in the 3D view.
New Add mode for Ipo actuator
=============================
A new Add button, mutually exclusive with Force button, is available in
the Ipo actuator. When selected, it activates the Add mode that consists
in adding the Ipo curve to the current object situation in world
coordinates, or parent coordinates if the object has a parent. Scale Ipo
curves are multiplied instead of added to the object current scale.
If the local flag is selected, the Ipo curve is added (multiplied) in
the object's local coordinates.
Delta Ipo curves are handled identically to normal Ipo curve and there
is no need to work with Delta Ipo curves provided that you make sure
that the Ipo curve starts from origin. Origin means location 0 for
Location Ipo curve, rotation 0 for Rotation Ipo curve and scale 1 for
Scale Ipo curve.
The "current object situation" means the object's location, rotation
and scale at the start of the Ipo curve. For Loop Stop and Loop End Ipo
actuators, this means at the start of each loop. This initial state is
used as a base during the execution of the Ipo Curve but when the Ipo
curve is restarted (later or immediately in case of Loop mode), the
object current situation at that time is used as the new base.
For reference, here is the exact operation of the Add mode for each
type of Ipo curve (oLoc, oRot, oScale, oMat: object's loc/rot/scale
and orientation matrix at the start of the curve; iLoc, iRot, iScale,
iMat: Ipo curve loc/rot/scale and orientation matrix resulting from
the rotation).
Location
Local=false: newLoc = oLoc+iLoc
Local=true : newLoc = oLoc+oScale*(oMat*iLoc)
Rotation
Local=false: newMat = iMat*oMat
Local=true : newMat = oMat*iMat
Scale
Local=false: newScale = oScale*iScale
Local=true : newScale = oScale*iScale
Add+Local mode is very useful to have dynamic object executing complex
movement relative to their current location/orientation. Of cource,
dynamics should be disabled during the execution of the curve.
Several corrections in state system
===================================
- Object initial state is taken into account when adding object
dynamically
- Fix bug with link count when adding object dynamically
- Fix false on-off detection for Actuator sensor when actuator is
trigged on negative event.
- Fix Parent actuator false activation on negative event
- Loop Ipo curve not restarting at correct frame when start frame is
different from one.
1. All Ipo channels are now independent.
In Blender 2.45, all 3 Loc Ipo channels were automatically set
together. For example, having just a LocX Ipo channel was sufficient
to fix the X, Y and Z coordinates, with the Y and Z value taken
from the object original Y and Z location in Blender. The same
was true for the 3 Rot and the 3 Scale Ipo channels: the missing
channels were assumed to have constant value taken from the object
original orientation/scale in Blender.
With this patch, all Ipo channels are now independent.
THIS WILL CREATE BACKWARD COMPATIBILITY PROBLEM if you omit to
define the 3 channels of a same type together in your Blend file:
the undefined Loc, Rot, Scale coordinates of the object will
be influenced by the parent/spawner Loc/Rot/Scale in case the
object is a child or dynamically created.
2. Delta Loc, Rot, Scale are now supported with the following
limitations:
- The delta Loc/Rot Ipo modify the object global (NOT local)
location/orientation
- The delta Scale change the object local scale
- The delta Ipo curves are relative to the object starting
Loc/Rot/Scale when the Ipo was first activated; after that, the
delta Ipo becomes global. This means that the object will return
to this initial Loc/Rot/Scale when you later restart the Ipo
curve, even if you had changed the object Loc/Rot/Scale in the
meantime. Of course this applies only to the specific Loc/Rot/Scale
coordinate that are defined in the Ipo channels as the channels
are now independent.
3. When the objects are converted from Blender to the BGE, the
delta Loc/Rot/Scale that might result from initial non-zero values
in delta Ipo Curves will be ignored. However, as soon as the
delta Ipo curve is activated, the non-zero values will be taken
into account and the object will jump to the same Loc/Rot/Scale
situation as in Blender. Note that delta Ipo curves with initial
non-zero values is bad practice; logically, a delta Ipo curver
should always start from 0.
4. If you define both a global and delta channel of the same
type (LocX and DLocX), the result will be a global channel equivalent
to the sum of the two channels (LocX+DLocX).
[SCons] Build with Solid as default when enabling the gameengine in the build process
[SCons] Build solid and qhull from the extern directory and link statically against them
That was about it.
There are a few things that needs double checking:
* Makefiles
* Projectfiles
* All the other systems than Linux and Windows on which the build (with scons) has been successfully tested.
