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.
Until we use something besides Native MIDI to play
back MIDI music, MIDI volume changing is disabled
since it causes way too much of a damn headache.
(It's not even our fault, it's fucking MS.)
Use whatever names you want for your music. So long as you prefix the lumps with O_ or D_, it doesn't matter anymore.
DISCLAIMER: Linedef type 413 (change music) and Lua scripting is not tested.
(cherry picked from commit 025ca413a2)
# Conflicts:
# src/p_user.c
Travis-CI builds
Merge support to build SRB2 for Linux system via Travis-Ci
This will build SRB2 with GCC and Clang to make sure we do not break Linux/GNU builds
See merge request !41
Basically, Wolfy's linux (non-CMake) compiling apparently fails here, and config.in.h actually lives outside of the sdl folder. Blame a particular someone for blindly copy+pasting these includes in this file without considering the consequences when adding support for CMake everywhere.
Basically, Wolfy's linux (non-CMake) compiling apparently fails here, and config.in.h actually lives outside of the sdl folder. Blame a particular someone for blindly copy+pasting these includes in this file without considering the consequences when adding support for CMake everywhere.
Core code has too many #define dependencies on interface-specific
defines. This means that it's currently not possible to safely
separate the core and interface code into different contexts. The
core code should be refactored to accomadate for this because we
should not have any interface-specific code in core in the first
place.
This reverts the static library SRB2Core from a7135094 and instead
adds the core sources to the SRB2SDL2 target directly.
So frustrating...
Core and SDL2 are two separate targets now. Core is a static library
that is linked into SRB2SDL2. The sources for both are separated.
When using an IDE like Visual Studio or Xcode, the source code
organized into groups that explain what that group of sources does.
In the future, "Main" could be split into a few more groups based on
file prefixes, but I think the way it is set up works for now.
Makefile targets are not affected by source_groups and typing `make`
will automatically compile both the "Core" library and SRB2SDL2
itself.
It is really messy at the moment. There is no support for copying the
necessary frameworks and dylibs out to the bundle for distribution, and
it is a frankenstein of manual find_library and find_package which can
sometimes pick up Homebrew dylibs.
In some cases, the warp back to center was being detected as a mouse motion, causing all sorts of silliness with the mouse. The workaround is by only using the first motion event and ignoring every event after that, until the next call to I_GetEvent.
