For best results use the latest 3Dconnexion driver. But latest is only
supported on Mac OS 10.9+. We go all the way back to Mac OS 10.6 so
have to deal with older driver versions.
See the original dlclose line for my faulty assumption. Waiting to
unload the driver later fixes the crash. Newer drivers don’t seem to
have this issue.
Also removed WITH_INPUT_NDOF guards as NDOFManager.h takes care of
this. Follow-up to b10d005 a few days ago.
When WITH_INPUT_NDOF is disabled, 3D mouse handling code is removed
from:
- GHOST (was mostly done, finished the job)
- window manager
- various editors
- RNA
- keymaps
The input tab of user prefs does not show 3D mouse settings. Key map
editor does not show NDOF mappings.
DNA does not change.
On my Mac the compiled binary is 42KB smaller after this change. It
runs fine WITH_INPUT_NDOF on or off.
Enable based on --debug-gpu at the command line. Linux already works
this way.
This commit in master (2.78 timeframe) is the smallest change that gets
the desired result. I did a similar commit in blender2.8. Most ongoing
GL debug work will go into 2.8, not 2.7x.
In support of T49089
This patch addresses the following issues in bf_intern_ghost
```
Warning C4312 'type cast': conversion from 'GHOST_TEmbedderWindowID' to 'HWND' of greater size bf_intern_ghost K:\BlenderGit\blender\intern\ghost\intern\GHOST_WindowWin32.cpp 179
Warning C4312 'type cast': conversion from 'GHOST_TEmbedderWindowID' to 'HWND' of greater size bf_intern_ghost K:\BlenderGit\blender\intern\ghost\intern\GHOST_WindowWin32.cpp 198
```
GHOST_TEmbedderWindowID is defined as long, handles are however of pointer size,
so this should have been an issue when we moved to 64 bits, guess we got lucky.
fixed by turning GHOST_TEmbedderWindowID from long into void*
```
Warning C4302 'reinterpret_cast': truncation from 'HKL' to 'LANGID' bf_intern_ghost K:\BlenderGit\blender\intern\ghost\intern\GHOST_ImeWin32.cpp 67
```
reinterpret_cast emits warnings on truncation, LOWORD does the job just
as well with no warnings.
```
Warning C4838 conversion from 'int' to 'DWORD' requires a narrowing conversion bf_intern_ghost K:\BlenderGit\blender\intern\ghost\intern\GHOST_ContextWGL.cpp 734
Warning C4838 conversion from 'int' to 'BYTE' requires a narrowing conversion bf_intern_ghost K:\BlenderGit\blender\intern\ghost\intern\GHOST_ContextWGL.cpp 734
```
Weird warning, it does a really bad job at telling you what parameter is
causing the warning , tuns out there's a bunch of parameters that cause it
but it still only yields a single warning, the problem is that every
(somevar ? a : b) construct results in an integer type. which needs to be
properly cast to get rid of the warning.
```
Warning C4996 'GetVersionExA': was declared deprecated bf_intern_ghost K:\BlenderGit\blender\intern\ghost\intern\GHOST_WindowWin32.cpp 105
Warning C4996 'GetVersionExA': was declared deprecated bf_intern_ghost K:\BlenderGit\blender\intern\ghost\intern\GHOST_WindowWin32.cpp 107
```
The warning was clear, the code not as much. The version check in place
here is quite convoluted and could be replaced by including VersionHelpers.h
and calling IsWindows7OrGreater, However, CreateInstance will just return NULL
in m_Bar if the interface is not supported, so the whole check is useless.
This however did require that the CreateInstance call actually asked for
ITaskbarList3 and not ITaskBarlist . (You're not really allowed to assign
different interface types to each-other, a roundtrip through QueryInterface
is required there, we were violating spec here by asking for ITaskBarlist and
storing it in ITaskbarList3* )
Reviewers: sergey
Reviewed By: sergey
Subscribers: sergey
Differential Revision: https://developer.blender.org/D2094
A new option '-a' can be passed to the blenderplayer. It forces the
framebuffer to have an alpha channel.
This can be used in VideoTexture to return a image with alpha channel
with ImageViewport (provided alpha is set to True on the ImageViewport
object and that the background color alpha channel is 0, which is the
default).
Without the -a option, the frame buffer has no alpha channel and
ImageViewport always returns an opaque image, no matter what.
In Linux, the player window will be rendered transparently over
the desktop.
In Windows, the player window is still rendered opaque because
transparency of the window is only possible using the 'compositing'
functions of Windows. The code is there but not enabled (look for
WIN32_COMPOSITING) because 1) it doesn't work so well 2) it requires
a DLL that is only available on Vista and up.
give precedence to AA over Swap copy:
Certain GPU (intel) will not allow MSAA together with swap copy.
Previously, swap copy had priority over MSAA: fewer AA samples would be
chosen if it was the condition to get swap copy. This patch reverse the
logic: swap copy will be abandonned if another swap method (undefined or
exchange) will provide the number of AA samples requested. If no AA
samples is requested, swap copy still has the priority of course.
Once and for all - I hope!
So, for the records: Xinput1 events' valuators have a first_axis and axis_count defining the 'range'
of valid axes for that event - but valid data in the valuator's array **always** start at zero
(which means that, if event reports first axis as being axis 2, axis 2's value is in axis_data[0]).
Many keyboard layouts (italian, spanish, german...) have direct access to '+' key on main
keyboard area (not the numpad one), ans x11 has own define for this key, so use it instead
of generating an unkown key event.
Note that we most likely have much more missing 'specific' keycodes for non-US keyboard layout,
but think since we already had a 'minus' keyevent, supporting 'plus' one is totally consistent.
And we had a spare space in our defined values just for it even!
This keyevent is only supported/generated by x11 and cocoa Ghost backends for now,
neither SDL nor win32 seem to have matching key events...
Regression from rB12c71508c2d7.
Now, we systematically first try keycode from `XLookupKeysym()`, and only fall back to
the one from `XLookupString()` if it failed to convert to a valid gkey.
Why this is not working in original code and works int this one remains mystery
(see comments for details).
Note that we still do not support at all non-latin keymaps for our shortcuts,
this would be nice to add someday, but that's a TODO, not a bug.
Reviewers: sergey, campbellbarton
Reviewed By: campbellbarton
Differential Revision: https://developer.blender.org/D1746
If anyone finds OS X UI drawing glitches with different graphics cards please
report them and I'll add an exception specifically for Intel, but in theory this
should work fine for all graphics cards.
While SCons building system was serving us really good for ages it's no longer
having much attention by the developers and started to become quite a difficult
task to maintain.
What's even worse -- there started to be quite serious divergence between SCons
and CMake which was only accumulating over the releases now. The fact that none
of the active developers are really using SCons and that our main studio is also
using CMake spotting bugs in the SCons builds became quite a difficult task and
we aren't always spotting them in time.
Meanwhile CMake became really mature building system which is available on every
platform we support and arguably it's also easier and more robust to use.
This commit includes:
- Removal of actual SCons building system
- Removal of SCons git submodule
- Removal of documentation which is stored in the sources and covers SCons
- Tweaks to the buildbot master to stop using SCons submodule
(this change requires deploying to the server)
- Tweaks to the install dependencies script to skip installing or mentioning
SCons building system
- Tweaks to various helper scripts to avoid mention of SCons folders/files
as well
Reviewers: mont29, dingto, dfelinto, lukastoenne, lukasstockner97, brecht, Severin, merwin, aligorith, psy-fi, campbellbarton, juicyfruit
Reviewed By: campbellbarton, juicyfruit
Differential Revision: https://developer.blender.org/D1680
Issue was that dispatchEvent might call removeWindowEvents/
removeTypeEvents which will delete the event before we can do so.
To address this, handled events are now put in a separate list.
Reported by psy-fi and reviewed by brecht in IRC.
The events are allocated on the heap, then pushed on a stack. Before
being processed, they are popped from the stack, and deleted after
processing is done. When the manager is destroyed (e.g. application
closing), any remaining event in the stack is detroyed.
Issue is that when the "application closing" event is processed, it is
never freed, because the manager gets destroyed before the call to
`delete` is made and the event is not on the stack anymore.
Now events are left on the stack while they are processed, and only
popped and deleted after processing is done.
As a slight bonus refactor: use void as return type for dispatch events
functions, as no caller is checking the return value, and it is not
clear what it means (suggested by the reviewer).
Reviewers: brecht
Differential Revision: https://developer.blender.org/D1695
In practice this gives us a context that is *compatible* with GL 2.1. On
my machine it gives a GL 3.3 or 4.3 compatibility profile context,
depending on graphics card installed.
Also fixed enum for core profile (not used yet).
Also added option for GL 3.2 compatibility profile. This will be useful
during Blender 2.8 development, until we are able to use the core
profile. On my machine this gives exactly a GL 3.2 compatibility profile
context, not 3.3 or 4.
Unfortunately there's no easy way to show a messagebox here, so just
print a warning on fstderr and exit. If we don't call exit() here we get
crashes on other blender systems (python, opensubdiv) and it can get
tricky to track the initialization state here, so just using exit()
should do the trick for now.
Load driver dynamically at runtime instead of weak-linking the
3Dconnexion framework. Driver no longer needed at build time!
Works with really old drivers (as in PowerMac old), more recent
versions, and the latest which allows us to process events on a
separate thread.
It turns out libGL from Intel crashes when calling glxewInit (where mesa, nvidia work fine),
unfortunately the only option without making larger changes to glew,
is to inline the parts of glew we're using - before the glx context is created.
