Hi again,

Over the past few months I've tried re-writing my program, several times in fact. Each time I run into a similar problem with scopes and modules that aren't able to interact. In my latest attempt, I made player into a class. I'm also using a graphics module to keep the ugly parts out of my main file. The problem is accessing the graphics class located in graphics.h/graphics.cpp - When I render my objects I'm in a for loop which seems to only access Tile but not Graphics.

Example:

for (Tile& it : tileList) {


it.square.x = it.x;


it.square.y = it.y;


g.draw(g.wallgfx, g.Backbuffer, it.square); // square is an SDL Rect object for drawing on


};


g.draw(g.wallgfx, g.Backbuffer, &singleObjectName.square);

Of course it's not going to work. When I'm in the for loop I can't call the "g for graphics" object. The stand-alone line at the bottom works fine but I'm not going to make a specific object with its own name, for every detail in the game world! I could move the draw() function into tile.h or thing.h which Tile is derived from, but then (staying strictly with the engine concept) I have to call the backbuffer from graphics.h which is included in main.cpp but not available in tile.h

I know that I cannot #include graphics.h into both main.cpp and tile.h - I tried that a month or two ago!

This is disappointing because I spent a lot of time reading text books and tutorials, plus I asked many questions here. I'm 26 and I still don't understand how to 'modularise' a program in c++. I read Jazon Yamamoto's book but I haven't been able to replicate any of his complex code for my own use - his example code is a properly-written engine but it's too abstract for me to grasp. I could go back to including everything into my main file but that's exactly what I want to avoid. If PY-SDL2 is any good, then I might give that a try.

edit: added tags to post. Also note my use of QUOTE not CODE which allows for traffic light indication of good vs. bad code :)

Would this help?

https://en.wikipedia.org/wiki/Pragma_once

https://en.wikipedia.org/wiki/Include_guard

Would this help?

https://en.wikipedia.org/wiki/Pragma_once

https://en.wikipedia.org/wiki/Include_guard

I'm happy to keep tapping the F9 key, and editing code, and pressing F9 again to run-and-compile. Including things once is what I'm already doing, the problem is getting the modules structured so that they work without causing me problems.

I'm not sure I'm understanding your issue correctly, but it sounds like the Singleton pattern would be a simple solution to your problem.

You are absolutely be allowed to include a header in both your main.cpp and another header file, though be wary of including in header files due to circular dependencies (two header files cannot include each other). You're not allowed to because of said circular dependencies. You can avoid them by forward declaring classes instead of including them when you don't need to access any members and only need the definition of the type, and by limiting your #includes to .cpp files as much as possible.

I think that explains it: have a master class which allows any derived class to be accessed from anywhere in the program.

In my programs I have only ever included .h files, never .cpp ... so this sounds like an esoteric concept to me. I'll look into it.

In my programs I have only ever included .h files, never .cpp

Include the .h files, but include them in .cpp files when possible.

Forward declare when possible, include when you must. Look up forward declaring if you're not familiar with it.

Your master class sounds like a bad idea. It sounds effectively like a global, which is generally considered a code smell. If everything can access and talk to everything else from anywhere, tracking code flow becomes a huge issue as the project grows.

I found some resources which appear to show exactly what I was after:

http://gameprogrammingpatterns.com/design-patterns-revisited.html

Above: singleton pattern explained in the context of games; and finally ...

... http://www.gamefromscratch.com/page/Game-From-Scratch-CPP-Edition-Part-5.aspx

Above, using GameObjectManager to manage objects by avoiding a for ranged loop, instead using while ... from within the GameObjectManager member function.

void GameObjectManager::DrawAll(sf::RenderWindow& renderWindow)

{

std::map<std::string,VisibleGameObject*>::const_iterator itr = _gameObjects.begin();

while(itr != _gameObjects.end())

{

itr->second->Draw(renderWindow);

itr++;

}

}

Could you give more details what problem gets solved by the 'while' ? (or even why the problem with the 'ranged loop' doesn't happen with 'while').

I've likely got the wrong idea in my head - I thought that scopes were handled differently (while versus for). A for-loop has its own scope/namespace, like a virtual container within the program, the same thing with functions. I thought while loops were different, because I can declare something immediately prior to the while loop, and access that data from within the while loop without needing to pass a value or reference.