On Friday, 7 April 2023 at 15:52:02 UTC, Ali Çehreli wrote:
I don't know how relevant it is but there is also Hipreme
Engine that supports Android:
I think the question is if you are doing games vs doing other
applications. There's some overlap between game and gui, but not
actually that much. Both draw things to the screen and accept
user input... but even these two things they tend to do quite
differently.
Guis tend to favor responsiveness. I know, there's people saying
"games have to be even more responsive!" but let me finish:
games tend to favor *predictability*. (Some exceptions of course.)
A gui will want to respond to input as soon as it can. If I can
press a key and see a response on screen in one millisecond,
great! Or, on the other hand, if it takes 200 ms... not so great,
but I can maybe still live with it.
A game will want to respond to input *on a strict schedule*.
Responding too fast might break its rules - the world physics
aren't infinitely precise and are designed with certain limits in
mind. It might also give an unfair advantage to some players over
others. Responding too slowly means players will miss their jumps
and other frustrating feelings of lack of control. But notice
that if something is *predictably* slow, players will get used to
it - a lot of things deliberately have some delay according to
the rules of the game. Something is only ever "too slow" if it is
inconsistently slow.
Thus it is common for games to poll input on a timer, whereas
guis wait for input on events.
Both games and guis draw, but games tend to draw many active
things at once, showing a game world that is changing with the
passage of time, and guis tend to draw one difference at a time,
in response to either a user input or some request finishing.
Sure, some guis will do large animations that are similar to how
a game works, but these are exceptional circumstances; most the
time, a game is drawing to keep the screen in sync with the state
of the game world and most the time a gui is idle, waiting for
something to happen.
That's just the differences in functionality where they overlap.
Other things are very different. Games often (but not always)
value predictable latency audio, to maintain its a/v sync. Guis,
being idle more often than not, can typically defer opening an
audio device until they need it, then close it as soon as that
effect is done. Most games contain themselves to one large,
multi-role window. Guis often use several, with varying roles
including temporary single-purpose windows (e.g. popup menus and
toolips). Guis need to implement a variety of input patterns that
games rarely care about - interprocess drag and drop, copy and
paste, ui automation and accessibility apis; guis are more often
part of a bigger cooperative whole than just on their own. Games
just want to take whatever global input they get into their own
self-contained game world, and games are more likely to care
about joysticks and gamepads than guis.
One library can help with both games and guis but it is unlikely
to be a complete solution for either, certainly not both.
