Create an account


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[SUGGESTION] Porting to FTEqw engine?

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

#2
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.


[Image: fte00001_small.jpg]
[Image: 230.png]
Reply

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

#4
(12-20-2013, 12:24 PM)poVoq Wrote: 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).
[Image: 230.png]
Reply

#5
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 Sad

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

#6
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.)
[Image:http://i.imgur.com/4XODR.png]640K ought to be enough for anybody.
     ― Linux Torvalds
Reply

#7
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?
Reply

#8
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.
[Image:http://i.imgur.com/4XODR.png]640K ought to be enough for anybody.
     ― Linux Torvalds
Reply

#9
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:
Quote:[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. Tongue
[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
Reply

#10
From IRC, a few moments ago:
Quote:<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 Tongue
<divVerent> and probably like 1000 small things that add up to a year or two of work
[Image:http://i.imgur.com/4XODR.png]640K ought to be enough for anybody.
     ― Linux Torvalds
Reply

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

#12
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/
Reply

#13
(12-20-2013, 12:59 PM)poVoq Wrote: 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 Sad

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.
Xonotic exists for a long time and low player count is the proof that nobody wants to play Xonotic since it is a bad game by default.
- Lyberta, 2017
Reply

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

#15
Looks interesting. But I really want QuakeC dead.
Reply

#16
You might as well say you want Xonotic dead Wink 
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.
Reply

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

#18
(10-23-2017, 03:13 AM)Lyberta Wrote: 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.
Xonotic exists for a long time and low player count is the proof that nobody wants to play Xonotic since it is a bad game by default.
- Lyberta, 2017
Reply

#19
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.
[Image: 21975.jpg]

Quote:“To summarize the summary of the summary: people are a problem.” - Douglas Adams
Reply

#20
Pushing and pulling to git still doesn't mean getting everyone to agree to rewrite everything in another language.
Xonotic exists for a long time and low player count is the proof that nobody wants to play Xonotic since it is a bad game by default.
- Lyberta, 2017
Reply

#21
The Daemon port has already been started by other developers. The idea was that we embed QuakeC VM into Daemon and have 2 versions of Xonotic that have the same code. This will require implementing all QuakeC builtin functions and full understanding of all parts of the engine. I personally think that we don't have people with free time and such knowledge and wanted to fork DarkPlaces so we can use DarkPlaces code as a base. That is not the consensus yet.

QuakeC is a terrible language and Xonotic uses it poorly. I'm trying to rewrite parts that I understand into idiomatic C style that then could be easily converted to C++. So far this resulted into refactoring the resource system and item system. Item system has not been merged yet.

There are 2 things that slow development a lot: QuakeC and Quake compatibility goal of DarkPlaces. IMO, Xonotic will never reach 1.0 if it stays with these limitations.
Reply

#22
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++.
Xonotic exists for a long time and low player count is the proof that nobody wants to play Xonotic since it is a bad game by default.
- Lyberta, 2017
Reply

#23
Here's the simple example. Take a small health item. Its code is in common/items/item/health.qh. I have counted its fields and got 26. All fields in QC are 4 bytes so we get 104 bytes of memory. Now, in QuakeC all entities have all fields that are ever declared. I've loaded progs.dat into my VM and found that Xonotic has 4823 entity fields.

So small health uses 104 bytes but the engine allocates 19292 bytes for it so 19188 bytes or 99.46% of memory is wasted. Let's try to extrapolate. I'm gonna be very generous and assume that most entities have 3 times more fields so 18980 bytes per entity is wasted and multiply that by 5000 because that's about how many entities are in the game usually and we get 94,900,000 bytes or 90.5 MiB. I've just loaded a dedicated server and it consumes 498.7 MiB. If we stop wasting memory, we could get 408.2 MiB which is 18% of memory saved.

That's just entity fields. I haven't talked about adding arrays and other stuff which will make the game much faster.

Xonotic has almost reached a 255 limit of stats, Xonotic has exceeded 255 limit of impulses, Xonotic comes very close to 65535 globals limit. And we stuck with those retarded limits for the sake of Quake compatibility - a boring game which nobody cares about.
Reply

#24
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.
Xonotic exists for a long time and low player count is the proof that nobody wants to play Xonotic since it is a bad game by default.
- Lyberta, 2017
Reply

#25
Are you using 32 bit build? That could explain it. About memory, the amount of RAM doesn't matter much. Cache is what matters and those 90 MiB completely defeat it. Xonotic constantly demands access to RAM. I've tried both Windows and GNU/Linux and FPS is terrible on high settings even when graphics are stuck between 2002 and 2005.

QC has 16 bit address space and all variables are global even if they are local in the code, their global memory simply gets reused when they go out of scope. QC has no arrays so it uses hacky intrusive lists which are extremely slow. Since bots need to traverse waypoint graph, this traversal totally kills performance.
Reply



Possibly Related Threads...
Thread Author Replies Views Last Post
  [SUGGESTION] Porting to XreaL Minkovsky 52 37,730 11-05-2011, 01:41 PM
Last Post: divVerent
  [SUGGESTION] xreal engine? ugluck 3 3,116 06-29-2010, 05:58 PM
Last Post: FruitieX

Forum Jump:


Users browsing this thread:
1 Guest(s)

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