Moving away from QuakeC

@Lyberta, this sounds like an interesting idea, and definitely something I'd like to have. In exercise, could you layout what exactly can be done for this to happen? (Or better yet, write something small as a proof-of-concept.)
Can we move this part of the discussion into its own thread?

Well, I haven't cloned the Daemon repo yet so I don't know the state of porting Xonotic code to Deamon. Basically, we need to modify the engine code that handles QuakeC and GMQCC compiler to be able to generate function stubs that will be resolved at runtime. I think this may break compatibility with Quake code and this will require a dedicated fork of DarkPlaces. As a proof of concept one just needs to move VM code out of DarkPlaces and hack on it. I think this is partly done in Daemon repo. Reply

Sounds like FTE_multiprogs.
http://forums.insideqc.com/viewtopic.php...multiprogs
Might be portable from FTEQW to darkplaces. Reply

Yes, this is almost exactly as my idea. Does it require FTEQCC? Is there a 100% free software version of FTEQW? I guess we'll need to modify GMQCC too. Reply

Yes, this is almost exactly as my idea. Does it require FTEQCC? Is there a 100% free software version of FTEQW? I guess we'll need to modify GMQCC too.

What do you mean, like a fully FOSS game based on FTEQW? Then no, not yet (there is one in the works though called projectUnkown). FTEQW is fully GPL though.
If you asked me, I would rather suggest to port Xonotic to FTEQW as it is mostly compatible and these days the better engine than Darkplaces (maybe with the recent Xonotic code refactoring it almost there?), but I guess the Deamon porting plans are also good. Reply

What do you mean, like a fully FOSS game based on FTEQW? Then no, not yet (there is one in the works though called projectUnkown). FTEQW is fully GPL though.

Yes, fully free game. I'm not going to get proprietary assets to see what's the engine is about.

If you asked me, I would rather suggest to port Xonotic to FTEQW as it is mostly compatible and these days the better engine than Darkplaces (maybe with the recent Xonotic code refactoring it almost there?), but I guess the Deamon porting plans are also good.

I dunno, looks ancient. Uses C, SVN and is hosted on SourceForge. Daemon on the other hand looks really cool. Reply

Well it is a Quake derived engine, so some ancient cruft is to be expected. Otherwise don't be fooled by the website or the lack of up to date documentation. It is a very well developed engine with a Vulkan renderer, a Android and a WebGL port and all kind of other cool and modern stuff.
Daemon is also cool, but it also has a lot of ancient cruft from Quake3 and RTCW days. It will also still take considerable effort to get Xonotic running on it as far as I know, and I expect that this unproven QuakeC layer will be quite buggy for a long time. Reply

By the looks of it, FTEQW is about as far off as Daemon from becoming suitable for Xonotic...
Not to mention this: https://forums.xonotic.org/showthread.ph...4#pid64474 Reply

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

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.

That's weird, even my 10 years-old laptop performs better (on a 1600x900 resolution).
Did you try both the GLX and SDL executables?

Maybe there's something wrong with the GPU? Reply

This Quake Engine fork has a LUA interface that can coexist with QuakeC:
https://github.com/KurtLoeffler/Slipgate
Might be a good way to migrate away from QuakeC without breaking stuff while doing so. Reply

To be honest, Lua is even worse. At least QC has static types and you need to compile it before you run the game. With Lua there is no compiler so you have to start the game to check if even your syntax is correct. Coding in Lua is extremely hard. Reply

Lets agree to disagree on Lua

I checked with the FTEQW author about the build in Lua support in that engine (which runs Xonotic mostly fine), but there the code hasn't been touched for a while and support is currently disabled by default. Could be a starting point together with the above code though. Reply

Maybe Lua haven't better performance in case when you build game, and errors can be checked only in execution mode, but use Lua as alternative script language will be maybe better choice. One of the reason is that this scripts doesn't need to restart game, and check working really with one command of restarting script, if it was. But use Lua as main language of game isn't good idea, because when building main engine, need to know about all bugs in code on compilation time, and use C as main language is better, than default QuakeC, or etc. Reply

Plain C is even worse than QuakeC though. Reply

Lua would of course be a substitute for the QuakeC script, not the actual C code the main engine is currently written in. Reply