Cube2 engine

[Odin]

The use of an in-house engine as an excuse was probably because Quake 3 was 6 years old at the time of CoD2's release. That probably wouldn't make very good press. It's likely the code was heavily modified though. I still bet MW2 has a tiny bit of Q3 left in it somewhere.

[Haraldx]

Here are all games made on IdTech3 (Quake 3 engine) http://www.moddb.com/engines/id-tech-3/games
Look! there is even a game made in 2009 using Quakes engine! does it look bad? NO!!!

EDIT: the list hasn't got Medal of Honor: allied assault games in it. when those games are starting it says, this game is using IdTech3, ID Tech3 is a something owned by ID software! happy?

[Asvarox]

Yes the point is, that these games use HEAVILY MODIFIED, EXTENDED, IMPROVED, FIXED idTech3 while Tremulous uses fixed idTech3 with few "enchantments" like "bloom".

But hey, xreal is based on ioq3! Then why you want devs to improve current renderer instead of moving to xreal?

[CATAHA]

After 5 minutes of googling around
http://www.neowin.net/forum/topic/396035-cod2-engine/

Its just opinion of one man. He isnt one of CoD2 devs, so his words its only words. =)
May be engine was based on some libraries of q3, but its different engine anyway. its NOT pure q3 engine.
I can say that XReal also such 'q3 engine'. But its modified so far that can be counted as new engine, based on ioq3.
And now we back to start. We need better engine (or manual upgrade for current) for "much better textures and other shit that trem hasn't"

[Haraldx]

Higher poly models would be more needed IMO. currently these ones look very much like many cubes just put together.

[Bowzer]

Here are all games made on IdTech3 (Quake 3 engine) http://www.moddb.com/engines/id-tech-3/games
Look! there is even a game made in 2009 using Quakes engine! does it look bad? NO!!!

It still has that "pre Doom III" look.  No per-pixel lighting at all.  Xreal would solve this issue.

[CATAHA]

Higher poly models would be more needed IMO. currently these ones look very much like many cubes just put together.

High poly count cant help much with quality. Without improved shaders even very high poly model gonna look not natural and ugly. But with good render engine u can make even low-poly model looks fantastic.

[SlackerLinux]

Tremulous uses fixed idTech3 with few "enchantments" like "bloom".

tremulous doesnt have bloom

those engines might be based on idtech3 but i bet 1/2 the codes been ripped-out and optimised features added etc soo much so its prob wrong to call it idtech3 not much can be done with idtech3 its kinda old and shows its age i think trem pushes it a lil much asis.

[A Spork]

Tremfusion has bloom....

[SlackerLinux]

Tremfusion has bloom....

so does fsm-trem(which is where TF got its bloom)(and fsm got it from some other game i forget what)
but the default client doesnt have it

[A Spork]

Maybe so, but Tremfusion is still a tremulous client, therefore its trem, therefore trem has bloom.

[Odin]

Maybe so, but Tremfusion is still a tremulous client, therefore its trem, therefore trem has bloom.

Your logic is revolutionary. We should build a computer based around this theory.

[Taiyo.uk]

The poor appearence of DP (as used in Nexuiz) is laregely due the game assets than the engine - many textures used in the game are "recycled" from old sources with normal/gloss maps badly hacked on to them. The handful of well-made maps using TRaK's textures and others using DOOM3/Q4 assets out there do a far better job of showing the engine's capabilities. Many of the performance issues can be attributed to poor exploitation of modern hardware, i.e. large parts of the code being written for single-threaded uniprocessor systems.

[FisherP]

I don't recall if I've ever expressed these sentiments before, but any discussion of other engines is really an academic exercise. Moving to a different engine basically entails a complete rewrite and (I hope) is obviously not something we want or have the time to do. The only realistic option for better graphics (which seems to be the main motivation for this thread) is to use something based on Q3 like XReaL or the UrT renderer.

Simply put, IF trem moves to a different engine then the only logical choice is XReal, end of story. Since there's already a port for linux then it's a lot simpler I would have thought.

I certainly would hope that any porting to a new engine would occur AFTER 1.2 is released.

[mooseberry]

Moving to a different engine basically entails a complete rewrite and (I hope) is obviously not something we want or have the time to do.

I certainly would hope that any porting to a new engine would occur AFTER 1.2 is released.

Why do you bother quoting him if you don't bother to read what he writes?

[Plague Bringer]

Moving to a different engine basically entails a complete rewrite and (I hope) is obviously not something we want or have the time to do.

I certainly would hope that any porting to a new engine would occur AFTER 1.2 is released.

Why do you bother quoting him if you don't bother to read what he writes?

Based on the assumption that 1.2 is the reason they can't do a port.

[mooseberry]

Moving to a different engine basically entails a complete rewrite and (I hope) is obviously not something we want or have the time to do.

I certainly would hope that any porting to a new engine would occur AFTER 1.2 is released.

Why do you bother quoting him if you don't bother to read what he writes?

Based on the assumption that 1.2 is the reason they can't do a port.

I don't recall asking you the question.

[Plague Bringer]

I certainly would hope that any porting to a new engine would occur AFTER 1.2 is released.

Why do you bother quoting him if you don't bother to read what he writes?

Based on the assumption that 1.2 is the reason they can't do a port.

I don't recall asking you the question.

I don't recall you thinking before typing.

[mooseberry]

I certainly would hope that any porting to a new engine would occur AFTER 1.2 is released.

Why do you bother quoting him if you don't bother to read what he writes?

Based on the assumption that 1.2 is the reason they can't do a port.

I don't recall asking you the question.

I don't recall you thinking before typing.

What are you talking about... Random word changing retorts are something I would expect from fifth graders. Please do not try to flame me or even get involved in this. This was obviously a personal response to FisherP, and it does not at all concern you. There is no way you can voice his opinion for him, so please do not respond to this anymore. Thank you.

[FisherP]

I don't recall if I've ever expressed these sentiments before, but any discussion of other engines is really an academic exercise. Moving to a different engine basically entails a complete rewrite and (I hope) is obviously not something we want or have the time to do. The only realistic option for better graphics (which seems to be the main motivation for this thread) is to use something based on Q3 like XReaL or the UrT renderer.

Simply put, IF trem moves to a different engine then the only logical choice is XReal, end of story. Since there's already a port for linux then it's a lot simpler I would have thought.

I certainly would hope that any porting to a new engine would occur AFTER 1.2 is released.

At Mooseberry, um, read the bits in bold in the quotes above.

[mooseberry]

I don't recall if I've ever expressed these sentiments before, but any discussion of other engines is really an academic exercise. Moving to a different engine basically entails a complete rewrite and (I hope) is obviously not something we want or have the time to do. The only realistic option for better graphics (which seems to be the main motivation for this thread) is to use something based on Q3 like XReaL or the UrT renderer.

Simply put, IF trem moves to a different engine then the only logical choice is XReal, end of story. Since there's already a port for linux then it's a lot simpler I would have thought.

I certainly would hope that any porting to a new engine would occur AFTER 1.2 is released.

At Mooseberry, um, read the bits in bold in the quotes above.

Ok... So for the first sentance you decided to repeat exactly what he just said, "only realistic option xreal" "xreal", and than for the second sentance, you said you hope porting to new engine happens after 1.2... which basically makes it seem like you didn't understand you were speaking hypothetically. Maybe you confuse yourself?

[jal]

big deal... mine looks better
( btw you missed the secret message in my previous post )

This isn't fair, you picked an ancient warsow pic. How about this one instead:

[sheridanm962]

Can someone, who understand engine problems, look at this?: http://sauerbraten.sourceforge.net/screenshots.html
It is suitable for Tremulous or not? I tried Sauerbraten game and I got low FPS (but I have old PC). Gameplay reminds me old DOOM I, but graphic is really nice, especially water or even bullet marks on wall. On the other side, animations are ugly even they should be ragdoll, same with explosions. I think that can be improved but what do you think about this engine?

Engine Features
    * 6 directional heightfield in octree world structure allowing for instant easy in-game geometry editing (even in multiplayer, coop edit).
    * Rendering engine optimized for high geometry throughput, supporting hardware occlusion culling and software precomputed conservative PVS with occluder fusion.
    * Lightmap based lighting with accurate shadows from everything including mapmodels, smooth lighting for faceted geometry, and fast compiles. Soft shadowmap based shadows for dynamic entities.
    * Pixel and vertex shader support, each model and world texture can have its own shader assigned. Supports normal and parallax mapping, specular and dynamic lighting with bloom and glow, environment-mapped and planar reflections/refractions, and post-process effects.
    * Robust physics written specifically for this world structure.
    * Loading of md2/md3/md5/obj models for skeletal and vertex animated characters, weapons, items, and world objects. Supports animation blending, procedural pitch animation, and ragdoll physics for skeletally-animated characters.
    * Network library designed for high speed games, client/server network system.
    * Small but complete configuration/scripting language.
    * Simple stereo positional sound system.
    * Particle engine, supporting text particles, volumetric explosions, soft particles, and decals.
    * 3d menu/gui system, for in-world representation of choices.

Try assualtcube it will still be slow but might have better features: "http://assault.cubers.net/"

and also you may need a decent graphics card to make it run fast because my dad's computer is DDr2 and only has 512mB ddr ram and a decent graphics card and runs smooth at 45-100fps online depending on graphics options

[Thorn]

I should take this opportunity to point out your apparent lack of understanding in computer hardware but shall instead stroke my signature, thanks.

[sheridanm962]

the second pic looks better since it looks like a TF2 Map and Tf2 is only 3 years old