SharpLife - Dot Net Core based modding p Created 2 months ago2018-05-06 19:15:02 UTC by Solokiller Solokiller

Created 2 months ago2018-05-06 19:15:02 UTC by Solokiller Solokiller

Posted 3 days ago2018-07-19 17:46:41 UTC Post #340197
If you test under Ubuntu 18.04 under VMWare Player xD Good luck. But Ubuntu 18..04 external slow :o in VMWare Player I really don't understand why does it happen with newest version of Ubuntu 18.04 because it removes Unity Desktop format is gone. And uses only Gnome/ Gtk Please remember use Gtk Sharp 3.22 for Net core by Cra0zy ( MonoGame Developer )

I think you need 2. computer or laptop for testing SharpLife.
Posted 3 days ago2018-07-19 18:02:34 UTC Post #340198
Alright i think we've talked enough about Mono, this project uses NET Core so all that's irrelevant anyway.

Progress update:
User posted image
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.
Posted 3 days ago2018-07-19 19:18:55 UTC Post #340199
Wow how did you load bsp and wad?? Do you use assimp-4.1 right?

Because assimp 4.1 is best strong loader for mdl and smd and obj and more any formats like blend fbx and more - if you like than you can merge more unknown formats into Half-Life with fbx files like Unity or Unreal Engine.

You mean door or camera control? It is very old and it has possible from Quake 2 with C# I found https://github.com/jacqueskrige/quake2-csharp-xna ( I don't know if you found func_door than you can copy from old c# files into new :) If you don't know how is parser for entities

And how is collision? Like I found https://github.com/livinamuk/OpenTK-simple-scene
Posted 3 days ago2018-07-19 19:43:24 UTC Post #340203
I wrote the code to load both file types.

I've only completed these two things, i haven't even started on entities.
Posted 3 days ago2018-07-19 19:45:10 UTC Post #340204
Than good luck I hope your sharplife works fine until we play under sharplife with more rendering like Unity or Unreal Engine.
Posted 3 days ago2018-07-19 21:32:45 UTC Post #340206
You have admirable patience to keep engaging him, Solo. Endlessly contrarian is the impression I've gotten.
Jessie JessieLadytype
Posted 2 days ago2018-07-20 13:40:24 UTC Post #340207
Yeah I found example but it is really old. You can check "custom collision" written from C# only. ( No helping by c++/c dlls via DllImport )

I think you can download subversion tool and check svn of https://code.google.com/archive/p/csharpgameprogramming/source/default/source?page=2

You can see how did writer with old initial Game Programming book and he uploaded to google code page.

I think it is recommend for SharpLife with sometimes like door or entity or teleport I have found book in live-book ( It has up to 40 pages for test in ebook. I have readden that

My brother bought for me book Game Programming Serious Game Creation ( I know it is very old ) But it is important to understand. I hope you have to get or to merge more details of C# files from svn If you tried... Good luck
Posted 2 days ago2018-07-20 14:14:56 UTC Post #340209
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.
Posted 2 days ago2018-07-20 14:36:59 UTC Post #340210
Reminder that Half-Life SDK code is not compatible with the GPL2 (Quake 1/2 source releases) and that projects like Xash3D, that violate those two licenses by mixing them have had disapproval by Valve.

So if you can (if you don't use Valve code directly), change the license on your code that's on git repo to be licensed under something GPL compatible instead.

That is, if you want to use Quake code.
eukos eukosOriginal Cowboy
Posted 2 days ago2018-07-20 14:48:17 UTC Post #340211
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.
Posted 2 days ago2018-07-20 15:04:45 UTC Post #340212
Your lack of care and knowledge in regards to software licenses is worrying.
Valve may not care about these projects but the Free-Software-Foundation and Zemimax might.
Valve doesn't approve of Xash because they used leaked code, not because of the license.
Sure, Xash3D may use leaked code in addition to GPL and HL1 SDK code. That doesn't change the fact that the GPL prohibits merging code with a license like the one in the Half-Life 1 SDK. This is not just a concern for Valve, but also Zenimax and the FSF.
Even if they don't approve, if they don't send a cease and desist it doesn't matter anyway.
It may not matter to you, but it matters to anyone that is using your software (which is what this is all about, right?). Some may depend on it and get screwed later down the line because you don't actually own the rights to the code.

I know people who actually dealt with Zenimax in regards to the Quake engine license (This was for Xonotic's standalone release). They still license it (for about 10 grand) and they'll negotiate a license with you. However they'll gain ownership over any changes you make and you start off with the original Quake 1 sourcecode release (you can't expect to buy a license and use something like the Darkplaces engine, because of the GPL code).

They have dealt with C&D's over the past decade, in both the Quake and Doom community. Don't push your luck.
eukos eukosOriginal Cowboy
Posted 2 days ago2018-07-20 15:22:03 UTC Post #340213
@SoloKiller okay no problem - I thought you have not books :D

@Original cowboy,

I didn't push his luck just I support for Solokiller If I have found somethings...
Please don't shoot mw! I am innocent German.
Posted 2 days ago2018-07-20 15:54:58 UTC Post #340214
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.
Posted 2 days ago2018-07-20 19:17:08 UTC Post #340215
@SoloKiller you're right. I think I need learn with veldrid. :/

How did you have success if you have experiences of veldrid? It looks very hard like very close to VulkanGL's commands "commandList". Did you have found many example written with veldrid.

I really want learn and I will help to expand with SharpLife if I have to add more details like Unity's or Unreal's features
Posted 2 days ago2018-07-20 19:27:48 UTC Post #340216
Quake is C with some assembly, which can't be used in C#.
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.
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.
I beg to differ. The game-logic from Deathmatch Classic, although it may be C++, is actually converted from the Quake 1.06 progs code.
A language that doesn't even have a concept of integers.

If Valve didn't own the licensed Quake code, that'd be, for example, a breach - if it was based off the GPL-released code and they didn't adjust their license properly to comply.
and the Quake license states this:
What you quoted is from the paragraph about modification of GPL2 code.
This does not allow you to take Quake code and put it into non-GPL works under any circumstances. It applies to your own modifications and when you can relicense them as something else. The license clearly states that once your code depends on working with GPL code, your code has to, I quote: "be on the terms of this License"
Thus, no licensing issues.
As long as you don't use any Quake code (converted, reformatted, copy&pasted etc.) you'll be fine.
eukos eukosOriginal Cowboy
Posted 2 days ago2018-07-20 20:17:04 UTC Post #340217
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.
Posted 15 hours ago2018-07-22 10:44:35 UTC Post #340224
I'm seriously considering swapping to Veldrid for Sledge. The API is way better than the half-assed OpenTK wrapper I've rigged up, and you get Vulkan/DirectX11 support for free. I've been doing a few tests and it embeds into Winforms with multiple viewports very easily. It's a bit inconvenient to require both .NET Framework and a bunch of .NET Core DLLs at the same time, but I can wait until .NET Core 3 is out which will ship with Winforms support out of the box.

Your last screenshot inspired me to try and write my own BSP renderer, I'm running into a lot of walls at the moment with Sledge and I need something different to play with for a while.
Penguinboy PenguinboyHaha, I died again!
Posted 13 hours ago2018-07-22 12:14:42 UTC Post #340225
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.
Posted 13 hours ago2018-07-22 12:48:52 UTC Post #340226
@PenguinBoy I think you need use Gtk Sharp 3.22 because GUI for Net Core

And if you want know how do you embed Veldrid into Gtk Sharp 3 just use UniversalBackend It is my Github repository for MonoGame But I will try for Veldrid's embeddirator to Gtk Sharp 3

For Windows 10 Users:
Do not forget to install Msys2 ( x64 or x86 )
If you don't like with msys2 than you make sure same github Gtk Sharp 3.x Installer ( x64 ) If you check same - But you need make sure themes and style ( I think up to ca 100 or 200 mb )into bundle.

Example:
Environment.CurrentDirectory = System.IO.Path.Combine("x64", "bin"); It is bundled runtime in Net 2.0
For Gtk Runtime 3.x 64 Bit or 32 Bit.

For Linux ( Ubuntu or CentOS whatever )
Please remember install libgtk3 or libgtk3-dev

For Mac OS Users:
Install JHBuild and compile it.
Posted 11 hours ago2018-07-22 14:23:07 UTC Post #340227
Yeah it works in Winforms, but pulling .NET Standard into a .NET Framework project adds about 100 extra DLLs, at that point you might as well just use .NET Core to begin with. (Though I suspect the extra DLLs may just be shims to the framework, since they're all pretty small)

Sledge will support extra formats with the plugins in the latest branch, but at the moment it's... not too great, stability wise. Which is why I'm looking into doing some side projects to polish up my 3D rendering skills.
Penguinboy PenguinboyHaha, I died again!
Posted 10 hours ago2018-07-22 15:27:41 UTC Post #340228
@PenguinBoy, so sad because WinForms is died now. WinForms is never released to NetCore. We use for Windows simple UWP/WPF I think sure If you try Veldrid Rendering into UWP or Gtk Sharp 3.

But UWP supports only DirectX ( SharpDX ). I hope you have to try with veldrid and user interface.
Posted 4 hours ago2018-07-22 21:37:19 UTC Post #340229
You must be logged in to post a response.