Not A Coder But
I'm a little optmistic. w00t!
Now we can have flamboyant colored light and cheesy particle effects in Q3!
...wait a minute...
i'm more hopeful that this might open the door for adding q3 features to quake.
Already Done That Sorta
seems like some engine mods already do that to some extent, what with md3, q3bsp, and 32bit color texture support. But a complete shader system and heightmapped alphablended terrain in Quake - well it would be interesting for sure. People could either abuse it and make utter shite, or something utterly cool we've never seen before.
I'm pretty certain the Quake Arena loading code for MD3's is quicker and more reliable than the code in current engines. It is funny how md3's load without a hitch for Arena on this craptastic machine of mine, but any more than a few static meshes in a custom Quake engine, and the redraw rate gets floored (I haven't tried the latest release of Dark Places and FTE on it yet, though).
Radiant Is Under The GPL Now
You win that one Lun.
Q3Radiant is under the GPL and you can use it for commercial purposes without paying fees to ID. However this doesn't apply to GTKRadiant, did I get this right?
take a look at the first paragraph of section O of the GPL agreement. GTKRadiant is a derivative work of Q3Radiant, so the answer to that you would think would be yes, it is covered. But look down a little further, and you encounter this:
These requirements apply to the modified work as a whole. If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works.
Now, it depends on the semantics of what is reasonable. Let's take a hypothetical case using the Q3map source here as an example; suppose that Ydnar's addition of phong shading to q3map2 used someone's method of phong shading who got a patent for that method? Then we are SOL and would have to use q3map. Not an unreasonable case, btw. As you'll notice in the readme, Id had to seperate out the Jpeg library stuff.
So, the answer is, it depends.
What's more confusing is this: GTKRadiant is a derivative work of Q3Radiant, now that Q3Radiant has changed it's licence to GPL does GTKRadiant fall under the GPL (per GPL's provision)? This doesn't really make sense to me.
Say I created a piece of software and licensed it's code for commercial exploitation to you for a big amount of $$$. Now I relicense my original piece of software under the GPL. I don't think I can now force you to GPL your commercial derivative: my license change cannot possibly retroactively affect you because it happened after the code split.
When the Quake2 source was GPLed, the mission pack sources from Xatrix and the like were not since they had a prior contracted agreement with Id. So you can use the original Q2 source to your hearts content in a commercial project but the add ons you cannot (the game .dll for Reckoning has superior AI code, for instance).
Awesome To Hear
Wonder if there'd be a proper Q1 sequel done in Q3.
From Q3 Source
From q_math.c, Q_rsqrt():
i = 0x5f3759df - ( i >> 1 ); // what the fuck?
Always good to know that the engine coders don't know what is going on.
An Address In Memory
hard coded like that, that is odd. Might as well be switching circuits with on and off toggles the old fashion way than to bother with code at all.
TinyURL'd Google Cache Of PDF Converted To HTML
Wow. That Almost Made My Head Hurt.
I think I followed enough of it to get the gist, but stuff like that makes me soooo glad to be a designer instead of a coder.
I'm going to go watch cartoons the rest of the weekend to get my normal neurochemical balance back...
that's the kind of stuff that seperates the gods from the the clods. I'm going back to thumbsucking.
Jago / Headthump
Jago, your post is surprisingly similar to one on Slashdot. Anyway, same answer as czg is below in that thread:
Player Benefits.. ;)
can someone who doesn't own Q3 , use an engine like OpenArena to play q3 Total conversions? (tremulous maybe?)
I Have No Idea...
I'm not a coder at all, but is it possible to combine q1 and q3 engines to make q1 engine that handle open areas much better than now?
I wonder what the "totally rewritten rendering code" in the twilight q1 engine (see qexpo booth) does, if it helps that already. Dunno.
what's wrong with the current q1 engines' handling of outdoor areas?
Question On Q1 & Q3 Map Formats
What are the most fundamental big blocks preventing the q3 renderer showing q1 maps?
I've understood the collision detection is quite different.
What about all the advanced visibility thingys etc in q3 maps? Are they only for the compilers?
Could q1 maps be recompiled from the original .map files so that q3 would have easier time showing them?
I'm just trying to gather some general picture for future projects... (no, don't have bad thoughts)
q3 renderer showing q1 maps WHY? thats pointless
and you already have DP if you want something heavy with glitter and stuff
No it's not pointless. For many reasons.
Basically, the q3 renderer is a much more modern and faster thing coded by very professional top-of-the industry coders that takes advantage of modern hardware (I don't know the technicalities, but for example buying a new graphics card didn't improve my qw frame rate much at all!) and has _much_ less legacy problems. Q3 was faster than Q1 on similar hardware already back in 2000. (With the right settings.) This of course includes some assumptions and the two are not directly comparable.
And I do not want dp glitter or any of that stuff because:
a) it's ugly (that is my personal taste)
b) compared to id stuff, it's badly coded fps hogging. I appreciate the efforts, but it's still what it is.
I have other purposes, but I won't tackle them right here because it would just start a flame fest when many people wouldn't understand.
Why Bother Arguing At All
if you "don't know the technicalities"
a lot of factors involved here, but I'd suspect that your vsynch was enabled if your fps wasn't affected by a significantly newer gfx card when using a GL-engine.
I believe Q3 can control vsynch itself, but with many older engines you'll have to disable it manually to get past the monitor refresh rate of 60-85 Hz. The latest FQ can also do this, I think.
Another issue is hardcoded (or cvar controlled) max_fps of 75-100 in many engines while playing (not during timedemos of course).
If you by "qw" means QuakeWorld software renderer, well then I believe very little is (or even could be) used of the gfx hardware to help fps.
of course I had vsync off.
I don't remember if it was glqwcl or fuhquake-gl.
This questioning seems pointless since the people with the most knowledge about the subject here (or anywhere) are engine coders having their own spoon in the soup or however you're supposed to say that.
I haven't bothered to download nexuiz but from what I've heard (from decent players that actually notice things), it's significantly slower than q3, even with the special effects turned off.
But whatever. Gluing stuff into q1 is just not the only way, and I'm trying to gather a picture of how hard the OTHER WAY would be.
for example buying a new graphics card didn't improve my qw frame rate much at all!
Not that this helps much, but this could also mean that your performance was already CPU limited.
Or that he hit a hard limit in the visual improvement... in quakeworld, servers limit the frames per second to 77, so a 400$ graphics card is not going to help you unless you are REALLY pushing it. The stresses could maybe come from something like tenebrae (slow and complex), but in general, clients optimized for displaying essentially the same thing as glqwcl.exe are not going to really need a turbocharged 4x dragon graphics card to reach acceptable, or even outstanding, performance. The mathematical demands placed on the card are just not high enough, because the core of the visual rendering engine is still from 1995, and thus easily handled by modern mediocre cards.
My 2 cents... engine coders, please correct me on my probable mistakes ;)
it was cpu limited, unlike q3, which was gpu limited.
Well, That's Because Quake Is CPU Limited
And isn't that the point of the discussion? That the Quake renderer is heavily CPU dependent and therefore can't take advantage of the power of modern video cards, whereas q3 can?
That efficiency would come in handy if people are going to make ambitious maps like Marcher.
Ok Let Me Put It In Another Way
we have an average or a little above dm map for quake and then a similar map for q3. Take your current computer, tune the settings of the games so they both look approximately similar. Have some medium-detail textures and dynamic lights on, but no muzzleflash or rocketlight. Fairly small explosion effects. Put the q3 server fps to 72 too.(?) Play some dm and check the timedemos.
Now in which engine is a higher stable fps achievable? How high is it? Why?
I don't have q3 now, but even 5 years ago when cpu power was still bigger compared to gpu power, they were roughly similar in speed.
yeah that's what I meant!
Although I'm not sure if that is the only difference. The games have been designed on somewhat different assumptions on available hardware, map size and complexity and whatnot...
Ooh ooh ooh. Speedy, go fuck yourself, I would love to play Q1SP's in the Quake3 engine.
Hell, I would love even more to BUILD them for Quake3.
Oh this is getting me hard.
why don't you build some Q3SPs for the Quake3 engine?
I have this great idea for a desert-themed Q3SP partial conversion! Maybe you should join me!
the engine would have to be modified so maps would look... faithful. Decent. Good. Not Q3. You know. At least some of you. Maybe.
I feel like I'm missing something here.
I've heard from a quake coding guy that the main difference in the maps is (q1 maps in q3) collision detection. Don't know if q3 then uses that q1-like multiple hull system or what. There prolly aren't monster hulls in q3. And the mods/licences with monsters aren't open-source, right?