FreeGameDev

I try to refactor InputManager into smaller input modes.
Any critical remarks about it should go in here .
Changes are done to branch development currently .
As discussed in diffrent thread and pictured above, I follow this idea, but *Modes does not inherit from ODFrameListener , instead there is abstract class AbstractApplicationModes:

Shouldn't the Gui.cpp singleton be removed and split , for each input Mode type ? Surely we don't need acess to buttons which aren't on screen anyway ...

Yeah I think it that should reside somewhere inside the modes, not sure what the best way of organising it would be though.

After spliting the Editor and Game and removing the exclusive parts not belonging to each of them , EditorMode.cpp is still quite large bulb of code ( and ugly ) : -+1000 LOC .
What I think , someone (probably the original inventor) look over the code and abstract the most common task , encapsulate them into functions, which in turn could be put into some potential new superclass of EditorMode and GameMode.

SO far there ar Console*, Game*, Editor* and PauseMode. I left the Console class as it is , only stripped and moved the methods which match interface of AbstractApplicationMode.
ConsoleMode use pointer to get access to Console. This is because AAM family should not contain any Application mechanic, only handle input interfaces declared in AAM. On the other hand there is no other point or use of the Console so far than through C*Mode.

PauseMode would be good , but it would require to have some access to game clocks mechanics ........... Do we want to have such Mode ?
Also , oln I see you wanted the whole application to have states similar of AbstractApplicationMode. Now I see the nomenclature is misleading , and the new family should be named
AbstratInputMode, second I think the main program or ODapplication control should be more sophisticated , at least having several modes is too poor....

Since the console object is only used inside consoleMode, it might as well reside in consoleMode rather than being a singleton.

Yeah, I think pausing could be implemented as a mode. I think pausing currently will require pausing/stopping the server thread as well as altering the inputs. I think it would be best to first make sure we have separated the map loading and gameplay stuff so it doesn't start automatically on the application start first.

My idea was that the modes would be classes managing the objects that were unique to the current mode. Then modes could optionally have an object that does the actual input handling, which would be a different class depending on the mode. Though the way it's done now might be a better approach. The name would depend on whether the mode objects should contain other objects that are unique to the mode, e.g GameMap. Or is there another approach here that is better?

{l Code}: {l Select All Code}

second I think the main program or ODapplication control should be more sophisticated , at least having several modes is too poor....


I'm not quite sure what you mean by this, what do you propose we do here?

NOTE: I will be away until Sunday evening, I can't reply more until then.