Create an account


Thread Rating:
  • 3 Vote(s) - 1.33 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[META] DarkPlaces fork

#1
See also

Also this:

(04-06-2020, 05:33 PM)Lyberta Wrote: OK, QuakeC really needs to die.

I've bought a new "gaming" laptop with Ryzen 3550H, 16 GiB of 2400 MHz RAM and Radeon 560X (4 GiB VRAM) and I get at most 60 fps on an empty map and 10-30 fps with bots. I've tried medium setting and lowest ones, they don't do anything. QuakeC completely destroys my performance.

For reference I get 120 fps on Red Eclipse 1.6 with all settings maxed out. Xonotic on lowest settings is 10 times slower than Red Eclipse on maximum settings and brings gaming laptops to a halt.

Background:

Ok, here's how Xonotic works right now. There are 4 parts:

  1. DarkPlaces engine, written in plain C. It still has entire Quake 1 client code that is not used by Xonotic.
  2. Xonotic menu QuakeC blob. Responsible for main menu, such as campaign, server list and settings.
  3. Xonotic client QuakeC blob. Responsible for pretty much all client logic that is not main menu. Can be downloaded from server ("csprogs.dat").
  4. Xonotic server QuakeC blob. Responsible for all things server-side. It is only active when you start local game or run dedicated server.

Each QuakeC blob is run in the separate virtual machine that is mostly isolated from other ones.

Problem:
This CPU cache torture has gone too far. QuakeC is unbearably slow and difficult to code in. For those who don't know, QuakeC has only a single "entity" type that is shared by all entities. Every time developer adds a new field, it is added to all entities. As a result, last time I checked (a year ago or so), Xonotic declared more than 4000 fields while uses 10 or less of them for each entity (of course, player entities are exception). As a result, more than 99% of memory is wasted, fields are spread out and every time QuakeC code accesses a field, it invalidates CPU cache. This absolutely kills performance. You need a beefy CPU with tons of cache to get playable framerates. And graphics settings don't matter anymore. Enough is enough!

Solution:
Fork DarkPlaces and slowly get rid of QuakeC. We can rewrite engine, main menu and server blobs without breaking compatibility with DarkPlaces. So as long as we keep client QuakeC blob, DarkPlaces clients can connect to new engine and vice versa.

Here's the plan:

  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.
  2. 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.
  3. Somewhere along the lines we can drop Quake 1 client code as it is not used by Xonotic and acts as a dead weight.
  4. Once 99% of menu and server code is C++, we can remove those QuakeC blobs completely. Again, this can be done in one merge so all builds are playable.
  5. Ok, at this point we removed ~60% of all QuakeC code while having fully playable builds and keeping compatibility with DarkPlaces. This is the time to break network protocol and start removing client QuakeC code. We can use the same approach, use QuakeC as a bridge while having new C++ code abstracted. But, since we need code to be portable, we compile new client C++ code to WebAssembly. So the call chain is this: engine -> old client QuakeC blob (now acting more as a bridge) -> new C++ code compiled to WebAssembly module. We still get fully playable builds but now DarkPlaces clients won't be able to connect to servers running a new engine.
  6. We finish removing QuakeC code completely. At this point we have new, clean C++ codebase. So, what about Daemon engine? Well, we now have full control over all of the code so porting becomes much easier. The idea to to try to sync API of our engine with API of Daemon as much as possible. This can be approached from both sides.
  7. Port to Daemon? Why not.

And finally, the name. I think there is only one and it is obvious:
Phoenix

This has been for about a year on my mind but right now I'm too busy fixing C++ itself and having good enough language of course comes before writing an engine in said language. This is a call to arms and a general survey of opinions of other developers at this point.
Reply

#2
(04-06-2020, 06:08 PM)Lyberta Wrote: slow and painless
Oxymoron?

I support bringing the game to better technologies, but with my very limited knowledge of the engine, I don't know how much work it is, let alone actually contribute to the engine. I can perhaps contribute to the game code itself.

Is it possible that you or somebody layout the steps for this migration? Right now my understanding is very rough: 

1. port the engine
2. port the game code
3. profit
Reply

#3
(04-07-2020, 04:46 PM)BuddyFriendGuy Wrote:
(04-06-2020, 06:08 PM)Lyberta Wrote: slow and painless
Oxymoron?

I meant that users will be able to stay on DarkPlaces engine/client and connect to Phoenix servers for quite some time. Only when we drop client QC there will be a hard break.

(04-07-2020, 04:46 PM)BuddyFriendGuy Wrote: I support bringing the game to better technologies, but with my very limited knowledge of the engine, I don't know how much work it is, let alone actually contribute to the engine. I can perhaps contribute to the game code itself.

Is it possible that you or somebody layout the steps for this migration? Right now my understanding is very rough: 

1. port the engine
2. port the game code
3. profit

Right, I'll update the first post because obviously people may not be familiar how everything works.
Reply

#4
then why not remake everything then? https://godotengine.org/
Reply

#5
(04-08-2020, 06:49 AM)_para Wrote: then why not remake everything then? https://godotengine.org/

This actually sounds intriguing, even though you might be joking. Curious -- how would the performance of Godot be for a fast-paced FPS like Xonotic?



This is not the first time Lyberta voiced this idea. The fact that we haven't jumped on board already sort of shows how feasible the devs think it is, mostly because we simply don't have enough active hands on deck for such a daunting task. What's our projected timeline of completion? 5 years? 10 years? Considering our current pace, even 10 years might be a conservative estimate.

As a player who's likely to stick with this game for a long time, I don't mind the 10-year timeline if that means the game will keep on living, and new devs will have an easier time contributing.

However, do we, as a (dev) community, have enough commitment/resources to carry out this long-term project? Or is it easier to stick with Quake and its eco-system?

Another thing to think about -- remember we had to reject Nexuiz clients? That means unless the new port is really equivalent to the existing one, we are risking having to start a new community from scratch.


(04-06-2020, 06:08 PM)Lyberta Wrote: Here's the plan:

  1. Start by forking the engine and compiling it as C++. 

How hard is this alone? Is it trivial to do a proof-of-concept working demo that can produce a drop-in replacement for the current binary?
Reply

#6
(04-08-2020, 06:49 AM)_para Wrote: then why not remake everything then? https://godotengine.org/

Godot uses GDScript for game code which is unacceptable and not gonna happen given current developer resources. This means rewriting everything in 1 go and not having playable builds. My proposal keeps the game playable during transition.

(04-08-2020, 02:14 PM)BuddyFriendGuy Wrote: This actually sounds intriguing, even though you might be joking. Curious -- how would the performance of Godot be for a fast-paced FPS like Xonotic?

Proper port to Godot will most likely run much better because any relatively sane language should be faster than QuakeC.

(04-08-2020, 02:14 PM)BuddyFriendGuy Wrote: What's our projected timeline of completion? 5 years? 10 years? Considering our current pace, even 10 years might be a conservative estimate.

Yes, full rewrite will most likely take 5+ years but we can still play all those builds and even have numbered releases during that time.

(04-08-2020, 02:14 PM)BuddyFriendGuy Wrote: However, do we, as a (dev) community, have enough commitment/resources to carry out this long-term project? Or is it easier to stick with Quake and its eco-system?

QuakeC is a dead end. And Xonotic QC code is riddled with macros. It requires developer who knows plain C well to understand what is going on. And C devs are rare these days.

(04-08-2020, 02:14 PM)BuddyFriendGuy Wrote: Another thing to think about -- remember we had to reject Nexuiz clients? That means unless the new port is really equivalent to the existing one, we are risking having to start a new community from scratch.

I'm pretty sure it was because of inherent split due to licensing and gameplay opinions. My proposal doesn't touch gameplay. Xonotic as a game stays Xonotic. The changes should be pretty invisible to regular players.

(04-08-2020, 02:14 PM)BuddyFriendGuy Wrote:
(04-06-2020, 06:08 PM)Lyberta Wrote: Here's the plan:

  1. Start by forking the engine and compiling it as C++.

How hard is this alone? Is it trivial to do a proof-of-concept working demo that can produce a drop-in replacement for the current binary?

Given that about 90% of valid C is also valid C++, here are my estimates for 1 developer working 4 hours per day:
  • Optimistic - within a day. DarkPlaces is written in clean C and is also a valid C++. We just change the build system and flip a switch to compile everything as C++.
  • Realistic - within a week. There is some C insanity, it requires manual tweaks to build as C++.
  • Pessimistic - more than a month. There is plenty of C insanity in the engine. Blood, sweat and tears ensue.

This is something I wanted to do myself because I plan to fork Xonotic into a military shooter but I've found that if I to fork DarkPlaces for my own purposes, I'd remove a lot of cruft as a very first step, maybe too much for what Xonotic devs would like. And I want to share as much code with Xonotic since there are not many FOSS shooters and I want everyone to benefit from my work.
Reply

#7
(04-08-2020, 05:51 PM)Lyberta Wrote:
(04-08-2020, 06:49 AM)_para Wrote: then why not remake everything then? https://godotengine.org/

Godot uses GDScript for game code which is unacceptable and not gonna happen given current developer resources. This means rewriting everything in 1 go and not having playable builds. My proposal keeps the game playable during transition.

Good point.

(04-08-2020, 05:51 PM)Lyberta Wrote:
(04-08-2020, 02:14 PM)BuddyFriendGuy Wrote: However, do we, as a (dev) community, have enough commitment/resources to carry out this long-term project? Or is it easier to stick with Quake and its eco-system?

QuakeC is a dead end. And Xonotic QC code is riddled with macros. It requires developer who knows plain C well to understand what is going on. And C devs are rare these days.

I personally have way less experience in C++ than in C (but agree that C++'s design is better), so I'm not sure whether it's true that there are fewer C devs.

(04-08-2020, 05:51 PM)Lyberta Wrote: Given that about 90% of valid C is also valid C++, here are my estimates for 1 developer working 4 hours per day:
  • Optimistic - within a day. DarkPlaces is written in clean C and is also a valid C++. We just change the build system and flip a switch to compile everything as C++.
  • Realistic - within a week. There is some C insanity, it requires manual tweaks to build as C++.
  • Pessimistic - more than a month. There is plenty of C insanity in the engine. Blood, sweat and tears ensue.

This is something I wanted to do myself because I plan to fork Xonotic into a military shooter but I've found that if I to fork DarkPlaces for my own purposes, I'd remove a lot of cruft as a very first step, maybe too much for what Xonotic devs would like. And I want to share as much code with Xonotic since there are not many FOSS shooters and I want everyone to benefit from my work.

Doesn't it make sense that you take the first stab and figure out how easy/difficult it is to port DarkPlaces, since you have a stake in it anyway?

I'm curious what components are considered "cruft" that you don't need in your military shooter game. Don't you want as much compatibility with other games so you can share resources?

One question though -- does it mean after this fork, it'll be very difficult for you to merge back DarkPlace's future new features (not sure how likely anyway)?
Reply

#8
Feasibility of the engine rewrite aside: have you looked at unvanquished? They have an engine in C++ (based on the q3 engine which was in C so rewritten already and it's newer tech, although not strictly superior feature-wise for now) and they already seem to have gameplay much closer to a realistic military shooter written in C++ as well so you could share much more code with them.
[Image: 30381.jpg]

<packer> when i see martin-t's name my blood pressure increases

<[BOT]Hоtdоg> anyone here lives near martin?
<[BOT]Hоtdоg> will pay monies for shooting him
Reply

#9
(04-11-2020, 04:33 PM)BuddyFriendGuy Wrote: Doesn't it make sense that you take the first stab and figure out how easy/difficult it is to port DarkPlaces, since you have a stake in it anyway?

Yes, it is on my TODO list.

(04-11-2020, 04:33 PM)BuddyFriendGuy Wrote: I'm curious what components are considered "cruft" that you don't need in your military shooter game. Don't you want as much compatibility with other games so you can share resources?

Looking just at the file list of the engine, I'd remove all IDE files and have just CMakeLists.txt. Also remove Android and iOS support as I don't have a smartphone and I have no idea how to play shooters without mouse and keyboard.

(04-11-2020, 04:33 PM)BuddyFriendGuy Wrote: One question though -- does it mean after this fork, it'll be very difficult for you to merge back DarkPlace's future new features (not sure how likely anyway)?

Yes, definitely.

(04-11-2020, 08:00 PM)martin-t Wrote: Feasibility of the engine rewrite aside: have you looked at unvanquished? They have an engine in C++ (based on the q3 engine which was in C so rewritten already and it's newer tech, although not strictly superior feature-wise for now) and they already seem to have gameplay much closer to a realistic military shooter written in C++ as well so you could share much more code with them.

Here's a couple of points:
  • If I fork UNV, Xonotic stays a laggy mess.
  • I've spent about 2 years working with Xonotic. I know the code base good enough.
  • I already have unmerged features such as Survival gametype and player templates system written for Xonotic that I want to carry over. That took me months of work.
  • I want to be on Xonotic server list the same way there are Quake 1 servers run by Mario.
  • Forking UNV means I will have to rewrite a lot to remove aliens and stuff. Which means either unplayable or very boring game during those builds. This is a huge motivation killer.
Reply

#10
The next versions Android and IOS will probably improve mouse and keyboard support. Apple will probably be a bit reluctant as they don't want to destroy their macbook market by making IOS too powerful, but Google has no need to hold back. The ports are not about playing Xonotic "on the go", but about having a port for the time when many people only have a single (portable) device and a docking station.
Imo, forking DP and customizing that fork only for Xonotic is a bad idea. The UNV devs also struggle to maintain their engine by themselves, hence they started to cooperate with us (and I think with the Smoking Guns dev(s)).
Reply

#11
(04-12-2020, 05:44 AM)Freddy Wrote: The next versions Android and IOS will probably improve mouse and keyboard support.

Probably, but how many years must pass before it is usable to people who might be interested in Xonotic? Replicant - the only sane Android distribution - is still stuck on Android 6. I've run it on Samsung Galaxy S3 - basically the flagship Replicant smartphone and got about 3 fps in 2D menus of stock Android shell. 2d menus! Imagine anything 3d.

And nowadays it's really hard to buy that phone because it is not produced for many years. I mean.... unless you have a ton of money. I bought it refurbished myself.

iOS? Well, when they release an iPhone that costs $100, maybe. That's about the maximum amount I'm willing to pay for a locked down phone. I'm willing to buy PinePhone for full price of $150 though because it runs vanilla Linux. But that means it will run Xonotic out of the box. No need for Android version.

(04-12-2020, 05:44 AM)Freddy Wrote: The ports are not about playing Xonotic "on the go", but about having a port for the time when many people only have a single (portable) device and a docking station.

No sure this will ever happen. I mean people running not-vanilla-Linux with mobile device and docking station. People who run Android are mostly satisfied with underage gambling games. That's what 99.99999% of mobile games are anyway. And people who want docking station will most likely buy device that runs Linux.
Reply

#12
(04-12-2020, 05:44 AM)Freddy Wrote: Imo, forking DP and customizing that fork only for Xonotic is a bad idea. The UNV devs also struggle to maintain their engine by themselves, hence they started to cooperate with us (and I think with the Smoking Guns dev(s)).

If I understand well, the only interest in using DarkPlaces over Daemon right now is that we can rewrite it in C++properly overtime, without having "a big update" that potentially breaks everything. Is that right?

However, if Xonotic is ultimately ported to Daemon, all this rewrite effort will go to nothing. So yes, I agree with Freddy here, why not trying to have resources in common with other similar projects from the very beginning?
Reply

#13
(04-13-2020, 02:46 AM)hox3d Wrote: However, if Xonotic is ultimately ported to Daemon, all this rewrite effort will go to nothing.

I don't see this happening. Porting to Daemon is a one huge leap that requires implementing almost all builtins of DarkPlaces on top of Daemon, at least given the current strategy. Xonotic Daemon repo tries to recreate DarkPlaces on top of the Daemon. I'm saying let's recreate Daemon on top of DarkPlaces while having playable game at every step.
Reply

#14
OK, there was one known person who keeps creating new accounts and getting banned because of reasons saying that I want other developers to port entire engine while I do nothing.

No, I do not. TBH I mostly ask for permission of what is allowed because I don't want to develop DarkPlaces fork alone. But, once I have free time from ISO C++ stuff and nobody does anything to the engine, I'm forking it myself.

Also, they said that 4000 floats mean nothing. No, 4000 useless floats mean a lot because in proper code you would load entire struct in CPU cache line (usually 64 bytes AFAIK) and work with it. With QuakeC you load 1 useful value and 15 useless "floats" (they are not really floats in VM but bags of 32 bits) so you have 4 useful octets and 60 useless ones and in order to access another entity field you will need to waste another cache line.

So in proper code to access 10 entity fields you do 1 cache line load. In QuakeC you do 10. That's most likely an order of magnitude slower.

Based on this StackOverflow answer, we can estimate costs. If entire entity is in L2 cache, we are talking 10 CPU cycles versus 100 CPU cycles. If it is in main RAM (more likely case), things get much worse: 120 cycles vs 1200 cycles. We just wasted 1080 cycles loading useless ("null" as that person said) data. CPU is idling and waiting for RAM instead of doing computations. That sucks. Hope you have 6 GHz CL1 liquid-nitrogen-cooled RAM to get CPU not to idle.

Also, I'm not a "he". Don't assume my gender.
Reply

#15
Your new "gaming laptop" gets less fps than my most ancient potato, so you blame the tools and propose a complete rewrite of everything? I have a better proposal: fix your laptop.

If Quake C was as slow as you say, how can I get a cpu limited fps in the 200 to 1100 range (depending on map) on an intel Q6600 from 2007?

Edit: And I have a somewhat broken 2013 laptop with intel integrated haswell graphics, and it gets a (gpu limited) 250 fps on most maps at decent settings.
Reply

#16
(04-20-2020, 01:04 PM)bones_was_here Wrote: Your new "gaming laptop" gets less fps than my most ancient potato, so you blame the tools and propose a complete rewrite of everything? I have a better proposal: fix your laptop.

If Quake C was as slow as you say, how can I get a cpu limited fps in the 200 to 1100 range (depending on map) on an intel Q6600 from 2007?

Edit: And I have a somewhat broken 2013 laptop with intel integrated haswell graphics, and it gets a (gpu limited) 250 fps on most maps at decent settings.

Well he is right about the "Cache" issue. My Sandybridge has 6MB Cache. When i join a CA or a CTF Game i can get huge drops which make the game just disgusting to play sometimes.   I tested in on several similar systems with pretty much the same results and the few buddies i convinced to try the game reported similar issues and just turned xon their back because they didn't want to deal with it. I can honestly say this game never ran really perfectly smooth (at least on Windows) on my end. I mean yeah i can reach 250+fps but i also get nasty drops to the 60s that feel much worse than 60fps. It's especially frustrating when you compare that to games like Quake Champions, Unreal Tournament 4 or other AFPS which sometimes look much better and also perform much better.
I love xon and i learned to "live with its flaws" but it is a tough love sometimes.
But i guess you are right the only thing i can do might be upgrading my system or try it on Linux.
Reply

#17
I find Xon runs smooth on computers far too old and underpowered to handle QC or UT 4, but there are situations where performance suffers.

The BSP format makes it hard work for mappers to achieve good performance and high detail in large and open maps, especially when reflection and warpzone effects multiply the amount of visible triangles. BSP was designed for boxy rooms linked by corridors that block visibility, as found in DOOM and Quake.

You can see the limitations of BSP in other games: when Valve added blacksite to CS:GO, it was much smaller than battle royale maps in other games, and its layout blocks visibilty as much as possible.  Despite these tradeoffs and a well paid, expert team to optimise, it still performs much worse than traditional (smaller, less open, BSP friendly) CS maps.

Many Xon servers run maps ported from other games such as Q3 and QL. Xon often allows water reflections on these maps, but Q3 and QL don't have fancy water and their maps were not optimised for it. The result can be a glitchy 30fps on a system that gets 300+fps on the same map with r_water 0.

There are also maps with excessive amounts of realtime lights, so on a normal map you think your PC can handle realtime lighting, then you go play one of these maps, and it's a slideshow.

Rewriting everything will do nothing to prevent map issues destroying performance.

Some weapon and damage effects are also quite slow, using too many API calls and causing the CPU, GPU and libGL to wait for each other many times per frame. The impact of this varies significantly between GPU drivers, independently of GPU power. Fortunately Xon has thousands of cvars, allowing you to reduce or disable effects as needed. Effects efficiency can be improved (contributions welcome), but rewriting in a different programming language won't help, and will greatly increase the work required.

Xon is currently using an OpenGL 2.1 renderer. Some (simpler) Quake based engines were able to improve performance by rendering with the modern Vulkan API instead. Contributions welcome...
Reply

#18
I know that rewriting everything will be a big pain. I hope you've created the fork and copies of Xonotic project(gamecode, engine, resources, ...). I don't know if the team learders have decided this because of your idea:

First of all, they will have to divide the developer groups: one group of developers for Lyberta idea (rewriting code, searching ways to improve the things, tests with the engine, modifications, ...) and other group of developers for standing Xonotic game from now for the players (do things as much as they can, fix, enhance, add new things in the game, ... using the QuakeC programming). I said one group for QuakeC, because we will need to maintain the community and the players whose are enjoying with it.
Without this group of QuakeC that maintains the game, maybe the community won't attract the players and some of them would leave. If the fork is successful and your idea works well and is stable, then some of the group of QuakeC may move from one project to another. Some players will play the game with this engine.
Believing is power
Reply

#19
No need to divide devs if every build is playable. It should be a very smooth transition. And regular player wouldn't notice until we start messing with client QC.
Reply

#20
Excuse me, Lyberta, I don't know if the questions that I'm doing are repeated. 
So if the project is successful and QuakeC is removed... This means that to develop gamecode we will use C++ instead QuakeC? As well as the commands, cvars, interface, mods, game modes, scoring systems, graphics settings, ... And the config / script files (.cfg) will be removed too? And won't we use scripts to create the custom configurations? I think that the scripts helped us a lot to setup and manage the servers.
Believing is power
Reply

#21
(04-27-2020, 10:01 AM)LegendGuard Wrote: Excuse me, Lyberta, I don't know if the questions that I'm doing are repeated. 
So if the project is successful and QuakeC is removed... This means that to develop gamecode we will use C++ instead QuakeC? As well as the commands, cvars, interface, mods, game modes, scoring systems, graphics settings, ... And the config / script files (.cfg) will be removed too? And won't we use scripts to create the custom configurations? I think that the scripts helped us a lot to setup and manage the servers.

Yes, QuakeC would be removed. Gamecode would either be written in C++ or Rust. With WASM it should even be possible to mix multiple languages, but that would lead to fragmentation and bugs because of inconsistent "expected behavior".
From the user perspective, not much would change (commands, cvars, etc.). Maybe there would be minor changes.
Even moving to Daemon would not cause completely new behavior.
Reply

#22
(04-27-2020, 10:57 AM)Freddy Wrote: Yes, QuakeC would be removed. Gamecode would either be written in C++ or Rust. With WASM it should even be possible to mix multiple languages, but that would lead to fragmentation and bugs because of inconsistent "expected behavior".
From the user perspective, not much would change (commands, cvars, etc.). Maybe there would be minor changes.
Even moving to Daemon would not cause completely new behavior.
Ok, Rust can be a great option, it can reduce the performance, security and memory management issues. It will make debugging less difficult. Why not?
Believing is power
Reply

#23
It is pretty easy to go from C engine and QuakeC game code to C++. It is harder to go to Rust. Unfortunately, I barely know Rust.
Reply

#24
Xonotic/Nexuiz gets excellent performance for the use case of playing a small 1-on-1 or at most 2-on-2 game on a small performance optimized map. I get over 60 frames a second (at 1280x800, low game settings) playing one bot on the seven maps I play [1] using an Intel Core 2 T8100 with Mobile Intel 865 express chipset (a 2007 era business laptop). The only time I get under 60 frames a second is when looking down at Aerowalk’s or Final Rage’s fairly open large vertical room; even here performance is 50 frames a second or higher. On my 2017 Intel Core i7 7600U with Intel HD 620 video chipeset (again, a basic video card for business non-gaming systems), I get 200-500 frames per second on medium settings, even with two or three bots.

Glancing at Lyberta’s postings, I do not see at first glance any reference to profiling tools being used to conclude that it is the QuakeC which is killing Xonotic’s performance. What I saw, back when I tried to run Xonotic on my old Intel N455 netbook (Intel GMA 3150 graphics), is that the maps were more detailed than the original Nexuiz maps, causing unacceptable performance on my then main computer.

I think Bones hits the nail on the head: Xonotic’s use case is for small, tight, hand-optimized maps, playing one-on-one games against someone on a home LAN.

Now, I think QuakeC’s real issue is the fact that it’s an unusual specialized programming language with limited documentation and a relatively small number of programmers who are comfortable with the language. If Xonotic were to be made today, it would probably use Lua, which is, last time I looked, the standard game scripting language which a lot of game developers are familiar with.

However, in the real world, to move away from QuakeC would require a good portion of the game’s content to be rewritten; the resulting game would probably be a good game, but it probably should not be called “Xonotic”, because the rewrite would inevitably change the fundamental game mechanics. Since we’re dealing with Open Source Economics (no one is getting paid to do this work), finding developers motivated enough to do the work is hard, even with the COVID-19 recession leaving developers out of work with lots of free time.

[1] For what it is worth: Nexuiz 1.1 Downer, Blood Prison, Nexuiz 2.3 Final Rage, Toxic, Soylent, the Xonotic map Graphite which I have converted in to Nexuiz format, and the originally for Quake3 Hub3 Aerowalk map.
Reply

#25
I usually play 8v8 with bots. And on laptop I've tried me and 9 bots. I guess bots destroy performance because you need to do pathfinding and pathfinding requires tons of entities.
Reply



Possibly Related Threads...
Thread Author Replies Views Last Post
  What was easy for you in development? (Darkplaces and QuakeC programming) LegendGuard 2 483 08-08-2020, 05:25 PM
Last Post: LegendGuard
  Trying to understand darkplaces source code wiefie 37 7,778 09-22-2017, 01:37 PM
Last Post: Lyberta
  Module (music) support for Darkplaces (again) [test it] nilyt 8 5,655 04-21-2015, 08:24 PM
Last Post: BuddyFriendGuy
  darkplaces wiki down .... hutty 4 5,383 10-13-2012, 09:47 PM
Last Post: hutty
  Parallelization of Xonotic (and Darkplaces engine) Sarge999 19 15,731 11-21-2011, 03:22 PM
Last Post: Sarge999
  [SOLVED] Compiling from GIT fails: darkplaces unfa 10 11,556 06-20-2011, 07:58 AM
Last Post: unicornsteak
  Darkplaces Code master[mind] 3 4,515 11-28-2010, 05:02 AM
Last Post: SavageX
Question How good is darkplaces really? Ihsan 61 46,612 09-18-2010, 07:11 PM
Last Post: Ihsan

Forum Jump:


Users browsing this thread:
2 Guest(s)

Forum software by © MyBB original theme © iAndrew 2016, remixed by -z-