State of the Code

[StefanP.MUC]

Nice.

But is it the best choice to separate level loading and the GameMap object? The loading functions could be static methods of GameMap or normal methods of the ResourceManager singleton. I'd find this more intuitive than having it separated.

[oln]

I don't know, but I think it would be best to keep the loading separate, to avoid the gameMap class being too large. (And/or splitting other things out of it.)

[StefanP.MUC]

I think it's no problem if classes are large, only functions shouldn't exceed reasonable limits. However, the current way with the namespace is already much better than before in global scope.

[MyEmail]

ewww, namespaces and bloated classes. Moar c and less ++ plz? (I believe the inverse transformation of C++ is C-- :P)

[oln]

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.

Have you done any testing on this?
From what I can see in the shader code, RGB (0-255, 0-255, 0-255) is mapped to XYZ(-1.0 to 1.0, -1.0 to 1.0, -1.0 to 1.0).
This page: http://www.blender.org/development/release-logs/blender-236/normal-maps/ on the blender wiki states that for the blue channel, blender maps 0-255 to 0-1.0 instead. Not sure what versions this applies to though.
Would be nice to find what blender uses so we can tell people how the normal maps should be made.

[oln]

I have implemented a very basic framework for implementing AIs now. Would be nice to make these scriptable as well.
Basically one would derive from the NullAI class, and implement the doTurn function that will be run each turn. The ai objects contains a class that contains, or should containt access to what the AI needs.

[svenskmand]

If anybody figures out how the normal map conversions then it should be easy to make a quick program to convert from a specified list of programs, e.g. Blender, Scrulptris, etc. to the Ogre 3D standard for normal maps.

[Skorpio]

I don't think we need an extra program, we just need to invert the red channel of the normal maps.

[oln]

Pushed a commit that improves creature behaviour slightly and fixes some issues with it. (Though the creature AI needs a major rework.)
There is also an ai operating now, all it does is mark the gold tiles close to it's dungeon temple for digging.

[StefanP.MUC]

I now get an error:
"dependencies/pthreads/include/semaphore.h:149:8: error: 'mode_t' has not been declared"

[oln]

What file is it included from?
Seems like mode_t doesn't get defined when compiling in mingw for some reason, so it has to have been defined before semaphore.h is included. I know it's done in globals.h at least.

[StefanP.MUC]

The error pops up when compiling TestAI.cpp and including GameMap.h from there.

[StefanP.MUC]

I added the #ifdef with #include <sys/types.h> that we have somewhere else already, this makes it working again. I will push it with my next commit.

edit: pushed

[StefanP.MUC]

I just pushed a commit introducing a new namespace "Helper". For the AS binding I needed some useful function like converting strings to numbers and checking if a string is a number. I moved them all into this new namespace. So, if we should stumble across string to number conversions (there are lots of passages that have many stringstreams just for this purpose, so it'S good to have central place for this task) in the code we should convert them to use these Helper:: functions.

Also, I removed all the #define M_PI stuff and put a new global "const double PI" into Helper.h and changed all M_PI to PI. If we ever need other math constants, like Euler e, they should be declared in Helper.h.

So, in the end, Helper.cpp/h should be the only file holding namespaced "general purpose globals", after Functions.cpp/h and Globals.cpp/h are sorted into better places.

[oln]

I just pushed a commit introducing a new namespace "Helper". For the AS binding I needed some useful function like converting strings to numbers and checking if a string is a number. I moved them all into this new namespace. So, if we should stumble across string to number conversions (there are lots of passages that have many stringstreams just for this purpose, so it'S good to have central place for this task) in the code we should convert them to use these Helper:: functions.

There is actually a class in ogre for this purpose (StringConverter), though abstracting it out might be a good idea anyhow.

[StefanP.MUC]

I think we need a consensus here anyways:
1) If one of our libraries already has a specific (and probably incomplete) functionality, do we always want to use it even if we could maybe have a (probably simpler, better, faster) function ourself, and only write our own functions if the library doesn't provide it?
2) Or do we want to have simple tasks done completly by our own functions (probably less overhead, more consistent with our codebase), even if there are ready function in one of our libraries?

The first case could save us some work, the second case gives us more control (and bugs can be fixed by ourselves).

I vote for case 2)

[oln]

I think it's more the question of whether we should use Ogre and CEGUI solely for the graphical stuff (and that way make the code more modular), or if we want to utilise the extra functionality these libraries contain. (I don't know whether it will be faster or slower than what we would write ourself.) (Also, we could go with using boost for utility things.)

For things like the number stuff, since we have written it now, we might as use our function, but we need something new and ogre or cegui provides it we can make a function that wraps the ogre/cegui call, or a typedef it it's a class, and alternatively implement it on our own later if needed.

Also, for the string/number conversion we might want to make a template function, rather than one function for each type.

[svenskmand]

I favor 1) since we can reuse existing code and therefore have less code to bug-fix. Regarding the speed bonus I do not really see why there should be a speed bonus by writing it ourself? (but please enlighten me )

[StefanP.MUC]

The speed bonus was only an assumption, it could be wrong. I think big general purpose libraries like Ogre and CEGUI have additional checks and stuff in their code to ensure portability, stability, safety and whatnot, but these things might not be needed by us.

An "aesthetic" argument could be: Do we always want to write "Ogre::StringConverter::toString(number)" or is "Helper:stringToInt(number)" easier to handle? (Ok, yeah, this can be easily avoided by useful #DEFINE's, typedef's and wrapper functions).

From my point of view there's currently also AngelScript. It's easier to register and maintain self-written functions (because we know where they are and how they are working, what parameters they need, what we expect from them and what functionality they need to make scripting work the way we want it, and so on).

Of course, we shouldn't implement everything by ourselves if it's already in a library. But I think simple functions ("3-liners") are easily written and maintained by ourselves.

[svenskmand]

A string to int is certainly not a 3-liner, also it is so general purpose that I find it wierd to not use a library. Even this function is alot of work to have it functioning well (handle special cases, throw corresponding exceptions etc.)

[oln]

A string to int is certainly not a 3-liner, also it is so general purpose that I find it wierd to not use a library. Even this function is alot of work to have it functioning well (handle special cases, throw corresponding exceptions etc.)

It's four lines, but yeah, I'd prefer we use library functions (ogre or boost), and wrap if needed (for angelscript etc.)

[StefanP.MUC]

Seems I'm out-voted then.

Anyways, I think we should write up a general overview on the wiki about what libraries we use for which purpose and what kind of tasks we are/were implementing ourselves (after the new website is up and the re-arranging of the web-content started). When I started coding on OD I often was (and sometimes still am ) in situations when I start to implement something and after coding some lines I noticed that there was already something alike. So, a general overview would help new devs a lot, imho.

[oln]

Agreed.

[svenskmand]

Oln: I am curious, how would you implement a string to int function in 4 lines, handling the parsing of the string, overflows of the int, exception handling if the string contains wierd garbage etc?

Stenfan and oln: I agree with the neede documentation. Maybe some UML diagrams would be usefull to give a rough overview of that is where, then the doxygen would be easier to navigate when you have a rough idea about where stuff is.

[oln]

The string to int functions are basically just convenience functions that creates a stringstream object, puts in the string and picks out an int from the stream. So most of it is handled by the standard library already.

A garbled string will return 0 using this method, and overflows are truncated. (Ogre just does this, boost seems to throw exceptions on failed casts.)