Quake2 vs Irrlicht

saigumi · Post by **saigumi** » Fri May 14, 2004 1:56 pm

The Managed C++ version of Quake 2 is actually pretty neat.
http://msdn.microsoft.com/visualc/homep ... fault.aspx

I ran through it and being able to add a radar to the application that simply was interesting.

I don't think I have the full concept of "Managed" down, but it seems a whole lot like COM+.

Guest · Post by **Guest** » Fri May 14, 2004 2:04 pm

Cool, so it's not actually it's own language? More of an extension to C++?

AssiDragon · Post by **AssiDragon** » Fri May 14, 2004 2:21 pm

Well, Quake2 was made for P2 PCs - even if it's 15% slower it's not noticeable. It would hardly even be noticeable if it was 50% slower LMAO!

And well, radar isn't that hard Saigumi - actually, it can be done with the old Quake2 as well (since you know the position of entities on the map and their rotation as well, it's fairly possible). But since Q2 wasn't for teamplay, noone really put it in - it would have been cheating, well, to a limit

And didn't they say it's in C++ compilable with Net2003? I didn't look at the actual source, and assumed it's C++ :S

Electron · Post by **Electron** » Tue May 18, 2004 9:17 pm

This is all quite interesting about Quake2, but I decided it doesn't really appeal to me. Ogre has some nice features, especially bum-mapping and the ability to manipulate bones in real time. Also, Ogre has a blender export with bones and weights, whereas I have not yetfound a way to get skeletal animation into Irrlicht using free tools (if blender .x exporter ever supports bones and weights . . .)
Right now I'm trying to figure out whether Ogre or Irrlciht is faster. I though Ogre was, but a small demo I made with both, simply loading the same bsp map and moving around in it seemed to run faster in Irrlicht (same resolution for both)

AssiDragon · Post by **AssiDragon** » Tue May 18, 2004 9:49 pm

On a sidenote, I had my game done 50% in Quake2 and still decided to ditch it.

It's not too good imho.

Ogre VS Irrlicht?

First of all - I'm using Ogre now. Might be biased.

Irrlicht runs *damn* slow on my PC, especially with shadows enabled. I fail to see why it does many things, especially with the MD2 format. Niko wasn't fair on that one, well, I felt that way. Why does Irrlicht THEORITICALLY support all sorts of modell formats when only .x works as supposed?! (The other formats wont be fixed any soon, a note...) Heck, MD2s take a LOT more than they should here, and with a few modells in the memory Irrlicht produces interesting things (runs outta RAM - even NFSU couldn't produce that, eck). 3DS modells did boost the RAM usage as well. I know, I'm just ranting here, but this was pretty much annoying.

And well - Ogre supports many methods to handle maps, even dynamic map loading which is very impressive. Plus, ogre has (quite) more advanced features over irrlicht... the only bad thing about Ogre is it's harder to learn and use.

Don't let me influence you though

Tyn · Post by **Tyn** » Tue May 18, 2004 11:22 pm

Everything you say is very true, OGRE is far more advanced. From what I understand ( equally biased towards Irrlicht ) the Irrlicht engine is built in a far easier to understand way. OGRE AFAIK has been out far longer in Irrlicht's defense and I'm sure it'll catch up one day. That's if your project can afford to wait that long, possibly another year until the engine is as functional as OGRE and is stable. I believe when that happens that Irr will be the superior engine so I'm prepared to take a gamble, depends on you tho.

vermeer · Post by **vermeer** » Wed May 19, 2004 7:34 am

for little I know for experienced coders, irrllitch has several features more related to games that are not in ogre (ogre does not have collisions?)

I dunno...but I have looking for a while for engines...not from the coder point of view...and irrlitch heads to have all what I wish in an engine..if makes life easier fo rthe coder , taht's a huge plus! ... I'f seen games done with much worse things, so I suppose this engine can be used to do wonders.There's always a limit fo revery engine. This is so true. the ability of us artist to overcome problems and find additional solutions is absolutely essential.The coder can't make absolutely all...

(if blender .x exporter ever supports bones and weights . . .)

hehe....TRUST ME, it will. And REALLY soon , yuk. And it will probably ROCK, not only for Irrllitch.

There are now many of game engines and game making tools (actually, the 4 main ones, one of them non directly) that support x import , with weights or not, depending on how good is each importer (in that Irrllitch is one of the few to support well weights)

So, it will have a tool to: develope fully animations, with -now, finally- a workable joint pinning system (with some tricks and the use of empties, I managed to emulate that) , damn powerful general 3d package.

Also...there's a in-the-works lightmap generation blender plugin. It may kick ass as, because, with ambient occlussion and many new blender internal render features, it surely will generae outstanding renders ---> outstanding lightmaps.

As far as I know (but somebody mentioned there are problems yet with x second uv channel in irrlitch?) then u can export x files from many tools and use in irrllitch.Really a load of tools.

What is even more...u can use any 3d painting tool (free for non comercial Tatoo, free for whatever Graffitti (a pain to use), or comercial like purchased mine, deep paint 3d 2.) to "fake" a lightmap.If u're good at painting you'll get surprised it can output a decent lightmap...I tested on a random scenery the other day...heh, I even painted subtle lights on areas, soft shadows...used Ultimate Unwrap (40$ , worth it, export as x files that irrlitch likes.... support for bumps, specular, lightmaps, generation of the 2 uv channels, loads of uv mapping operations.Gratest uv mapping tool ever) to generate a pair of uv channels (could do different channels each but just copied from one to the other.) and assigned a composite material with a diffuse map, and the lightmap.The 3d preview with both in multiply mode really kicked ass.

So, as also Ultimate Unwrap allows me export x with the 2 uv channels, I can export x with the uv info fo rlightmaps from there.I'm afraid u can't do this yet in blender, but if u find a way via code to copy uvs from channel 1 to channel 2 of UVs, then u can use my 3d painting method (or just future generation of neat lightmaps with Blenders renderer and lightmaps plugins) to export the tga, and assign to ur recently created second channel uvs. As u just used the uv channel 1 in blender to generate lightmaps, and copied the lightmaps from 1 to 2nd channel, it will work.

U see...the main important features of 3d stuff in games (lightmaps and bones with weights and animations) are both supported by *.x format.

MD2 I have tested in sebveral viewers, including irrlitch, that deforms mesh, uglily.Trembling vertices, bad shading.IN WHATEVER the engine.As that awful format is full of limits. I'd use md3 instead,(u can export mesh frames as ASE or 3ds, and convert with nmd3 compiler, but some problems too) and much better , much more, x format.

As I though at the very beguinning, I keep thinking....x format is the key. I'm no MS friend or geek about it, all the opposite.But i love this format. Anyway, is an open source format. So, all development done to polish the format, will end up in having a rock solid, feature advanced way for atist get content into irrlitch, nd there so few -or none- free engines that allow this....

there are still some issues with the x files in Irrlitch.As far as I know, saved models with MS SDK mesh Viewer, or the comercial Ultimate Unwrap, are ones that Irrlitch likes(of course, those saved with the Panda Max6 plugin, but u mentioned not comercial...for me , the Ultimate Unwrap 40$ is not that expensive...). Now I am overloaded of work for personal stuff, but in a bit more than a month, if all goes well for me, I may even mount a site for help with ways and tricks and free tools for free game content.

AssiDragon · Post by **AssiDragon** » Wed May 19, 2004 9:00 am

Well, Irrlicht right now is quite far from Ogre, imho. Take a look at shadows. Ogre has now 3, working all perfect and fast even - while Irrlicht has one, which appareantly does not work on every hardware and is VERY slow. And Ogre is being improved as well, not only Irrlicht...

Vermeen - a game engine does not need collision or anything such. It's just unneccesary, which I don't consider too good. A game engine should just do the rendering and that's it - collisions and stuff are for the physics engine. Ofc this makes the life easier for the programmer, but if you want to make a serious game you need to get a phys plugin anyway. As for being easier for the programmer - Ogre isn't THAT much hard after a while, you can get used to it if you have enough experience. And I think it lets more tuning than Irrlicht (a tradeoff for easiness).

As for .x and MD2 - Irrlicht doesn't use anything but .x properly. It's a bit upsetting to claim "this engine uses so many modells" when single modells of 3DS or MD2 take up quite a lot megabytes in memory, making the whole thing pointless. As you can see, not everyone is an .x fan.

Electron · Post by **Electron** » Wed May 19, 2004 10:15 pm

Hmm, thanks for the help. I agree with Tyn that Irrlicht is yet young and will probably have all the features of Ogre at some point (though of course Ogre is still developing too)
As for not everyone liking .x, I'm sure that's true,but if I use use Irrlicht I will almost certainly use .x, it supports skelteal animation ans a large number of other things. And Vermeer, I really hope your right that Blender will support bones and weights soon

One of the samples that comes with Ogreloads a bsp map (just like the Quake3 map example). I just changed the bsp so it loads the one that comes with Irrlicht. Ogre runs that camera thru the map at a depressing 30-50 fps on my machine.
The Quake3 map example in Irr (even if I remove the octree,load as a regular AnimatedMeshSceneNode) runs at 120+ fps. Resolution same, and i set the scene node in Irr to optimize for quality and use 32 bit textures.
Ogre did load the shaders that Irr doesn't, but they looked horrible,kept flickering as I moved the camera. I didn't change the samplesource in ogre at all,just the bsp, so I'm surprised that it comes out that poor. I dunno if its just something with my machine, but it certainly didn't impress me.

Irr shadows are horrible, but I hope they'll be getting some improvements and I don't view themas a critical factor in my decision

the thing that I really do like about Ogre is its much better skeletal animation support (blending animations, real-time manipulations of bones, etc).

Ogre support of MinGW/Dev-cpp is poor, meaning that I don't imagine I'll have an easy time if i try to modify the engine at all.

There's my ramblings, thanks again for the help

vermeer · Post by **vermeer** » Wed May 19, 2004 10:18 pm

In the coding side, I can't say a word. So I don't know.

But about the x file...I know am a fan of it, but for reasons. I am an artist, and quite long time at it. And know well the pains for the artist, and what is worse, the artistic limits imposed by formats like md2 or 3ds. I do not mind actually other formats if is provided a format well supported by most tools, and many free converters, and is powerful enough.

To list some of the problems that even will make any artist run away from an engine, open source or not :

- 3ds. Does not support shared UVs. This means that when I have -most often- a human leg mirrored in the uv map, I wont be able to mirror(it will do, but put a break in the mesh) and weld, so to use same uv space for both sides. (provided in the character design that is symetrical, ofc) That's huge drawback. basicly force u to waste 2x the texture space. It also was useful for avoiding texture seams easily.
Count limit to 65.000 tris. Way too much ...maybe, but I've been doing levels with some mates of that number and higher, for scneeries. If one surface is wished to keep better performance... long names in materials...a DOS limitation I thing.. *.3ds is...OLD. X supports shared UVs without breaking, splitting the mesh. 3ds dont support two uv channels, while X does. (in a future, to do cool lightmaps with x files)

-Milkshape 3d.Nice format supporting smooth groups, bones, animation. (I think it was ms3d fro base mesh, the ascii format for anim) problem is...weights aren't stored as Milkshape yet is not having weights...which make joint deformations worse. Still, just as nice as OBJ -yet I like more OBJ- for static objects, and robot animations. or if u don't mind loosing smooth bending in human joints. X have weights.Besides, u can only output mshape files with mshape, comercial, as well as with cfx, comercial also. And they are only two.Blender will soon export weighted x, and it's free, and the number of big comercial packages (an smaller like 3d canvas, character Fx, Ultimate Unwrap) is crazily big, all the big ones in fact. No othe rformat doing this, as well as in the cheap/free side. (FBX is not supported in the free land. Wings 3d, but wings does not animate) Is not passion of mine, is plainly the only one to do this.

-Md2, huge in memory (it is huge even in the engines that don't have that bug) as stores a mesh per keyframe... Tip here is...use less keyframe...yeah, but then animation is waaay less smooth.Even robotic. Even more...the amount of meory-performance eaten goes wild when u use these days models counts...most of my models are 2000 and higher (unless is for strategy games) ...that...makes it even huger, and also, for some reason, weird deformation is way more noticed.
Weird deformation is for something about not using floats, this format (don't ask,I am not a coder) The fact is it makes vertex position sun accurate, making VERY weird deformation to your carefull modelled mesh, and producing a disgusting trembling of vertex, which also produces strange shading changes. bad shading, for other reasons also, which I don't remeber why it happened.
besides, way less fewer packages exporting md2. Even less doing properly.
And I have Milkshape, and I learnt to use Quake Modeller for it, and npherno md2 NST for mapping them.
X is based on a kind of base mesh info, and then is key frames based on changes of rotations and locations, is not much heavier with more frames, it has not those bad viewing problems, and it puts the exact mesh that you want.

-md3 is much better than md2, and u can use it one single mesh as I prefer...but again, is vertex animation, heavier as explained, and also...well,...never will have access to "bones" by code...

But yet though, i fully respect those preferring using md2 and other format than x...but I hope those to prefer it really know the issues of these formats...I have used many 3d formats, and suffered many "pains"... and limitations.

Domarius · Post by **Domarius** » Thu May 20, 2004 4:59 am

AssiDragon wrote:As far as I know there is no C++ source of Quake2. If there is one, could you give me the URL?

At www.gamedev.net, where else?

On this page, down the bottom;
http://www.gamedev.net/reference/list.asp?categoryid=45
This is the specific link, if you want to download it;
http://www.gamedev.net/reference/articl ... le1772.asp

So now you know

I would like to quote "Spike", from the forum link you posted, AssiDragon, since he feels the same way I do;

...it's better that the programmer understands it, and it being stable instead of crashing five times and having to be rerun. Good code is often better than fast code...

and "dno";

...execution speed is just one of the considerations. Things like development time, stability, portability, and modifiability also need to be taken into consideration.

Even if there is a 15% speed increase with Quake2 in C, is it worthwhile? And that is a specific case, there is no telling how other projects would benifit from C in speed alone, and wether it would be worth what they would suffer in other areas of the project.

For me, the 15% speed increase wouldn't be worth dealing with an non OO language. OOP is a newer, more evolved programming standard.

AssiDragon · Post by **AssiDragon** » Thu May 20, 2004 2:44 pm

15% speed DOES matter, especially at something which wouldn't run at 200FPS without a silly FPS cap but would run with say 40 FPS. You would feel that 15% there for sure.

As for the easyness of coding - that's COMPLETELY a side issue for me.

Gamers want to see the game working fine and fast; how I do is not an issue for them, at all. They simply don't care, you know... they just want results. Silly thing, but this is how it works.

As for those comments - Quake2 uses C (not C++) and does never ever crash unless you do something VERY silly in the code.

So it's stable.

Development time - depends at which are you more experienced at.

Portability and modifiability - Q2 is portable to Linux and Win as well, and that two pretty much covers up everything a game would need. Modifying - Q2 is as modifiable as a sane game needs it. Alright, it wont get total conversions but that's not something I wanna consider when writing a game. ^_^ Though if you want games where some people can completely strip your gameplay out and place theirs in while leaving the rest unchanged, yeah, C++ is better

(sorry, not a fan of the idea because they tend to claim it their "hard work" only and forget the rest

)
And, I strongly dislike the "performance for my own comfort" tradeoff.

Well, that's me only though.

Vermeer - sure then ^_^ though try explaining me why does an engine support formats that don't work with it at all, and wont ever because noone will bother doing them?! One thing though - I'm playing and developing Quake2 for quite a while, and I never really saw trembling vertices...

Besides, I'm gonna use a fairly unkown modell format called REO/REC anyway. It was used for the game called Drakan (old one). Supports UVs (to a limit), skeletal animating+weighted vertices, unlimited number of bounding boxes/spheres and some yummy stuff. ^_^ It's just annoying tht something is propogated as supporting so many things and in the end it supports only one.

Tyn · Post by **Tyn** » Thu May 20, 2004 5:31 pm

My point would be that there are bugs in all the formats, they will all be fixed before the First Release is out. Irrlicht isn't finished yet, trying to twist an unfinished piece of work by saying that bugs in the formats is actually some conspiricy to hide the fact that Niko doesn't care about anything but the DirectX file format is just plain wrong IMO. Don't forget that it is an incomplete work, if your comments were still valid when Niko finishes 1.0 then I would wholeheartedly agree with you but I think it is still too early in development to try and make statements like that.

AssiDragon · Post by **AssiDragon** » Thu May 20, 2004 9:04 pm

Quoting Niko, from the thread where this has been reported:

"I know the problem with the md2 files, but it has not that much priority for me. [I am focusing on .x files, you know ]"

Anyway, I'm moving to Ogre now I think. Just wish these stupid exams would end so I could work on it

Tyn · Post by **Tyn** » Thu May 20, 2004 10:50 pm

Which of cause means that the bugs in the other formats will never be sorted out