Create an account


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Porting Xonotic to idTech 4

For the record, NetRadiant is fully compatible with importing meshes and props in standard .obj and .ase formats. You can even use animated formats such as .md3 and .iqm, provided the engine supports them.
All models lack vis though, and so shouldn't be used for too much of the main structure of the map.

As for the whole GPL vs non-GPL thing; This is all heading towards a war between open source freedom and commercial success, and is all off topic to what Xonotic and its developers are capable of.

DarkPlaces may still receive a minor tweak from Havoc once or twice a year, but this is hardly enough to keep the engine alive, or working well enough to support Xonotic. divVerent has kept it functional for now, but we're basically beating a dead horse.
Daemon has active developers working constantly to make it a better engine, all we'll need to do is keep it compatible with Xonotic's requirements, probably via a minor fork if any changes are unacceptable by their team.
The cleaner code and better language of Daemon's may also encourage more developers to support it as it becomes more of an open engine for other games.
[Image: 230.png]
Reply

kditd, let me stress this again: software freedom matters to us. I don't know what you are trying to do with your charged language -- you are calling our free software ideals a "dogma", why not a philosophy or a movement? -- but it serves to show that you are misunderstanding one of our core values. Of course we could make it so much easier by breaking free from free software (eh) but this free software thing is how we work. And as Mario points out, that is not today's debate anyway.

I appreciate the rest of your comment, though.
[Image:http://i.imgur.com/4XODR.png]640K ought to be enough for anybody.
     ― Linux Torvalds
Reply

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.
"Yes, there was a spambot some time ago on these forums." - aa
Reply

Actually I find this thread quite entertaining, but I have a faible for silly things.
[Image: 249.png] Latest track on soundcloud: For You (piano improvisation)
New to Xonotic? Check out my Newbie Corner!
<ZeRoQL> i think i got 1 proper quad and that cunt halogen fuck me over with a laser
Reply

Yeah I guess I should just laugh it off, but for some reason this really gets on my robotits.
"Yes, there was a spambot some time ago on these forums." - aa
Reply

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

Tongue 
(08-10-2016, 08:55 AM)zerok Wrote: 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 Rolleyes
Reply

(08-10-2016, 08:55 AM)zerok Wrote: 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.
<spackObot> Congratulations to Samual and Taoki, your lovescore is 98.463%!
Samual (~dioteckte@...) quit #xonotic.pickup (gonna kill myself now)
Reply

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

(08-10-2016, 09:07 AM)motorsep Wrote:
(08-10-2016, 08:55 AM)zerok Wrote: 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 Rolleyes

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. Angry 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... ?
Reply

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

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

/thread
[Image: 38483.png]
Reply

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...
[MoFo] Servers - North America - Hosted in Montreal Canada and EU Paris France - Admin DeadDred [MoFo]
Reply

(08-11-2016, 05:22 AM)SavageX Wrote: 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.
Reply

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

(08-21-2016, 10:57 AM)zerok Wrote: 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.
Reply

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

(12-25-2016, 06:39 AM)SavageX Wrote: 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..
<spackObot> Congratulations to Samual and Taoki, your lovescore is 98.463%!
Samual (~dioteckte@...) quit #xonotic.pickup (gonna kill myself now)
Reply

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



Forum Jump:


Users browsing this thread:
2 Guest(s)

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