This commit deprecates the forward, backward, left, and right binary
inputs currently used for player movement in the PlayerControl struct.
In their place, it adds the movement_speed and movement_direction
values, which represents the player movement is a polar coordinate
system.
movement_speed is a scalar from 0.0 to 1.0. movement_direction is
an angle from 0 to +-Pi:
FWD
0
_
LFT / \ RGT
-Pi/2 | | +Pi/2
\_/
+-Pi
BCK
Boolean movement bits will still be set for server telegrams and
Lua script invocations to provide full backward compatibility.
When generating these values from an analog input, a direction is
considered active when it is 22.5 degrees away from either
orthogonal axis.
Co-authored-by: Markus Koch <markus@notsyncing.net>
Co-authored-by: sfan5 <sfan5@live.de>
When setting a sprite animation, do not keep the last animation's frame number. Setting a new animation should start the animation at the start of the new animation.
Reduces stutter and freezes when playing.
* Maintains double SM and SM Color textures
* Light frustum update triggers incremental generation of shadow map into secondary 'future' textures.
* Every incremental update renders a portion of the shadow draw list (split equally).
* After defined number of frames (currently, 4), 'future' and 'current' textures are swapped, and DirectionalLight 'commits' the new frustum to use when rendering shadows on screen.
Co-authored-by: sfan5 <sfan5@live.de>
Apparently the C++ standard library is supposed to provide
specializations of std::hash for enums (even in C++11)
but those don't always work for whatever reason.
* Separate draw list and shadows update to reduce jitter
* Avoid draw list update and shadow update in the same frame
* Force-update shadows when camera offset changes
* Adjust minimum filter radius for perspective
* Expand shadow frustum when camera FOV changes, reuse FOV distance adjustment from numeric.cpp
* Read shadow_soft_radius setting as float
* Use adaptive filter radius to accomodate for PSM distortion
* Adjust filter radius for texture resolution
This completely removes any mention of the software and D3D drivers from MT, preventing the user from accidentally attempting to use them. Users who need a software renderer should be asked to install Mesa drivers which offer superior fidelity and performance over the 'burningsvideo' driver.
This permits to make evidence that we have some bad object passing on various code parts. I fixed majority of them to reduce the scope of passed objects
Unfortunately, for some edge cases i should have to expose ISceneManager from client, this should be fixed in the future when our POO will be cleaner client side (we have a mix of rendering and processing in majority of the client objects, it works but it's not clean)
* we don't need on CAO side more than SceneManager, and temporary. Pass only required SceneManager as a parameter to build CAO and add them to the current scene
* Use temporary the RenderingEngine singleton from ClientEnvironment, waitfor for better solution
* Make ClientActiveObject::addToScene virtual function mandatory to be defined by children to ensure we don't forget to properly define it
* No more access to the singleton instance from everywhere (RenderingEngine::get_instance dropped)
* RenderingEngine::get_timer_time is now non static
* RenderingEngine::draw_menu_scene is now non static
* RenderingEngine::draw_scene is now non static
* RenderingEngine::{initialize,finalize} are now non static
* RenderingEngine::run is now non static
* RenderingEngine::getWindowSize now have a static helper. It was mandatory to hide the global get_instance access
Make the RenderingEngine filesystem member non accessible from everywhere
This permits also to determine that some lua code has directly a logic to extract zip file. Move this logic inside client, it's not the lua stack role to perform a such complex operation
Found also another irrlicht <1.8 compat code to remove
It's often useful to know where the map block boundaries are for doing server admin work and the like.
Adds three modes: single mapblock, range of 5, and disabled.
The only valid usecase for these is interfacing with OS APIs
that want a locale/OS-specific multibyte encoding.
But they weren't used for that anywhere, instead UTF-8 is pretty
much assumed when it comes to that.
Since these are only a potential source of bugs and do not fulfil
their purpose at all, drop them entirely.
