Back to General and Gameplay Programming

How should important data be passed around a program?

AldenB · 2017-05-20T19:58:38

In my particular case I have a "________App" class which is basically a wrapper for all the logic in the program. This is the class which calls the run(), update(), draw(), etc, functions. I'm also using a StateMachine class which is used to handle the different "states" of the program (e.g. the "main" state or the "pause" state). The update() and draw() methods are really just wrapper functions for the state machine's update() and draw(). It look a little bit like this... class MyApp { private: //... Graphics gfx; StateMachine<MyApp> state_machine; //... public: //... void update() {state_machine.draw();} void draw() {state_machine.draw();} //... } However, in order for my state_machine to properly update() and draw(), it needs access to some of MyApp's private members, such as gfx. What I'm really looking for here is a way that the StateMachine can modify the members of the MyApp class that owns it. Making the StateMachine a friend class is tempting, although I believe that it's a poor design decision. Can someone give me some advice or point me in a direction where I could read up on this? Here's a look at my actual code: //Sol::Application is the class I made which implements run() as well as other lower level operations. class LogicGatesApp : public Sol::Application { public: using WireGraph = SparseGraph<GraphNode, Wire>; private: StateMachine<LogicGatesApp> m_state_machine; //This is the graphical component of the grid that the user will //be interacting with Grid m_grid; //this is used to represent the wire circuitry logic of the program. //each cell in the grid corresponds to a node in the wire graph. //see the file description at the top for a visual. WireGraph m_wire_graph; public: LogicGatesApp(); void update(); void draw(); //... }; In this case, the StateMachine needs to be able to access and modify Grid and WireGraph. Particularly, in one of the states, it needs to highlight the block in the grid that the mouse is hovering over (hence the need to modify the Graphics object, and access to the Mouse object both found in Sol::Application)

General and Gameplay Programming Programming

Started by AldenB May 19, 2017 07:18 PM

10 comments, last by Khatharr 6 years, 11 months ago

AldenB

107

Author

May 19, 2017 09:55 PM

The idea of the state stack - if you're not familiar - is that the state base class contains a pointer to a state, which is nullptr by default. If the pointer is null then nothing special happens. Otherwise the state logic and drawing delegate to the sub-state indicated there.

I'm familiar with the state stack. However, I'm not using it for my StateMachine in this program. Although this state stack is a little different then what I'm used to. Are you saying that a State would look something like this?


template <typename T>
class State
{
private:
    State<T>* sub_state;

public:
    State() : sub_state{nullptr} {}
    State(State<T>* sub) : sub_state{sub} {}

    void update()=0;
    //...
}

Khatharr

8,814

May 20, 2017 07:58 PM

Just a linked list, really. (And please use std::unique_ptr.) The simplest form would be to only process the state at the "tail" of the list, but the structure - as mentioned - allows for elective processing/drawing of the enclosing states.

I'm not sure why you'd have a constructor that takes an existing state object and assigns it to the sub-state.

Why is your state class templated?

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

How should important data be passed around a program?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

How should important data be passed around a program?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines