A value of 1 in freesrc for Mix_LoadWAV_RW and Mix_LoadMus_RW calls SDL_RWclose on the RWops anyway.
For Mix_LoadWAV_RW the RWops is freed right after the data is loaded (because it makes a copy of the data in memory)
For Mix_LoadMUS_RW the RWops is freed when Mix_FreeMusic is called (because the data is not a copy)
So setting 1 on freesrc doesn't actually free the RWops immediately on Mix_LoadMus_RW *unless* it failed to load any music.
Checks for the flag when freeing, and if it's 0, we free the data manually after Mix_FreeChunk.
I went back to Z_Malloc and Z_Free for this because they still work after this.
* Mixer code has been in mixer_sound.c; this file is not invoked unless compiling with NOMIXER=1
* Remove everything under #ifdef HAVE_MIXER because this is never triggered
* Comment out #ifdef HAVE_LIBGME because we don't support playing music anyway (but theoretically, it could have worked separately from Mixer)
* Stub new music calls
* Stop-gap for now. Ideally the logic would be in the respective places.
# Conflicts:
# src/sdl/mixer_sound.c
(cherry picked from commit eae5d3333f5001512c82f22f2b1433a955b3a6c3)
* S_Init -> S_InitSfxChannels because it did mostly SFX anyway
* S_MusicPlaying, S_MusicPaused, S_MusicName, S_MusicExists new status methods
* I_MusicPlaying, I_MusicPaused
(cherry picked from commit f5f0b5e76c2fd405c8cc895dde653c5ed2652622)
* In s_sound, they are merged to one method as well, but there are still two separate digvolume and seqvolume variables
* Simplified Dig/MidiMusicDisabled in s_sound
* Method reordering
(cherry picked from commit 701cc5a7dd1dfead87a42ec7558c9fa6a1deb193)
With that, I moved R_CreateColormap2's exclusive software colormap malloc code to R_CreateColormap, and merged the two software-only blocks of code into one. I also disabled any unneeded variables and fixed a preprocessor-related goofup
* V_DrawFixedPatch and ilk:
* Change the offset of V_FLIP so it's not one screen-pixel off where its non-flipped sprite would have started being drawn from.
* Write to x and y as well as desttop so that anti-screen-overflow checks later in the function behave properly with non-green resolutions.
* V_DrawFill:
* Reduce number of operations performed upon `c`.
* V_DrawString and ilk:
* Offset the left and right boundary checks in non-green resolutions such that you can actually draw stuff to the left of basevid screen x coordinate 0.
* Stop orphaning their memory. They ARE PU_LEVEL, so they'll disappear eventually, but, like... it's not good memory management practice to just *orphan* them when you're literally never going to do anything with them ever again. Y'know?
* Make ghosts spawn properly on slopes.
* Fix that thing where ALL transparent FOF planes were continuously fullbright unless encased in a fog which disables sprite fullbrightness, which was long-hated by many people in the community!
* For backwards compatibility, setting flag 1 in that fog field (which is probably the most common "in-the-wild" usage of this feature) will continue to make objects un-fullbright.
* For situations where you desperately want the behaviour to be enabled, you can apply fog flag 2.
* Change the fadestart and fadeend range in which colormaps are generated.
* The problem HERE was that the darkest light level reached by generated colormaps was actually slightly brighter than the darkest level reached by normal colormaps.
* The typo I fixed does have SOME basis in fact - standard colormap lumps are 34 (33 in 0-indexing) long rather than 32 (31), but whoever wrote this didn't realise that the code for generating them didn't do it DooM style, just bright-to-dark with no extras on the end...
Also tweaked a weird splitscreen check in HWR_DrawSpriteShadow; still investigating whether stplyr is ever not player 2 when it's player 2's view, but this looks better for now
Move old fix for too large maps having rendering issues from R_CheckBBox to OpenGL's HWR_CheckBBox
From what I know, this effects at least Aerial Garden and Seraphic Skylands
The FixedMul() C implementation would produce off by one results,
causing constant desyncs on 64 bit builds and builds without an
ASM implementation of the function.
This is fixed by shifting instead of dividing, possibly avoiding
rounding errors.
gcc accepts
__asm__ ( "" : : : "%cc");
but not clang:
error: unknown register name '%cc' in asm
:"%cc", "%edx" // edx and condition codes clobbered
'cc' is not a register, thus '%cc' is rightfully not accepted.
Repro: build the project on x86_64 with:
cmake -H. -Bbuild -DCMAKE_C_COMPILER=clang -DCMAKE_SIZEOF_VOID_P=4 -DCMAKE_C_FLAGS="-m32"
This makes OpenGL stop using a specific function that doesn't really do anything for it anymore. It looks like it was used for a hack that would change the colour of polygons for the flashpal equivalent in DOOM.
I made it so ST_DoPaletteStuff doesn't set the flashpal in OpenGL as it already does its own hacky overlay and doing that would cause all the textures to be flushed more mid-level, it could be enabled for more correct flashpals, but they still wouldn't effect fog or lighting.
This means the palette will be set when going to the title screen, and twice when starting a map, (causing the OpenGL cached textures to also be flushed at those times)
This means that, if the three paths are not the same, you should be able to tell if at least one of them has a file that just had a bad MD5. Most relevant for Linux peeps I expect.
Note: Untested as of writing
I don't fully understand this, but it's what software does and it fixes the issue of the lighting in DSZ3. Also don't need the extra call to R_Prep3DFloors.
I don't think it does anything for us anymore, and might even break things with slopes.
Someone let me know if I'm wrong and am breaking things horribly here.
Transformation based on screen space would make sense if we didn't want anything in the world to effect the sprites.
This should allow sprite splitting and sorting of sprites with level geometry easier.
stransform is no longer needed.
Solid walls *can* be cut
Fix issues with water and fog FOFs not cutting each other out correctly
Fix Fog colourmap and lighting setting that is done here.
Remove HWR_SplitFog
There is currently a bug with FF_DOUBLESHADOW (that also exists in software) but has a larger impact here. When 2 FF_DOUBLESHADOW lights are directly stacked on each other the bottom one has its height set incorrectly. This causes all the Fog in the timed gravity flipping section of ERZ2 to be drawn and it looks really bad.
This reverts commit 121fcd8369.
The reason I am reverting this is because the last commit actually fixes the *old* screenshot functionality, as the screen is being drawn back onto the buffer after they're swapped in the "real" size. Meaning the old function actually works perfectly fine now.
They still aren't perfect, but now they are at least not quite so obviously just translucent polygons over the level. A mixture between partially modulating the background colours and adding the fog colour. Notably white fog blocks look like they're brightening what's behind them.
Additive was also setting noalphatest before, can probably decide that depending on what it needs anyway. I don't think it's currently used anyway.
Sorts all translucent sprites and MD2s so they're drawn after all the opaque ones. Fixes most of the observable issues between translucent MD2s and opaque sprites/MD2s.
Only use glCopyTexImage2D when first creating the screen texture, use glCopyTexSubImage2D anytime after that as it does not define a new texture each time.
Flushing of the screen textures has been implemented for when the screen size changes (so that the screen textures don't stay at a wrong size) and the game is closed, I believe they would leave a memory leak before.
The Far clipping plane did not need to be nearly as high as it was, the new value is 32768, which I suspect is about how far software can render before it completely falls apart.
It is desirable to increase the near clipping plane to between 6-10, but it can introduce more issues with close geometry not being drawn when the player or camera is scaled or viewheight is set to MIN in first person view. It would also stop sprites from being drawn ever so slightly too early, but this isn't too much of an issue and isn't too noticeable with those values. Might look into scaling near clipping plane in accordance to camera scale in the future.
The reason for wanting to increase the near clipping plane is because the small value can cause very noticeable Z-fighting where there shouldn't be on older GPU's, usually Intel ones, that don't support 24-bits for the depth buffer.
* fix screen to properly truncate the filename to just the real name only
* if the real name itself is too long, use ellipsis and paste in parts of the start and end of the actual name
note: I haven't actually tested if this works or compiles yet, I haven't the time right now
