This makes the shading in Polymost more or less 1:1 with classic mode.
git-svn-id: https://svn.eduke32.com/eduke32@7412 1a8010ca-5511-0410-912e-c29ae57300e0
This "fixes" relative texture alignment for floors and ceilings in Polymost to match classic mode. "Fix" is in quotes because this actually means the alignment is less correct in terms of proper scaling than before, but more correct in terms of accuracy to classic mode.
git-svn-id: https://svn.eduke32.com/eduke32@7411 1a8010ca-5511-0410-912e-c29ae57300e0
Because this is a check for sprites above the sprite being moved and not a check for sprites below, the height of the sprite should not be taken into account at all here and the base of the sprite should be used instead.
git-svn-id: https://svn.eduke32.com/eduke32@7404 1a8010ca-5511-0410-912e-c29ae57300e0
This isn't really intended to fix any specific issue, but to shut up Visual Studio whining about arithmetic overflows.
git-svn-id: https://svn.eduke32.com/eduke32@7403 1a8010ca-5511-0410-912e-c29ae57300e0
This one should bring Polymost TROR into parity with classic mode.
git-svn-id: https://svn.eduke32.com/eduke32@7400 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes an issue with clipmove() caused by sectors behind walls which were candidates for clipping not being added to the list of sectors that definitely clip the player, forcing the function to fall back to a slow, sector-by-sector brute force approach. This brute force approach has also been removed in favor of something more efficient.
git-svn-id: https://svn.eduke32.com/eduke32@7398 1a8010ca-5511-0410-912e-c29ae57300e0
Long-term we will need to replace all uses of "\n" in string literals printed to disk.
git-svn-id: https://svn.eduke32.com/eduke32@7394 1a8010ca-5511-0410-912e-c29ae57300e0
There are still a bunch of warnings, but fixing warnings in deprecated code that only one guy uses anymore isn't an efficient use of time.
git-svn-id: https://svn.eduke32.com/eduke32@7387 1a8010ca-5511-0410-912e-c29ae57300e0
This bails out of drawing any domost spans that seem to be entirely outside of the range of the screen coordinates. Since this seems so obvious, I have to wonder if Polymost is supposed to be doing this elsewhere already...
git-svn-id: https://svn.eduke32.com/eduke32@7379 1a8010ca-5511-0410-912e-c29ae57300e0
It turns out hash_findcase() has never worked properly because the correct bucket would never have been searched.
git-svn-id: https://svn.eduke32.com/eduke32@7364 1a8010ca-5511-0410-912e-c29ae57300e0
Currently it passes calls through to the system libraries as before.
Also adds an incomplete implementation on PhysFS.
git-svn-id: https://svn.eduke32.com/eduke32@7359 1a8010ca-5511-0410-912e-c29ae57300e0
This avoids conflicts with folders named "textures", such as in World Tour. Thanks to enderandrew for the observation.
git-svn-id: https://svn.eduke32.com/eduke32@7347 1a8010ca-5511-0410-912e-c29ae57300e0
Add a FOV option in the menu. Range from 75 to 120 degrees (at 4:3 resolution), default is 90.
New userdef "fov". Equals the FOV in 360 degrees.
Update Polymost projection hack, so it compensates for the FOV or height of the game view.
Fix FOV in Polymer when the full status bar is visible. Now the FOV depends of the width of the game view instead of the height.
git-svn-id: https://svn.eduke32.com/eduke32@7329 1a8010ca-5511-0410-912e-c29ae57300e0
terminx
hendricks266