It seems some internals change recently due to web security reasons and some emscripten HTML5 funtionalities like pointerLock or fullscreen modes behave very weird or just don't work as expected
Most warning were related to types conversion (casting required) and unsigned/signed types comparisons.
Added preprocessor directives (_CRT_SECURE_NO_DEPRECATE; _CRT_NONSTDC_NO_DEPRECATE) to avoid warnings about unsafe functions, those functions are safe while used properly and recommended alternatives are MS only.
Some external libraries still generate warnings.
There are multiple #define values around raylib, usually not exposed for redefinition, just reviewed all of them to allow users redefining them on compile time if required.
Also, multiple #define have been renamed and commented.
* First draft of UWP rework.
* Read desc
- Moved UWP specific functions to uwp_events.h
- Removed BaseApp.
- Implemented example UWP lifecycle.
* Added GIF recording and screenshot support.
* Character inputs and filesystem stuff
* Fix game closing on Xbox when B is pressed.
* Fix the gamepad binding hack
* Add as many keys as I believe are possible.
* Implemented mouse locking of a sort.
* Remove rogue todo, the rest are for a game dev using this example.
* Implemented touch how I "think" it should work. I cant test this.
* Review.
* [cppcheck] Improvements in SaveStorageValue() in core.c
in file core.c cppcheck shows errors only in function SaveStorageValue():
* Common realloc mistake: 'fileData' nulled but not freed upon failure
* Memory pointed to by 'fileData' is freed twice.
Validation:
* Tested examples/core/core_storage_values.c
* Launched Unit Test for this function
* Rerun CPPCHECK afer fix
* [cppcheck] Change functions header to accept only positive position in files
Changes:
* Functions SaveStorageValue(), LoadStorageValue() (core.c)
* Functions LoadFileData(), SaveFileData() (utils.c)
* Headers in raylib.h
Validation:
* Tested examples/core/core_storage_values.c
* Launched Unit Test for these functions
* Rerun CPPCHECK afer fix
* Android: Better track touch input returned from IsMouse*()
Switch to actually tracking touch input to use for "mouse" input rather
than the gestures system. The gesture system as an abstraction ontop of
raw touch input loses some information needed to map to "mouse"
input.
Before,
- IsMouseButtonReleased() triggers immediately after the initial touch
(because GESTURE_TAP activates immediately on touch) instead of waiting for the
touch to be released.
- IsMouseButtonUp() returns false, when it should just be the opposite
of IsMouseButtonDown().
- IsMouseButtonDown() returns true only after GESTURE_HOLD (which
activates after some period of time after GESTURE_TAP), when instead it
should just be true whenever there is touch input i.e. gesture !=
GESTURE_NONE or alternatively when any input is received on the screen.
After this PR, touches map closer to mouse input.
- IsMouseButtonReleased() triggers when touch is released (last frame
was touched, this frame not touched).
- IsMouseButtonUp() returns the opposite of IsMouseButtonDown()
- IsMouseButtonDown() is true when
(AMOTION_EVENT_ACTION_DOWN || AMOTION_EVENT_ACTION_MOVE) and false when
(AMOTION_EVENT_ACTION_UP)
* RPI: Include index check for RPI in GetTouchPosition()
This was working in 2.6 but no longer does in current git tree.
It appears touch position is only tracked on
AMOTION_EVENT_ACTION_[DOWN|UP], which only registers the initial touch
on the screen. Subsequent movement is not tracked into CORE.
Touch position and the Gesture System appears to be updated twice in
AndroidInputCallback in what looks like perhaps a copy paste error (code
is identical) with the exception of tracking AMOTION_EVENT_ACTION_UP in
the 2nd copy of the code (but this is not necessary to track).
If you need to track the first touch or release touch position, you can
do so with checking IsMouseButton[Pressed|Released] on the same frame.
This patch makes it so the touch position is always updated, and merges the
duplicated code into 1 singular code path.
In `InitGraphicsDevice(...)`, the Android section has a screen security check
like other platforms- but CORE.display.width, CORE.display.height are
not set yet, so the security check sets it to 0. So ensure we query the
device's screen width and height before the screen size security check.
This also gives you the ability to run a proper full-screen application
on Android without any scaling and guess work on the target device by
setting screen width and height to 0 in `InitWindow(...)` and using
`GetScreen[Width|Height]()` to get the actual values.
raysan5
Random
seanpringle
Shylie
Chang Si Yuan
ChrisDill
ivn
Mickaël Malécot
Reece Mackie
Dani Martin
Doyle