data associated with a character, rather than individually as we were
planning to do with stats/inv/etc... This removes potential for DB locking when we deal with each individually, and we
should have plenty of room for additional writes within the transaction.
For anything in worldgen where you use a HashMap, *please* think
carefully about which hasher you are going to use! This is
especially true if (for some reason) you are depending on hashmap
iteration order remaining stable for some aspect of worldgen.
For anything in worldgen where you use a HashMap, *please* think
carefully about which hasher you are going to use! This is
especially true if (for some reason) you are depending on hashmap
iteration order remaining stable for some aspect of worldgen.
- Make the character screen load with an empty character list from the server, send event to the server for character creation with data, but not yet saving them to the DB.
- Working but messy character saving to DB
- Add the character_data to the client, rather than keep it in the GLobalState.
Horizon mapping is a method of shadow mapping specific to height maps.
It can handle any angle between 0 and 90 degrees from the ground, as
long as know the horizontal direction in advance, by remembering only a
single angle (the "horizon angle" of the shadow map). More is explained
in common/src/msg/server.rs. We also remember the approximate height of
the largest occluder, to try to be able to generate soft shadows and
create a vertical position where the shadows can't go higher.
Additionally, map generation has been reworked. Instead of computing
everything from explicit samples, we pass in sampling functions that
return exactly what the map generator needs. This allows us to cleanly
separate the way we sample things like altitudes and colors from the map
generation process. We exploit this to generate maps *partially* on the
server (with colors and rivers, but not shading). We can then send the
partially completed map to the client, which can combine it with shadow
information to generate the final map. This is useful for two reasons:
first, it makes sure the client can apply shadow information by itself,
and second, it lets us pass the unshaded map for use with level of
detail functionality.
For similar reasons, river generation is split
out into its own layer, but for now we opt to still generate rivers on
the server (since the river wire format is more complicated to compress
and may require some extra work to make sure we have enough precision to
draw rivers well enough for LoD).
Finally, the mostly ad-hoc lighting we were performing has been (mostly)
replaced with explicit Phong reflection shading (including specular
highlights). Regularizing this seems useful and helps clarify the
"meaning" of the various light intensities, and helps us keep a more
physically plausible basis. However, its interaction with soft shadows
is still imperfect, and it's not yet clear to me what we need to do to
turn this into something useful for LoD.
- Add font configuration in internationalization files
- Scale font size using a configurable ratio
- Add a script to identify translation item statuses using Git metadata
- Execute the i18n script in a new gitlab-ci step (delayed)
- Clone haxrcorp_4089_cyrillic_altgr font (haxrcorp_4089_cyrillic_altgr_extended)
to add some additional latin characters (mainly for French)
- soil production (currently disabled).
- debris flow erosion (combined with regular stream power law).
- flow computation using multiple receivers.
- filling strategy during drainage network calculations.
Also tweaks a variety of other aspects of erosion.
- Added a localization system in voxygen
- Support English and French languages
- Added a configuration option in the interface settings to change
the language
This is a `cargo update -p conrod_core` to bring in updates to
`veloren/conrod/conrod_core` to add support for copy and paste.
Ref: veloren/conrod!2
Fixes#171
Currently we only do this when no players are in range of the chunk. We
also send the first client who posted the chunk a message indicating
that it's canceled, the hope being that this will be a performance win
in single player mode since you don't have to wait three seconds to
realize that the server won't generate the chunk for you.
We now check an atomic flag for every column sample in a chunk. We
could probably do this less frequently, but since it's a relaxed load it
has essentially no performance impact on Intel architectures.
This uses a more recent version of cpal (a dependency of rodio hence the
rodio change) which seems to have fixed a crash due to
'device not available: "Invalid argument"' coming from Alsa.
The change in cpal also made some functions now return `Result` instead
of a bare type which I dealt with by using `expect` to minimize how far
these changes fan out into the code but maybe this isn't ideal.
Fixing https://gitlab.com/veloren/veloren/issues/280 - Crash with ALSA
