Xonotic Forums
[META] DarkPlaces fork - Printable Version

+- Xonotic Forums (https://forums.xonotic.org)
+-- Forum: Creating & Contributing (https://forums.xonotic.org/forumdisplay.php?fid=10)
+--- Forum: Xonotic - Development (https://forums.xonotic.org/forumdisplay.php?fid=12)
+--- Thread: [META] DarkPlaces fork (/showthread.php?tid=8293)

Pages: 1 2

RE: DarkPlaces fork - LegendGuard - 05-02-2020

Has the project to rewrite all the code in C++ started? Will we use the Daemon engine? If this goes well, will it also work for older computers with minimum requirements of 1 gb of RAM, 2 ghz Pentium ...? What is there for developers to do right now, do this, or continue the previous way (QuakeC, using DarkPlaces engine)?

RE: DarkPlaces fork - illwieckz - 05-02-2020

That's a lot of question. For what I know:
  • Has the project to rewrite all the code in C++ started:
    I've seen no public sign about that and enough will to wait for a start.
  • Will we use the Daemon engine:
    Only If people work on it.
  • If this goes well, will it also work for older computers […]:
    I don't see why c++ would raise the limit, and for Dæmon, that would be the usual requirement.
    Note: 1GB is very low, at some point people with 15 years old PC would face issues to run their operating system before trying to play a game.
  • What is there for developers to do right now:
    Developers prepare next release. Xonotic 0.8.2 is three years old, releasing something new that works is the priority.
Note that anything things about “rewriting” or “port to another engine” are mostly personnal experiments at this point.

RE: DarkPlaces fork - LegendGuard - 05-11-2020

Then after the release of the new version and having done the TOS and GDPR things, maybe it's possible continue this topic and other ideas, if this gonna well.

RE: DarkPlaces fork - Lyberta - 05-16-2020

Very related article.

RE: DarkPlaces fork - samiam - 05-17-2020

(05-16-2020, 11:50 PM)Lyberta Wrote: Very related article.

The issue is this: Open Source Economics. Which means two things:
  • Software will be maintained and updated for far longer than a typical commercial game
  • Integrating new technologies is a lot slower
In order to integrate new technologies, such as new versions of the C++ standard, requires a non-trivial amount of developer effort (especially since Dark Places is written in C, not C++), and since no one is getting paid to do this effort, changes like this will be quite slow. Sure, if we could get some venture capital (say a million dollars) and hire a team of developers, we could get a game written using the latest C++ standard and whatever scripting language we want out the door within a year.

However, this is open source. We don’t have venture capital. We don’t have a million dollars to hire developers. We just have a lot of enthusiastic volunteers making a really great game, but since Xonotic is already a really great game, there is relatively little motivation to rewrite it using the “latest and greatest” technology.

RE: DarkPlaces fork - Cloudwalk - 07-22-2020

I'm a (new) developer for Darkplaces so I feel I can speak somewhat authoritatively on this matter.

(04-06-2020, 06:08 PM)Lyberta Wrote:
  1. Start by forking the engine and compiling it as C++. We can then slowly rewrite each individual part in C++. That way every development build can be fully playable.
The engine already compiles as perfectly valid, warning-free C++. You don't have to rewrite anything. Darkplaces adheres to what I like to call a "hidden standard" of C that sits in the middle of a Venn diagram of compatibility between C and C++. It's ISO C minus a few C-isms that C++ doesn't like

(04-06-2020, 06:08 PM)Lyberta Wrote: Modify the engine so it can operate with menu and server components written in C++. First step can be as simple as adding the ability to call runtime created QuakeC "builtins" via meta builtin. So the call chain can be this: engine -> old QuakeC blob (now acting more as a bridge) -> new C++ code. This way we can slowly start rewriting menu and server code in C++ while still having fully playable builds.
I'm not sure about this. I'd prefer exporting (within reason) all of the QuakeC builtins so they can be called from native code. This has been in the cards for months and it's something I want to do, but I can't give an ETA. What this could mean is potential Quake 2 support, and QuakeC would essentially become a language binding among potential many (as such an interface would make implementing other languages much easier).

(04-06-2020, 06:08 PM)Lyberta Wrote: Somewhere along the lines we can drop Quake 1 client code as it is not used by Xonotic and acts as a dead weight.
I'm all for separating the Quake 1 client (and server) code from the engine, but removing Quake support altogether will never happen upstream. Darkplaces is a *Quake* engine. A better solution would be to reimplement Quake on top of the native API I mentioned above, with a bunch of hooks where Quake 1 code used to reside. That said, there's far too much generic code referencing Quake code. Untethering it would take an ungodly amount of effort.

I don't think Xonotic is likely to move away from QC any time soon, but this hypothetical native API I have in mind already would allow you to achieve the rest of the bullet points (of which I only addressed the first three). It's for these reasons I would strongly encourage collaboration with upstream, rather than forking the engine. Quake 1 doesn't have to be sacrificed.