Irrlicht Engine

I don't know if anybody else has had the same problems as me compiling the Irrlicht 0.5 source code under Linux, but after a little time spent tracing back compiler output, I managed to get it to compile. the problem lies in the CVideoOpenGL.cpp file. The functions "glActiveTextureARB" and "glClientActiveTextureARB" from the WIN32 constructor are called several times in the code without the proper #IFDEFs and #ENDIFs around them to keep gcc from compiling the source correctly under Linux. I've managed to get the source fixed to where it will compile, though I haven't tested it yet, so I don't know how well it performs. Anyways, I thought maybe this would be helpful to some of the other fellow Linux users that have run into this problem. I have also posted my modified version of the source file here for anybody who wants to download it. I would also like to thank Niko for writing this great engine, and giving us all the oppurtunity to use it in our games.

Download the updated source file here

hehe, I have had so many problems with compiling GL programs that I ended up modding the system wide headers

Well, I finally got around to testing the enging after these changes, and I'm pleased to say that it works nice and fast!

Now for the other thing that's been bugging me? How do I get the Techdemo to compile under Linux?

I did never try to compile and run the techdemo in linux (simply because I was too lazy), but with a few changes, it should work. Remove the COMPILE_WITH_AUDIERE (or whatever I named it) define, and change WinMain() to main(). Maybe you'll get some simple compiler errors (did not test it with g++) and after they are fixed it should work.

Thanx for the fixes! I already wondered how to compile it (and how Nico compiled it for Linux!).

For the techdemo, look here:

http://irrlicht.sourceforge.net/phpBB2/ ... php?t=1543

:twisted:

Cheers,

Tels

I was just reading your page about the techdemo, and thought I'd try to explain some of the bugs in it.

I am not sure whether this are general bugs or Linux specific problems:

* There are some holes in the level, especially at the floor. You can look through some 20cm by 5 m rectangles near a wall. The bullets you shot also go through these holes.
* The shadows are ultra-black (instead of half-transparent)
* Some pixels are disturbed on the model and by the shadows, this looks odd
* No mipmapping seems to take place (and no filtering). There is a lot of noise in the textures.
* When walking around, sometimes the textures get very heavily distorted depending on viewpoint
* The main menu is very hard to read due to it's high transparency

The "holes" that you see in the level are not necessarily bugs in the Irrlicht engine, but are there because they originally used shaders (in this case the Quake 3 Lava Shader) , which Niko has not implemented into the engine yet. If you want, you can replace the techdemo map with one of your own, preferrably one that doesn't use shaders, and it will look fine. If you want to see what I'm talking about with the missing shaders, simply open up the techdemo map in Quake 3, and you'll see right away why it doesn't show up in irrlicht.

As for the shadows, this is something I've been trying to dig into myself, but I'm relatively new to 3D programming. I've been programming in C++ for several years, but as far as 3D stuff goes, my extent is pretty much just things like mods for Quake 3. But, I have a feeling that the stencil-buffer thing is just a problem with setting transparency in Linux, and there's probably just an alpha value that needs to be changed somewhere.

And about the mipmapping, I really don't know a whole lot about this, but I think that the mipmapping, and the lightmap problems might have been caused by the "quick-and-dirty" way I patched the OpenGL driver in the engine source. Basically, I pushed all of the multi-texturing calls over into the WIN32 #IFDEFs. Again, I know jack-squat about 3D programming, so I could be wrong here too. Strangely, the lighting works great in the SpecialFX example that's included within the SDK.

Also, as far as the GUI text being hard to read, just take a look at the GUI example in the SDK, and you should get enough of an understanding of how it works to fix the code and make it a bit easier to read.

That being said, I'm going to keep rooting through the source and see if I can't find what's causing this problems, though I don't expect to accomplish anything, because some of the stuff in there makes me feel like a monkey reading a Quantum Physics book. But, I guess it's the only way to learn.

"Honkey Kong"]I was just reading your page about the techdemo, and thought I'd try to explain some of the bugs in it.

Thanx for the explanation about the holes! Makes sense. Should probably go into the README I wrote.

techdemo map in Quake 3, and you'll see right away why it doesn't show up in irrlicht."

I dont have quake3 (yes, yes I know :)

But, I have a feeling that the stencil-buffer thing is just a problem with setting transparency in Linux, and there's probably just an alpha value that needs to be changed somewhere.

There also might be different capabilities of grafic cards here.

And about the mipmapping, I really don't know a whole lot about this, but I think that the mipmapping, and the lightmap problems might have been caused by the "quick-and-dirty" way I patched the OpenGL driver in the engine source.

No, because I used the pre-compiled Irrlicht. However, I wonder how it was compiled because the source didn't compile on our machines. Maybe Nico used the same hack than you to compile it?

"Strangely, the lighting works great in the SpecialFX example that's included within the SDK."

I have to check that out.

"Also, as far as the GUI text being hard to read, just take a look at the GUI example in the SDK, and you should get enough of an understanding of how it works to fix the code and make it a bit easier to read."

Ok, that should be generally fixed in the techdemo, because it looks unprofessional :)

That being said, I'm going to keep rooting through the source and see if I can't find what's causing this problems, though I don't expect to accomplish anything, because some of the stuff in there makes me feel like a monkey reading a Quantum Physics book. But, I guess it's the only way to learn. :wink:

:-)

I'll also work on Linux because of my Perl project, so I might send patches in.

Cheers,

Tels

Tels wrote:

And about the mipmapping, I really don't know a whole lot about this, but I think that the mipmapping, and the lightmap problems might have been caused by the "quick-and-dirty" way I patched the OpenGL driver in the engine source.

No, because I used the pre-compiled Irrlicht. However, I wonder how it was compiled because the source didn't compile on our machines. Maybe Nico used the same hack than you to compile it?

Well, it's nice to know that my hack didn't mess up the stencil buffer any worse than it already was. Although, Niko making this hack just to make it compile in Linux doesn't seem to be likely. The reason I say this is because I know that certain compilers seem to be more lenient than others when it comes to #IFDEFs and such. For example, in the Quake 3 game source code, in order to make it compile under linux, you have to change a few lines that say #ENDIF MISSIONPACK to #ENDIF // MISSIONPACK because Microsoft's compiler lets this slide, whereas the GNU compiler is more strict about standards, and will call you on it. My guess is that Niko used a compiler other than GCC/G++ to compile the Linux version, and hence, it allowed the little #IFDEF slip by simply ignoring the Win32-specific functions. I noticed that the makefile was generated by bloodshed, so I'm guessing that the compiler in question would be the one used by Dev-C++. Just a guess, of course . I am open to corrections.

Hi

Is there any solution on the problem with mipmapping and lightmap? When loading a quake3 level on linux.

I am try to do a Linux release of YAMMO and Venom.