| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
CMake already distributes FindSDL*.cmake files for SDL and SDL_mixer,
which support custom prefixes via environment variables, removing the
need for ad-hoc logic in Win9x builds.
Also, according to FindSDL.cmake, #include <SDL.h> is the preferred way
for portability reasons, instead of #include <SDL/SDL.h>, which is the
option that has been used so far.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
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.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
Checking against `sel` is just plain wrong, since it always expected to
be non-NULL, since `h->sel` is an array defined in `struct
human_player`. Instead, `sel->d.i` is the pointer that should be
checked.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
The older implementation would leave empty areas on the right side of
the screen.
|
| |
|
|
| |
This function is no longer needed since `gui` was revamped.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`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.
|
| | |
|
| |
|
|
| |
Other members will be initialized according to peripheral configuration.
|
| |
|
|
|
| |
Using memset(3) does not ensure pointers are assigned to NULL for all
platforms.
|
| |
|
|
|
| |
- All platforms should allow for the same resources.
- Population is not expected to exceed UCHAR_MAX on any platform.
|
| |
|
|
|
|
|
|
|
|
|
| |
On platforms with PERIPHERAL_TYPE_PAD, navigating through menus and
options can be cumbersome if moving the cursor freely around the
screen.
Therefore, this commit instead defines a list of (X, Y) coordinates that
the cursor can jump to. The implementation also attempts to guess which
direction the cursor should jump to for the previous/next point, and
hence determine which button should be pressed by the user.
|
| |
|
|
| |
So that uninitialized members are set to 0.
|
| |
|
|
|
|
| |
Whereas some actions are context-specific (e.g.: selecting a player),
some are context-independent and can be executed for all screens
(e.g.: exiting the game).
|
| |
|
|
|
| |
This will allow using camera for purposes other than showing the game
map.
|
| |
|
|
|
|
|
|
|
|
|
| |
This has several advantages:
- `camera` no longer needs to define public functions for each
peripheral type.
- Peripheral-related is now no longer tighly coupled to human_player,
so peripheral logic can be reused elsewhere e.g.: on menus.
- Makes camera_update_touch consistent compared to equivalent functions,
since now `pan` has now been moved to `camera` (as it should be).
|