NAMEcLcR sprite angle loading, take 2
HEY LOOK, A NEW SPRITE LUMP LOADING FEATURE (which isn't that new since this merge request description is literally copypasted from the one for public next)
* NAMEcL refers to a frame which is seen for the entirety of an object's left side. (ie - in 2d mode, facing to the left relative to the camera)
* NAMEcR refers to a name which is seen for the entirety of an object's right side. (ie - in 2d mode, facing to the right relative to the camera)
* NAMEcLcR does both sides, duh. I didn't break reflection.
* Having just a NAMEcL requires you to fill in the opposite side either with NAMEcn where n is 1 and 5-8 OR a NAMEcR OR a NAMEc0
* Having just a NAMEcR requires you to fill in the opposite side either with NAMEcn where n is 1-5 OR a NAMEcL OR a NAMEc0
* Switches down the centerline of the object instead of at the ANGLE_202h interval for normal sprites. Has a very small window where you can see a NAMEc1 and NAMEc5 if you only use one of NAMEcL or NAMEcR down one side.
* The specific symbols selected for this were selected for 1) ease of mental understanding (Left, Right) and 2) not getting in the way of adding support for zdoom's totally bananas 16-way sprite system at a later date if we so choose, which only goes up to G
totally makes sense for stuff like NiGHTS stuff, Axis2D stuff, and maybe if SRB1 survives the chopping block in some shape or form it can take advantage of that too
See merge request !33
* Don't allow arbitrary numbers to be used for a skin's supercolor, only strings.
* Devmode is no fun allowed mode, so turn off the god hyper flash there.
* Several new supercolours.
- SKINCOLOR_SUPERSILVER1-5 (for fun) - "Silver"
- SKINCOLOR_SUPERPERIDOT1-5 (nyeheheh) - "Peridot"
- SKINCOLOR_SUPERCYAN1-5 (for fun) - "Cyan"
- SKINCOLOR_SUPERPURPLE1-5 (for fun) - "Purple"
- SKINCOLOR_SUPERRUST1-5 (mecha/metal sonic) - "Rust"
- SKINCOLOR_SUPERTAN1-5 (shadow/silver the hedgehog) - "Tan"
* SKINCOLOR_SUPER1-5 renamed to SKINCOLOR_SUPERGOLD1-5, one index for darkest is changed - "Gold"
* SKINCOLOR_TSUPER1-5 renamed to SKINCOLOR_SUPERORANGE1-5, ported properly to the new palette - "Orange"
* SKINCOLOR_KSUPER1-5 renamed to SKINCOLOR_SUPERRED1-5, ported properly to the new palette - "Red"
* new S_SKIN attribute - supercolor - uses an entirely different function to get the names (R_GetSuperColorByName instead of R_GetColorByName)
* a fun little secret - typing "god on" in the console whilst super makes the player hyper (visual only, no sparkles - just rainbow flash) - can be removed if no fun is allowed
-warp checking for invalid map names
I've noticed a bunch of new people getting the "Cannot warp to map 0 (out of range)" error when testing their custom maps. On asking what map name they used, it was clear they didn't use a MAPxx name at all. Sadly it was not obvious to them that other kind of map names are not accepted by SRB2, so I thought it best we make that more clear in-game.
SRB2 now gives you the error "Cannot warp to map \[your input\] (invalid map name)" if you used -warp with a param that is neither a MAPxx name or a plain number.
See merge request !99
P_FindSpecialLineFromTag crash fix
This fixes the case where an in-level sector or FOF control sector with a tag of -1 or 65535 (seriously, who does that?) can possibly lead to a crash in this function when searching for heat linedef specials in 1st person. And also the same kind of crash any other sort of weird case where the tag number that function uses for searching is -1 or 65535, I suppose!
See merge request !98
Fix R_AddSingleSpriteDef's I_Error messages
Whoops, seems I forgot about this little branch. Basically this fixes how for a character's sprites, a full sprite lump name is displayed instead of just its sprite prefix in the "R_AddSingleSpriteDef: No patches found for [sprite prefix] frame [frame character]" message (unlike when it occurs for non-character sprites), resulting in something like "R_AddSingleSpriteDef: No patches found for PLAYC2C8 frame \^" which does NOT help custom character authors at all as it just confuses them instead. (for the record, the problem would actually with the ^ frame and not the ones displayed after "PLAY")
Oh, and the same problem is also fixed for this similar message: "R_AddSingleSpriteDef: Sprite [sprite prefix] frame [frame character] is missing rotations"
See merge request !95
Spr2 freeslots
Needed for Miles, generally a good idea to have around anyway. Considering Miles uses it without problems, seems to work fine.
See merge request !24
for some apparent reason the compiler didn't like the while loop condition edit on its own (it complained about inline failures for P_MobjReadyToTrigger for some reason), so I had to add that extra bit above the while loop... and it was happy again, huh
Software crashes fix... fix
Fixes a typo introduced by merge request !75 that caused upper textures to set the wrong ceiling clipping value when not visible, allowing all sorts behind the walls to be visible. This is most noticable in GFZ2 when the inside of the tunnel section is visible
...probably a good idea to make sure this one doesn't introduce any MORE visual glitches by mistake (again, compare with 2.1.15 if possible)
See merge request !93
Fix for flats with transparent pixels on slopes
This fixes how R_DrawTiltedSplat_8 unintentionally allows the cyan pixels to NOT be considered "transparent" if after being remapped, depending on sector brightness and/or linedef type 606 colormaps, the result of remapping is not palette index 247 (the cyan we typically turn transparent). That is, the original colors from the source flat graphic are not checked, but instead the __result__ of coloring the flat under the respective colormap is checked for "transparent" pixels. This is only a problem for the tilted splat drawing function, not the regular one for non-sloped planes with cyan-pixel-using flats.
I found out about this bug from the issues Ritz was having with sloped 255-alpha translucent FOFs using transparent flats and his custom COLORMAP lump (and later when he applied a linedef type 606 colormap to the FOF) for his custom map. Thankfully he has some workarounds, but this should fix the code-side issues that caused his problems in the first place.
I also fixed stuff with another splat drawing function that's not currently used atm (maybe it will be in the future, if splats themselves are ever enabled again? *shrugs*).
See merge request !92
Skybox rendering offset fix for third person/alt view camera
Fixes the issue reported in this thread: https://mb.srb2.org/showthread.php?t=41729
I dunno if this will negatively affect any existing skyboxes in SRB2's own levels, that said. I tried out THZ2 and CEZ1 with this fix at least but I forgot to compare them with how they are in 2.1.15 so _*shrugs_*
See merge request !94
OS X Makefile build setup
This merge request:
* Cleans up the OS X bundle resource location code and fixes a SIGSEGV and memory leak
* Simplifies and fixes the OS X desktop alert code, closing more leaks
* Adds the MACOSX build flag to the Makefiles, to allow building a binary (but not Mac app yet) of SRB2.
This is intended to make it easier for developers to build on Mac OS X, without having to pull in all of XCode. You can keep using CMake if you prefer.
To test, use `make -C src MACOSX=1 NONX86=1 SDL=1 NOASM=1` for a release build.
Left to do:
* Add a content bundling script to be run after building, and a flag to trigger doing that.
`MACOSX_BUNDLE` maybe?
* Somehow get access to a Mac running PowerPC and figure out how to build a multi-platform binary.
* Add the proper magic to compile using gcc if requested. (Right now, compilation is done via LLVM/Clang)
See merge request !72
