-
We had a few methods that needlessly traversed whole
TCastleTransform
hierarchy. Reworking them was an optimization and also an API simplification (IOW, a “no-brainer” 🙂 ). Changes:-
TCastleTransform.Press, TCastleTransform.Release are now only called when TCastleTransform.ListenPressRelease is
true
.The need to process keys in TCastleTransform is very seldom (we only had 2 use-cases for it in the engine, one is in soon-to-be-deprecated
CastlePlayer
, the other was for X3D key sensors which are not very useful for normal engine usage). -
TCastleTransform.CameraChanged
,TCastleTransform.UpdateGeneratedTextures
,TCastleTransform.VisibleChangeHere
virtual methods removed (their use-case is now implemented as an internal mechanism, tailored to factual needs, not needing to be recursive). -
TCastleTransform.Dragging
removed (not needed, a simple Boolean internal field that tracks “whether something is betweenPointingDevicePress
andPointingDeviceRelease
” is enough).
-
-
CastleWindow GTK backend (default on Linux) can now initialize OpenGLES context using EGL. (Note that it was already possible with Xlib backend previously.)
This allows to test OpenGLES rendering on desktops, just define symbol
OpenGLES
at compilation (e.g. by adding it to CastleEngineManifest.xml, or just tweak one line of src/base/castleconf.inc). And make sure you have OpenGLES installed (libgles2
package on Debian and similar). -
Optimized bounding box calculation for meshes (boxes are now a little less optimal, but much faster calculated; undefine
FAST_MESH_BOUNDING_BOXES
if you want to try again the old method). -
Optimized
GeneratedCubeMap
withupdate=NONE
(should take zero time, was accidentally consuming some). -
Fixed LOD node behavior under transformation animation (testcase: navigation/lod_test.x3dv in demo-models).
Simplifications, optimizations, GTK backend suitable for testing OpenGLES too
Start the discussion at Castle Game Engine Forum