State of the Code

[oln]

Seems like it's best to use the function from xp and older. Seems like it will still work on newer versions. (Don't know if that stuff is backwards-compatible.)
I changed to this method and this shortened the needed code quite a bit.
Should we use a "." in front of the name on windows, or just on linux(/osx)?

[MyEmail]

Assuming that PRROGRAMFILES gives you back c:\program files that is not going to work as windows vista and 7 does not allow a program to change files in that directory.

Ummm... Yes it does . You just have to add the appropriate flags to your manifest.

GetEnv is used on linux.

Its available both in MinGW and VS C++ as well.

Yeah, you are probably right.

{l Code}: {l Select All Code}

SHGetFolderPathA(NULL, CSIDL_PERSONAL, NULL, SHGFP_TYPE_CURRENT, user_path)


That definitely works, but it uses the windows shell extension (which I would steer clear of at all costs).

[oln]

That definitely works, but it uses the windows shell extension (which I would steer clear of at all costs).

Could you elaborate on this?
Also, if one is to use env variables for windows, it seems it's "USERPROFILE" one should try first. (http://qt.gitorious.org/qt/qt/blobs/4.7 ... p#line1045)

EDIT: I changed the code to use the env variables anyhow.

[MyEmail]

The windows shell is the GUI-core of windows. When you use the shell to do menial tasks it does far more than what you need it too under-the-hood. This by itself causes unnecessary overhead that can lead to delays/lag, and if windows explorer is idling (which it will be in a full-screen game) each shell-call could cause tremendous lag.

For example, say I wanted to copy a file. Using the shell provides a easy way to do this, and I pass the parameters to do it in the background (remember, its the GUI so if I copy a file it will pop open a GUI box showing the file transfer, and we don't want that). Explorer is idling when the task is queued, it then fights for CPU time with OpenDungeons and upon acquiring the CPU time does its over-bloated GUI features, then performs the actual copy of the file.

End result: It would have been far faster to use the C file i/o and skip the queuing, CPU-time fight, and extra GUI overheads. The shell just acts as a wrapper too the C i/o anyway, but it does extra stuff behind the scenes that you don't want. Although this example is for copying a file, it goes for pretty much every other shell extension out there. You only use the shell if you need that interface to windows explorer.

[StefanP.MUC]

The path detection isn't working on Windows. The game creates the paths directly on "C:\" without slashes. I now have the folder "C:\OpenDungeonsshaderCache" and "C:\OpenDungeons". Both are empty.

[oln]

I think I found the issue. Try the latest commit. Otherwise I will test myself.

[StefanP.MUC]

Nope, Now I only get this standard error box from Windows 7: "OpenDungeons.exe doesn't work anymore" (not sure if this is the exact English text, only translated from German). It pops up before the Ogre options dialog starts.

Error must be in the ResourceManager, because this is the only thing that is called before the ogre dialog.

[oln]

Found another error, an = where there should be ==.
That should hopefully fix the issue.
EDIT: Seems to be more problems, looking into it..

[oln]

Okay, latest commit is working for me in windows now. (Or atleast getting to the ogre dialog, have to fix the graphics drivers in virtualbox, so I can't check any further.)
EDIT: only worked if the folder didn't already exist.

[oln]

Seems like I got it working now, with a workaround.

[StefanP.MUC]

Works again.

OpenGL also works again, but has a horrible framerate (<20fps), with DirectX I get ~50 fps.

[svenskmand]

I get 60 constant with DirectX on Windows 7 with a Geforce GTS 250 with vsync, so it probably goes higher

Edit: without vsync it is the same.

[oln]

I think it's limited to 60 in the code.

[oln]

I now seem to finally have gotten normal mapping with the RTShader system working properly in the latest commits. Though the the normal-map textures are currently specified in the code. So I will look at making creature definition files next. Some of the normal map textures might be inverted, someone else has to check this.
I also changed the available team colours to the one suggested in the other thread. (Though the old ones were quite similar.)

EDIT: I had to remove the "-ansi" flag that was set for gcc in linux to make angelscript compile (Somehow it worked fine earlier.), due to what I assume is a bug in AS. I think it was myself that added it, and it's not overly important.

[svenskmand]

Nice I will try and compile it again tonight and see how it looks

[svenskmand]

It worked The bump-mapping on the floor, dirt and wall tiles really look nice , although it is very hard to see anything as there is almost not light in the game now :S and the lights there are have very low intensity.

[oln]

Yeah, we could try to increase the intensity of some of them, or place one in the starting room of the players base. I had to remove most lights for the shaders to work. If we want a large number of lights we need to use a different way of applying lighting, which MyEmail was talking about in one of the other threads.

Also, some of the normal maps look a bit like they are not right, either having an inverted axis, or are in object space rather than tangent space. (Both of which are easy to fix.)

[MyEmail]

I now seem to finally have gotten normal mapping with the RTShader system working properly in the latest commits.

Well done!

Some of the normal map textures might be inverted, someone else has to check this.

There are a bunch of things that can cause inverted lighting, and the normalmaps would be the last place I would look. Normalmaps are stored in tangent-space, which means they all face the same direction which is why they are blue. I would check the normals of the meshes, or if the engine calculates the mesh-normals I would check that. Or it could be something as simple as a polygon-winding problem, or the lack of having GL_NORMALIZE enabled. Or it could be in your shader, how you calculate the light vector and whatnot.

EDIT: The most likely culprit is that of the mesh's normals. Just pop open blender and flip the normals.

[Skorpio]

Many programs and engines use different tangent space normal maps. Some have the tangent vectors inverted, others the binormal vectors, or both. Even Blender 2.49 and 2.5 use different normal maps. I wonder why NMs are not standardized.

That means if I want to use a normal map from Sculptris in Blender 2.49, I have to invert both the green and red channels, for Blender 2.5 I can leave it as it is, and for Ogre I have to invert the red or green channel. However, I'm not absolutely sure if everything is correct after inverting the channels.

[MyEmail]

Its not standardized because its trivial. Regardless, this is an easy thing to fix. Just some trial and error in inverting mesh normals and/or fiddling with the shaders should reveal the perpetrator.

[svenskmand]

Yes it is weird that they do not follow a standard, but if we can change the defaults, then I think we should use the same standard as they use in Blender

[oln]

It would be easier if we didn't have to do any changes to how normal mapping is done in the shaders, as they are actually a part of ogre. If the normal maps that come out has to be altered, we could make a simple script using imagemagick or similar for each case to make conversion simple for modellers. (Whether object or tangent space is used can be specified as a parameter, so that can be specified in the coming creature files.) Is it possible to specify parameters for the normal maps in e.g sculptris?

[MCMic]

when trying to build git version I get that :
In file included from /usr/include/CEGUI/CEGUIAffector.h:33:0,
from /usr/include/CEGUI/CEGUI.h:34,
from /home/mcmic/dev/opendungeons/source/Creature.cpp:4:
/usr/include/CEGUI/CEGUIString.h:65:11: erreur: ‘ptrdiff_t’ does not name a type

[oln]

Looks like that is an issue with CEGUI:
http://www.cegui.org.uk/phpBB2/viewtopic.php?f=3&t=5546
(Including cstddef before CEGUI.h may work)

[oln]

Pushed a large commit, moving the gameMap out of global scope. Currently it's created in ODApplication, but that should be changed.
There were some ugly things in the gameMap class, where member functions referred to the global object rather than to "this", which is rather odd.
I also added a function showErrorDialog in ODApplication that shows an error dialog box on windows, we should try to use this when catching errors in the application rather than just printing to the console.