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.
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
