Gfx Engine - Orientation
Device orientation refers to the physical orientation of a device in space. It can be detected by built-in sensors such as accelerometers and gyroscopes.
In programming, device orientation is an important consideration when developing cubeapps. It allows developers to create visuals that adjust to the device's orientation, providing a better user experience.
But what specific changes can the user interface undergo depending on the orientation of the device, especially if that device is a WOWCube?
First of all, we should remember that, unlike all other devices, the WOWCube is a compound device of 8 separate modules, each of which has 3 independent screens. And also that each face of the WOWCube consists of four independent screens belonging to different modules.
Essentially, this means that, by default, the screens of modules are arbitrarily oriented relative to each other, which in turn leads us to the conclusion:
if you just take a sprite and display it on all screens in the same screen coordinate, the final picture will be a set of unaligned sprites rotated differently relative to each other
This means that in order to align the sprites within one side of the WOWCube, some of them need to be rotated by a certain angle.
The question of how exactly to calculate this angle is discussed in more detail in the Topology-Device Orientation example. And only when the sprites are correctly rotated relative to each other within the same face, you can start drawing the faces themselves, depending on the orientation of the device in space.
After all, what is orientation?
Orientation is when you know which of the faces is on top and which is on the bottom. Or, in other words, when it is known where the gravity vector is directed.

GFX Engine supports three orientation control modes:
Each of these modes, as the name implies, is used by the CubiOS operating system either when rendering specific user interface components, or in general for games and applications that require control of the device's orientation.
In addition, the engine allows you to specify the mode of automatic rotation of graphic objects for alignment, depending on the orientation control mode.
Let's consider the features of each mode separately:
ORIENTATION_MODE_MENU
As the name implies, this mode is used when rendering the cube system menu, as well as for applications that do not require orientation control. In this mode, the control and comparison of the position of the faces with the gravity vector is not performed, and the drawing of the faces does not depend on the position of the cube in space.
ORIENTATION_MODE_GRAVITY
In this mode, the direction of the gravity vector relative to the faces of the cube will be continuously checked and the topology will be rebuilt depending on its direction. In other words, the cube will always "know" what face it has, for example, at the top and how to draw objects on that face.
ORIENTATION_MODE_SPLASH
This mode is a kind of combination of the two previous modes, mainly used for displaying splash screens.
The example
The main purpose of this example is to demonstrate how the relative position of sprites on faces changes depending on the orientation control mode and automatic rotation of objects.
So let's get started...
As always, the application starts by initializing resources in the InitializeResources() function:
Here we fill in the modes array with orientation control values we want to demonstrate, create some objects for visuals and texts and a timer for animated sprite.
We want to make sure that when tapping on one module, the orientation control mode changes on all modules. For this we use the networк:
As you can see from the source code above, when module 0 registers a tap, the application increments the index of the current orientation control mode and broadcasts it to neighboring modules. Neighboring modules, in turn, get this index and write it to a local variable.
Simple.
So, we have an array with all the orientation control modes and the current index. The only thing left is to apply the mode at this index and demonstrate the result visually.
Let's take a look at the on_Render() function:
As you can see, there are two places where the orientation control mode setting appears.
First, the mode for each screen is set:
As a rule, dynamic orientation mode is rarely used in real applications, so calling this function in on_Render() is the exception rather than the rule. However, for this example, it is required.
Next comes the Begin()-End() block.
In GFX Engine, all objects displayed on the screen are added exclusively inside this block. In fact, the main purpose of the Begin() function is to inform the engine that the addition of objects to the screen has begun, and the End() function - that the addition is completed and the engine is ready to draw. But drawing, as we know, depends on the device orientation control mode and automatic rotation, so the Begin() function takes these two parameters as input.
Following further on the code, everything is very simple. We ask the current screen which face it currently belongs to using the Direction() function. If the face is lateral, we display text and sprites on the screen. If not, just fill in the background color.