You can modify changelevel entities to work in multiplayer: https://github.com/ValveSoftware/halflife/blob/5d761709a31ce1e71488f2668321de05f791b405/dlls/triggers.cpp#L1466
Disable the deathmatch check and add a g_pGameRules->IsMultiplayer() check to disable the transition volume check. You may also want to disable transitioning of entities since that's not really going to work well in multiplayer.
Forum posts
- Forums
- Posts
- Posted by
Solokiller
Did you mark the door to start open? Decals are applied after all entities have spawned, but this means that doors with start open set or trains that are set to be moved elsewhere won't be where they are in the editor when the decals are applied.
I built an event system so UI, client and server code isn't all over the place. The engine updates the UI state directly and some server code will directly call client code when running as a listen server. To avoid this all of the code will dispatch events that can be listened to.
Events are registered before use and can have a data type registered along with them that carries that event's specific data, for instance when a map starts loading an event is dispatched containing the map name, previous map name, whether it's a changelevel or a new map, and whether it's being loaded from a saved game.
This makes the event system type safe, allowing data to be easily passed around.
It's pretty easy to register listeners for specific events, if the event has data you can register a listener that takes that specific data type and just register it, it'll figure out the event name from that.
I'm designing the engine with the possibility that systems will be separate between client and server, so for instance there can be separate command systems so the server can't just execute client commands directly when running a listen server.
Still working on networking, i've been trying to figure out how exactly the engine does things, it's slowly getting there.
Events are registered before use and can have a data type registered along with them that carries that event's specific data, for instance when a map starts loading an event is dispatched containing the map name, previous map name, whether it's a changelevel or a new map, and whether it's being loaded from a saved game.
This makes the event system type safe, allowing data to be easily passed around.
It's pretty easy to register listeners for specific events, if the event has data you can register a listener that takes that specific data type and just register it, it'll figure out the event name from that.
I'm designing the engine with the possibility that systems will be separate between client and server, so for instance there can be separate command systems so the server can't just execute client commands directly when running a listen server.
Still working on networking, i've been trying to figure out how exactly the engine does things, it's slowly getting there.
At the moment it's hardcoded yes, this is still early in development and i haven't gotten to the point where map loading is done like the original. Please remember that it will take months if not years for this to get to a playable state.
Half-Life can't be converted to 64 bit because parts of it depend on it being a 32 bit application, like for instance function lookup where pointers are cast to a 32 bit int.
SharpLife can't be ran as 64 bit since it has to be in the same process space, which forces the use of 32 bit.
SharpLife can't be ran as 64 bit since it has to be in the same process space, which forces the use of 32 bit.
You need to install the 32 bit Net Core runtime and SDK.
If you're having problems even getting it to launch then go to sharplife_full/cfg/SharpLife-Wrapper-native.ini and set DebugLoggingEnabled to true, then look in SharpLifeWrapper-Native.log in the Half-Life directory, it might tell you some useful things.
Your problem is probably that it's trying to run as 64 bit so it fails to load 32 bit binaries.
If you're having problems even getting it to launch then go to sharplife_full/cfg/SharpLife-Wrapper-native.ini and set DebugLoggingEnabled to true, then look in SharpLifeWrapper-Native.log in the Half-Life directory, it might tell you some useful things.
Your problem is probably that it's trying to run as 64 bit so it fails to load 32 bit binaries.
What are you trying to use SDL2.dll for? You shouldn't need to compile the native wrapper yourself, if you do you should just use the one in Half-Life. There shouldn't be any need to reference the file explicitly though.
The wrapper does only one thing and that's bootstrapping the Net Core host. You shouldn't need to touch it unless there's a problem with it or if you need some interop with the engine somehow (you probably won't).
I've removed the need to use a local NuGet package source, all assemblies are now either from the standard NuGet package source or a local assembly reference in sharplife_full/assemblies.
I've also implemented the basics for client-server stuff, up to loading game assemblies. Before i can continue i need to get the networking system done so that all works, since map loading relies on it to load the data on the client (clients always use data from the server to load content, even if it's a listen server).
This'll probably take a while so don't expect it to work from the start.
As far as using local assemblies goes, when ImageSharp is updated i'll use the NuGet version, same for Veldrid. The assemblies will still be committed to allow anybody to run it though, so it only really changes how the dependencies are managed.
I've also upgraded all projects to use Net Core 2.1.
The wrapper does only one thing and that's bootstrapping the Net Core host. You shouldn't need to touch it unless there's a problem with it or if you need some interop with the engine somehow (you probably won't).
I've removed the need to use a local NuGet package source, all assemblies are now either from the standard NuGet package source or a local assembly reference in sharplife_full/assemblies.
I've also implemented the basics for client-server stuff, up to loading game assemblies. Before i can continue i need to get the networking system done so that all works, since map loading relies on it to load the data on the client (clients always use data from the server to load content, even if it's a listen server).
This'll probably take a while so don't expect it to work from the start.
As far as using local assemblies goes, when ImageSharp is updated i'll use the NuGet version, same for Veldrid. The assemblies will still be committed to allow anybody to run it though, so it only really changes how the dependencies are managed.
I've also upgraded all projects to use Net Core 2.1.
I'll get the package stuff sorted out, right now there's a couple beta versions in use and the SDL2 library is a custom build to work around a problem in the older version used by the game.
I think we've established by now that nobody's using Mono or Gtk.
The source code and game files can be found in these repositories:
https://github.com/SamVanheer/SharpLife-Engine
https://github.com/SamVanheer/SharpLife-Install
Put SharpLife-Install in Half-Life/sharplife_full and define the STEAMCOMMON environment variable to point to the steam/steamapps/common directory.
@Solokiller, how is your work in process? Rendering nsp and wad and can we have sourcesI'm working on implementing the client-server architecture so there's nothing new to show.
The source code and game files can be found in these repositories:
https://github.com/SamVanheer/SharpLife-Engine
https://github.com/SamVanheer/SharpLife-Install
Put SharpLife-Install in Half-Life/sharplife_full and define the STEAMCOMMON environment variable to point to the steam/steamapps/common directory.
Veldrid is .NET Standard, not .NET Core so it should work fine with .NET Framework based projects: https://docs.microsoft.com/en-us/dotnet/standard/net-standard
Veldrid does make it easy to swap backends, but you will need to account for backend specifics quirks, like for example using samplers in OpenGL requires you to add the sampler to resource sets in a specific order to make it affect rendering, and shader outputs may be flipped vertically, requiring you to change the shader to output something different. You will generally also need shaders specific for a given backend, but SPIR-V intermediate compilation may make that relatively simple.
BSP rendering isn't terribly difficult once you get the data part going, but if you're making an editor you'll need to make sure to mark buffers as dynamic. I don't know what the best approach is for that kind of stuff, it depends on the cost difference between static and dynamic buffers.
I'm trying to modularize my code as much as possible, so BSP rendering should be standalone for the most part, but it's probably still going to have some dependencies on the file format. Still, the shaders can be reused for drawing in-editor. The current LightMappedGeneric shader is pretty much what you'd use in an editor, aside from maybe simple light shading like Source does to show the difference between face normals.
I have thought about maybe having some kind of support added to Sledge to add some new stuff eventually, but that'll require a new map format. I haven't looked at its source code yet so i don't know how easy that would be, but given that it's open source and written in C# it's the best way to open up new possibilities for content creation.
Veldrid does make it easy to swap backends, but you will need to account for backend specifics quirks, like for example using samplers in OpenGL requires you to add the sampler to resource sets in a specific order to make it affect rendering, and shader outputs may be flipped vertically, requiring you to change the shader to output something different. You will generally also need shaders specific for a given backend, but SPIR-V intermediate compilation may make that relatively simple.
BSP rendering isn't terribly difficult once you get the data part going, but if you're making an editor you'll need to make sure to mark buffers as dynamic. I don't know what the best approach is for that kind of stuff, it depends on the cost difference between static and dynamic buffers.
I'm trying to modularize my code as much as possible, so BSP rendering should be standalone for the most part, but it's probably still going to have some dependencies on the file format. Still, the shaders can be reused for drawing in-editor. The current LightMappedGeneric shader is pretty much what you'd use in an editor, aside from maybe simple light shading like Source does to show the difference between face normals.
I have thought about maybe having some kind of support added to Sledge to add some new stuff eventually, but that'll require a new map format. I haven't looked at its source code yet so i don't know how easy that would be, but given that it's open source and written in C# it's the best way to open up new possibilities for content creation.
Code conversion from one language into another happens very often.My point is that you'd have to heavily modify the code just to make it work and not be the ugly mess that Quake code is. I won't be doing anything like that so it doesn't matter.
Besides, the ASM is only the sped-up 256 color software-renderering code so that's really irrelevant.
So far i've just been making it all from scratch since the original version is such as mess. Thanks for bringing this up before we got any Quake code in there.
I forgot one item on the list of systems: User Interface. That'll probably be a custom design, unless i can find a library for that.
I'm not using Quake code directly, i'm referencing it to rebuild parts of GoldSource. I can't change the license because i'm using code from the SDK to rebuild parts.
You won't find actual Quake code in this because it's C code and pretty outdated. You wouldn't be able to to see any matching code as a result since it's still completely rewritten.
EDIT:
We've talked this over and we've concluded that no actual Quake code is in use at all, and the Quake license states this:
From now on i won't reference Quake anymore when working on this project, so there will be no legal issues with that codebase.
I've taken this opportunity to make a list of systems that are needed to make a working GoldSource engine, and how Quake relates to it:
Also of note: Quake is C with some assembly, which can't be used in C#. GoldSource has a C engine and largely C++ game logic. Quake code would have to be heavily modified to even be usable, to the point where it has to be redesigned from scratch to be useful. Since Quake and GoldSource rely on global variables in many areas, any properly designed C# equivalent would be drastically different.
Thus, no licensing issues.
You won't find actual Quake code in this because it's C code and pretty outdated. You wouldn't be able to to see any matching code as a result since it's still completely rewritten.
EDIT:
We've talked this over and we've concluded that no actual Quake code is in use at all, and the Quake license states this:
These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.
From now on i won't reference Quake anymore when working on this project, so there will be no legal issues with that codebase.
I've taken this opportunity to make a list of systems that are needed to make a working GoldSource engine, and how Quake relates to it:
- Platform specific code used for window, input, graphics management: Provided by SDL2
- Platform specific code used for file input/output: provided by NET Core APIs
- Common code (tokenization, string utility functions): Tokenization code comes from multiplay_gamerules.cpp, string utility functions are provided by NET Core APIs
- Math functions: Provided by NET Core APIs
- Graphics: Provided by Veldrid, GoldSource specific code derived from public SDK code and completed by me
- Sound: Provided by FMOD SoundSystem library
- Memory management: Quake memory management is largely obsolete even in modern Quake derivatives, and C# doesn't allow that kind of control anyway
- File loading: Derived from SDK code
- Networking: I'll be using a networking system built using a NET Core library and ProtoBuf, completely different from Quake's QSocket and Quake 2's NetChan (used by GoldSource). GoldSource's networking code is pretty terrible so reusing any of it is a waste of time and effort anyway
- Various engine and game logic functions: derived from SDK code (parts of Quake engine code were moved into game code in Half-Life), missing parts can be re-implemented
Also of note: Quake is C with some assembly, which can't be used in C#. GoldSource has a C engine and largely C++ game logic. Quake code would have to be heavily modified to even be usable, to the point where it has to be redesigned from scratch to be useful. Since Quake and GoldSource rely on global variables in many areas, any properly designed C# equivalent would be drastically different.
Thus, no licensing issues.
Valve doesn't approve of Xash because they used leaked code, not because of the license. People have used Quake code in tools and mods before with no problems from Valve. Even Sven Co-op has some code taken from Quake in it, and that was before they got the engine.
Even if they don't approve, if they don't send a cease and desist it doesn't matter anyway. Projects like ReHLDS have been going for years doing things far worse than mixing the two codebases with no legal issues.
Even if they don't approve, if they don't send a cease and desist it doesn't matter anyway. Projects like ReHLDS have been going for years doing things far worse than mixing the two codebases with no legal issues.
I think i'll stick to porting Quake's code and updating it to work like GoldSource does it, no need to start breaking stuff by using physics code from some book.
I wrote the code to load both file types.
I've only completed these two things, i haven't even started on entities.
I've only completed these two things, i haven't even started on entities.
Alright i think we've talked enough about Mono, this project uses NET Core so all that's irrelevant anyway.
Progress update:
BSP & WAD loading is finished, currently rendering the entire map but the code can be adjusted to use VIS data pretty easily.
Now i'll have to make sure the camera angles are correct so movement is properly translated and everything, since at the moment the world is actually sideways.
Progress update:
Now i'll have to make sure the camera angles are correct so movement is properly translated and everything, since at the moment the world is actually sideways.
NET Core runs on Linux and Mac natively, it doesn't run through WINE, it doesn't compile to native code like Mono does.
The --self-contained option packages the runtime along with the exe, but it doesn't embed assemblies into the exe. For reference, SharpLife references the default 32 bit installation directory at this time, though it may eventually change when i get to testing the Linux version.
The --self-contained option packages the runtime along with the exe, but it doesn't embed assemblies into the exe. For reference, SharpLife references the default 32 bit installation directory at this time, though it may eventually change when i get to testing the Linux version.
Posted 6 years ago2018-07-18 15:56:11 UTC
in Decreasing a texture's scale drastically increases the map's filesize and compiling time. Post #340180
in Decreasing a texture's scale drastically increases the map's filesize and compiling time. Post #340180
That has to do with lightmap scale, which is tied to texture scale in GoldSource. You'll have to scale the actual textures to avoid that.
I set my projects to copy local assemblies so all of the required files are in the assemblies directory. It's a simple solution.
C# is managed code, so there is no need to make a native executable, not that it would matter in this case anyway since the executable is the original Half-Life executable which i can't replace. My code is all libraries, so combining them isn't an option either way.
The command you're using uses a Mono tool to consume a .NET Core executable, obviously that will never work.
C# is managed code, so there is no need to make a native executable, not that it would matter in this case anyway since the executable is the original Half-Life executable which i can't replace. My code is all libraries, so combining them isn't an option either way.
The command you're using uses a Mono tool to consume a .NET Core executable, obviously that will never work.
Well i like it.
Veldrid uses ImageSharp for texture loading, no other libraries are needed.
Nothing yet, it's mostly backend stuff. I'm about to start implementing texture management, that's where things will change a bit. The original engine has a limit on the number of textures, how large they can be, etc. There's no reason why there would be any limitations here.
Framerate's pretty good, should probably clamp it though.
Sure let me just write an entire GUI library before i can start drawing stuff on-screen.
ImGui is meant for debugging, not actual UI development. It's easy to use, fast and there's already a library for it.
If you need to show blocks of code use pre tags: https://twhl.info/wiki/page/TWHL:_WikiCode_Syntax#wiki-heading-16
ImGui is meant for debugging, not actual UI development. It's easy to use, fast and there's already a library for it.
If you need to show blocks of code use pre tags: https://twhl.info/wiki/page/TWHL:_WikiCode_Syntax#wiki-heading-16
Now i can start adding ImGui based menus and debug output to make things easier, and load 2D and 3D data to render it. That represents a sizeable chunk of what's needed in the engine.
Posted 6 years ago2018-07-13 08:28:46 UTC
in Compiling issue. asking for a file with the .p0 file type when it doesnt exist Post #340133
in Compiling issue. asking for a file with the .p0 file type when it doesnt exist Post #340133
RMF stores brushes as floating point, MAP stores as integer. If you have brushes with strange face angles the result could become invalid when converted to MAP. If you're using an editor that has the option to export to MAP with floating point coordinates, enable it to see if it works.
The problem has been solved, i can now continue implementing the renderer.
I've been working on getting Veldrid integrated, unfortunately i've encountered a showstopper bug: https://github.com/mellinoe/veldrid/issues/100
Basically Veldrid doesn't work in 32 bit applications (and it should), so i can't get this to work until that's fixed. I hope the problem can be found soon, but there's no telling where the problem is.
Beyond that i can do some work writing libraries to load BSP, MDL, SPR, etc file types to make things easier down the road.
Basically Veldrid doesn't work in 32 bit applications (and it should), so i can't get this to work until that's fixed. I hope the problem can be found soon, but there's no telling where the problem is.
Beyond that i can do some work writing libraries to load BSP, MDL, SPR, etc file types to make things easier down the road.
Windows Defender is marking Hammer as a password stealing malware, so i cant test it. I suggest you reinstall Hammer from a trusted source, such as this: http://www.slackiller.com/hlprograms.htm
EDIT: Seems that you installed some kind of modified Hammer, from the file "Readme_PACK.txt":
EDIT: Seems that you installed some kind of modified Hammer, from the file "Readme_PACK.txt":
Hammer improvement Pack unofficial 3.5.2 // version 2.0 made by Cellulo aka Kato-yuen www.flat2d.com August 26 2012
- added Hammer 3.5 beta with some new tweaks in the interface based on CSM HAMMMER Editor 0.3.8.1 (http://cs-fun-pro.com/load/35-1-0-313)
and VHE Neon ( http://gamebanana.com/cs/tools/5130).
Mediafire is blocking the download, you'll need to host it somewhere else.
The configuration looks good, nothing wrong there.
What i meant about Hammer was putting the entire directory in a rar and giving it to us. With that we can see if Hammer or the compile tools are broken somehow.
If that fails the only thing i can think of doing is using TeamViewer to check your installation directly.
What i meant about Hammer was putting the entire directory in a rar and giving it to us. With that we can see if Hammer or the compile tools are broken somehow.
If that fails the only thing i can think of doing is using TeamViewer to check your installation directly.
It's definitely running them in the wrong order.
Go to your Hammer installation directory and give us the GameCfg.wc file you find there. It contains your Hammer configuration, we'll take a look at it and see if anything's wrong there.
If possible, try to provide the entire Hammer directory, containing the executable, configuration file and compile tools. That'll make replicating your problem easier.
You don't need to include any map sources if you don't want to.
Go to your Hammer installation directory and give us the GameCfg.wc file you find there. It contains your Hammer configuration, we'll take a look at it and see if anything's wrong there.
If possible, try to provide the entire Hammer directory, containing the executable, configuration file and compile tools. That'll make replicating your problem easier.
You don't need to include any map sources if you don't want to.
Ok, then try this: compile the map 4 times, each with only one of the stages enabled. Show us the logs for each of those so we can see what it's doing for each. Make sure to add which tool you enabled for each log.
The idea is to see if having a tool enabled actually runs that tool or if it runs something else, that'll tell us whether Hammer is invoking the wrong tool or if something else is wrong.
The idea is to see if having a tool enabled actually runs that tool or if it runs something else, that'll tell us whether Hammer is invoking the wrong tool or if something else is wrong.
Hammer can have multiple configurations so you can make maps for different games. Make sure the correct one is selected when you compile this map.
Ok so it's definitely running CSG last. Are you sure the build programs are correct, and that you're using the configuration you've showed us? Hammer can have multiple and you have to select it when you load the map.
If that's all correct then Hammer must be executing them out of order, which doesn't make sense. Do you use a custom compile configuration?
If that's all correct then Hammer must be executing them out of order, which doesn't make sense. Do you use a custom compile configuration?
Use the latest tools, show us the compile log. We can't help you unless you do that.
Make sure you're using the latest tools, then show us the complete log. Make sure it's in order, so if CSG is really at the end then it shows that there's a problem.
You're not using the latest compile tools, the output differs from mine. Make sure you're using VHLT 34: https://twhl.info/thread/view/17830?page=1
The map will never load in the game until it can compile successfully, so that's the problem you need to look at first.
The map will never load in the game until it can compile successfully, so that's the problem you need to look at first.
You forgot to show CSG, so either you missed it or it's not turned on.
You need to put everything in a path with no spaces in it, otherwise it will fail to open and/or copy files.
Try validating games files. If that doesn't work, delete the BSP file and recompile it.
I removed all of the env_sprite entities and then compiled it. It compiled fine using VHLT V34 and loads once i've placed vnam.wad in the game directory.
Aside from missing spawn points it works just fine.
Are you loading this in Counter-Strike 1.6 or Condition Zero, did you use different compilers and are you absolutely sure it's the correct bsp file?
Aside from missing spawn points it works just fine.
Are you loading this in Counter-Strike 1.6 or Condition Zero, did you use different compilers and are you absolutely sure it's the correct bsp file?
That error can only happen in two situations:
1. A brush entity had its brush deleted from the map during compilation, causing the game to reference a non-existent brush
2. You're using a brush model name as a sound name somewhere
It's probably the first, so check if the compiler is doing any of that. Compile with verbose output set to the highest level, enable any additional output if possible.
Otherwise you'll have to check to see if there are any weird brush entities. Since it's complaining about the first brush model the map is either small or its brush model data is invalid somehow.
Also make sure that the compiler is actually putting your map where it's supposed to be, otherwise you could be trying to run an older version.
1. A brush entity had its brush deleted from the map during compilation, causing the game to reference a non-existent brush
2. You're using a brush model name as a sound name somewhere
It's probably the first, so check if the compiler is doing any of that. Compile with verbose output set to the highest level, enable any additional output if possible.
Otherwise you'll have to check to see if there are any weird brush entities. Since it's complaining about the first brush model the map is either small or its brush model data is invalid somehow.
Also make sure that the compiler is actually putting your map where it's supposed to be, otherwise you could be trying to run an older version.
Posted 6 years ago2018-07-01 09:27:44 UTC
in Any way to increase the number of gibs when you kill an enemy? Post #340035
in Any way to increase the number of gibs when you kill an enemy? Post #340035
cl_gibcount was added to Sven Co-op, it doesn't exist in the vanilla game.
The number of gibs spawned is hardcoded: https://github.com/ValveSoftware/halflife/blob/master/dlls/combat.cpp#L303
The second value passed to SpawnRandomGibs defines how many are spawned.
The number of gibs spawned is hardcoded: https://github.com/ValveSoftware/halflife/blob/master/dlls/combat.cpp#L303
The second value passed to SpawnRandomGibs defines how many are spawned.
Posted 6 years ago2018-06-27 14:19:42 UTC
in Skybox solids behaving weird when compiled with default compilers? Post #340020
in Skybox solids behaving weird when compiled with default compilers? Post #340020
The skybox does not have any clipnodes generated for it when using old compilers. Newer ones will generate them by default, but that can be disabled with -noskyclip. This thread has a bit more information: https://forums.svencoop.com/showthread.php/38059-ARCHIVE-Custom-ZHLT-by-vluzacn?p=478658&viewfull=1#post478658
It's still pretty early on in development, it won't be anywhere near ready for months.
It will have an OpenGL 3 based backend, which means better graphics performance and better effects if you want it, increased/eliminated engine limits, better networking, better debug overlays, better entity management for programmers. Limits that depend on fixed size buffers are now unlimited as long as there's no need to network the data.
There's a lot that i can't predict can be done until we get there but on the whole it's better than the original.
It will have an OpenGL 3 based backend, which means better graphics performance and better effects if you want it, increased/eliminated engine limits, better networking, better debug overlays, better entity management for programmers. Limits that depend on fixed size buffers are now unlimited as long as there's no need to network the data.
There's a lot that i can't predict can be done until we get there but on the whole it's better than the original.
Technically it's neither. Xash is illegal and porting GoldSource would also be illegal. It's a mod that replicates the engine's behavior without using original GoldSource engine code.
The new SharpLife engine is running under Half-Life as a mod now, having taken over execution. Now all further development should be done in C# only.
The engine codebase is now on Github: https://github.com/SamVanheer/SharpLife-Engine
I've worked around the SDL2 issues by renaming the library used by the managed libraries. This means there are 2 SDL libraries being used.
It doesn't appear to be causing problems so far though.
EDIT: spoke too soon, using multiple libraries causes problems because the engine creates a window as well, the library attaches data to the window which both libraries recognize so it ends up calling into the wrong one. I had to change the source code so it uses a different tag so it doesn't conflict.
There appears to be a bug with SDL2 on Windows 10, i emailed Valve about it: https://github.com/ValveSoftware/halflife/issues/1887
This should also let me use the same library, thus solving the problem entirely for this project.
The engine codebase is now on Github: https://github.com/SamVanheer/SharpLife-Engine
I've worked around the SDL2 issues by renaming the library used by the managed libraries. This means there are 2 SDL libraries being used.
It doesn't appear to be causing problems so far though.
EDIT: spoke too soon, using multiple libraries causes problems because the engine creates a window as well, the library attaches data to the window which both libraries recognize so it ends up calling into the wrong one. I had to change the source code so it uses a different tag so it doesn't conflict.
There appears to be a bug with SDL2 on Windows 10, i emailed Valve about it: https://github.com/ValveSoftware/halflife/issues/1887
This should also let me use the same library, thus solving the problem entirely for this project.