stringstreams were shown to be slow when reading/writing single characters
and there is lots of potential by having functions perform on existing
buffers whenever possible.
The logging streams now do almost no work when there is no output target for them.
For example, if LL_VERBOSE has no output targets, then `verbosestream << x` will return a StreamProxy with a null target. Any further `<<` operations applied to it will do nothing.
Fix HTTPFetch caller and request ID to 64 bits
Check that allocated caller ID is not DISCARD
Print body if serverlist request returns error
Don't print control characters from HTTP responses
Document special HTTPFetch caller IDs
Allow unicode to be printed
- iconv() prototype changed from traditional Unix defintion
to POSIX definition in 9.99.x.
- wchar_t is not a valid character set for iconv. Share code
with Android for using UTF-32.
* Add a simple PNG image encoder with Lua API
Add ColorSpec to RGBA converter
Make a safety wrapper for the encoder
Create devtest examples
Co-authored-by: hecktest <>
Co-authored-by: sfan5 <sfan5@live.de>
* 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
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.
This commit clarifies the maximal length of the serialized strings.
It will avoid accidental use of serializeString() when a larger string can be expected.
Removes unused Wide String serialization functions
This reverts 1a5b4b3 and further functions in serialize.cpp that are unused
The intend for a sane NetworkPacket/stream replacement was good, but a wrapper
class around i/ostream might be more versatile than introducing a new
vector-based serialization class.
