about Id Tech4

[Setlec]

i was wondering about when Id software would release the game engine as GPL or LGPL... and i was wondering about the features that could be released, like megatexture as used in ETQW...

Cheers

[deanjo]

i was wondering about when Id software would release the game engine as GPL or LGPL... and i was wondering about the features that could be released, like megatexture as used in ETQW...

Cheers

IIRC 6 years after release is the trend meaning not until 2010.

[L33F3R]

ETQW' megatexture tech was borrowed from tech5. you wont see etqw open sourced for a very long time if at all.

[Dragonlord]

And in the end it's not even anything new. Most probably there are others but games like Trespasser had already a mega-texture style terrain engine... and this had been in the old era of gaming.

[xav1r]

And in the end it's not even anything new. Most probably there are others but games like Trespasser had already a mega-texture style terrain engine... and this had been in the old era of gaming.

But are those you mention 100% GPL?

[xav1r]

IIRC 6 years after release is the trend meaning not until 2010.

They dont have a fixed time period. For quake 1 it was 3 years after it was released. For quake 2 it was 4 years after. Quake 3 was 6 years after, but only because at last moment a company bought a license for it, so they had to delay the GPL release. They might annouce a GPL release this quakecon, it's already been 5 years and no one AFAIK is buying a license. :)

[xav1r]

ETQW' megatexture tech was borrowed from tech5. you wont see etqw open sourced for a very long time if at all.

Hmm, source for that? I think megatexture was made by carmack specifically for ETQW, which is based in idtech4. On id's technology licensing site, they say that all idtech4 licensors get the full source code of doom3, quake4, AND ETQW, so the entire megatexture thing might be included. It'd be pretty awesome if it did. ;)

[L33F3R]

Hmm, source for that? I think megatexture was made by carmack specifically for ETQW, which is based in idtech4. On id's technology licensing site, they say that all idtech4 licensors get the full source code of doom3, quake4, AND ETQW, so the entire megatexture thing might be included. It'd be pretty awesome if it did. ;)

it was actually an old pre-release ETQW video from splash damage as i recall. Its been a few years so don't expect me to go looking for it XD. If what i believe is right and its a similar technology to whats seen in Tech5, its a much more primitive assessment as rage levels can be much larger.

all and all, SD/ID put lipstick on a pig, but that pig died of swine flu. The ETQW megatexture is essentially only a modeled terrain as i recall. If i remember correctly from SD forums its either OBJ or LWO and then its painted. I never got into the mapping side of ETQW because few people have the time to produce something decent of that scale by themselves:(.

But hey, it might be some decent code for you folks to look at should megatexture code be released:).

[Dragonlord]

Mega-Texture is as the name says: a huge texture ( we talk here of dimensions like 40'000 x 40'000 ). The terrain there is a huge unwrapped triangle mesh ( they did this so they can do some minor overhangs without requiring separate meshes ). The texture is a pixel map split into tons of segments streamed in at runtime ( using John special compression ). It's in fact a brute force version of what Trespasser did ( did not store MTs on disk but generated them at run-time from special meshes ) which is why they can not do large terrains ( and with large I mean up to things like 40km of terrain ). As you could easily math out 40k texels over 40km means 1 texel per 1m squared ( ouch! ). Disc consumption is tremendous for small levels compared to less free form solutions. Hope this sheds some light on it.

[L33F3R]

dont even get me started on downloading the poor buggers :p

[Julius]

Well a GPLed ETQW would be definitely awesome, as that game has some much potential, but was ultimately so flawed at release (and still is I think) that it is not really worth playing :(

But given the history of scource release of only strictly in house titles I highly doubt that this will happen.

The Quake3 source code however included changes made for the expansion pack Team-Arena, thus maybe some changes have been merged back into the Doom3 code which gets released.

[Naib]

ETQW will NOT become GLP'ed - for starters it aint a iD product
likewise there is no guarantee that iD will GPL their Tech4 engine

[L33F3R]

true, they only said it was a goal if all goes well.

but SD worked on it, SD did the original enemy territory and thats open sourced isn't it?

SD also mad the DOOM3 multi-player (although seriously lacking, it exists).

[Naib]

true, they only said it was a goal if all goes well.

but SD worked on it, SD did the original enemy territory and thats open sourced isn't it?
SD did do ET, but it is released under their own licence (RTCW-ETEULA), free but not that kind of free, plus ET was a mod on RTCW


SD also mad the DOOM3 multi-player (although seriously lacking, it exists). Their involvement was pretty much only on map design (some slight code stuff)


I hope iD release Tech4 as GPL (and that pretty much depends on how well they can get game houses to license Tech5), but don't expect SD to open up their bits.

[deanjo]

Last I heard, Carmack said yes it would be opensourced, he just wasn't sure nor would he commit to any time period.

[xav1r]

true, they only said it was a goal if all goes well.

but SD worked on it, SD did the original enemy territory and thats open sourced isn't it?

SD also mad the DOOM3 multi-player (although seriously lacking, it exists).

Only the original technology, id tech 3 (quake 3) which powered all those games has been GPL'ed. The derivative games are still closed. Actually, there are quake3 and enemy territory mods which are still closed source to this day, like Urban Terror for Q3 and True Combat for enemy territory. id tech 4 will definitely be GPL'ed, probably announced this quakecon, but i dont know about the derivative games from it. (quake 4, ETWQ, etc)

[Aradreth]

probably announced this quakecon
Do you have any reason to believe that or is it just a shot in the dark?

[L33F3R]

SD did do ET, but it is released under their own licence (RTCW-ETEULA), free but not that kind of free, plus ET was a mod on RTCW

confirmed. It is infact a custom license.

[jonwil]

From my understanding the release of code for RTCW:ET isn't "Open Source" by the definition of the term. It doesn't include all the code for it, just parts of it IIRC. And also the license prohibits things like commercial use of it. That makes it not Open Source according to the official OSI Open Source definition.

[yogi_berra]

i was wondering about when Id software would release the game engine as GPL or LGPL... and i was wondering about the features that could be released, like megatexture as used in ETQW...

Cheers

The only timeline I've seen was "sometime after the last game is released" the last game being the new Wolfenstein game. Also remember that if someone licenses the engine after the release of the Wolfenstein game and before the gpl release, Carmack will be polite and wait a while longer (as he did when id tech 3 was released under the gpl).

Megatexture is available in Doom 3 but is more Proof of Concept than anything else<1>. You'd have to do a lot of work to make it a viable alternative to tiled terrain. The real question should be how much of the sound architecture will be ripped out because of the deal with Creative?

<1> http://doom3.filefront.com/file/Megatexture_Technology_Mod;80169

[xav1r]

Do you have any reason to believe that or is it just a shot in the dark?

Somewhere between the two. He annouced last quakecon that it was going to be released "sometime", and they usually make their big annoucements at quakecons.

[Svartalf]

Do you have any reason to believe that or is it just a shot in the dark?

Heh... That's a guesstimate on xav1r's part there. A good one, to be sure- but still a guesstimate.

Mr. Carmack did publicly state (and at last Quakecon) that it would be GPLed- he just couldn't commit to a firm timeline other than more sooner than later. Typically, iD likes to make the big announcements of this nature and demos of new things like Rage at Quakecon each year. It'll be this or next Quakecon, most likely, that they'll announce it. If they don't have any new licensees within the last 8 or so months on it, we'll likely see it this year, if not, probably next.

The fact of the matter is, you'll either find out from Here (Either through Michael Larabel being there or myself in the forums... (I live in the DFW area...)) or you'll find out from LinuxGames.com. Maybe this year, maybe next... ;)

[L33F3R]

is there really a point when we have xreal? I know xreal is a pain in the 455 to compile but she runs mighty fast with a similar fetureset.

[Dragonlord]

I doubt xreal has a similar feature set... not even remotely.

[xav1r]

Heh... That's a guesstimate on xav1r's part there. A good one, to be sure- but still a guesstimate.

Mr. Carmack did publicly state (and at last Quakecon) that it would be GPLed- he just couldn't commit to a firm timeline other than more sooner than later. Typically, iD likes to make the big announcements of this nature and demos of new things like Rage at Quakecon each year. It'll be this or next Quakecon, most likely, that they'll announce it. If they don't have any new licensees within the last 8 or so months on it, we'll likely see it this year, if not, probably next.

The fact of the matter is, you'll either find out from Here (Either through Michael Larabel being there or myself in the forums... (I live in the DFW area...)) or you'll find out from LinuxGames.com. Maybe this year, maybe next... ;)

I think last time there was an id release, the id tech 3 one, carmack announced the release and the next day it occured. I think he annouced the quake3 code would be out in a 19 of August, and the source code release was on the 20th of august. :)

[Svartalf]

is there really a point when we have xreal? I know xreal is a pain in the 455 to compile but she runs mighty fast with a similar fetureset.

I'd have to concur with Dragonlord. XReal's got potential, but it's not the same class of engine (and won't be for some time yet to come...sorry...) as what iD's likely to hand us if they hand us the new one this year or next.

[curaga]

*sigh* I only wish they hadn't turned to C++ with tech4

[Dragonlord]

What do you mean with that? You can't make a "really" serious game engine ( with all the bling and still fast ) without C/C++/Asm.

[curaga]

Nothing against C/asm. It's just that tech3 was in C, for 4 they moved to C++.

[Dragonlord]

And what's the problem with that move? After all C++ is simply C with a couple of extensions. The only thing that can happen is that people get lost in STL/template diddy-dadly :P

[xav1r]

That's an old debate, right? Some people say that C++ is the only way to go nowadays, while others say you can do everything in plain C without needing the object based thing from C++.

[Dragonlord]

If somebody likes C or C++ more that's definitely a question of taste but from a technical point of view the two are similar. Granted some crap like templates or STL you should not use in GameDev but aside from that I don't see much of a reason why it should be bad to move over to C++.

[curaga]

It's mostly just that I very much prefer C to C++ and so have been able to muck around tech3, but won't be able so much with 4.

[Dragonlord]

I don't think this should be much of a show stopper.

[Irritant]

Yeah the C/C++ issue isn't a problem.

I'm more curious as to what the engine will have to offer. Alot of features have already found their way into opensourced engines already, so I doubt you'd see alot of projects switching to the engine, but probably more of a "cobbling" of the features they like out of it into their own.

[xav1r]

Yeah the C/C++ issue isn't a problem.

I'm more curious as to what the engine will have to offer. Alot of features have already found their way into opensourced engines already, so I doubt you'd see alot of projects switching to the engine, but probably more of a "cobbling" of the features they like out of it into their own.

Well, probably devs will update id tech 4 with more modern features like like tesselation or whatever you spell that, remove the 60 fps cap it has by default, maybe work on the megatexture if it includes some of it. Theres room for lots of features to add.

[Irritant]

Well, probably devs will update id tech 4 with more modern features like like tesselation or whatever you spell that, remove the 60 fps cap it has by default, maybe work on the megatexture if it includes some of it. Theres room for lots of features to add.

Agreed, I was speaking more from the perspective of existing projects looking to improve their engine. I'm sure something similar to the IOQ3 project will exisit for tech4.

[Dragonlord]

This is anyways not how it works there. Most AAA engines changes over time quite a bit. If it's downwards compatible, okay, but don't expect this to be the case. But attaching a C++ System to a C System is easier than the other way round.

[Svartalf]

That's an old debate, right? Some people say that C++ is the only way to go nowadays, while others say you can do everything in plain C without needing the object based thing from C++.

C++ enforces things and makes it easier to code.

You can do a substantive portion of C++'s OO stuff in C, though you have some odd sharp edges when you do it. Many things aren't automatic like they are in C++. It actually requires more discipline to code it that way than with C++ and moreover you end up with something that may not be as fast as the C++ code in many cases.

You can code C++ code that is faster and easier to maintain than C, but it requires nearly as much discipline to code OO in C to do it.

The biggest complaint I have with C++ development in general is that many tend to over apply OO development. In C++, you should really, really only apply as much OO as is realistically needed for your project. Templates are fine, but you shouldn't make everything a template. Abstraction is fine, but you shouldn't be making tons and tons of wrapper classes that serve little purpose past data encapsulation unless you NEED the encapsulation. (In many, many situations, the dev absolutely did NOT need it.) There's tons of more examples.

[Svartalf]

But attaching a C++ System to a C System is easier than the other way round.

No kidding. (Try to use a templated class inside of C... Good LUCK!! ;) )

[Svartalf]

Well, probably devs will update id tech 4 with more modern features like like tesselation or whatever you spell that, remove the 60 fps cap it has by default, maybe work on the megatexture if it includes some of it. Theres room for lots of features to add.

There's a distinct reason there's a 60fps cap. Most humans can only discern 1/6th of that resolution. The UI atom has typically been 100msec. Larger feels laggy. Smaller's snappy, but the event loops on many machines until recently couldn't give it to you any better than 100msec. Same goes for framerate. You can't discern past 60fps as anything more than flicker unless you've trained yourself and then it's something like 80 or so fps as that threshold.

[Kano]

With CRT i could see flickering with 75 hz, disappeared with 85 hz. But as currently TFT are common 60 hz is enough. When you want a completely smooth vsync you should consider only integer divisors to sync. Thats the thing which is problematic with 24/25hz material for example when shown as 60 hz. Therefore for syncing with pal movie 100 hz for pal was my favorite choice - in order to sync 24 and 30 fps perfectly you would even need 120 hz. Thats for movies, back to games: when you update for example every 2nd frame with 30 fps it looks more smooth than when you update every 1.x frames, as without vsync you get the tearing lines due to different content and even without vsync you get update some frames after 2 frames delay and others after 1 frame. With mainly static content that will not be visable, but when you use fast turns you see it, therefore a real gamer needs framerate way over 60 hz in every case.

[Svartalf]

With mainly static content that will not be visable, but when you use fast turns you see it, therefore a real gamer needs framerate way over 60 hz in every case.

Heh...

The average LCD happens to have a 5ms latency on the monitor.
The good stuff has a 2ms latency.

5ms is serviceable for most games with a refresh rate of ~20Hz.
2ms is good for most gaming with a refresh rate of ~60Hz.

Kind of puts this whole discussion in perspective, doesn't it?

Unless you've got sub-millisecond refresh (only some fairly high-end LCD's and Plasma displays currently do this to the best of my knowledge...), then throwing more FPS at the problem won't make the game play ANY better. If you're on a CRT, unbinding it will help some, but only until you hit the monitor's refresh rate, and then you're not getting any better out of it either.

[Kano]

Maybe you misunderstood me. You can use 30 or 60 fps to make a turn smooth, but when you try 40 or 50 fps it will jump. 20 fps is nothing you would ever want to see as the eye is faster. That the monitor has to be fast enough thats clear.

[Svartalf]

Maybe you misunderstood me. You can use 30 or 60 fps to make a turn smooth, but when you try 40 or 50 fps it will jump. 20 fps is nothing you would ever want to see as the eye is faster. That the monitor has to be fast enough thats clear.

The thing is, unless you're using a CRT, high-end LCD TV, or Plasma TV, you're not going to see better than 60fps. Hence the framerate lock- most everyone's using LCD's these days. ;)

Now, I don't agree with it either. It's extra code in there that can break- but it's there to ensure consistent results for most hardware out there. I just don't want people to think that ripping it out is going to magically make the game play better now. ;)

[Kano]

60 fps is perfectly fine - best on a 60 or 120 hz displays. A more flexible engine can help in cases where the monitor has a differnet refreshrate but i think 30 or 60 fps restrictions are made mainly for multiplayer matches - with older engines those with faster systems had an advantage because they saw the enemy faster at the correct position. Thats why hardcore gamers only need high fps instead of high res and effects - you have to be trained of course to use the advantage. An untrained player can use the fastest system on earth and would still fail.

[Dragonlord]

@Svartalf:
I meant in fact more driving a C backend calling into C++ classes or whatever. So calling from static functions into objects is easier than trying to wrap objects into static calls. But I agree with you there that templates are overdone and OO often too. One should also pay attention to virtual calls. One of the tricky bits in all my design: call virtual only if needed. Nothing beats though thinkingly aligned structs in sequential mode :D

@Kano:
I would stake the claim that a high resolution mouse and training helps more than higher framerates.

[Setlec]

ok i've been quite away from my own thread and it's kinda off topic now... so here is my question again! What features will be available in Id tech 4 when open sourced?

*mega texture?
*voip system?

Cheers