Features
XreaL is based on a heavily modified IOQuake 3 engine. Some of the new features compared to vanilla id Tech 3 are listed here:
- access to the OpenGL driver through a new interface designed like OpenGL ES 2.0 with additional support for OpenGL 3.1
- clever usage of vertex buffer objects (VBO) to speed up rendering of everything
- avoids geometry processing at render time using the CPU (worst bottleneck with the Q3A engine)
- renders up to 500 000 – 1 000 000 polygons at 50-60 fps on current hardware (DX10 generation)
- optional GPU occlusion culling (improved Coherent Hierarchy Culling) useful for rendering large city scenes
- GPU accelerated skeletal animation system that outperforms all current CPU based implementations
- Doom 3 .MD5mesh/.MD5anim skeletal model and animation support
- Unreal Actor X .PSK/.PSA skeletal model and animation support
- true 64 bit HDR lighting with adaptive tone mapping
- advanced projective and omni-directional soft shadow mapping methods like VSM and ESM
- real-time sun lights with parallel-split shadow maps
- optional deferred shading
- relief mapping that can be enabled by materials
- optional uniform lighting and shadowing model like in Doom 3 including globe mapping
- supports almost all Quake 3 and Doom 3 material shader keywords
- TGA, PNG, JPG and DDS format support for textures
- usage of frame buffer objects (FBO) to perform offscreen rendering effects
- improved TrueType font support that does not require external tools
- off-server data downloads (http redirection) via HTTP and FTP with cURL
- OpenAL sound rendering allowing for surround (5.1 and 7.1) speaker layouts and generally improved sound
quality. Especially on the Windows Vista Operating System. - Ogg Vorbis audio decoding for positional sounds and music streams
- Ogg Theora video playback for MPEG-4/DiVX class video decoding
- VOIP support using Speex
- IPV6 Networking. We’re ready to frag on the net of the future!
- SDL backend for the OpenGL context, window management, and input. This also improves portability.
- improved console command auto-completion
- persistent console command history
- colored terminal output on POSIX operating systems
- multiuser support on Windows systems (user-specific game data is stored in their respective Application Data folders)
- numerous security fixes
- replaced Gladiator bot by the Quake2 ACEBot with waypoints navigation
- customized XreaLRadiant level editor based on DarkRadiant
- advanced XMap2 map compiler based on the popular Q3Map2 compiler by Randy ydnar Reddig
This is really impressive for an open-source engine. One of the most advanced I have ever seen. Although I would strongly suggest JPEG support for textures. Its the most common file format for images and will make development with the engine so much easier.
The Sauerbraten engine is good, but it dosen’t have the features needed to make commercial-quality single player games.
Very nice engine! But I think this engine need some physics (ODE for example), Do you you think about some physics for your x-real project?
Physics? How about implementing nvidia physx ?
http://www.nvidia.com/object/physx_new.html
I think about rewriting the game code from scratch using Java and to use JBullet the Java port of Bullet for advanced physics. It’s clean code with advanced physics. Just try the demos: http://jbullet.advel.cz/
Mixing the existing C game code using C++ physics engines like PhysX is not very convienent.
\I think about rewriting the game code from scratch using Java\
really??
>\I think about rewriting the game code from scratch using Java\
>
>really??
Yeah, why? I mean, not to bash Java, but it’s just not what pops into mind when working on performance oriented projects.
Yes, all the comparisons show Java code runs almost as fast as C, but starting the VM is still slow and needs more memory.
>Mixing the existing C game code using C++ physics engines like PhysX is not very convienent.
Hmm, have you tried compiling your C code with g++? I would imagine there aren’t many problems left, regarding C++ libraries/engines, once it compiles. And it’s a better step then jumping on the JVM slowboat ;-P
Still, awesome feature list! If there is anything left to wish for, it would be a scripting extension. Lua is pretty awesome as embedded script language.
Ah well Lua was not listed but it is already implemented in the C game code and client game code. I already embedded the Java VM into the engine and server and I can do advanced physics simulations with JBullet. The speed is ok even with hundreds of dynamic rigid bodies while running the server and network at 60Hz.
>Ah well Lua was not listed but it is already implemented in the C game code and client game code.
Sweet! To what extent is Lua embedded, how much can you do with it?
>I already embedded the Java VM into the engine
So, you didn’t have to port the engine to Java? I didn’t even know the JVM was embeddable. How much glue (as in code) is needed to make that work?
Awesome job man, but Im still afraid that the it will run SLOWER than pure C and C++ merge.
so we have both Java and Lua embedded into Xreal?
I wonder, since you have that walk-on-walls like prey has, does your game have the ability to have completely altered gravity like prey does?
Like you shoot a ‘node’ on the ceiling, and everything turns upside down, including objects which fall to the ‘floor’?
about physics:
)
If skeletal animation is implemented why then not to try to add advanced physics engine for rigid body calculation ( ragdoll in q3 would be cool
maybe havok or physx ?
I would like to see q3 on this engine.
anyway You guys don’t need some music to your project ?
all the best with XREAL!
I’m following news since it was first released
Concerning Physics, have you thought of ODE http://www.ode.org/ ?
Because I personally think sticking to C/C++ is the right way and ODE should work great with the C Code.
ODE is no option because it does not support Continues Collision Detection (CCD).
Dude, don’t take Java
This game looks really, really awesome. Java will make it slow und less portable. Users will have to worry about Java-Version, especially on Linux or BSD there is different free and different non-free Java-Versions, and that really sucks.
I really can’t imagine that the overhead is worth it…
Anyways, the game looks really great, I hope it gets ported to FreeBSD!
I don’t think we should put Nvidia PhysX, because not all GFX cards support it. I say, go for Bullet. Its very advanced physics engine.
> RE: Java Gaming.
I’ve worked on some Java multimedia projects and one very annoying Java problem (other than terrible audio support and floating input latency) is unless you have a very smart, highly-optimized JVM your game may occasionally pause or stutter as Java decides to take a time out and garbage collect.
Xreal has the best id3 tech graphics ever! Great work! Nice Features!
But what’s about this Shena Playermodel? (even Quake 1 animations looks better)
I thought Xreal supports IK (can’t see that, confused…)
So, will there ever be advanced physics via CUDA, Open CL or Physix? I’m no programmer, so I don’t know how hard it would be to implement Physix or something, but I think Xreal should really have Ragdolls etc.
(Nvidia PhysX is free, and YES, it does run on every modern Gfx-Card).
Anyways, Xreal rocks! Go On!
As long as Xreal doesn’t have advanced ragdolls, most artists will create models, maps and such for other games, but not for Xreal. The question is, why should we create time consuming stuff for Xreal when we cold do the same for Doom 3, UT3 or Crysis?
So what are the future plans? What features will come next? I can’t find a Xreal roadmap. It would be nice if some of the devs would clearify…
Again, the game looks really great. Good job!
I’d not use proprietary PhysX in Open-Source project.
The nvidia physx engine (in cuda form) does NOT run on any graphics card. It will not run on ATI/AMD cards, and that is unlikely to change any time soon. You talk about using jbullet, but what’s wrong with the native C(++?) version of the bullet engine? http://bulletphysics.org/wordpress/
If you’re doing physics, do it natively, not in JVM land please.
You could wait for some opencl implementations to come out if you don’t think the cpu is up to the task, but for the rigid body stuff the cpu will probably be fine.
Wondered if the devs had given any thought to using a positional audio plugin for VoIP much like Mumble (which also uses Speex?) So many games forgo using the leverage found in a decent VoIP integration and the games/mods that result suck because everyone is doing their own thing (including cheating) with any of a myriad of other VoIP clients. I’m happy to see Xreal at least has VoIP but something as \bleeding edge\ as positional audio would take the cake IMHO!
You think you need Bullet because of CCD. Anything else?
And do you have anything in mind about paralel programming. You know the users now have multiple core pc’s and they want to get the most of it.
Have you ever had a look at Aqsis Renderer. It’s written in c++ but the libraries can help developing the 3d experience. It’s based on RenderMan. Maybe the ideas can be useful for you.
Have you ever tried grouping these features? I’d like to do some suggestions but I can never be sure if there’s a solution about that already.