Specifically, we address three concerns (the image stretching during
rotation, artifacts around the image due to clamping to the nearest
border color when the image is drawn to a larger space than the image
itself takes up, and potential artifacts around a rotated image which
accidentally ended up in an atlas and didn't have enough extra space to
guarantee the rotation would work).
The first concern was addressed by fixing the dimensions of the map
images drawn from the UI (so that we always use a square source
rectangle, rather than a rectangular one according to the dimensions of
the map). We also fixed the way rotation was done in the fragment
shader for north-facing sources to make it properly handle aspect ratio
(this was already done for north-facing targets). Together, these fix
rendering issues peculiar to rectangular maps.
The second and third concerns were jointly addressed by adding an
optional border color to every 2D image drawn by the UI. This turns
out not to waste extra space even though we hold a full f32 color
(to avoid an extra dependency on gfx's PackedColor), since voxel
images already take up more space than Optiion<[f32; 4]> requires.
This is then implemented automatically using the "border color"
wrapping method in the attached sampler.
Since this is implemented in graphics hardware, it only works (at
least naively) if the actual image bounds match the texture bounds.
Therefore, we altered the way the graphics cache stores images
with a border color to guarantee that they are always in their own
texture, whose size exactly matches their extent. Since the easiest
currently exposed way to set a border color is to do so for an
immutable texture, we went a bit further and added a new "immutable"
texture storage type used for these cases; currently, it is always
and automatically used only when there is a specified border color,
but in theory there's no reason we couldn't provide immutable-only
images that use the default wrapping mdoe (though clamp to border
is admittedly not a great default).
To fix the maps case specifically, we set the border color to a
translucent version of the ocean border color. This may need
tweaking going forward, which shouldn't be hard.
As part of this process, we had to modify graphics replacement to
make sure immutable images are *removed* when invalidated, rather
than just having a validity flag unset (this is normally done by
the UI to try to reuse allocations in place if images are updated
in benign ways, since the texture atlases used for Ui do not
support deallocation; currently this is only used for item images,
so there should be no overlap with immutable image replacement,
so this was purely precautionary).
Since we were already touching the relevant code, we also updated
the image dependency to a newer version that provides more ways
to avoid allocations, and made a few other changes that should
hopefully eliminate redundant most of the intermediate buffer
allocations we were performing for what should be zero-cost
conversions. This may slightly improve performance in some
cases.
Erased almost every instance of WORLD_SIZE and replaced it with a local
power of two, map_size_lg (which respects certain invariants; see
common/src/terrain/map.rs for more details about MapSizeLg). This also
means we can avoid a dependency on the world crate from client, as
desired.
Now that the rest of the code is not expecting a fixed WORLD_SIZE, the
next step is to arrange for maps to store their world size, and to use
that world size as a basis prior to loading the map (as well, probably,
as prior to configuring some of the noise functions).
- replace serde_derive by feature of serde
incl. source code modifications to compile
- reduce futures-timer to "2.0" to be same as async_std
- update notify
- removed mio, bincode and lz4 compress in common as networking is now in own crate
btw there is a better lz4 compress crate, which is newer than 2017
- update prometheus to 0.9
- can't update uvth yet due to usues
- hashbrown to 7.2 to only need a single version
- libsqlite3 update
- image didn't change as there is a problem with `image 0.23`
- switch old directories with newer directories-next
- no num upgrade as we still depend on num 0.2 anyways
- rodio and cpal upgrade
- const-tewaker update
- dispatch (untested) update
- git2 update
- iterations update
- swap out std::mpsc with crossbeam-channel in networking crate
- remove log spam by only logging when populating a new cache entry and not on every get
this is the part which prob has less Merge conflics and is easy to rebase
the next commit will have prob alot of merge conflics
followed by a fmt commit
- Completely removed both `log` and `pretty_env_logger` and replaced
with `tracing` and `tracing_subscriber` where necessary.
- Converted all `log::info!(...)` et al. statements to just use the
shorthand macro i.e. `info!`. This was mostly to make renaming easier.
There are several noteable changes in this commit that mean that logging
will behave differently to how it did previously.
- There are now no separate filter levels for terminal and file output.
This is a feature that is lacking in `tracing` but is set to be resolved
by https://github.com/tokio-rs/tracing/pull/508. At which point we MAY
include it.
- The default log level was previously `WARN` - it is now `INFO`.
- authc no longer uses reqwest
- image only supports PNG
- replace routille with tiny_http
- several other dependencies
- cargo upgrade
- following improvement was measured on R7 1700X:
before:
- cargo build: 3076.73s user / 4:45 total / 589 dependencies
- cargo test: 6118.38s user / 7:30 total / 959 dependencies
after:
- cargo build: 2680.54s user / 4:05 total / 480 dependencies
- cargo test: 5351.81s user / 7:04 total / 791 dependencies
- added xMAC94x to CODEOWNERS for Cargo.toml, he will protect them from now on and hit people with evil looks ;)
- removing async_serde as it seems to be not usefull
the idea was because deserialising is slow parallising it could speed up.
Whoever we need to keep the order of frames, (at least for controlframes) so serialising in threads would be quite complicated.
Also serialisation is quite fast, about 1 Gbit/s such speed is enough for messaging, it's more important to serve parallel streams better.
Thats why i am removing async serde coding for now
- frames are no longer serialized by serde, by byte by byte manually, increadible speed upgrade
- more metrics
- switch channel_creator into for_each_concurrent
- removing some pool.spwan_ok() as they dont allow me to use self
- reduce features needed
- switch `listen` to async in oder to verify if the bind was successful
- Introduce the following examples
- network speed
- chat
- fileshare
- add additional tests
- fix dropping stream before last messages can be handled bug, when dropping a stream, BParticipant will wait for prio to be empty before dropping the stream and sending the signal
- correct closing of stream and participant
- move tcp to protocols and create udp front and backend
- tracing and fixing a bug that is caused by not waiting for configuration after receiving a frame
- fix a bug in network-speed, but there is still a bug if trace=warn after 2.000.000 messages the server doesnt get that client has shut down and seems to lock somewhere. hard to reproduce
open tasks
[ ] verify UDP works correctly, especcially the connect!
[ ] implements UDP shutdown correctly, the one created in connect!
[ ] unify logging
[ ] fill metrics
[ ] fix dropping stream before last messages can be handled bug
[ ] add documentation
[ ] add benchmarks
[ ] remove async_serde???
[ ] add mpsc
It should compile and tests run fine now.
If not, the 2nd last squashed commit message said it currently only send frames but not incomming messages, also recv would only handle frames. The last one said i added internal messages and a reverse path (prob for .recv)
