GCC/Clang reported these warnings:
src/textures/jpegtexture.cpp:305:29: warning: data argument not used by format string [-Wformat-extra-args]
src/textures/jpegtexture.cpp:388:28: warning: data argument not used by format string [-Wformat-extra-args]
src/textures/jpegtexture.cpp:432:29: warning: data argument not used by format string [-Wformat-extra-args]
src/textures/jpegtexture.cpp:481:28: warning: data argument not used by format string [-Wformat-extra-args]
Now it is no longer necessary to provide specially set up textures for rendering shaded decals, they can use any PNG texture now that contains a proper red channel.
Handling of the alPh chunk has been removed as a result as it in no longer needed.
Even though unlikely, this should work as a regular texture because it can be used as such.
As a result of the above, true color generation needs to be done explicitly now.
Until now each subclass of FTexture had to implement the entire span generation itself, presumably so that a few classes can use simpler structures.
This does not work if a texture can have more than one pixel buffer as is needed for alpha textures.
Even though it means that some classes will allocate more data now, it's the only way to do it properly.
In addition this removes a significant amount of mostly redundant code from the texture classes.
- added alpha texture processing to all converted classes
As of now this is not active and not tested.
Note that as part of the conversion even those textures that were working as alphatextures will not look correct until the higher level code gets adjusted.
This was implemented in a way that made it entirely impossible to load Build resources and make them usable for modding.
ZDoom had Build texture support for many years but the limitations the palette handling imposed made it impossible to use them.
It wasn't usable for anything more than to load Build maps and have them display properly - a feature that had to be removed because it was irreparably broken already.
With the forced palette override out of the way it should now be possible to implement loading of Build ART files as actually usable resources.
- a bit of header cleanup.
* moved <zlib.h> and <bzlib.h> from files.h to files_decompress.cpp because they are no longer needed for defining the interface.
* added <functional> to the precompiled header
This should be dealt with at the source, not one level up, so that it also works properly if the GetReader function of the ResourceFile object is called directly and not through the resource manager.
Due to how the VM handles default parameters, these must always be identical to the parent to prevent undefined behavior.
So now, if such parameters are encountered, the compiler will either abort (for script version >= 3.3) or print a warning (for older versions.)
Any defaults being specified for older versions will be ignored, though, and the defaults of the parent function be copied to the override.
The native byte order converters were defined as macros which hid some issues due to lack of type checks.
Additionally the ???Long variants taking 'long' variables were removed, because longs are not always 32 bits so this could be destructive.
As a result of this, removed several DWORDs from struct definitions in i_crash.cpp.
* initial positioning in a subsection of a file failed. This mainly affected music playback.
* made the FileRdr constructor which takes a FileReaderInterface private so that everything that needs it must be explicitly declared as friend.
* removed a few redundant construction initializers for FileRdrs.
* loading compressed nodes needs to check the validity of its reader.
* use GetLength to detemine the size of a Zip file instead of doing another seek to the end.
* removed duplicate Length variables.
- fixed: The streaming music player must return the file reader if it fails to open, so that the next player can still use it.
- fixed: Timidity++'s Instruments class did not delete the sound font when it was destroyed.
..-
The idea here is to decouple the actual reader creation from the code using them so that, for example, the Open function can decide if it wants to open the file regularly or memory mapped and return different readers as deemed useful. For that to work the exposed object needs to be an abstract wrapper so that this can be done without having to use pointers and all the drawbacks coming from that.
So far put to use in a few parts of the music code so the general functionality could be tested.
Sorting modes are
1 - by name, from A to Z
2 - by name, from Z to A
3 - number of calls, ascending
4 - number of calls, descending
5 - total time, ascending
anything else - total time, descending
This was done after the players had already been created. To ensure that everything gets set properly it is necessary to pass the desired sample rate to the device's constructor and let it make sure that a proper sample rate gets set.
Due to the special nature of this expression the code generator got stuck in 'address' mode and passed the address of the variable instead of its value.
Note that this is just the bare abstract interface. It is up to content makers to define usable HUD message classes and optionally contribute them to the engine.
https://forum.zdoom.org/viewtopic.php?t=57116
The problem was caused by missing state label in conjunction with incomplete class
actor A : ArmorBonus
{
Inventory.ForbiddenTo "Missing"
}
actor B : Pistol
{
states
{
TNT1 A 0
Loop
}
}
The order of processing is different here so when the property gets parsed there are no states to delete.
To fix this the property just flags the class and lets the ZScript state compiler deal with this as needed.
* this has to be disabled for missiles which should explode instead of stepping up.
* interpolation adjustment was not correct
* it could crash because the target portal group could be retrieved from a non-portal sector.
The state map will just be skipped and the parser only needs to run to get over the data.
However, due to changes from a previous patch the data cannot be validated so aside from not using the data it may also not abort on errors.
- implemented a fallback both for sound font lookup and for MIDI device selection so that if some non-working combination is set up, the player will fall back to something that works.
In file included from /usr/include/c++/6/math.h:36:0,
from src/vectors.h:43,
from src/sound/i_soundinternal.h:7,
from src/sound/i_sound.h:39,
from src/sound/i_musicinterns.h:5,
from src/sound/timidity/timidity.cpp:36:
/usr/include/c++/6/cmath:407:11: error: ‘::pow’ has not been declared
VC\include\type_traits(1468): warning C4800: 'int': forcing value to bool 'true' or 'false' (performance warning)
src\sound\musicformats\music_midistream.cpp(832): note: see reference to function template instantiation 'std::function<bool (int)>::function<MIDIStreamer::SetMIDISource::<lambda_...>,int,void>(_Fx)' being compiled
src/sound/timiditypp/reverb.h:467:6: error: declaration of ‘TimidityPlus::lfo TimidityPlus::<anonymous struct>::lfo’ [-fpermissive]
src/sound/timiditypp/reverb.h:61:8: error: changes meaning of ‘lfo’ from ‘struct TimidityPlus::lfo’ [-fpermissive]
This reverts commit 8f7a503561.
# Conflicts:
# src/sound/timiditypp/playmidi.cpp
Something in here wasn't working as intended, and since it needs better synchronization let's redo it entirely.
This may cause problems because the player runs in a different thread than the input code.
Instead the play thread will now copy their values to local variables when it starts generating output.
