| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
This will avoid crashing the application on rendering due to
uninitialized labels.
|
| |
|
|
|
| |
Even if neither hcentered or vcentered are used, GUI element position
must be determined by that of its parents.
|
| | |
|
| |
|
|
|
|
| |
When a GUI element is hidden, no rendering or updating is done to it or
its children. This can be useful to define a complex GUI tree structure
that changes under specific conditions, without redefining it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The older implementation caused some elements to be
update/rendered/deinitialized more than once per call. For example,
considering the following tree of GUI elements:
A
B
C
D
E
The older implementation would update/render/deinitialize C and E more
than once, as shown below:
Update A
Update B
Update C
Update D
Update E
Update C
This was because a GUI element was acting on its siblings, but the
siblings would also act on theirs, causing the extra calls.
OTOH, as an additional improvement, no nested call is now required for
siblings.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This allows to calculate dimensions for containers with children
containers in it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
So far, their position inside the container was determined when
initializing the interface. However, if a child were resized
afterwards, the container would not adjust its elements accordingly.
Moreover, the implementation for gui_container relied on hacking the
children's X/Y coordinates, which could only be done once.
Now, two additional members have been added to gui_common so that
specific X/Y offset can be determined by the parent, additionally to the
traditional rules followed by gui_coords. Despite the extra memory
footprint, it now allows containers to set specific X/Y offsets for
their children on every game cycle.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
There is no need to allocate memory for these callbacks for each single
GUI element. Instead, a single, statically-allocated instance can be
shared among all GUI elements of a given type.
|
| |
|
|
|
| |
Containers, somewhat inspired by GtkBox, allow to packed other GUI
elements into a single row or column.
|
| | |
|
| |
|
|
|
|
|
| |
The older logic would iterate for all parents, where each parent would
again iterate for all of its parents, until no more parents found.
This is however not needed, since only inspecting the closest parent
will already cause the (recursive) algorithm to iterate for all parents.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`gui` was tighly coupled to game logic, and could not be extended for
other purposes. Therefore, a generic GUI implementation, loosely
inspired by well-known GUI frameworks such as GTK, is now provided, with
the following properties:
- Does not depend on dynamic or static memory allocation, only automatic
(i.e., stack) memory allocation required.
- Portable among existing implementations.
- Simple to extend.
- Tiny memory footprint.
`gui` is now composed by GUI elements that can be chained to form a tree
structure. This is useful e.g.: to calculate X/Y coordinates for a given
GUI element given its parent(s).
This commit also refactors the older implementation, moving
game-specific logic into `player` and making use of the new component.
|
| |
|
|
|
|
| |
The PS1 port relies on a heap for primitives since the GPU renders the
scene asynchronously. However, SDL-based platforms render primitives
synchronously, so structures can be allocated on the stack instead.
|
| |
|
