IMGUI and MVC

I wouldn't agree that IMGUI is about state management...

I assume that what you basically want to do is at some point:

if(doButton())
{
//change some state in model
}

If you are using IEventTarget then that is what you need to call to change the state in Model. Even if the IEventTarget reference you are using is the Model you still don't conceptually know that / see that from the calling code:

Controller::doInput(IEventTarget& aTarget, const Model& aModel);

This is of course assuming that you don't already have a const & to the Model via View, as in my earlier examples.

The whole split of input() and output() in Controller(s) is basically my (johno's) style, and I personally do IMGUI stuff in Controller::doInput(IEventTarget& anET).

This means that each doButton() call does hit-testing and mouse button checks within that call and returns the results directly. doButton() also stores whatever rects, lines, bitmaps, and text required to render said button at a later time (that is, in doOutput()).

In Controller::doOutput() I do drawing, and then at the end of that method the IMGUI draws all cached rects, lines, bitmaps, texts, etc. This cache lives for "half a frame" so to speak.

Now for the beginner this is obviously more complicated than it needs to be, so let's look at what (I think) hObbE does.

Instead of your main loop being:

controller.input();
model.update();
controller.output();

you can do:

model.update();
controller.update();

In the latter case, you can do all input and output together while rendering your scene. This means that your typical doButton() can do immediate hit-testing and button checks and also directly render whatever it needs to to D3D or whatever your doing.

So I'm guessing that the interface would be something like:

bool IMGUI::doButton(int x, int y, int width, int height, const char* text, IDirect3DDevice9* aDevice);

This implies that doButton() is also a rendering / drawing operation.

I can't really motivate "my style" (input separate from output) other than it being legacy. I can argue that there is no real point in doing user input before a logic tick or especially a rendered frame, since the user would be hard pressed to interact with a gui that is yet to be rendered...

I think that at some point I did the cache of "gui primitives" in order to be able to compose my rendering exactly as I wanted, but since everything I do is immediate mode anyway, there is no "scene graph", and I have complete control of where the gui stuff gets drawn anyhow.

So one could do something like this:

void Controller::update(IEventTarget& aTarget, IDirect3DDevice9* aDevice)
{
//draw all 3d stuff
draw(aDevice);

//do and draw all imgui interactions
if(gui.doButton(aDevice))
{
aTarget.changeSomething();
}
}

The big win is that there is no temporary cache inside your gui code at all, you are just rendering straight to the underlying API.

(Come to think of it, there are probably gains to be had by doing a certain amount of batching; drawing all rectangles for buttons first, and then all texts later, depending on your underlying API.)

Again, I've been assuming that this is the gist of what hObbE does (I know that the hUb IMGUI code works this way), but hObbE please confirm.

/johno
"you can't stop the change"

I thought I'd mention that I plan on doing a simple reference game and post full source on my website in order to exemplify this whole discussion about MVC and IMGUI.

Blakhouse came up with the idea of doing Pong, which I thought was a good idea as it is as simple as can be, so it will be something along those lines.

I'm thinking of using GDI+ for the rendering and one of Windows' simple sound-playing functions for sound.

Right now I'm in between machines (writing this in Safe Mode) but as soon as I'm up and running again I'll get to work on this.

/johno
"you can't stop the change"

sounds great that id handling isn't needed. i'll just remove it for now. I thought it would be more useful since that tutorial used it.

sounds great with a pong game. i don't understand why you'd prefer to do it in GDI rather than d3d or opengl though

---------------
Solid Core Entertainment
Developer of Roadclub and Sense: Survival Prelude (Developer blog)

Ah i see. I don't think i understood that the const model was only useful due to preparation of a remote proxy before. I think i'd rather learn to keep that way though to see if it gets in the way of a local game or not. If not i could as well code that way to have experience needed for networked games later.

Interesting about the view. that would be ideal for tutorial purposes as anyone could just take a game source and implement whatever visualization they wanted for it.

Also interesting to hear that the controller was so different you had to have completely different controllers rather than sharing them. I guess the controllers are so close to the view that its natural.

---------------
Solid Core Entertainment
Developer of Roadclub and Sense: Survival Prelude (Developer blog)

Reading this back again I think one thing needs to be made very clear. You wrote:

"well what i meant was of course that imgui is tightly coupled with state since user interactions probably leads to some kind of change in state."

I would say that the Controller and View are both tightly coupled to / dependent upon Model since they both read the contents of Model. Controller also of course writes changes to Model either directly or via the IEventTarget abstraction.

However, one of the main points of IMGUI is that you DON'T move state from your application into your "imgui context" to be STORED (which would be the retained mode thing to do).

To be fair, neither IMGUI or RMGUI can be said to deal with any kind of application specific data, rather they work with ints and floats and strings and things like that.

The main thing I want to stress is that while Controller and View are directly dependent upon your domain Model, your IMGUI can still be a "library", i.e. not specifically tied to your specific Model.

An example, as verbose as I can make it:

void Controller::doInput(IEventTarget& aTarget)
{
if(myView.myGui.doRadioButton(myView.myModel.myState == STATE_MENU))
{
aTarget.setState(STATE_MENU);
}

if(myView.myGui.doRadioButton(myView.myModel.myState == STATE_GAME))
{
aTarget.setState(STATE_GAME);
}
}

This is meant to show that there are two radio buttons with which you can select the current "state of the application".

The "gui context" as being part of the View. Each call to doRadioButton() requires that you explicitly pass state (whether or not the button is depressed) in order for it to display correctly. If the button was clicked on, the gui returns true and the Controller can change the state it wants to.

The main point here is that Controller is basically translating domain specific state (stuff from the Model) into the generic state (a boolean) that the IMGUI is using to draw a radio button. This is one of Controller's very important jobs.

In this manner you can have a more or less generic imgui library (based on some rendering API) that you can reuse between projects.

Another stab at this would be:

void Controller::doInput(IEventTarget& aTarget)
{
if(myView.doStateRadioButton(STATE_MENU))
{
aTarget.setState(STATE_MENU);
}

if(myView.doStateRadioButton(STATE_GAME))
{
aTarget.setState(STATE_GAME);
}
}

In this case I have conceptually mashed together the View and the IMGUI context, intending that there is no dilineation between the View and the gui. Thereby I can have a more high-level and domain-specific interface for the gui / widget calls, in that View knows about the Model and knows what a "state radio button" is and what state it needs to look at (Model::myState) in order to draw the button in the correct way.

Neither way is really wrong or right, it depends more on the level of reuse you're aiming at. The important thing is still that Model is unaware of any of this stuff, and that any implementation of a gui should render based on the actual state of the Model, whether it is being "translated" as in the first example, or "looked up directly" as in the second.

/johno
"you can't stop the change"

I regret my poor choice of words here. I had no intention of placing state in the imgui. i meant that interactions usually at some point end up changing data. at this point you're preaching to the choir as i would place data in either the model or controller/view depending on the razor you mention still, always nice with all the extra info. thanks guys!

---------------
Solid Core Entertainment
Developer of Roadclub and Sense: Survival Prelude (Developer blog)

hi

Well I do not store any state at all in my imgui classes, in fact my imgui functions are all static to prevent me from that

And my implementation does not completely divide the view from the controller...

some code to explain it

void controller::EditorController::DoEditorguiInput(const model::Model &a_model, IEventTarget &a_target) {
if(IMGui::DoButton(0,0, "Save", a_model.HasBeenChanged() == true) == IMgui::LeftMouseButtonClicked) {
a_target.DoSaveLevel()
}
}


so the dobutton above does render the button and all state variables must be sent to it...


IMGui::MouseFeedback DoButton(int a_x, int a_y, String a_text, bool a_isEnabled) {
//check if mouse is on text and if any buttons are pressed
//draw button
//return feedback depending on mouse state...
}


ok you use the provided facilities for the graphics api then, not caching in your own classes so to speak. I actually went ahead and created new stored copies of all objects to be drawn later but there are a lot of copying and new-delete-ing in there so i'll probably change it to use opengl display lists later and a similar structure for text like you mentioned.

---------------
Solid Core Entertainment
Developer of Roadclub and Sense: Survival Prelude (Developer blog)