src/gl/renderer/gl_renderer.cpp:775:39: warning: comparison of two values with different enumeration types ('F2DDrawer::ETextureDrawMode' and 'TexMode') [-Wenum-compare]
src/gl/renderer/gl_renderer.cpp:776:39: warning: comparison of two values with different enumeration types ('F2DDrawer::ETextureDrawMode' and 'TexMode') [-Wenum-compare]
src/gl/renderer/gl_renderer.cpp:777:39: warning: comparison of two values with different enumeration types ('F2DDrawer::ETextureDrawMode' and 'TexMode') [-Wenum-compare]
src/gl/renderer/gl_renderer.cpp:778:45: warning: comparison of two values with different enumeration types ('F2DDrawer::ETextureDrawMode' and 'TexMode') [-Wenum-compare]
src/gl/renderer/gl_renderer.cpp:779:40: warning: comparison of two values with different enumeration types ('F2DDrawer::ETextureDrawMode' and 'TexMode') [-Wenum-compare]
src/gl/renderer/gl_renderer.cpp:780:45: warning: comparison of two values with different enumeration types ('F2DDrawer::ETextureDrawMode' and 'TexMode') [-Wenum-compare]
src/v_draw.cpp:1144:51: warning: '&' within '|' [-Wbitwise-op-parentheses]
src/textures/texture.cpp:1050:20: warning: comparison of integers of different signs: 'int' and 'unsigned long' [-Wsign-compare]
src\intermission\intermission.cpp(80): warning C4101: 'lumpnum': unreferenced local variable
GCC 7:
src/gl/renderer/gl_renderer.cpp:702:2: error: non-constant condition for static assertion
src/gl/renderer/gl_renderer.cpp:702:2: error: value ‘12’ of type ‘float*’ is not a constant expression
src/gl/renderer/gl_renderer.cpp:703:2: error: non-constant condition for static assertion
src/gl/renderer/gl_renderer.cpp:703:2: error: value ‘20’ of type ‘PalEntry*’ is not a constant expression
Clang:
src/gl/renderer/gl_renderer.cpp:701:16: error: static_assert expression is not an integral constant expression
src/gl/renderer/gl_renderer.cpp:701:23: note: cannot access field of null pointer
This removes the entire palette switch and all the special checks to ensure that no menu can be drawn over this image.
Instead it gives this texture its special palette in the texture manager so that the proper image is created right away.
I decided against exposing this as an editing feature because it is far too specific to this particular image and the raw page format it uses.
A quick check of /idgames shows no project ever replacing it - especially no ZDoom-based project - so no extended handling is needed to make this work with other texture formats.
- with renderers freely switchable, some shortcuts in the 3D floor code had to be removed, because now the hardware renderer can get FF_THISINSIDE-flagged 3D floors.
- changed handling of attenuated lights in the legacy renderer to be adjusted when being rendered instead of when being spawned. For the software renderer the light needs to retain its original values.
- Slightly improve how softpoly processes portals
- Pass the vertex transform matrix via a command rather than being part of the drawer args
- Improve zbuffer drawers in the software renderer
- Misc model rendering fixes
It may use the same calculations as the hardware renderer but must use the 2D drawer for display.
It should be investigated if the hardware renderer can do this as well.
This does not work with a setup where the same backend is driving both renderers.
Most of this is now routed through 'screen', and the decision between renderers has to be made inside the actual render functions.
The software renderer is still driven by a thin opaque interface to keep it mostly an isolated module.
This will cause incorrectly generated textures and the reason for this no longer exists because CreateTexBuffer is doing this as a postprocessing step now.
* the MAPINFO options now get handled in g_mapinfo.cpp and g_level.cpp, just like the rest of them as members of level_info_t and FLevelLocals.
* RecalcVertexHeights has been made a member of vertex_t and been moved to p_sectors.cpp.
* the dumpgeometry CCMD has been moved to p_setup.cpp
This fixes usage of uninitialized variable in ACSStringPool::PoolEntry objects
The initial version (before 66d15dc) increased pool size by one entry and assign all its members right after that
The improved version reserved MIN_GC_SIZE entries but didn't initialize anything except the first one
ACSStringPool::FindFirstFreeEntry() cannot find the proper entry as it uses PoolEntry::Next member for list traversal
It's enough to initialize Next member with FREE_ENTRY value because other fields will be assigned anyway inside ACSStringPool::InsertString()
https://forum.zdoom.org/viewtopic.php?t=60049
This theoretically means that the software renderer could access this data as well - if it just had been written with a more flexible texture interface.
However, as things stand, this may require quite a bit of work to achieve.
The old organization made sense when ZDoom still was a thing but now it'd be better if all pure data with no dependence on renderer implementation details was moved out.
A separation between GL2 and GL3+4 renderers looks to be inevitable and the more data is out of the renderer when that happens, the better.
Previously, only .wad files can specified without file extension for -iwad command line option
For example, -iwad square1 will load square1.pk3 as IWAD
This was originally invented to fix the sprite offsets for the hardware renderer.
Changed it so that it doesn't override the original offsets but acts as a second set.
A new CVAR has been added to allow controlling the behavior per renderer.
This also replaces DTA_ColormapStyle with proper implementations of its components. As implemented it was a very awkward mixture of various effects that already existed in a separate form. As a result of its implementation it required additional but completely redundant shader support which could be removed now. As a side effect of this change a new DTA_Desaturate option was added.
No more locking insanity! :)
There are no locking counters or other saveguards here that would complicate the implementation because there's precisely two places where this buffer must be locked - the RenderView functions of the regular and poly SW renderer which cannot be called recursively.
In its current form this is quite useless. What's really needed is to require a lock on the RenderBuffer for the 3D scene, but since this is not needed for the 2D stuff anymore it can be done far simpler.
This was a bad idea from the start and really only made sense with DirectDraw.
These days a FrameBuffer represents an abstract hardware canvas that shares nothing with a software canvas so having these classes linked together makes things needlessly complicated.
The software render buffer is now a canvas object owned by the FrameBuffer.
Note that this commit deactivates a few things in the software renderer, but from the looks of it none of those will be needed anymore if we set OpenGL 2 as minimum target.
This is a necessary first step for simplifying the texture handling in order to refactor it.
# Conflicts:
# src/gl/system/gl_swframebuffer.cpp
# src/textures/textures.h
# src/win32/fb_d3d9.cpp
This was done mainly to reduce the amount of occurences of the word FTexture but it immediately helped detect two small and mostly harmless bugs that were found due to the stricter type checks.
This merely addresses the crashing issue, it does nothing about the faulty initialization logic here that causes the chorus not to get initialized properly if reverb is active.
The issue needs more in-detail investigation but for now this has to suffice.
Notes:
* ADL: The DMX volume model was set as default to unify volumes on all bank. Otherwise, if you will use 'Generic' or 'Win9x', the sound will became too loud than wanted. Each bank has own default volume model which is used when 'Auto' is set.
* ADL: 6 chips is optimal to work with default banks
* OPN: 8 chips are set to provide 48 polyphony channels. (each OPN2 chip has 6 channels only)
* Text files: junk spaces from end of lines are was auto-removed.
Also embedded MIDI sequencer has been disabled too as it is not needed in GZDoom
I made that to allow easier updates of ADLMIDI into newer versions without of any future troubles and conflicts
Also embedded MIDI sequencer has been disabled too as it is not needed in GZDoom
I made that to allow easier updates of ADLMIDI into newer versions without of any future troubles and conflicts
src/v_video.h:56:6: error: ISO C++ forbids forward references to 'enum' types
src/v_video.h:342:17: error: field has incomplete type 'FTextureFormat'
src/v_video.h:344:47: error: variable has incomplete type 'FTextureFormat'
These cannot be done with the regular textures so there needs to be an option to create more than one native texture per FTexture. For completeness' sake there is also the option now to create a paletted version of a texture if the regular one is true color. This fixes a long standing problem that translations were not applied to non-paletted textures.
Aside from PCX 4 bit, uncompressed PCX and TGA grayscale for which I was unable to obtain test images, all others now produce proper textures in both 8 and 32 bit mode.
The old logic used a translation table that does not work with color images, it was designed to handle 8 bit grayscale images.
So now, it creates a true color buffer and then turns it into a texture with R,G,B = 255 and the alpha channel set to the grayscale value.
This was also the reason why crosshairs made from 32 bit PNGs did not show correctly.
* Instead of using the red channel it now uses the grayscale value. While slower in a few situations, it is also more precise and makes the feature more useful.
* For paletted textures do not use the index as alpha anymore but the actual grayscaled color. This is again to make the feature more consistent and useful.
* To compensate for the above there is now a list of hashes for known alpha textures in patch format, so that they don't get broken.
* IMGZ is now considered a grayscale format. There's only two known textures that use IMGZ for something else than crosshairs and those are explicitly handled.
* several smaller fixes.
* the actual color conversion functions for paletted output are now consolidated in a small number of inlines so that future changes are easier to do.
Note: This hasn't been tested yet and will need further changes in the hardware rendering code. As it is it is not production-ready.
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.
The text input field for the configs have been removed. Instead it will now present a list of soundfonts that are found in specific locations.
For that it will look in the 'soundfont' directories of the FileSearch.Directories entry of the config.
Acceptable file formats here are SF2 and zipped GUS patch sets. These zipped patch sets need to have a timidity.cfg at the root and refer to all containing data by relative path. References to outside files are not allowed here.
It is still possible to refer to sound fonts elsewhere on the hard drive by manually entering a path at the console - but these won't show in the menu and will get lost if one cycles through the list of available options.
Of the available softsynths, FluidSynth will only list SF", Wildmidi will only list GUS patch sets and Timidity++ and GUS will list both.
Please note that although the GUS synth can read SF2, the output appears to be broken die to some old bug.
This is necessary to write a universal, device independent wave dumper for MIDIs.
With each format inheriting from the main player class it is not possible to create a generic dumper player.
PathExpander has been integrated into the sound font manager and PseudoMidiDevice was only used as the base class for the old Timidity++ device with the external executable.
- allow the GUS to change sound fonts at run time.
- implemented sound font manager support in the GUS synth. This works but also made me realize that the SF2 support of this synth has been rather broken, apparently forever.
- added the missing handler for reading Timidity configs from the lump directory.
- fixed incomplete init of the GUS synth when no soundfont can be located.
- fixed bad initialization of WildMidi sampling frequency. It would default to 11.025 kHz if no valid rate was set. Now it will use the sound device's native frequency.
- final tweak to volume adjustment: Do this upon extraction for better results.
If this is done via the synth's parameters it will affect channel balance.
The given factor of 5 is necessary to roughly match the output of FluidSynth.
