Compilation error was mostly caused by trying to use namespace std before it was
actually defined (e.g. before any include of stl header).
It's not actually good idea to use namespaces in header files -- it's really easy to
run into namespace conflicts and so. Resolved by not using "using namespace" in header
files and using full quality accessing to stl collections (e.g. std::vector).
Here is the description:
As the summary says, this patch adds a new event to both SCA_PythonKeyboard and SCA_PythonMouse. This property is similar to the events property that both have, but it only returns events which are not KX_NO_INPUTSTATUS. This moves the "no input" check from Python to C, which gave my input handling code a 2x speed up. Python sucks (performance-wise) with iterating lists and SCA_PythonKeyboard has close to 200 events (I think something like 177, but I don't know for sure).
- rename define DISABLE_SDL --> WITH_SDL (which was already used in some places)
- blenders interation preset was using orbit rather then turntable 3d view preference (different from factory defaults).
- tagged some unused rna args.
trying to fix blenderplayer startup warnings. It seems we do need to init
the SDL video subsystem even if we only want events, thanks Juha Maki-Kanto
for pointing this out.
error messages on start. These were coming from initializing the SDL video
subsystem as part of Joystick init. We do not need this, as video stuff is
covered by GHOST, most likely this was conflicting.
The problem was that SCA_2DFilterActuator was defining and using a
variable called "m_gameObj", when it should be using "m_gameobj" as
defined by SCA_ILogicBrick. The way it was, reparenting did only half
the work required to duplicate the actuator.
Patch by Alex Fraser, thanks!
blender_add_lib now takes a separate include argument to suppress warnings in system includes (mostly ffmpeg & python).
also only build wm_apple.c on apple+carbon configuration.
globbing vs explicit is discussed here.
http://www.cmake.org/pipermail/cmake/2008-December/025694.html
Practical implications are:
- developers need to keep CMakeLists.txt files up to date.
- Users wont get strange linking errors if they build after a file is added, since CMake detects CMakeLists.txt is modified and automatically reconfigure.
