Create an account


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

#51
Whaaaaaaat? I mean, there is no way to do this and this will not fix QC as a language.
?️‍? <- that should be a rainbow flag emoji.
Reply

#52
you may as do the ridiculous task of making a program that reads qc code rewrites it in c++.
or you could fix the language, only if you had the source code of qc.
or you could just rewrite the entire game. if you do that you may as well make a new game in source2 because it has better graphics.
you probably found this comment infuriating.
lolxd!
Reply

#53
Extending the VM is actually possible (and an option often overlooked for the state of our current codebase - too many personal agendas and snobbery over languages IMO), however it would break protocol, something DarkPlaces is very strict about maintaining compatibility with. There's also the issue of nobody wanting to actually work with the engine (possibly for its restrictive and bloated design).

FTEQW doesn't share this restriction, however, by a large factor, DarkPlaces is quite clean and stable in comparison.
On another note, any form of rewrite is simply out of the question. Any possible port relies on efforts from that engine's developers to provide compatibility with what we have.
[Image: 230.png]
Reply

#54
So I didn't wanna respond to any of this because I have plenty of other ways to procrastinate from qc2rust (sry, no public repo yet) but then i realized I wouldn't be able to stop thinking about it anyway.

(03-13-2019, 03:35 AM)Snowball Wrote: ridiculous task of making a program that reads qc code rewrites it in c++
It's called a compiler. It's been done before, though it would need more work to make it usable. Jcompile doesn't work with our latest code anymore and from what i am told it never produced readable code.

(03-13-2019, 03:35 AM)Snowball Wrote: you could fix the language
Language design is hard, that's why there are so many bad ones that people don't even know things could be better. Read about the blub paradox. Just like other kinds of forks, adding another bad one won't help.

(03-13-2019, 03:35 AM)Snowball Wrote: or you could just rewrite the entire game. if you do that you may as well make a new game in source2 because it has better graphics.
Yeah, and it wouldn't be xon, the whole point is to make xon better, not make a different game.

(03-13-2019, 03:35 AM)Snowball Wrote: you probably found this comment infuriating.
More like incoherent but close enough. From your previous post you clearly have no idea what you're talking about. As a rule of thumb, if you feel obliged to say "you could just", you're missing something obvious. That is indeed the case here.

(03-13-2019, 04:18 AM)Mario Wrote: too many personal agendas and snobbery over languages IMO
Idk about others but my agenda is having a FOSS game that i wanna come back to as both a player and a dev. Being written in a language that others wanna come back to would greatly help that goal, especially given the dev team's not exactly been growing over the past few years and plenty of bugs are directly or indirectly caused by QC (and sometimes the compiler).

I see why you might be worried i wanna push for a "rewrite" in rust no matter what. From another person's perspective it might seem like i really like the lang. I don't. Well, a little. Rust is bad. It's just WAY less bad than all the others i've tried and i think it aligns pretty well with our needs.

(03-13-2019, 04:18 AM)Mario Wrote: any form of rewrite is simply out of the question
Yes, generating readable code or bust.

About FTE's flavor of QC:

I haven't used it so take this with a huge grain of salt, the feature list looks interesting and it is no doubt a better lang that our current QC. However, I am afraid it might secretly be another C++, just with its own, different, set of quirks.

Moving away from FTE QC later (if it turns out to be a dead end) would be even harder than from our QC since it's a much more complex language. A compiler from our QC to c++ or rust is not easy but it's doable. (Otherwise, seeing as it's my bachelor thesis, i am deeply and thoroughly fucked. We'll find out in 2 months.) From FTE QC, i'd be really afraid of it.

Finally, switching to an established lang (while we can) gives us an actual ecosystem which we can depend on. Both rust and c++ have plenty of libs we can use and IDE support, not to mention better learning resources and existing experienced devs. Very long term, in rust's case parallelizing parts of the code like bot logic will be much easier and we'll avoid a whole lot of hard to track bugs.

Either way, if rust or c++ on daemon don't work out, then FTE is definitely a nice backup to have.
[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

#55
(03-13-2019, 12:16 PM)martin-t Wrote: Language design is hard, that's why there are so many bad ones that people don't even know things could be better. Read about the blub paradox. Just like other kinds of forks, adding another bad one won't help.

Tbh I've already suggested QuakeC++ but since nobody volunteered I decided to write my own language and then write QC compiler and then extend it to QC++. But that's a lot of work.

(03-13-2019, 12:16 PM)martin-t Wrote: Yeah, and it wouldn't be xon, the whole point is to make xon better, not make a different game.

Tbh I want to eventually fork Xonotic and make a modern military shooter but first I want to make Xonotic forkable.

(03-13-2019, 12:16 PM)martin-t Wrote: Idk about others but my agenda is having a FOSS game that i wanna come back to as both a player and a dev. Being written in a language that others wanna come back to would greatly help that goal, especially given the dev team's not exactly been growing over the past few years and plenty of bugs are directly or indirectly caused by QC (and sometimes the compiler).

Totally agree, I think QuakeC was doomed to kill all games that use it eventually.

(03-13-2019, 04:18 AM)Mario Wrote: any form of rewrite is simply out of the question

Wait, why? As long as we have playable build, rewrite is fine for me.

(03-13-2019, 12:16 PM)martin-t Wrote: Moving away from FTE QC later (if it turns out to be a dead end) would be even harder than from our QC since it's a much more complex language. A compiler from our QC to c++ or rust is not easy but it's doable. (Otherwise, seeing as it's my bachelor thesis, i am deeply and thoroughly fucked. We'll find out in 2 months.) From FTE QC, i'd be really afraid of it.

What is the problem you encountered with qc2rust?

(03-13-2019, 12:16 PM)martin-t Wrote: Finally, switching to an established lang (while we can) gives us an actual ecosystem which we can depend on. Both rust and c++ have plenty of libs we can use and IDE support, not to mention better learning resources and existing experienced devs. Very long term, in rust's case parallelizing parts of the code like bot logic will be much easier and we'll avoid a whole lot of hard to track bugs.

Tbh I haven't seen a good libre C++ or Rust IDE, pretty much all of them suck. I don't think Rust is a clear winner in parallel stuff. C++ already has parallel algorithms and coroutines with executors expected in a couple of years. I'm writing a build system in C++ and I've realized if I wanted to write a parallel non-module build I could just write:

Code:
std::for_each(std::execution::par, std::begin(translation_units), std::end(translation_units), [&](const auto& tu)
{
   this->Compile(tu);
});
?️‍? <- that should be a rainbow flag emoji.
Reply

#56
[quote pid='84709' dateline='1552497386']

(03-13-2019, 03:35 AM)Snowball Wrote: or you could just rewrite the entire game. if you do that you may as well make a new game in source2 because it has better graphics.
Yeah, and it wouldn't be xon, the whole point is to make xon better, not make a different game.

[/quote]
it not a different game if it plays the same that sort of go's without saying.
players don't care too much about what is under the hood anyway they just care about what they can see/do.
if you added better graphics it might attract more new players (only if it was advertised). 
lol you right i don't really know what i am talking about. i know what is possible but i don't know how hard it would be to implement.
Reply

#57
(03-13-2019, 05:42 PM)Lyberta Wrote: What is the problem you encountered with qc2rust?
So far nothing serious, it's just a lot of work. I might not be able to transpile variadic functions. Rust can call existing ones (like our builtins) but not declare new ones yet. There's an issue, looks like it's implemented but not stable.

There are also constructs like STATIC_INIT and [[accumulate]] that will be ugly when translated to rust. And references. I am gonna probably end up using raw pointers and unsafe as a start, it won't be worse than generating c(++) though it won't be idiomatic. Field references are another thing rust won't like but i saw some crates for them, will have a look.

For goto and switches i am hopefully gonna be able to use code from c2rust.

(03-13-2019, 05:42 PM)Lyberta Wrote: Tbh I haven't seen a good libre C++ or Rust IDE, pretty much all of them suck.

Hmm, i haven't considered libre stuff. I use clion for c(++) because as a student i have it for free. Some parts of intelliJ are supposedly open source, no idea about exact licence, clion is probably not. For rust i keep switching between intelliJ + rust plugin and VSCode + RLS. Most official rust stuff is MIT+apache, not sure if that's libre enough for you Tongue

intellij+rust is usually better but doesn't support all nightly features and i've seen its type inference make mistakes. VSCode+RLS depend on rustc so it's always up to date even if you use nightly but it's way slower.

There's also rust-analyzer being written by one of rust's team members. It is supposed to replace them both but so far is WIP.

(03-13-2019, 05:42 PM)Lyberta Wrote: I don't think Rust is a clear winner in parallel stuff. C++ already has parallel algorithms and coroutines with executors expected in a couple of years. I'm writing a build system in C++ and I've realized if I wanted to write a parallel non-module build I could just write:

Code:
std::for_each(std::execution::par, std::begin(translation_units), std::end(translation_units), [&](const auto& tu)
{
   this->Compile(tu);
});

I am not keeping up with latest c++ (and even not so latest because the lang is HUGE) but afaik this can't guarantee that somewhere deep down the individual TUs aren't pointing to the same data and won't cause races if you're mutating stuff. I'd like to give you a more detailed answer but i haven't used rust's parallelism in real code. From what i've seen in excercises and examples you can't accidentally share stuff between threads that's not properly locked.
[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

#58
FTEqw, Rust, C++ ... it seems our very scarce dev resources are split here. There may be an ideal technical solution (that eventually we as a team will all agree, after a very long debate and persuasion), but we'll also need to consider a strategy that will enable us to move forward. 
I'm willing to go whichever direction we as a team decides on. It just seems FTEqw is so far the only one with enough work done and is kind of working, while Rust and C++ routes are still in the talking stage. Am I correct in that FTEqw will be the least painful transition?
I'm not sure that our game code will look like Python one day, so perhaps we should go with whatever is the most feasible, dev resource-wise, for now, rather than betting on a much harder path that leads to ultimate paradise.
Reply

#59
(03-15-2019, 07:47 AM)martin-t Wrote: I am not keeping up with latest c++ (and even not so latest because the lang is HUGE) but afaik this can't guarantee that somewhere deep down the individual TUs aren't pointing to the same data and won't cause races if you're mutating stuff. I'd like to give you a more detailed answer but i haven't used rust's parallelism in real code. From what i've seen in excercises and examples you can't accidentally share stuff between threads that's not properly locked.

Well, that's why you never share mutable data. That's like the first rule of multithreading.
?️‍? <- that should be a rainbow flag emoji.
Reply

#60
FTEQW is by far the closest functional replacement for DarkPlaces, and while their developers have expressed disinterest in making it any more compatible, they may be swayed by our desire to use it, should it reach a playable state.
The biggest obstacle is one we would need to solve anyway regardless of engine choice; cvar and command names. These differ between engines, so some kind of common aliases may be desirable.
[Image: 230.png]
Reply

#61
(03-16-2019, 01:39 AM)BuddyFriendGuy Wrote: FTEqw, Rust, C++ ... it seems our very scarce dev resources are split here.
Opinions are split, resources are not. Afaik the only people working on FTE are the FTE devs and maybe Mario occasionally? Though afaik Mario doesn't know c++ or rust yet so he wouldn't be able to help with those for now. Nobody is working on c++ - TimePath (who wrote jcompile, which isn't usable in its current state) is busy with life.

(03-16-2019, 01:39 AM)BuddyFriendGuy Wrote: Rust and C++ routes are still in the talking stage
Rust is in the coding stage. I finished the research part (mostly) and now i am working on beating up libclang/libtooling hard enough that it tells me how exactly it expands macros. Somehow i got the idea that it would be easier that writing my own preprocessor. Oh, yeah, umm, part of my assignement is to support macros by converting them into rust macros and/or functions for maximum readability :hype:. And yes, I knew how hard it would be when i agreed to it, i wasn't stupid, i was insane :/

(03-16-2019, 01:39 AM)BuddyFriendGuy Wrote: Am I correct in that FTEqw will be the least painful transition?
Yes Sad Though i am the one feeling most of the pain of the rust transition so far. Maybe the borrow checker will avenge me.

(03-16-2019, 01:39 AM)BuddyFriendGuy Wrote: I'm not sure that our game code will look like Python one day, so perhaps we should go with whatever is the most feasible, dev resource-wise, for now, rather than betting on a much harder path that leads to ultimate paradise.
Antibody, matthiaskrgr and morosophos have all stated QC is one of the big reasons they're staying out of gamecode. I don't know how betterQC will change their opinion and i am aware transpiling to rust won't change the design of our codebase but i think it will make refactoring it into something sane much easier.

Also keep in mind daemon is supposedly a much better engine (being based on q3 instead of q1 - correct?) so should have higher potential long term and we need either rust or c++ for it. Also navmesh. No more waypoints. :hype:

(03-16-2019, 03:36 AM)Lyberta Wrote: Well, that's why you never share mutable data. That's like the first rule of multithreading.
Have rules ever stopped even experienced devs from doing it accidentally? Smile Plus xon is not designed for threading from the ground up so you'd have to track all references of each object and all function calls manually to make sure you're not sharing stuff mutably somewhere deep down. FTEQC doesn't even seem to mention immutability anywhere, with c++ there might be at least some remote semblance of hope.... sigh .... while i am evangelising, might as well link this. /me feels dirty for linking medium Sad
[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

#62
(03-16-2019, 07:52 AM)martin-t Wrote:
(03-16-2019, 03:36 AM)Lyberta Wrote: Well, that's why you never share mutable data. That's like the first rule of multithreading.
Have rules ever stopped even experienced devs from doing it accidentally? Smile

Depends. Good encapsulation of the fact that there are actually threads is a good technique.

(03-16-2019, 07:52 AM)martin-t Wrote: Plus xon is not designed for threading from the ground up so you'd have to track all references of each object and all function calls manually to make sure you're not sharing stuff mutably somewhere deep down.

No you don't, you copy data between threads or have references to const. But mostly you copy. For example, the bot nav code would make a copy of the whole mutable AI system pretty much so that it is then atomically reassigned. Which means no QC because QC can't do shit at all.
?️‍? <- that should be a rainbow flag emoji.
Reply

#63
(03-16-2019, 03:59 AM)Mario Wrote: The biggest obstacle is one we would need to solve anyway regardless of engine choice; cvar and command names. These differ between engines, so some kind of common aliases may be desirable.

Could you elaborate, @Mario? Do you mean the references to the console CVAR have different prefixes under different engines? Isn't that just a matter of find/replace? Why is it a big obstacle?
Reply

#64
A lot of the cvars are different across engines, a simpler example (as in, one that exists on both engines at all) would be the acceleration rate of the mouse; on DarkPlaces, the cvar is m_accelerate, while on FTEQW it is m_accel, and Daemon has cl_mouseAccel.
The option in our menu is broken without renaming the cvar if you're testing FTEQW, and there currently isn't a functional test case of Daemon, so it doesn't matter as much yet.

There are of course more extreme examples (such as video and font settings), simply renaming all the cvars to match another engine means we'll have to repeat the process if we end up moving again (while also confusing users & breaking configs in the process), and we also make it much harder to test in the meantime (requiring a separate branch or fork of the gamecode for FTEQW to be maintained, instead of allowing it to be cross-compatible).
Commands would be a bit easier to handle - we can just provide aliases when one engine is detected.


Others may not see this as an obstacle, but given the rate at which FTEQW is improving in compatibility with DarkPlaces' protocols, it is one of few major issues that are on our side to fix.
[Image: 230.png]
Reply

#65
@Mario, I see the difference now. Thanks for the explanation.

Common aliases. This seems to benefit the larger community. How do we tackle that?
Reply

#66
(04-17-2019, 06:22 PM)BuddyFriendGuy Wrote: @Mario, I see the difference now. Thanks for the explanation.

Common aliases. This seems to benefit the larger community. How do we tackle that?

This seems to be mainly effecting the menu code, which is anyways separate from rest of the client side code.
IMHO the easiest would be to take an existing FTEWQ compatible menu and adapt it for Xonotic. The existing menu anyways looks quite dated by now and a face-lift wouldn't hurt at all Smile
Reply

#67
This is a cool new modern Menu system for FTEQW:
https://github.com/shpuld/sui-qc
Reply



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