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.