SDL2 has an API for getting a string description of a key. Change the
textscreen API which does the same to use it. This has the added bonus
that the setup tool will now adjust to show key descriptions that match
the system keyboard layout.
It's not enough to simply return the first byte from the buffer, since
it may be a non-ASCII character. Decode the whole first character using
the UTF8 library.
This replaces the old control over whether key mapping is enabled. We
have three different modes used in different situations: "normal" (used
when navigating windows, etc.); "raw" (used when configuring a key and
we want something derived from the scancode) and "text" (used when typing
something into an input box widget).
As per the recent change to PHILOSOPHY, we now support non-vanilla
demo format extensions provided that warnings are given and there is
an option to disable them (#817). Add an API for handling such
extensions in a consistent way across games.
This follows some recent discussions around the project's philosophy
and which fan-made hacks are supported (specifically the Doom
v1.91 / -longtics feature). It's worth providing some explicit
guidance as to why this feature is supported, while other executable
hacks are not.
Some of the features of this new clause are not yet implemented (the
-strictdemos flag and the warnings when playing non-vanilla demos).
This is part of #817. Thanks to @AXDOOMER for challenging some of the
perceived inconsistencies in the project philosophy and inspiring me
to explain this in a more rational/structured way.
Save and restore of these extension bits is a convenience for demo
playback purposes and not intended as an editing feature. If a demo
with such bits set is found inside a WAD file, we ignore them as
Vanilla Hexen would do.
Part of #817.
We are now working to emulate older (pre-v1.9) Doom versions, so it
is worth clarifying the goals of the project slightly.
Also add Chex Quest to the list of games.
As with the Doom v1.91 format, parsing of vvHeretic extension bits is
a convenience for demo playback purposes and not intended as an
editing feature. If a demo with such bits set is found inside a WAD
file, we ignore them as Vanilla Heretic would do.
Part of #817.
As per reasoning on #817, we only allow longtics demos as a feature for
users to cleanly record vanilla gameplay without affecting the turning
resolution. When playing back demos, we detect the different header byte
(111) that indicates a longtics demo file and proceed accordingly.
However, we should only support such demos when they are played manually
on the command line by the user. Longtics demo playback support should
not be a feature that WAD authors can use to break from Vanilla
behavior. If such a demo is encountered inside a WAD, treat it as
Vanilla would treat it and exit accordingly.
Certain IWADs (Freedoom and Hacx) contain DEHACKED lumps that must be
loaded to be played properly. This is conditional on the value of
gamevariant, but this variable was only being initialized for these
IWADs after the code to load the DEHACKED lumps. Reorder to correct.
Add M_FileCaseExists() that checks if a file exists by trying
multiple different capitalization formats, and change WAD
search code to use this when locating WAD files.
Strafe left, strafe right, and move backward mouse commands work.
'Double click acts as "use"' option works, where previously it was
always enabled.
Fix for #813
Display speed box when acceleration settings are inconsequential.
Additionally, show as direct mouse input and adjust if input exceeds box
length by decreasing resolution.
Fix for #791
When Choco has reaches the end of a savegame file, further attempts to
read from this file with fread() will fail and the result variable
will not get set set. Since the result variable does not get initialized
either, saveg_read8() will return some "random" value.
However, as it turns out, the uninitlaized value of the result
variable isn't that random at all, but most often 0. Unfortunately, 0
has a specific meaning in the context of p_saveg.c, as it is the value
of tc_ceiling in enum specials_e. As a result, the tclass variable in
P_UnArchiveSpecials() will get interpreted as tc_ceiling and lead to
the construction of ceiling thinkers until Choco runs out of zone
memory.
What this little change does is initialize the result variable
returned by saveg_read8() to some arbitrary value that has no further
meaning in any of the enums in p_save.c. This will lead to Choco
erroring out with an "unknown tclass" message, which is consistent
with Vanilla. The actual tclass value may be different, but since it
is expected to be somehow "random" this isn't something I plan to
emulate any further at this point.
Fixes#794, #658, #85.
