Dark lightmaps?

[BRabbit]

Today I finished compiling the Cafu main executable.
But everytime I open a map, i get some kind of weird dark lightmaps. I have made some modifications, (but not many to get this result !) i just would like to know where in the code (probably the Material system or the 3D engine itself) I can look to find if i have changed something to get this horrible screens:



It happens with all (unmodified) maps, here are pictured AEonsCanyonTower and BPWxBeta both opened with my a bit customized Cafu engine and with the original unmodified one.
Any help will be appreciated.

[Carsten]

Hi BRabbit,

Today I finished compiling the Cafu main executable.

How exactly did you compile Cafu?
Using SCons as described at Getting Started with the Cafu Source Code, or by some other means?

I've just verified locally that CaLight and Cafu work properly, and the screenshots seem to suggest a problem with - just a guess - struct alignment.

But everytime I open a map, i get some kind of weird dark lightmaps. I have made some modifications, (but not many to get this result !)

Well, which modifications exactly did you make?
Did you modify anything in CaLight, and/or the world file loader code?

i just would like to know where in the code (probably the Material system or the 3D engine itself) I can look to find if i have changed something to get this horrible screens:
[...]
It happens with all (unmodified) maps, here are pictured AEonsCanyonTower and BPWxBeta both opened with my a bit customized Cafu engine and with the original unmodified one.

Well, the key is certainly in identifying what exactly you changed. Knowing that, we'll know what causes the problem shown in the screenshots.

Can you post the result of svn diff (assuming you're using the code from the Subversion repository)?

[BRabbit]

I compiled it using a visual studio solution with the r-76 version of the Cafu source.
The thing is that the maps aren't changed or compiled by me, so i don't think CaLight is the problem, neither the Deathmatch or the renderer DLLs (i haven't compiled or used them).
Maybe i'm wrong, but this seems to be a problem of the reading part of the map. The skyboxes, models and materials are rendered properly, but not the lightmaps (those rare color stains are the lightmaps right?).

Where in the code are these lightmaps processed? Maybe as you say doing a diff with the custom and the unmodified code I could find the error. (Making a diff with the entire solution would be harder, given that i've been doing modifications for a while here and I would find a lot of differences.)
Oh! And some GUIs are wrong displayed too:

As you can see in the picture, the blue color is changed to green, the cyan to red, and it goes on (Grayscale colors don't seem to be modified), and it happens in the maps and in the GUIs as well...WTF??
Thx a lot.

[Carsten]

Well...
the lightmaps for faces are loaded in FaceNodeT::CreateFromFile_cw(), but the problem might just be with BitmapT::SetPixel() as well, or where the bitmaps are turned into OpenGL texture objects.

Also, what maps exactly do you use? Those of r76? r174? r...?
Did you test what happens when you're compiling them yourself, e.g. like this:

Code: Select all

D:\Dev\Cafu> Games\DeathMatch\compileMap.bat AEonsCanyonTower

(Note that you likely have to edit compileMap.bat before it can work!)

Generally, this looks as if the byte-alignment went wrong somewhere (you are on a pure 32-bit system, are you?)but it's really difficult if not impossible to say what exactly happens without knowing what changes you did, when this started, etc..

Btw., note that - for example - Beyond Compare is an excellent tool for comparing entire directory trees (e.g. yours, and r76 or SVN head of unchanged Cafu code), and to create very nice difference reports.

[BRabbit]

Ok, thats enough information to get me working on this for a while
And i'm using the maps bundled with that version. Also tried with the latest maps and got the same.

[BRabbit]

I never thought that a simple compiler switch could fix all this problems! LOL The /J (Changes the default char type from signed char to unsigned char, and the char type is zero-extended when widened to an int type.) compiler switch solved both errors, from the wrong lightmaps to the GUI.
Fixing this error wouldn't be possible without you Carsten saying that the byte alignment was wrong! haha thanks!

[Carsten]

Hehe, good job , and nice to hear that you found the problem (such issues are often not easy to identify)!

When I wrote the original code using the Watcom compiler, chars used to be unsigned by default (iirc), so using the /J switch was necessary with newer compilers.
(The proper solution would of course be to explicitly change the type from char to unsigned char or even better to uint8_t wherever appropriate (I'd happily accept related patches), but doing that properly might be a lot of work...)