Thomas Debesse [Tue, 18 Jul 2017 11:04:26 +0000 (13:04 +0200)]
[dpkdir] restart VFS only for Map_Free() and Map_LoadFile(), refresh others
Since there is no map file observer anymore for that stuff,
we Restart or Refresh it explicitely when needed.
- Opening map or New map needs Restarting VFS.
- Saving map or Renaming map (Save as) needs Refreshing VFS.
The Refresh also triggers the Texture browser.
A previous fix for #105 was done Refreshing VFS instead of Restarting it
but it was not perfect, for example map opening behavior is better with
VFS restart, and map saving needs to refresh the VFS and the texture
browser but not restart (that was the earlier fault). So, it's clearly
not a good idea to trigger either Refresh or Restart on any map event
since the behavior differs according to the event.
If one day one plugin wants to act on VFS on map event, it must refresh or
restart VFS according to what the plugin does. It does not make sense to
trigger the same task for different events.
Neumond probably thoughts it would be cool to make a file observer
that reloads the VFS each time the map change, was a nice idea.
Badly, it makes the VFS reloading itself before saving a map,
losing the current work done.
Would be easier to not rely on that observer mechanism and just
make an explicit call to reload VFS when needed instead, so we
revert this part.
This VFS reload mechanism will be reintroduced in next commit.
This commit fixes #105 even if DPK VFS is not yet fully restored.
Note: this observer mechanism was also made available to plugins, so
it's not available to plugins anymore (it was not used, and it's a bad
idea, see the next commit).
Thomas Debesse [Tue, 18 Jul 2017 11:26:30 +0000 (13:26 +0200)]
refresh VFS on map change instead of restarting VFS, fix #105
Neumond probably thoughts it would be cool to make a file observer
that reloads the VFS each time the map change, was a nice idea.
Badly, it makes the VFS reloading itself before saving a map,
losing the current work done.
Hopefull, since I added a “Refresh” ability that refreshes the VFS
without reloading the map, we can just use that Regresh ability
instead.
Thomas Debesse [Tue, 25 Apr 2017 23:02:51 +0000 (01:02 +0200)]
do not copypaste zlib
unzip.c contains many bits from an older zlib which mismatches with newer zlib loaded by libpng.
This fix just make unzip.c relying on zlib like libpng does, without copypasting it.
Thomas Debesse [Mon, 13 Mar 2017 02:41:55 +0000 (03:41 +0100)]
introduce dpk / dpkdir support
- do not rely on game name but on new dpk format
to check for DEPS and versions
- pk3 / pk3dir support is for legacy paks only
- add pk4dir support for free (legacy paks)
replace unvanquished references by daemon ones
in function/variable name for versionned vfs code
Thomas Debesse [Sat, 15 Oct 2016 18:00:27 +0000 (20:00 +0200)]
More: Using Sys_FPrintf with SYS_WRN and SYS_ERR
This commit do the same as “Using Sys_FPrintf with SYS_WRN and SYS_ERR” commit by @Pan7 (a288b9c) for occurrences that were left untouched (tools/ subtree only).
TimePath [Fri, 7 Oct 2016 13:57:13 +0000 (13:57 +0000)]
Merge branch 'nobigfirst' into 'master'
revert "allocate bigger first"
partial revert of d4fa608 ([L2313](https://gitlab.com/xonotic/netradiant/commit/8bc246a01343d9c9dd3a8b678681710cf04a2953#416ec0c19ddc04c6485e9853a0c8a125f98dca13_2295_2313))
see #54 ([13326399](https://gitlab.com/xonotic/netradiant/issues/54#note_13326399))
"allocate bigger first" change was meant to save allocation time keeping same lightmap file size, actually wastes both time and size
TimePath [Thu, 30 Jun 2016 11:33:02 +0000 (11:33 +0000)]
Merge branch 'default-srgb-color-fix' into 'master'
Fix default minimum/ambience color for sRGB lightmaps
Having _minlight or _ambient set in "worldspawn" without explicitly specifying the respective value resulted in overbright lights if -sRGB mode was specified.
Thomas Debesse [Sat, 6 Feb 2016 05:35:14 +0000 (06:35 +0100)]
lightmap allocation speed-up, add -fastallocate
- Allocate large lightmaps first to speed up the allocation process
- Add `-fastallocate` option to trade lightmap size against allocation time (useful with hi res lightmaps on large maps: reduce allocation time from days to minutes for only some extra bytes:
- If fast allocation, skip lightmap files that are more than 90% complete
- If fast allocation, do not test allocation on every pixels, especially for large lightmaps
Thanks to Kangz (Corentin Wallez) for his precious help and his kind availability.
projects / xonotic / netradiant.git / log