[SUGGESTION] Porting to FTEqw engine?

Following this thread:

http://quakeone.com/forums/quake-help/qu...ngine.html

I am wondering if switching to the much more in development FTEqw engine wouldn't make sense. It's also quake1 based and more or less compatible with Darkplaces so porting should be quite do-able. There is even talk about writing a DP compatibility layer.

The amount of additional features in FTE is quite amazing and it even performs better in many cases that DP. Especially the build-in realtime lights, particles and terrain editor should really be nice for mapping.

Maybe this would give Xonotic the much needed shot in the arm to revitalize the project with new developers and exciting new features that attract new players?

I guess this has been discussed before, but I think with all the new features in FTE it might be worth reconsidering.

This actually looks fairly promising.

I was able to get it to launch the Nexuiz menu, crashed upon loading a map though, and there were freezes when loading the menus.

EDIT:
It actually loaded the map when using console, but disconnected when joining (seems it doesn't like our .dat files much).
Also getting double the FPS than in Nexuiz, though that may be due to missing effects and stuff.

That is cool, although why Nexuiz and not Xonotic?

I guess since Xonotic has been modified to use the QC compiler by the same author already (FTEQCC) it should actually work better, no?

Edit: you used the experimental build right? The "stable" one is really outdated.

That is cool, although why Nexuiz and not Xonotic?

I guess since Xonotic has been modified to use the QC compiler by the same author already (FTEQCC) it should actually work better, no?

Edit: you used the experimental build right? The "stable" one is really outdated.

Xonotic uses a different compiler now, which has some engine-side incompatibilities apparently.

I used their website's latest experimental build.
The crashing on map load seems to be random (sometimes it crashes, sometimes it works).

A different one from FTEQCC? I thought that one was the new one? It is from the same author than the FTEqw engine.

But this engine really lacks up to date documentation

All those nice features like plugins, voiceIP chat, ragdolls etc. seem to there, but not written down in the wiki.

gmqcc

It's a fairly recent project, which was developed from the ground up.

We use it because fteqcc sucks (disclaimer: I'm not the one who originally formulated this opinion.)

Ahh, right. sorry for mixing those up. Hmm so I guess FTWqw would need to be made compatible with that compiler?

Edit: according to the gmqcc documentation it supports compiling in fteqcc format:
http://graphitemaster.github.io/gmqcc/doc.html
maybe worth a try?

And with all the extensions DP provides and it probably doesn't support yet.

You should talk to divVerent about this, he probably knows why we would want or not want to move to FTEqw.

I shortly talked to the creator of FTEqw and he seemed concerned that it should only be done as an official project with full endorsement by the Xonotic dev team to avoid a fork (or people staying behind like seen with Nexuiz etc.).

But he seemed relatively confident that it could be made to work technically:

[23:49] <Spoike> I do occasionally have a go at getting FTE to run xonotic a bit better. I tend to get bored before its working properly though, and as its a moving target, many more things are broken by the next time I try.
[23:50] <Spoike> I'm not aware of any compatibility issues with gmqcc-produced bytecode, but I can't say I've cared to try

Another idea would be to just take a mod like Overkill, DotC or maybe the vehicle mode and port that. Seems to me that those are really sufficiently seperate to make up their own games and Xonotic could concentrate more on it's core gameplay.

P.S.: He posted this file for FTEextensions: http://triptohell.info/moodles/fteqcc/fteextensions.qc

From IRC, a few moments ago:

<divVerent> do share that many features of DP are missing in FTEQW
<divVerent> e.g. support for player statistics
<divVerent> and multi-language font rendering
<divVerent> so it'd be quite a big effort to port it all
<divVerent> and warpzones
<divVerent> and probably like 1000 small things that add up to a year or two of work

Thanks... well maybe some stuff could be ported the other way around?

The height-map terrain would be really nice to have in xonotic and all the ingame editing stuff seems to be actually implenemted via a CSQC file: http://triptohell.info/moodles/csaddon/ ( http://sourceforge.net/p/fteqw/code/HEAD...c/csaddon/ )

The option to have "plugins" for various features like ingame irc etc would be cool too.

---

http://spawnhost.wordpress.com/2012/08/14/on-the-rocks/

some feature description of that terrain editing. Newer version of FTEqw also support real time shadowmapping on the terrain.

Looks like FTEQW is now mostly compatible with Xonotic0.8.2, see recent changelogs:
https://sourceforge.net/p/fteqw/code/5154/log/?path=
"improve dp compat in a number of areas, should now mostly be able to run xonotic 0.8.2, but will need some more extra cvars/defaults/stuff." and some later changes.
Have not tried it yet, as the binaries are not yet updated, but I am eagerly waiting to updates here: http://triptohell.info/moodles/

A different one from FTEQCC? I thought that one was the new one? It is from the same author than the FTEqw engine.

But this engine really lacks up to date documentation

All those nice features like plugins, voiceIP chat, ragdolls etc. seem to there, but not written down in the wiki.

We don't need VOIP. I propose we rebase our communications around a high frequency series of chat beeps from spamming :-) / nice one and Morse code.

The author of FTE pointed me to this file:
http://86.139.74.60:27500/FTE-Xonotic-0.8.2.zip
"xtract that into your xonotic dir. download the latest fte build. run."
Even with the current older build it should somewhat work according to him, as he managed to work around most gmqcc issues.

Edit: Still crashes for me, but as said before, lets wait for the latest code to find its way into the binaries.

You might as well say you want Xonotic dead  
Xonotic is QuakeC, and there is no way it will be anything but QuakeC in the future. Just live with it, or have a look at another game contribute to (qFusion/Warsow has a much nicer Angelscript codebase if that's your thing).
That said... it would be nice if different QuakeC implementations wouldn't differ so much. this gmqcc / fteqcc divide seems quite annoying to deal with in this case.

My goal is to rewrite Xonotic in C++ after porting it to Daemon. Sure, this will take years but it's worth it. Xonotic codebase has come to the limits of DarkPlaces and QC. If it stays QC, it will die.

You also run the risk of killing Xonotic by spending years reimplementing and re-testing everything from near-scratch especially when there's a frustration that Xonotic is not getting closer to its 1.0 release, therefore is further delaying in its publishing and PR stage, and what also seems to be without the consensus of other developers regarding the new language (especially when you can be using it in a completely different programming paradigm than many are used to).

This is probably the worst things to do especially when its been said that the code has largely been refactored recently.

From what I can see (based solely on interactions on IRC and thru git pulls/requests mind you), Lyberta has been working "with" the developers, pushing sensible stuff back and also pointing out a few hidden issues that he's uncovered going through the code to convert it (corner edge cases, obscure bugs that people knew about but had no idea what was causing them).

Also, I seriously doubt porting to Daemon would be done before 1.0 (Daemon itself hasn't hit 1.0 yet). It'd be something I'd see happening after 1.0, in prep for a 2.0.

Pushing and pulling to git still doesn't mean getting everyone to agree to rewrite everything in another language.

As you've said before, rewriting everything in C++ will take years, that isn't exactly helping the case of slow development; rather, it is exasperating it. Especially when code rewrites and refactors do not affect the user. 

E.g after all this time,
- The map pool for Onslaught, Assault, other uncommon modes are extremely small to the point it can't really be on servers, and I think plainly re-using maps for modes they weren't designed for gives a poor experience.
- Xonotic's DeFrag is lacking since it heavily borrows from Q3 DeFrag and guts Xonotic's own unique features for that.
CTF maps aren't as carefully designed as the duel/DM maps.
- We still have bots getting stuck under stairs and on complex geometry on official maps because there aren't or isn't bot clips where they would reasonably be some. (This might even help the server frame rate issue with bots or "bot stutter" according to this). Everyone else has been writing them off as hopelessly retarded, but with enough tweaking and attention they're actually capable of winning some pub matches and pulling their weight in team games.

It is a general thing that reading someone else's code is more difficult than writing your own, and I have my own doubts regarding your perceptions and promised benefits to C++.

I run a dedicated Xonotic server- it being online 24/7. It currently takes 221 MB of memory with no one on it (of course this and cpu usage grows as clients connect and bots spawn). If you're looking to optimize for memory, you're doing it rather early in development and especially in current times when memory is cheap i.e people have, on the lower end and old hardware 4 GB (my very old laptop has this much), gaming PC averages maybe 8 GB, and workstations or higher end PCs having 16 GB.

If you are talking about frame rates, Xonotic isn't very resource intensive either. It however will chug on reflections and water heavy maps on Linux (where same hardware running Windows and the Windows build runs 10x the frame rate), but this is an issue with graphics drivers, not game logic. In most cases / anecdotally the server frame rates and responsiveness results from, if it isn't internet infrastructure issues, scheduling i.e server for a real-time action game is going to lag (spike) or yield packet losses if it is normal, low priority, or poorly prioritized in general relative to other processes the host machine is running.

As for the limits of the engine or whatever, I can't comment too much since I'm not a QC programmer. (I do however know C++, and my own little commentary was just to use more local variables, but that's not something I will prompt for more details on). But it is my observation the developers are still willing to merge in random additions or features that had little demand to begin with.

I generally have smooth frame rates except the described scenario on Linux, again in that scenario the problem isn't the application code. If you are concerned about frame rate on high graphics settings, your concerns are better directed towards the code regarding rendering rather than game logic. High graphics settings can only do so much with the current assets; many of which, especially ported maps, are from that era. Resolution, shadow quality, and dynamic lighting doesn't change the situation too much.

As for QC vs C++, they're syntactically similar but they're for entirely different purposes. Many other game engines also use an interpreted language for game logic where you may be able to voice similar complaints regarding performance or may as well also complain about execution also involving parsing.

Add:
I'm not 100% clear what you mean by your first paragraph. If you could elaborate / explain what you mean here that would be nice.

Are you using 32 bit build? That could explain it.

Add 2:
If you could also disambiguate cache as well, http://xonotic.org/tools/cacs/#0a/0/cache or specific hardware (disk drive, RAM, CPU cache, etc) storing the cache, that would help the discussion.

I run Xonotic's 64 bit build for the dedicated server, but thank you for demonstrating you have little idea of what you are talking about.

Yeah, what about the original topic of this thread (hint: not arguing about QuakeC)?

With the latest FTEQW binary from 1st of November Xonotic runs surprisingly well.
There are some sound issues and the movement speed/bunny hop is somehow strange, but the overall graphics look similar to Darkplaces. It seems almost playable indeed (only tried some bot matches as network play is not compatible for now). A bit more crash prone under Linux though.
The FTEQW Author also seems to continue trying to get the QC code to compile better with the FTEQCC system.
Furthermore check out the new FTEQW section on the QuakeWiki that I am working on: https://quakewiki.org/wiki/FTEQW_Wiki and feel free to help out making better documentation for this awesome engine.