I have a question regarding ODClient.cpp and it's client -server architecture : When ServerNotificationType::startGameMode: token is passed between server and a client ? BEFORE or AFTER GameMode is initialized ? For me it seems it is before , because some of the GameMode objects ( Minimapcamera ) is not initialized at that point.

What is the proper point in ODClient to insert startTileCulling ? I need GameMode to be initialized .IS there some point where GameMode just has been initialized ?

GameMode seems to be outside agnositc , it doesn't contain any pointers to outside objects . This is called low-coupling if I remember correctly. COuld we leave that and just implement symmetrical message ServerNotificationType::gameModeStarted ; from which I would call my starttileculling ? If so could you implement that ? BTW who implemented the client -server architecture ?

Not really. It uses ODFrameListener using its singleton get method. And ODFrameListener calls everything else. Moreover, other Singletons are called in the modes (TextRenderer, RenderManager, ...).

paul424 {l Wrote}:This is called low-coupling if I remember correctly

No, low coupling is splitting a class definition and its implementation. Basically, it consists as defining an abstract class with as few implementation as possible. For an example, you can have a look at GameEntityListener and how it is used.

paul424 {l Wrote}:COuld we leave that and just implement symmetrical message ServerNotificationType::gameModeStarted ; from which I would call my starttileculling ?

No. Basically, ServerNotificationType are used by the server to notify the client of new server events. For example, ServerNotificationType::startGameMode is thrown when the seats are configured (faction, team, ...). Once it is done, the client switches to game mode and starts playing. Launching game mode is client side event so there cannot be any message from the server for that.

Note that AFAIK, there is no reason not to implement culling for the editor (correct me if you see some). If you implement culling for both editor and game modes, you can have a look at GameEditorModeBase which is the base class for common things.

Well, I'm not sure what you mean but if you say there is a noticeable glitch, no, it is not acceptable. However, if you can manage to get a list of not visible tiles, you can easily show/hide them while rendering the minimap.

http://www.dailymotion.com/video/x4di24sThe main map does not matter. This is what I get with miniMapCamera. Notice the slow time of tiles refreshing in minimap Window.It's especially strange, because when culling with gameMap window the code manages to set tiles on time .Ain't the minimap drawing with some delay than ?

Yes, there is a delay in MiniMapCamera::update. ATM, it is set to 0.5 seconds min between 2 refreshes. I guess you can somehow manage to allow a shorter refresh time when the camera moves. However, note that refreshing the minimap is one of the most CPU consuming tasks we had according to a profiler I ran so we should avoid to refresh it when not needed.

paul424 {l Wrote}:It's especially strange, because when culling with gameMap window the code manages to set tiles on time

I don't understand either. Can you hang on IRC sometimes ?After experimenting with static const Ogre::Real MIN_TIME_REFRESH_SECS = 0.05; I manage to correct the situation a little . How much glitching is acceptable ?