State of the Code

[TheAncientGoat]

He's busy with Libya stuff still, I think. Sooo, he's going to be busy for quite a while

[StefanP.MUC]

Further improvements to MusicPlayer pushed:

- added possibility of random track selection to MusicPlayer
- added possibility of starting at any track to MusicPlayer
- made sure that only one single track is played at a time

What other features do we want to have for the music?

[svenskmand]

If we want dynamic music which changes according to gameplay conditions, you could make it ready for that, so the music changes to some more intense an dramatic theme when your attacked or are attacking. Or if your sneaking up on a enemy, preparing for an ambush.

He's busy with Libya stuff still, I think. Sooo, he's going to be busy for quite a while

Ok, what exactly can he do? I assume he is not in Libya, so he cannot map stuff so what is he doing on OSM there?

[oln]

If you want to work with the sound system it would be cool if you could look into timing sounds to animations.

[StefanP.MUC]

For the dynamic music changing we only need to "start(newTrack);"
The only thing missing there is some fading effect (could maybe be done with SetAttenuation() or some selfmade volume decreasing - need to look what's the best way here).

About the sound timing:
Where should the timing values be stored? Maybe a file containing the animations + a timing information? Or hardcoded? Until now I never looked into the animation code.

[oln]

I haven't looked into it either, so I'm not sure.

[svenskmand]

I vote for a config file. Which can be edited while the game runs. It gives the smallest turnaround time when tweaking the syncing to the animations.

[eftertanke]

I use a Dvorak keyboard. It makes things tricky when I start a new game; I have to reorganize keybinds as best as I can.

[oln]

Yeah, a keyboard config system is something that's needed.

[Bodsda]

Yeah, a keyboard config system is something that's needed.

Is this not something OIS handles?

Bodsda

[oln]

Possibly, but it can't be put in a config file yet I think.

[svenskmand]

Lets put it on the roadmap for 0.4.8, should be an easy fix.

[StefanP.MUC]

Just pushed SVN and Git commits containing the GUI refactoring. It's now a singleton class containing everything that is needed by CEGUI and very easily extandable. This includes: initializing the CEGUI Renderer/System, the button handlers, the loading of the schemes, static const strings containing the window identifiers.

This also removed/merged some other files (ButtonHandler.cpp/h, MainMenu.cpp/h).

I did not just copy the old initialization code, but used CEGUIs bootstrap method (-> merging 20 lines into 1 doing exactly the same ). This automatically sets up CEGUI and linking cegui to the OGRE resource manager (this means that CEGUI path are now to be configured in resource.cfg from Ogre). The gui XML files containing references to other files now only need to know the plain filenames but no absolute nor relative paths.

Additionally, this will make it much easier to load different menus (like game menu, main menu, option menu, etc). (edit: done) <strike>I still need to add this functionality, however.</strike>

[StefanP.MUC]

I did some further clean up in the last few commits (moving some stuff around, clearing some fixmes, etc). The code gets more and more into the state of being able to accept a main menu, so this should definitly stay on the todo for 0.48.

[StefanP.MUC]

I just pushed a first step of cleaning up all the example stuff: Merging MapEditor and ExampleApplication into OpenDungeonsApplication. Looks like this could be cleaned up a lot more, however.

[svenskmand]

Nice work

[StefanP.MUC]

The code should now be ready to insert a main menu before displaying the map (I already tried displaying and switching to the ingame menu, it works fine). The .layout of the menu still needs some tweeking to look good, however.

But there's still a lot to do to get the whole program initialization into a good shape. It's good for 0.4.8, but far from beeing perfect. For example, currently the code doesn't allow us to display a menu without loading a level file first. The main menu can simply be made black and displayed on top of the test.level, for the time being. But for the future I suggest one of these:
1) displaying a custom made 3D scene in the background giving the impression of being in some "preparation room" (like e.g. DK2)
2) displaying a cut-out scene from a "real" savegame, "mainmenu.level" (like e.g. OpenTTD)
3) displaying some fancy wobly fullscreen texture (like a lot of other games)

[oln]

I would suggest the last option. Personally I dislike it when games takes ages to start and have a slow-running menu because there is a lot of fancy stuff going on in the background.

[charlie]

I would suggest the last option. Personally I dislike it when games takes ages to start and have a slow-running menu because there is a lot of fancy stuff going on in the background.

OpenTTD starts nearly instantly. If the scene is constructed carefully (i.e. only a few wisely used assets) then loading times should still be pretty snappy.

Or start with a fairly empty scene and bring units into it 1by1 to keep initial display time as low as possible.

[StefanP.MUC]

I think the current slow loading comes from loading a fully visible level with a lot of creatures already in it (I don't know a lot about 3D rendering internals, but the things p0ss mentioned about the graphical ineffiencies in the other thread could be some factor to).

I agree with oln, however, on the slow menu behaviour. Assasins Creed and DK2 directly come to my mind when it comes to menus I dislike. OpenTTD has the advantage of using 2D pixelated graphics. You can put thousands of these on the screen before noting some performance decrease.
A problem with 3D background is this: If you set your graphic setting too high (because you just don't know what to expect from the game performance), you'll end up with a slow-responding menu (and that's something really annoying).

I think with 0.4.8 we should start with a simple menu. And for 0.4.9 try some fancy picture or some coloring effect.
A 3D menu background later on could be good, no question, but it has to be decent and should be well thought out.

[svenskmand]

Very true Stefan, I also really hate the DK2 menu :S, also I remember the Shogun menu was pretty crappy too, it had a huge avi running in the background and you could actually see you hdd lamp blinking all the time the menu was running :S

[Bodsda]

How is the code in terms of threading? If we could have a very short intro that runs whilst the initial loading sequences are underway, this would solve a pet hate I have about games that take ages to load anything after you make a game selection (think loading times on a console racing game - very annoying)

Bodsda

[StefanP.MUC]

My last few commits cleaned up ExampleFrameListener:
renamed to ODFrameListener, made it a singleton (-> out of global scope), removed unused Joystick stuff, namespace cleaning, some optimizations here and there

The code slowly gets readable and understandable.

[StefanP.MUC]

Added a new singleton class: ResourceManager
it handles the whole path initialization (did some optimization to it, too) and provides easy access to the pathes (with clearly named getter methods).

The ODApplication.cpp now doesn't has much left from what shouldn't be there (maybe all the createViewport/Scene/etc stuff could be put in a better place, like RenderManager or something, as the Application basically only should initialize all needed helper singletons and set overall settings).

[oln]

Looks like you forgot to commit the ResourceManager class.