FreeGameDev

StefanP.MUC {l Wrote}:In Germany we have QWERTZU.

But to solve his problem, this maybe should be coupled to the multilang support. So that translators have the possibility to add keyboard default settings to their language. Or by some auto-detection of the keyboard layout.

Yes that would be the best way to go.

My opinion is that controls should be 100% configurable. The fact that some people prefer different configurations means it makes perfect sense to have controls configured in a config file, rather than hard coded. Things like scroll wheel should be voted on but should be easily configurable, things like keyboard controls should be selected automatically to begin with based on keyboard layout configuration.

It should be trivial to make the change from hard coded values to config file loaded values.

Bodsda

Bodsda@ agreed.

I just bumped the master branch up to where the 0.4.7 release is as suggested by MCMic. Gonna try to keep the master branch at the latest "stable" version from now on.

This sounds good. I wondered this often: what purpose had the master branch up until now and why is it the default branch (on my first setps with git and OD, I first made the mistake to not switch to the dev branch and wondered where all the new stuff is )?

Pushed a commit with a lot of cleanup to the cmake scripts. (Didn't test it on windows yet, but should work)
Please tell if there are issues with it.

I have so far made it clearer , reorganised and commented it.
I still have to make it copy the needed files to the build directory for out of source builds, fix tabs, and a few other things before I'm done with it.
The plan after that is to start cleaning up the source code.

Also, ill make a tag on svn tomorrow for the 0.4.7 release, to make it easy to get the right media files for the release.

oln {l Wrote}:Also, ill make a tag on svn tomorrow for the 0.4.7 release, to make it easy to get the right media files for the release.

Good idea

On Linux, the FindBoost.cmake doesn't work anymore. Can't build the game.

Fixed in latest git.

Did you push it already? It's still the old one that doesn't work.

Apparently not, I have now though.

Cool, thanks. Now it works.

I'm currently going through the code and optimize some for-loops. This means:
- replacing i++ by ++i (the ++i is better in for loops because it doesn't need an internal temp variable to store the old value - this gives some milliseconds)
- remove function calls out of the check condition, where possible (possible where its constant over the runtime of the for loop)

{l Code}: {l Select All Code}

for(int i = 0; i < object.func(); ++i)
//replace with:
int n = object.func();
for(int i = 0; i < n; ++i)


In first case object.func() would be called n times. In second case only one tim without changing the purpose of the for loop.

After I'm done I'll test it and then push it.

Pushed a commit changing the level folder on git to levels_git, and changed the code to first look in this folder for the default level.
This is to prevent any collisions with svn.
My next task will be fixing out of source builds to make building less ugly, and less prone to git/svn collisions.

Pushed another small commit doing the needed changes for out of source builds. (Have to test that this works on windows as well)
This means that one can make a directory, e.g "build", cd into it, and do cmake path/to/source, and the project will be build in the build folder.
Will update the wiki to recommend this approach once I have done a few more changes.

Pushed a commit adding the claim and build sounds to the game. Also did some const correctness fixes.

oln {l Wrote}:Pushed a commit adding the claim and build sounds to the game. Also did some const correctness fixes.

Nice I will look forward to checking that out

It seems (from what Stefan says) that the code generally needs refactoring. Maybe that should be our goal in the next release?

Yes, the code definetly needs refactoring. Working on it will also make it easier for me and stefan to get a better overview of the codebase.
And I agree that should be the main goal for the next release.
(As well as getting the new models and sounds into the game)

Just pushed a commit:
- add basic main menu code files (mostly empty)
- remove forceLowercase(), use std::transform() instead
- remove some unused includes
- some comment fixes

Pushed a commit that moves most of the render request handling to a separate class.
There are still a few things that has to be moved into the class, but the main thing(render queue processing) is now out of exampleframelistener. Seemed to work fine when I tested it.

Yeah, works fine. Nice work.
Could be wrong, but it looks like this also fixed some bugs or at least made the game feel more "responsive" (especially when building rooms and picking/dropping creatures).

By the way, RenderManager.cpp, line 285, I changed this a little. The if(empty) calling "break;" in a while(true) is the same as while(!empty). The missing code requested by the FIXME note can then be added after the while loop instead of in the if statement in the while. I think this looks a bit cleaner and removes one unneeded check and a NULL initialisation.

and in line 279 and 280:
I removed the "break;" in front of the "return false;" Breaking exists the switch causing the "return false;" to be never exectuted and always to "return true;" outside the switch.

StefanP.MUC {l Wrote}:Yeah, works fine. Nice work.
Could be wrong, but it looks like this also fixed some bugs or at least made the game feel more "responsive" (especially when building rooms and picking/dropping creatures).

That's nice, didn't expect that. I did do a few fixes and tweaks in the functions, so it could have affected some things.

I am also going to move the render queue push function into the same class (and a few variables from exampleframelistener), which means we can move some variables out of the global scope.

Regarding the if queue is empty stuff, the reason for the check being in an if-statement rather than being in the while statement is that the queue semaphore is not locked when the empty() check in the while loop is performed. Though, it could possibly be solved by locking the queue at the end of the while loop instead, (and lock once before starting the loop).

Just pushed some cleaning up of the MusicPlayer:
- merged start() and startCurrent() (all start() was doing was calling startCurrent())
- implemented the already declared next() -> moving two duplicated codes into this function
- deleted all old commented out OgreSound stuff
- upgraded the TODO comment about update() being called on every frame (SFML 2.0 will provide a good way of achieving this)

I'll also add some kind of load random track feature later.

Nice work
Now we just need some actual music

I pushed a change moving more stuff to renderManager earlier today. (And a few other minor fixes)
That class is now mostly done, so I think I will have another look at normal mapping again next.

Nice work guys I really look forward to get normal mapping working

Andrew are you too busy with real-life or what are you doing currently? We MISS YOU

PS: Not to force you to work on OD if you do not have time, but it is nice to hear from you once in a while