Use Premake to generate MSVC projects

[jpcy]

The 2008 and 2010 projects in misc are broken. Rather than trying to fix them, and adding 2012 support, it makes more sense to generate them all with Premake.

I've tested this on Windows 7 with 2008, 2010 and 2012, and everything works.

The precompiled SDL binaries in code/libs didn't work correctly, so I'm building SDL from source instead. I removed the files that aren't used by windows to reduce the size (~1MB instead of ~6MB).

64-bit support doesn't work because the asm files that won't build with MASM64. This is beyond my expertise.

premake5.exe is built from the latest development version of premake.
https://bitbucket.org/premake/premake-dev

There's some improvements over the existing MSVC projects:

• debugging works if you set the output path to a working Q3A install (see the top of premake5.lua for details)
• dedicated server
• GLSL files are tied to the build

[ensiform]

Why not just remove asm support ? I don't think it's any faster at this point.

[ensiform]

I also believe I had the sdl linked as it currently is in the ioq3 msvc project in my old premake script from q3pp. I'll try to dig that up later.

I thought premake5 was meant to support asm files for msvc too. Haven't really messed with it though.

[jpcy]

It's just the 64-bit build that won't compile ftola.asm and snapvector.asm, 32-bit is fine. Are there C versions somewhere?

The precompiled SDL libs linked without issue, the problem was runtime errors. Also, the 32-bit and 64-bit SDL dlls are both named "SDL.dll", which is idiotic for obvious reasons.

[ensiform]

It's installed as SDL64.dll I believe. Might just be in the git hub win64 folder as such.

[jpcy]

It turns out that the precompiled SDL libs in code/libs are static (not import), so they were never going to work after the renderer(s) were separated out as dlls. Building SDL from source is the right move.

[ensiform]

They're supposed to be dynamic ( I thought this was already fixed in msvc10 or maybe the 2008 files I can't remember), no reason to try and force feed the entire SDL source.

[jpcy]

They're static:
http://stackoverflow.com/questions/6402586/know-if-lib-is-static-or-import
http://pastebin.com/UFZz8Cfw

The MSVC2010 project in misc/msvc10 hasn't been updated since 2011 - before the renderer was moved to a dll. It's rotten.

You can "fix" the MSVC2008 project in misc/msvc by linking to dxguid (required by SDL) in the quake3, opengl1 and opengl2 projects. Add "$(DXSDK_DIR)Lib\x86\dxguid.lib" to linker inputs. When you run it, it crashes with the error "IN_Init called before SDL_Init( SDL_INIT_VIDEO )". This is because quake3, opengl1 and opengl2 all link to the static SDL lib, so they all have their own copy of SDL. The renderer dll calls SDL_Init( SDL_INIT_VIDEO ), then quake3 calls SDL_WasInit and it always returns false, because it's running a completely separate copy of SDL. So SDL needs to be linked dynamically - the precompiled static libs are useless.

[ensiform]

Can't you have it link dynamically without having the whole source built every-time with the existing headers?

[jpcy]

The official SDL libs here are import, I'll use those instead.
http://libsdl.org/download-1.2.php