Porting Xonotic to idTech 4

The GPL vs non-GPL thing, that's really getting out of hand with people signing up specifically to our forums just to question our license structure. That needs to stop. I do not go around telling other games what license to adopt, so I am really starting to wonder what the incentive (or possibly personal agenda) is here.

Actually I find this thread quite entertaining, but I have a faible for silly things.

Yeah I guess I should just laugh it off, but for some reason this really gets on my robotits.

Is adding rtlights one by one with console commands in game the only way to work with rtlights?? That's ridiculous!

No, it's not ridiculous. It's the cost of software freedom

Is adding rtlights one by one with console commands in game the only way to work with rtlights?? That's ridiculous!

By default, that is indeed the way it's done... same for bot waypoint creation. I did make a script that can disable lightmaps and automatically convert all static lights into realtime lights. It is however unusable on most maps, since they must be compiled with the --keep-lights option, and divVerent doesn't approve of enabling that on the autobuild-bsp server.

FTEQW has a ingame editor for lights that is probably more or less compatible with DP as it is CSQC only.

Is adding rtlights one by one with console commands in game the only way to work with rtlights?? That's ridiculous!

No, it's not ridiculous. It's the cost of software freedom

Why is it a cost? Anybody is free to change this and that's a good thing imo. If you don't like it then do something to improve it!

It should be mentioned that rtlights are defined by a text file storing position and properties. Simply editing that is also an option. The console commands does exactly the same. Same for the bot waypoints. If it is too cumbersome you could just bind the commands to hotkeys and you are good to go. Or add pseudo entities in NetRadiant to simulate waypoints/rtlights and write a simple program which extracts the coordinates from the map file resulting in a ready-to-use rtlights/waypoints file. So many possibilities... yet you don't care to improve anything but instead continue to complain. Nothing will change if you point out problems but don't present any solutions!

Sorry that I'm reacting that way but I'm freaking upset about people mindlessly bashing things that they think are shit.

To come back on-topic: Isn't it clear to most of us that we won't use idTech4 anyway and will most likely port Xonotic to Daemon... ?

Converting static light entities to realtime lights usually is not a great idea, as this in many cases would yield too many realtime lights and - accordingly - bad performance.

Personally, if I were to use realtime lights, I'd prefer to place them in NetRadiant, e.g., with a "light_realtime" entity. After all, that's how I place static lights as well. Same for bot waypoints. Having everything in the .map-file also makes sure that things keep consistent over map changes.

idTech 4 isn't going to happen; nobody capable of doing so wants to

/thread

That was an odd thing, out of the blue people trying to argue over Xon being Open Source. Looks like zerok was a hit and run account...

Converting static light entities to realtime lights usually is not a great idea, as this in many cases would yield too many realtime lights and - accordingly - bad performance.

Personally, if I were to use realtime lights, I'd prefer to place them in NetRadiant, e.g., with a "light_realtime" entity. After all, that's how I place static lights as well. Same for bot waypoints. Having everything in the .map-file also makes sure that things keep consistent over map changes.

Yes, the performance is a major issue with DP and too many RT lights. I've never been much of a fan of how DP does this, but it couldn't use actual light entities because DP was primarily meant to be an improved Q1 engine, and Q1 maps had literally hundreds of light entities. There are though, ways around that, such as creating RT lightpoints that group these lights into single RT lightpoints at map load time, and using that(sort of automating the RT light system). This would fix a lot of the problems I see with Xonotic and DP, in that the lighting/shadowing is often simply missing on many maps.

Bad performance with rtlights is more about changing the render than switching from darkplaces to something else. id tech 4 has full realtime lights but it scales badly with increasing vertex counts.

Deferred rendering perhaps? Tha's how modern games handle dynamic lights.

Good lord, don't tell me there is still only a forward renderer

---

Would there be any desire for someone to write a deferred renderer? Also some capability testing for dynamically switching to things like glMultiDrawElementsIndirect when available would be a massive performance win.

Darkplaces has deferred lighting (r_shadow_deferred), but it performs much worse as far as I can tell.

Darkplaces has deferred lighting (r_shadow_deferred), but it performs much worse as far as I can tell.

I can confirm that: FPS is reduced a whole lot when enabling this. There is no visual improvement either, from what I could see..

I think the most important thing to invest in is adding dynamic linking into QuakeC VM. Xonotic is written in QuakeC which makes it not very portable. When dynamic linking is implemented, it would then be possible to rewrite game gradually into any modern language. Otherwise nobody gonna rewrite the whole game at once.

I'm not sure that I understand what you mean. Could you elaborate?

Internally there will be a C or C++ API inside the engine. And since most languages have C bindings, you could rewrite Overkill in C, C++, Rust, Python, anything.

That sounds convenient, and very unsafe.
There are good reasons why the server-supplied code is
limited in its capability and sandboxed by the engine.
Though maybe I misunderstood something?

@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?