Forum posts

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.

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.

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.

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.

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.

@Solokiller, how is your work in process? Rendering nsp and wad and can we have sources

I'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.

Code conversion from one language into another happens very often.
Besides, the ASM is only the sped-up 256 color software-renderering code so that's really irrelevant.

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.

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:

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.

SharpLife is based on GoldSource, and is largely designed from scratch, with reused code from the SDK.

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

Anything else is minor and can be reproduced without the use of Quake code.

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.

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.

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.

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.

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.

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.

Finished the essentials of the renderer, added in skybox rendering.

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

Veldrid's working, along with ImGui on top. I'll need to simplify the code since the sample code is way too much for what's needed right now, but it's a good start.

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.

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.

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":

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).

This may be why it's not working as it should. Try using a vanilla Hammer first, then use any modified one, or better yet use Sledge or JACK.

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.

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.

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.

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?

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.

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?

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.

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 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.

Got the SDL2 window up and running. Had to patch the SDL2 library again because more strings were conflicting with the original. I hope Valve updates the library soon.

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.

I've looked at a few networking libraries and it looks like Lidgren is the one to go for: https://github.com/lidgren/lidgren-network-gen3
It's recommended by most and provides everything that's needed to replicate the original system.

It also supports DotNet Core, albeit requiring a manual build. It should be possible to distribute the NuGet package itself and load it up locally, as i've done. That's relatively simple to do compared to the C++ dependency management approach.

Unlike GoldSource Lidgren doesn't impose any packet size limitations, but hardware and software limitations in the network infrastructure still apply here. Once a packet grows beyond a certain size it will be fragmented and reassembled on the other side, which means high amounts of packet loss can still cause problems. I may have to look into creating something that can send data in discrete packets to limit the effects of packet loss, but that will require further investigation to see if it's a real problem or not. I'm not too familiar with that stuff so it may not be a problem.

In any case it means the "reliable channel overflow" errors should be a non-issue. Timeouts, high ping and excessive packet loss should be the only reason to disconnect clients.

As far as GUI libraries go i've found that Imgui has a .NET Core wrapper: https://github.com/mellinoe/ImGui.NET
This should make implementing debug overlays simple, i know suXin from Facepunch has done this before so it should be simple to implement.

There's also a library for graphics programming: https://github.com/mellinoe/veldrid

It's low-level, cross platform and supports multiple backends, so i think this is a good way to support Vulkan and D3D.
It uses SDL2 for window management, and the library names are the same as Half-Life's so there is a need to modify the source. This is because Half-Life uses an older SDL2 library that may be missing functions. I may need to make a custom build for this to work out. I see that Veldrid uses a library to load native libraries, i may be able to provide a custom SDL2 path to load it.

For keyboard and mouse input i can also use SDL2, but i'll need to use a .NET wrapper here that also works together with Veldrid.
The wrapper i found uses DllImport which may not cooperate with manual library loading: https://github.com/flibitijibibo/SDL2-CS

Normally any given library is loaded once, so the goal will be to make sure the right SDL2 library gets loaded. If i can control where it looks for native libraries i can use a custom one and bypass the entire issue, otherwise i'll need to modify the source code of all involved libraries.

One option is to use this: https://msdn.microsoft.com/en-us/library/system.runtime.interopservices.defaultdllimportsearchpathsattribute(v=vs.110).aspx

But that only affects the assemblies that it's applied to. What i'm thinking is i can do this: free the original SDL2 library, load the correct one in the engine assembly, marked with that attribute, and then rely on the other load calls to use that library. This depends on the SDL2 library used by the original engine being freed, which may not be possible since it's a load time linked library. I'll have to verify this, otherwise using renamed libraries is the way to go.

That should cover networking, (debug) graphics and input. Sound can be handled through FMOD, that has a C# wrapper. The engine doesn't use it so there's no problem there.

I already have the filesystem code written up, though some changes are needed here and there. I'll be ditching the registry part of its initialization since that forces it to have Windows only dependencies, it'll be stored in a general purpose engine config file, along with things like the default game directory ("valve").

I've also built a command system, i've taken into account the problems that Valve had with engine upgrades to the classes. The problem there was that the class layout couldn't be altered without breaking mods, i've solved this by not making modders create instances of the classes. Instead, you provide info objects that describe commands, which are then used to construct the classes. Combined with C#'s delegates allowing class member functions and the compatibility between libraries, it should solve all of the problems that the command system has had since Quake.

As an example, here's the alias command:

RegisterConCommand(new ConCommandInfo("alias", arguments =>
{
    if (arguments.Count == 0)
    {
        Console.WriteLine("Current alias commands:");
        foreach (var entry in _aliases)
        {
            Console.WriteLine($"{entry.Key}: {entry.Value}\n");
        }
        return;
    }

    // if the alias already exists, reuse it
    _aliases[arguments[0]] = arguments.ArgumentsAsString(1);
})
.WithHelpInfo("Aliases a command to a name"));

Compare with the original: https://github.com/id-Software/Quake/blob/master/WinQuake/cmd.c#L341

The registration methods return interfaces to the commands to allow you to reference them, add more handlers, directly query variables, etc.
Commands and variables both allow you to add multiple handlers, so for instance if you have your cheat cvar "sv_cheats" defined somewhere, you can do this anywhere:

var svCheats = commandSystem.FindCommand<ConVar>("sv_cheats");

svCheats.OnChange += (ref ConVarChangeEvent conVarChangeEvent) =>
{
    if (!conVarChangeEvent.Boolean)
    {
        players.ForEach(p => p.DisableCheats());
    }
};

This adds a handler that checks if cheats have been disabled, and if so disables cheat properties on all players.

Variables also have filters that are checked before their values are changed. It's a pretty simple thing, if the filter returns false the change is not allowed. Filters can also modify inputs to for instance clamp values to a range, similar to Source's cvars. I've added filters that can do a few basic things, like testing if inputs are in a list, allowing only numbers, inverting filters, etc. For example, sv_cheats can have a boolean filter applied that restricts all inputs to 0 or 1.

Filters can be added and removed as well. Since both filters and change handlers are events, removing handlers you don't have a reference to is impossible, at least unless you use reflection to get the underlying event handler. It is thus difficult to accidentally break existing handlers.

Once all of this stuff is set up, the essentials should all be there. When i can draw stuff onscreen debugging will be easier, and i can start writing libraries that can load the various file formats used by the engine (bsp, mdl, spr). These will be standalone to allow for re-usability, hopefully useful to make new tools with.

If i can find the time i should be able to set this stuff up soonish, but i can't promise anything. I'm hoping there won't be any more unexpected problems, but you never know with these sorts of workarounds.