* 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)
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.
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.
Turns out compiling for Linux 32-bit using the Makefiles never actually defines LINUX! Apart from that, most of the existing Linux-specific code in SRB2's source code (except for tmap.s) actually uses __linux__ instead anyway
Turns out sdl12's version of this function only did stuff for DC/GP2X ports; support for them have been cut out for SDL2, so for now let's just not use the function at all
Basically, it manually sets *_FOUND, *_INCLUDE_DIRS and *_LIBRARIES instead of using find_package. Frankly I have no idea how well what I've done works currently though, not even sure if I've set the _LIBRARIES variables correctly. Again, it's WIP work, this can probably be fixed eventually I suppose.
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
Remove i_net.c
The code in i_net.c doesn't actually seem to be used in SRB2. I was able to compile a build without it, and hosting and joining netgames worked just fine (well, as fine as they can with the current state of the netcode...).
The vast majority of code in the file seems to be contained in HAVE_SDLNET ifdefs, and I'm pretty sure SRB2 has never used SDLNET in a public build. The only bit not contained in that block is I_InitNetwork(), which just prints an error and returns false.
Do we really need to keep it around? If not, I say get rid of it. It seems like useless clutter that is just going to confuse people who are trying to understand the source code.
See merge request !73
Re-factoring AA tree code from m_misc.c/m_misc.h into its own files
What the title says. The AA tree-related code now lives in the files m_aatree.c and m_aatree.h. Part of why I did this was to solve this m_misc.h/w_wad.h cyclic dependency problem (involving MAX_WADPATH and AA trees themselves) mentioned in the now-removed comments, another reason was ...only OpenGL uses AA trees at all, why include the relevent structs/functions/otherwise anywhere except where is necessary (which is very few files as it turns out)?
Otherwise, it just looked better on its own rather than mixed with all the other stuff already in the m_misc files. Not really important or anything affecting gameplay at all I guess.
See merge request !82
Also updated any relevant project files that I can think of to include the new files, as well as the makefile of course. Some of the other project files haven't been touched in years so I'll leave those alone ...unless someone objects
Do we really need to keep it around? If not, I say get rid of it. It seems like useless clutter that is just going to confuse people who are trying to understand the source code.
