Create an account

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

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.

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.
(10-26-2017, 11:07 AM)Lyberta Wrote: Are you using 32 bit build? That could explain it.
Add 2:
If you could also disambiguate cache as well, or specific hardware (disk drive, RAM, CPU cache, etc) storing the cache, that would help the discussion.
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

32 bit build means 32 bit pointers which consume less memory. I was talking about CPU cache.

(10-26-2017, 01:01 PM)Antares* Wrote: 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.

I was playing single player campaign on Windows and the game lagged a lot. Bots lag on any OS and the game is unplayable on listenserver.

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

And you demonstrated that you seem to know a lot without actually getting your hands dirty in QC. Psychic!

[Image: 21.png]
IRC (QuakeNet): #bot.xonotic | #xonotic.pickup | #xonotic | #xonotic.cup
Steam | | YouTube
Movies: Mirification #1 | #2 | Mirificaption #1 | #3 | #4 | [BOT] Clan #3 | #5 | #6 | #7 | [BOT] Clan #4 | #8 | #9


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: and feel free to help out making better documentation for this awesome engine.

With some compile flags and the SVN version of FTEQCC it seems to be possible to compile the Xonotic QuakeC code now (important step for further development).
Crosshairs also seem to be fixed (or set "/vid_conautoscale 1") and the sound is ok when disabling OpenAL (with OpenAL some sounds get cut short or don't play when many different sounds are played the same time).
Note that the Xonotic menu settings are largely non-functional for now.
Overall the biggest problem is that the Xonotic specific movement code is understood differently, and I am not sure if that is something the FTEQW author is willing to fix. Thus one would have to probably redo the movement code FTEQW specific, which is no quick and easy task.

"fix sound issue not reusing distant sounds (fixes massive cut-off sounds in xonotic)."
Is the latest from the SVN changelog... so I guess sounds should work nicely now too Smile

With the latest binaries (16/11/2017) and these updated configs:
It works mostly fine... rough around the edges (jumppads have issues, menu settings are not fully working etc.), but it shows that FTEQW could be made to run Xonotic quite well if a bit of further development polish would go into it.
By default the graphics look worse, but that's mainly a configuration issue. Generally FTEQW should be able to render Xonotic looking just as good if not better than Darkplaces.

With the latest binaries from the 6th of January, the remaining movement issues are fixed (incl. jumpads), and the (old) weapon models also look the same as with Darkplaces.
Still a few minor issues with sounds, the cross-hairs sometimes get bugged on level change, and going up stairs is a bit bumpy Wink
And the menu configuration isn't really able to change most FTEQW settings...

But overall this is close to Darkplaces experience now. Seriously worth considering a engine switch if I was to decide it, due to all the advantages FTWQW has over Darkplaces. Sadly due to (not easy to fix) networking incompatibility this can't just be an alternative client engine Sad

So what are the advantages?

tldr: Active development, Android and WebGL port, Vulkan renderer, real terrain support, Voicechat, XMPP and IRC integration and much more (even some early WebVR support Wink ). However not all of the features will be imediatly compatible due to how Xonotic is setup, for example splitscreen support will be difficult to get working according to the FTEQW developer.

P.S.: Trying to start Overkill currently breaks the engine Sad

(01-08-2018, 01:58 PM)poVoq Wrote: ..., real terrain support,...

whats that?
<Samual> I am the most unprofessional developer ever
<bluez> halogene, you make awesome music, but you have no clue about ctf.
<Halogene> I didn't know mappers include some mysterious waypoints so members of the BOT clan can navigate a map?
<divVerent> if you don't pay for a premium account, your movement speed is limited to 100qu/s

Large out-door terrain maps with texture blending etc. are relatively easy to make in FTEQW due to its build in support and in-engine brush based hightmap editor.

@poVoq, I'm now very curious. Is there a compiling guide somewhere? I could only find the binaries.

All in the wiki I just linked :p

Ok, I looked at that wiki. So far, looks cool. Does FTEQW support games not written in QC? Say, a mix of native code and QC?

It supports Quake3 like modding in C to some extend, but mixing it with QC seems only be possible to a very limited extend so far (at least that is the response I got from the FTEQW author to a similar question a few months ago).
I also vaguely remember someone mentioning halfworking lua scripting support in there, but I might be mixing that up with another engine.

Because I feel the only way forward for Xonotic is to be rewritten into C++ as the first step. And nobody is going to do this in one go. It's a process that will take decades.

With the latest FTEQW binaries (2018-10-14) Xonotic runs pretty well.

@poVoq, thanks for keeping working on this. What are the remaining issues right now?
You mentioned the network incompatibility -- does it mean the server and the client have to both be using FTEQW? Did the authors talk about adding a protocol translation layer?

For the record, FTEQW is protocol-compatible with DarkPlaces and existing Xonotic servers.

That said, FTEQW still has a way to go before we can consider it usable - a few important features are missing, and there are still many issues (stability and compatibility for the most part). Some of these are likely to be fixed, while some depend on the flexibility and motivations of the engine's developers.
In the future, if they continue to improve, we may be able to offer it as an alternative to DarkPlaces, but for the time being, it is only useful for developers and testers.

All aside, the future is starting to look promising, and maybe we'll be able to transition to it as a stepping stone to Dæmon:
[Image: 39YIfOXl.jpg]
[Image: 230.png]

@ BuddyFriendGuy

I am not the developer of FTEQW, just following its development and strongly considering to fork out a few rarely used game-modes from Xonotic into a seperate game based on this alternative engine (and removal of a lot of legacy cruft, for example focus on making all maps editable with Trenchbroom... good bye GTK Radiant Wink ). But right now I lack the time to do it.

@ Mario

Cool, I didn't know it is network compatible now. That must have changed relatively recently.

re writing the game in to c++ sound a bit ambitious.
i dont know too much about programming languages but i do have an idea.
you probably want to move to c++ because it much faster.
instead of rewriting the game you could modify the quakec runs through the code and than saves the machine code output.
you may have to make it ignore conditional statements so it runs through everything.
than you would input code magic here dsjkhflkshf.
then you would run the machine code.
the jist is to turn it into a compiled language.
i dont know how ridiculous this is but it might be better than rewriting the entire game.

hope you found this helpful, and good luck!

Possibly Related Threads...
Thread Author Replies Views Last Post
  [SUGGESTION] Porting to XreaL Minkovsky 52 40,152 11-05-2011, 01:41 PM
Last Post: divVerent
  [SUGGESTION] xreal engine? ugluck 3 3,517 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-