Integrating Box2D with an existing game class structure in SDL? - c++

Sorry for the rather vague title, but it seemed befitting of a similarly vague question, though hopefully succinct enough that somebody will be able to answer it. I have spent a decent amount of time working on the framework for a 2D side-scrolling game in SDL, and now that I am comfortable with the library and have a working prototype, I'm looking to integrate the Box2D physics library into my game. Now, I didn't just dive in head first and actually took the time to compile the library on my system (obviously), study the Testbed application, create a few of my own to get the hang of it all. And yet, I'm still unable to figure out how exactly to integrate it into my existing game structure. Below is a sample of my source for the game "engine," if I may be so bold:
CMain.cpp
// Constructor. Initialize the screen display surface and
// let the application know that we are running.
CMain::CMain(){
displaySurface = NULL;
isRunning = true;
}
// Init function, hooks SDL libraries, configures the display
// surface, window and all pre-runtime environment parts.
int CMain::OnExecute(){
if(OnInit() == false){
return -1;
}
// Event checking, game loop and render loop.
SDL_Event Event;
while(isRunning){
while(SDL_PollEvent(&Event)){
OnEvent(&Event);
}
OnLoop();
OnRender();
}
// Cleanup, called when the application is no longer running,
// handles the removal of all loaded resources from memory.
OnCleanup();
return 0;
}
int main(int argc, char* argv[]){
CMain digIt;
return digIt.OnExecute();
}
As you can see this takes care of the crucial game loop functions. I didn't think the full code of the various helper functions was necessary for the context of the question, but if it would be helpful just say so and I'd be glad to post it. So, my question is this:
Being familiar with the structure of the Box2D world and how it is initialized, stepped and everything, how do I now integrate that into this existing game structure? Do I want my entire CMain class to inherit from b2World? (i.e. class CMain : b2World{}) is there some other way to create the world so that it is globally accessible without committing a cardinal sin of good coding practice? For instance, I tried to declare a b2World* pointer in the CMain header and then pass that around to the subsequent functions to do with it what they had to do but that lead to a great many null pointer exceptions. Any advice you could give, or sample code if at all possible, will be incredibly appreciated!

I would not suggest that your CMain class derives from the b2world, since it definitely is not a is-a relation but rather a has-a. I cannot tell if it is the perfect solution, since I do not know your overall architecture, but it seems like a good place fot the Singleton pattern.
I suggest that you create a class implementing the singleton pattern which holds the central instance of b2World, like CPhysicsService. The instance is taked with stepping the world and for creation of new bodies. Because of the singleton, the instance of the class can be retrieved anywhere you need it.
I also had this issue while making an extension for the Gamebryo engine. But the engine was heavily built on services anyway, so the creation of a Box2D service was the obvious way to go.
I hope this was somehow useful.

Related

Platformer game - Avoid collision with platform when getting down

I'm using BulletPhysics in C++.
I would like to know if there is a way to avoid collision for an object when I want?
I'm trying to create a platformer and I want my character to be able to pass through a platform (by holding down the down button). I've thought about using ray cast to manage its position but it doesn't seems for me to be a good way; it would be better if I could access the physics response and choose whether or not to apply it to my object, but I don't know if this is possible.
(If you have a solution without code it's ok for me, I'm just making some research, I haven't started development).
Thank you in advance.
I found a solution to my problem.
To be able to cross a platform (by holding down the down button), you have to know if the character is on a platform. To do this, you have to put a box (which listens to all object that collide with it) and if it collides with a platform, get a pointer of the platform and call the method void setIgnoreCollisionCheck btCollisionObject * co, bool ignoreCollisionCheck) on the character's btCollisionObject.

Communication between objects (in C++)

I am currently coding my biggest C++ program, using multiple objects to manage a windows (using Windows API functions), a 3D engine (DirectX), and other objects all having to work together to accomplish their task.
I have some problems to organize my objects so they can interact with each other intelligently.
When an object has to perform operations, or worse, pass parameters to another object, I struggle to define the best solution to harmonise and organize my code.
Here is an excellent example:
As I said, in my program I have 2 objects: (1) "windowManager" which handles all the operations related to the window itself, and (2) "rendererManager" which handles all my DirectX operations, from the initialisation to the rendering of every frame.
When the window get resized, DirectX has to be reset to adjust the drawing area, otherwise the image gets stretched, so "windowManager" has to be able to order "rendererManager" to reset.
I could not think of a better solution than to create a "rendererManager.Reset()" method, then 2 methods for the window manager "windowManager.GetRequestRendererReset()" and "windowManager.SetRequestRendererReset(bool reset)"
When my window get resized, the object "windowManager" calls its own method "windowManager.SetRequestRendererReset(true)" to change one of his arguments that can be queried from a "get method".
With this, in my main cycle (in the infinite loop in the main) I applied some verification such as:
if (windowManager.GetRequestRendererReset()) { // The window has been resized, we need to reset DirectX
rendererManager.Reset(windowManager.GetWindow());
windowManager.SetRequestRendererReset(false);
}
This feels very sub-optimal and I feel that there is a better solution.
In addition to this, I now need to send more complex information to my object "rendererManager", such as text to write in the image at specific location, and without an intelligent organization my whole code might become swampy.
Is there some guidelines on how to optimise interactions and communications between objects?
Do you have a good lesson/tutorial about this, or do you have examples of good practices?

Switching between various screens of the same state type?

I've been having an issue with the basic structure of a program that I'm working on. I'm a very inexperienced programmer trying to teach myself the basics of programs that use multiple states.
Right now, I have a very simple game-ish program with a game loop that redirects event, logic, and rendering to my StateManager class, which pushes and pops states onto a . The StateManager class then redirects the events, logic, and rendering to whatever state is on the back() of the vector. The idea is to have an assortment of different states for each phase of the program (in this case a simple game with splash screens, menus, gameplay, death screens, etc)...
However, I'm a VERY novice coder (trying my best to learn), and I've run into a fundamental issue with my program right from the very first state class...
The first class that I made is the SplashScreenState. And the basic concept was to have a state that essentially just shows a series of 'splash screen images' (lets say 3, for the sake of example), and each time the user presses a key, it switches to the next image, and finally (when it is out of splash screen images to cycle through) switches to the next state (menustate).
My problem is that I'm having a hard time figuring out how to structure this. Originally, I made the mistake of treating each different splash screen image as an instance of the SplashScreenState. However, I figured that do so was incorrect, as all 3 splash screens would technically be part of the same 'state'.
So now I have two main issues:
The first issue is that I'm not sure how/where to store all the splashscreen images. If I want to cycle between 3 different screen images when the program starts up, should I make them all members of the SplashScreenState class? Or is it smarter to simply have one class member for the 'currentImage', and each time the user hits a key it runs a load() function to load the next image into the currentImage pointer? Is it better to make an array or vector of images and cycle through them? I'm just not sure...
My second issue is with the eventhandling() of the SplashScreenState.. I know that I want the image on the screen to change like; *image1 -> image 2 -> image 3 -> changeState(menuState).. So that each time the user hits a key on their keyboard, it switches to the next splash screen, until the last splash screen, where it will then change state to the main menu. I'm not sure what the best way of doing this is either.. Should I create an enum for each splash screen and increment through them (until the final screen where it changes states)? I also think that, if I did store all my various screens in an array, then I could easily increment through them, but then would that be unoptimized because all the screens would have to be stored in memory at all times?
Anyway, I'm know this question might be very basic and noobish, but that's where I am right now unfortunately! I haven't had any formal education in programming and I've been teaching myself, so I really really appreciate all the help and expertise that's present on this site! ^^
Thanks!
You seem to be torn between an object-oriented vs a procedural paradigm for handling state transitions. The other answer suggesting a switch statement to handle enumerated state changes is a good procedural way to go about it. The drawbacks to that are that you might end up with a monolithic game class that contains all the code and all the superfluous state-specific data for handling your event/logic/rendering for all possible states. The object-oriented way to handle this is much cleaner, and encapsulates these into their own separate state objects where they can be used polymorphically through a shared interface. Then, instead of holding all the details for handling all the states in your game class, your game class needs only to store a state pointer and not worry about the implementation details of the concrete state object. This moves the responsibility of handling state transitions out of the game class and into the state class where it belongs. You should read up on the state/strategy pattern from a design patterns book. Handling the changing of a state should be the responsibility of the state object itself. Here is some reading:
http://www.codeproject.com/Articles/14325/Understanding-State-Pattern-in-C
http://sourcemaking.com/design_patterns/state
http://sourcemaking.com/design_patterns/state/cpp/1
http://codewrangler.home.comcast.net/~codewrangler/tech_info/patterns_code.html#State
http://en.wikipedia.org/wiki/State_pattern
http://www.codeproject.com/Articles/38962/State-Design-Pattern
Quoting from the Design Patterns and Pattern-Oriented Software Architecture books:
The pattern-based approach uses code instead of data structures to specify state transitions, but does a good job of accommodating state transition actions. The state pattern doesn't specify where the state transitions must be defined. It can be done in the context object, or in each individual derived state class. It is generally more flexible and appropriate to let the state subclasses specify their successor state and when to make the transition.
You have the option of creating state objects ahead of time and never destroying them, which can be good when state changes occur rapidly and you want to avoid destroying states that might be needed again shortly. On the other hand, it can be inconvenient because the context must keep references to all states that might be entered.
When the states that will be entered are not known at run-time and contexts change state infrequently, it is preferable to create state objects as needed and destroy them thereafter. In determining which to use, you need to consider cost as well as transition frequency.
Excellent explanation of your problem, first of all.
The portion of your game managing the splash screen can work in two ways. You've examined the problem and it's really that simple:
Receive input; set next state.
So, examples:
STATE_SPLASH1
STATE_SPLASH2
STATE_SPLASH3
STATE_TITLE
STATE_GAME_INIT
STATE_GAME
STATE_EXIT
pseudocode:
state = STATE_SPLASH1
while (state != STATE_EXIT)
... receive input ...
... process events to responders ...
... update ...
... yadda yadda ...
switch (state) {
case STATE_SPLASH1:
show_splash1()
case STATE_SPLASH2:
show_splash2()
case ..:
case STATE_TITLE:
show_title()
case STATE_GAME_INIT:
show_loading()
setup_level()
setup_characters()
case STATE_GAME:
game_update()
case STATE_EXIT:
cleanup_and_quit()
Another way is to manage splash a 'game state' and then the state of the splash as an internal state. and when splash has no more logic to run, set the game state to the next one. When I was learning, I found the DOOM source to be a valuable resource and man, is it nothing but hundreds of state machines. :)

Multiple Qt widgets depicting different OpenSceneGraph nodes without performance loss

We are currently facing the following problem: We have an application that needs to display a multitude of separate OpenSceneGraph scenes in different Qt widgets. For example, we might have one Qt widget depicting a sphere, while another widget depicts an icosahedron. Since we are using OpenSceneGraph 3.0.1, we followed the osgViewerQt example from the official documentation for implementing this.
The example code uses a QTimer in order to force updates for the viewer widget:
connect( &_timer, SIGNAL(timeout()), this, SLOT(update()) );
_timer.start( 10 );
The problems now begin when we want to create and show multiple widgets. Since each widget comes with its own timer, performance rapidly decreases with the number of open widgets. Not only is the interaction with the OSG widgets very slow, also the interaction with other Qt widgets noticeably lags. Even a halfway recent quad-core system is almost overwhelmed when approximately 5 windows are open. This issue is definitely not related to our graphics hardware. Other applications may render much larger scenes (Blender, Meshlab etc.) without any negative performance impact.
So, to summarize: What would be the best way of creating multiple Qt widgets showing different OpenSceneGraph scenes without a performance impact?
What we already tried:
We already considered using a single osgViewer::CompositeViewer for
rendering all scene objects. However, we discarded this idea for
now because it will probably make interactions with a single widget
very complicated.
We tried putting the rendering portion of each osgViewer::CompositeViewer in a separate thread as detailed by the osgQtWidgets example.
Our second try (using threads) looked roughly like this:
class ViewerFrameThread : public OpenThreads::Thread
{
public:
ViewerFrameThread(osgViewer::ViewerBase* viewerBase):
_viewerBase(viewerBase) {}
~ViewerFrameThread()
{
cancel();
while(isRunning())
{
OpenThreads::Thread::YieldCurrentThread();
}
}
int cancel()
{
_viewerBase->setDone(true);
return 0;
}
void run()
{
int result = _viewerBase->run();
}
osg::ref_ptr<osgViewer::ViewerBase> _viewerBase;
};
However, this also resulted in a remarkable performance decrease. Each thread still requires much CPU time (which is not surprising as the basic interaction is still handled with a timer). The only advantage of this approach is that at least interaction with other Qt widgets remain possible.
The ideal solution for us would be a widget that only fires redraw requests whenever the user interacts with it, for example by clicking, double-clicking, scrolling etc. More precisely, this widget should remain idle until there is a need for an update. Is something akin to this possible at all? We would welcome any suggestions.
Having tried out several models for this problem, I am happy to report that I found one that is working perfectly. I am using a QThread (similar to the thread described above) that essentially wraps an osgViewer::ViewerBase object and simply calls viewer->run().
The trick to keep CPU usage low is to force OpenSceneGraph to render on demand only. Having tried out the various options, I found the following two settings to work best:
viewer->setRunFrameScheme( osgViewer::ViewerBase::ON_DEMAND );
viewer->setThreadingModel( osgViewer::ViewerBase::CullDrawThreadPerContext );
A viewer that is modified like this will not use spurious CPU cycles for continuous updates while still using multiple threads for culling and drawing. Other threading models might of course perform better in some cases, but for me, this was sufficient.
If any one else attempts a similar solution, be warned that some operations now require explicit redraw requests. For example, when handling interactions with OSG objects or when you are writing your own CameraManipulator class, it doesn't hurt to call viewer->requestRedraw() after changing viewer settings. Else, the viewer will only refresh when the widget requires a repaint.
In short, here's what I learned:
Don't use timers for rendering
Don't give up on multiple threads just yet
Nothing beats reading the source code (the official OSG examples were sometimes scarce on details, but the source never lies...)
It should be possible. I can't believe they used a timer running at 100Hz to update the widgets -- it's really not the right way to do it.
I don't know about OSG's architecture, but you need to figure a way to obtain a callback from OSG when the data has been changed. In the callback, you simply queue an update event to the appropriate widget like so:
void OSGCallbackForWidgetA()
{
QCoreApplication::postEvent(widgetA, new QEvent(QEvent::UpdateRequest),
Qt::LowEventPriority);
}
This callback code is thread safe and you can invoke it in any thread, whether it has been started by QThread or not. The event will be compressed, that means that it acts like a flag. Posting it sets the flag, and the flag will be reset when the widget finishes with the update. Posting it multiple times when the update is pending does not add any events to the event queue, and does not imply multiple updates.
I met similar problem when I have multiple OSG viewers in one Qt application, where one of them works well, while the rest are very "slow".
By turning on the rendering stats (press "s" on the viewer), I found that the "slow" actually is not caused by the rendering, actually the rendering is fast.
The reason why the viewers are "slow" is that many gui events are not handled. For example, whey you drag the scene, many drag events are generated by Qt, but only few are passed to the OSG viewer, so the viewers response "slowly".
The events dropping actually is due to that the rendering is too fast...in Viewer::eventTraversal(), only those relative new events are processed, and the "relative new" is measured by cutOffTime = _frameStamp->getReferenceTime(). So if Qt generates the events slower than the rendering, many events will be cut off, and thus not processed.
And finally, after I found the root cause, the solution is easy. Let's cheat a bit on the reference time of _frameStamp used in the Viewer::eventTraversal():
class MyViewer : public osgViewer::Viewer
{
...
virtual void eventTraversal();
...
}
void MyViewer::eventTraversal()
{
double reference_time = _frameStamp->getReferenceTime();
_frameStamp->setReferenceTime(reference_time*100);
osgViewer::Viewer::eventTraversal();
_frameStamp->setReferenceTime(reference_time);
return;
}
I spent also quite some time to figure out how to make this work.
I think that the answer from Gnosophilon cannot work with Qt5, as the rules for switching context thread are more strict than with Qt4 (ie, a call to moveToThread() is required on the OpenGL context object). At time of writing, OSG doesn't satisfy this rules.
(At least I couldn't make it work)
I haven't figure out how to do it in a separate thread, however, to render the scene smoothly in the UI thread, without use of fixed interval timer, one may do the following
viewer_->setRunFrameScheme(osgViewer::ViewerBase::ON_DEMAND);
viewer_->setThreadingModel(osgViewer::CompositeViewer::SingleThreaded);
osgQt::initQtWindowingSystem();
osgQt::setViewer(viewer_.get());
osgQt::setViewer() handle with global variables, so only one viewer at a time can be used.
(which can be a CompositeViewer of course)

How to handle this situation (need to register functions with variable arguments)

I'm looking for suggestion on how to handle this situation as anything I've thought of thus far does not work.
I'm working on an RPG game and am currently developing the graphical system. My graphics system consists of a series of ScreenStacks which are arranged in a particular order and then drawn.
A ScreenStack is basically just a collection of related Screens, along with a unique id and a draw order.
i.e.
class ScreenStack
{
//Constructors, getters/setters etc.
private:
std::string StackName;
int DrawPriority;
int UID;
bool Valid;
bool DrawStack;
bool UpdateStack;
bool SendInputs;
bool DeleteStack;
std::vector<screen_ptr> OwnedScreens; //screen_ptr is a shared_ptr around a Screen object
};
A screen is a simple graphical layer responsible for visualizing some part of the game, for example there's a screen for showing the player inventory, party overview, party status in battle, enemy party, etc.
I have a screen manager that is responsible for storing the various functions for creating screen stacks (i.e. a function to create a battle stack will make a screen for the player party, the enemy party, the attack animation screen, the background, and the user interface). Each of the various screen stack creation functions needs a different set of paramters to construct it. What I'm doing now is manually adding in stack creation functions to the screen manager on an as needed basis. For instance, right now the screen manager has a function for creating the title screen stack, the start menu stack, the battle stack, the overworld stack, the tilemap stack etc.
This works, but is cumbersome and cluttered. What I'd like to be able to do is have files external from the screen manager be able to register stack creation functions with the screen manager and then I can just look up the screen creation function instead of having to add a new function to the screen manager for each stack I need to create.
I initially tried adding an unordered_map<std::string, StackCreationFunction> with StackCreationFunction being typedef'd as
boost::function<ScreenStack (Engine& engine, ScreenManager& manager, const std::string screenName, const int StackID, const std::vector<std::string>& TryToCopyScreens, ...)>
... was from cstdargs. The idea was that each ScreenStack would add it's own StackCreationFunction to this map. This doesn't work however as boost::function is invalid with ...
So essentially what I'm trying to do is allow external files/screens be able to register their own creation functions (that has variable arguments) with the screenmanager, and Ideally be able to do this at compile time/immediately after starting. This feels like it should be possible with the preprocessor, but I'm unsure how to do it. I'm pretty stuck here, and I really would like a better solution then adding many stack creator functions to the screen manager and cluttering it up.
Any suggestions/a better solution would be greatly appreciated, and I can provide more details if the above was not clear enough
Thanks
Each of the various screen stack creation functions needs a different set of paramters to construct it.
I think that's the problem here, and you need to think of an abstraction here to make your map work. After all, how are these extra arguments actually provided by the calling code? When the calling code knows which class is instantiated and can provide the arguments, you don't need the map. When not, the map is of no use, since you can't tell which arguments to provide to the stack creation function.
The most likely solution is to boost::bind away all arguments of your StackCreatorFunction that would normally go into the ... arguments and register this bound version of your function at the unordered map, which can be freed of the ....
I would suggest that rather than having something external register into your system think about having your system call the external entity. In this case your system would locate and load a series of plugins that have specific entry points. You will need to create your variable length argument list using some convential container; either an array or data structure.
I'm not sure if that answers your question, but if your concern is to call various functions of different signatures from an interpreter-like code, you could (under GNU/Linux at least) use the LibFFI (a library for foreign function interface) for that.