• Content count

  • Joined

  • Last visited

Community Reputation

228 Neutral

About Sundeepkahlon

  • Rank
  1. Thanks ChaosEngine! Some of the points you made, I had thought about as well but I wasn't too sure since c++ is pretty new to me. I think I'm much more confident with ownership and thinking about how to setup my dependencies.        Well I guess it pays to have some critical thinking, that's why I posted those links so that someone could help me understand things much easier, Thanks!
  2.   A is should live through whilst the program is running, like for example a box2d b2World object.       Aren't storing references a bad idea? . Again I'm only going by what I'm reading online.         I like this approach, even though raw pointers are usually not good. I think if someone was to read my code and saw it, it would clearly convey there is no Ownership of this b2World object. If I take this approach, it would mean that I don't need to delete my a object in the destructor of both B and C. It would need to be handled separately?  Something like this then: main(){ A aObject; B bObject(&aObject); C cObject(&aObject); } Then A would be deleted when it goes out of scope along with B and C automatically.
  3. Hi, so I have a simple question in terms of dependency injection with c++. Say I have 3 classes A, B and C. If both B and C have a dependency on A, what is the best way to inject and share A with both B and C. I could have the following (pseudo code): B(A& a) : uniqueAptr(&a){} C(A& a) : uniqueAptr(&a){} Where uniqueAptr is a unique_ptr (std::unique_ptr<A> uniqueAptr) member variable and then intialize B and C like so: A aObject; B bObject(aObject); C cObject(aObject); But wouldn't that cause both bObject and cObject object to delete the pointer to aObject effectively trying to delete aObject twice (which would cause an error). Would a shared_ptr make most sense in this case? I've read a few resources online saying that shared_ptr is not all that great to use for exampple . So what's the preferred way of doing something like the above? This is a simple example, but in reality you would have other pointer member variable and so on.
  4. I'm currently using C++ on my linux machine (ubuntu 14.10). Here's my setup:   Eclipse CDT (latest version) Opengl SFML Box2d Luascript Terminal   SFML and Box2d both can be compiled very easily. I find eclipse the best ide for C++ on linux, it has luascript plugins as well which makes life much easier. Everything should be straight forward to setup.
  5.   I got rid of the RenderWindow::clear(), but that didn't do anything. Infact, I got rid of the pushGLStates/popGLStates and I'm trying to handle all the states my self. Though I'm not really confident with that. Here's what I have: void Game::render() { //TODO draw opengl stuff here glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT); m_openglTextureRenderer.render(); //TODO sfml stuff here glPushAttrib(GL_CURRENT_BIT | GL_TRANSFORM_BIT | GL_VIEWPORT_BIT); TextureLoader::checkError("glPushAttrib"); glPushMatrix(); m_mainRenderWindow->resetGLStates(); m_mainRenderWindow->draw(m_cameraSystem); m_mainRenderWindow->draw(m_mapLoader); // m_mainRenderWindow->draw(m_animationSystem); m_mainRenderWindow->draw(m_mouseSplitterSystem); m_fixedTimeStepSystem.drawDebug(); glPopAttrib(); glPopMatrix(); m_mainRenderWindow->display(); } Infact all my code can be found here in this branch: . It's not really in a shareable state atm, but all the code is pretty much there. I don't see any opengl errors in my console, but I'll have to do some reading to understand how to save states, any help appreciated. With the code above, the texture is showing correctly, but I'm not really convinced since I'm not too familiar with opengl.
  6. Hi,    I'm trying to draw some opengl textures after some SFML draw calls. from what I understand I need to call  pushGLStates before and draw calls and then popGLStates after any draw calls. Then I should be safe to call my opengl code. However, in doing so, opengl stops drawing textures on the screen. I'm pretty confused about what might be causing the problems. I've attached an image showing the problem (the texutre is displayed on the left when I comment out the calls to  pushGLStates/popGLStates). Any ideas on what be causing the problem? Even if I comment out all sfml drawing code, I still see the same problem.   Here's my games init code which basically runs a bunch of opengl code. void Game::init() { glDisable(GL_LIGHTING); // Configure the viewport (the same size as the window) glViewport(0, 0, m_mainRenderWindow->getSize().x, m_mainRenderWindow->getSize().y); glMatrixMode(GL_PROJECTION); glOrtho(0, 1280, 800, 0, -1, 1); glMatrixMode(GL_MODELVIEW); glEnableClientState(GL_VERTEX_ARRAY); glEnableClientState(GL_TEXTURE_COORD_ARRAY); glEnable(GL_TEXTURE_2D); glShadeModel(GL_SMOOTH); glClearColor(0.0f, 0.0f, 0.0f, 0.5f); glClearDepth(1.0f); // Depth Buffer Setup glEnable(GL_DEPTH_TEST); // Enables Depth Testing glDepthFunc(GL_LEQUAL); } Here's my render function: void Game::render() { m_mainRenderWindow->setActive(true); //TODO sfml stuff here m_mainRenderWindow->clear(sf::Color(50, 50, 50)); m_mainRenderWindow->pushGLStates(); m_mainRenderWindow->draw(m_cameraSystem); m_mainRenderWindow->draw(m_mapLoader); m_mainRenderWindow->draw(m_mouseSplitterSystem); m_fixedTimeStepSystem.drawDebug(); m_mainRenderWindow->popGLStates(); //TODO draw opengl stuff here glClear(GL_DEPTH_BUFFER_BIT); m_openglTextureRenderer.render(); m_mainRenderWindow->display(); } m_openglTextureRenderer is an instance of OpenGLTextureRenderer, which draws a bunch of textures to the screen, here's the render code for that: void OpenGLTextureRenderer::OpenGLTextureRendererImpl::render(std::vector<anax::Entity>& entities) { const float M2P = 30.0f; for (auto entity : entities) { if(!entity.isActivated() || !entity.isValid()) continue; auto& texCoordsComp = entity.getComponent<Texcoords>(); auto& physicsComp = entity.getComponent<PhysicsComponent>(); auto& texCoordsVec = texCoordsComp.textCoords; if(texCoordsVec.size() <= 0) continue; b2Body* body = physicsComp.physicsBody; glBindTexture(GL_TEXTURE_2D, texCoordsComp.texture); b2PolygonShape* shape = ((b2PolygonShape*) body->GetFixtureList()->GetShape()); std::vector<b2Vec2> points(shape->GetVertexCount()); for (int i = 0; i < shape->GetVertexCount(); i++) { points[i] = (shape)->GetVertex(i); } glPushMatrix(); b2Vec2 center = (body->GetPosition()); float angle = body->GetAngle(); glTranslatef(static_cast<float>(floor(center.x * M2P)), static_cast<float>(floor(center.y * M2P)), 0.0f); glRotatef(angle * 180.0 / M_PI, 0, 0, 1); glBegin(GL_POLYGON); //begin drawing of polygon for (int i = 0; i < shape->GetVertexCount(); i++) { glTexCoord2d(texCoordsVec[i].x, texCoordsVec[i].y); glVertex2f(floor(points[i].x * M2P), floor(points[i].y * M2P)); } glEnd(); //end drawing of polygon glPopMatrix(); } }
  7. Norman Barrows is right, simplest approach first, and it's in fact what usually works best. But when things start to get complicated you need a way of managing things a little better. Heres what I'm currently working on doing. I implement my game logic related to collisions in lua script and bind the box2d to lua through lua bind. Taking this approach, each level will have its own lua script (where you can reuse existing scripts if need be) where collisions will be handled, but only collisions that are very specific to that level. E.g. a player jumps on a switch which opens a specific trap door.   You can inialiaze your game objects (might be box2d bodies) at the start of a level to the lua script via meta tables and keep a reference to them. Then on a collision, call the a lua function from your c++ and  check if the fixtures/body is the one your interested in and some game logic. I havnt quite finished yet, but I'm at the point where I can implement the game logic via my lua script (my source is on git, I'll update the question when I'm done). I'm taking this approach since im still prototying my ideas and I think it's worth it to spend a little time to experiment, but its hacky since I don't know if it will end up being clean or not and I havnt refactored code yet.
  8. I managed to fix the problem by using a camera specific for opengl. So I maintain an sf::View for SFML related drawing and a camera class for opengl related calls. I don't know if this is best practice, but it seems to work. I also read that raw opengl calls should be maintained sperate from sfml, so I guess it would make sense to have seperate camera's. On a side note, my texture still ins't being drawn in the correct place. Here's an image showing what I mean: . Moving around correctly leave the texture in one place, but it's not located where the green box should be.   I suspect the problem maybe with how I draw my texture  (  Though I cannot see what maybe wrong.
  9. Hi,   I'm having some trouble with using an sf::VIew as a camera when mixing raw opengl calls with SFML. For example, here in my code I'm mixing opengl calls with SFML: Everything drawn by SFML is correct but the textures drawn manually using opengl calls follow the camera when the player moves, rather than staying put. Here's an example image: . When I move, you can see that the wooden texture follows rather than staying where it's box2d body is.   What would be the general way of handling a camera in this scenario? Would I need to write a custom camera class?
  10. As promised, I'm giving a simple update in case someone is interested. I've implemented a simple example of how to do this, the code can be found here: . I'm still working on things, and it's not tested 100%, but it's something  .
  11. Thanks! I think this makes sense. I'll try implementing this and post back with an update.
  12. Hi, I'm currently using Box2D, Opengl and SFML (still pretty new to this stuff) to build a splitting engine where the user can use their mouse to split shapes into smaller ones. I'm having a hard time actually figuring out how the split shapes would be textured after they have been sliced. For example, say I have a quad which has been textured correctly. I slice the square on the top right causing a new triangle and a 5 sided polygon to be created. How would the 2 new shapes be textured after this? I've only seen examples of quads and triangles being textured in opengl and subrecting a texture in SFML won't work since it only supports rects. Any thoughts? Thanks.
  13. Fixed timestep with box2d and SFML

    I'm pretty sure that its not to do with the interpolation, since I've tried using the position from the box2d body directly. I've also written things to work by directly limiting frame rate as a test to 60 fps as well. Still cannot see why I'm getting this odd blurring.  Thanks.
  14. Fixed timestep with box2d and SFML

      Yeah, I tried this and it still looks odd.
  15. With out being to specific, I've found that breaking things up into many small components works well, not only for games but for general software. The idea is to make many small components (that does only one thing, but it does it very well) that are easier to test and maintain and build something bigger out of them. For example, when making a game, you might want to write a generic lighting system that's totally separate and not coupled with any game code. This component has a simple interface that exposes only a few functions/methods to clients so that its easier to maintain and less breaking when changes are made. Don't embed any specific domain knowledge into the component.   Then you can start putting these components to together to build something bigger. Testing becomes easier and finding out where a bug lives is also easier since there's only one place you'll likely need to look. Try limiting them to only exposing one/two functions.   Also here's a good link more specific to game design: . Search gamesutra for similar articles since they do talk about similar topics.   I'd also say try being more DRY. If you find a open source library that does what you need, don't write your own and just adopt it. Make changes as necessary and commit to the project if it doesn't meet your needs. Also read books like: clean code. Author talks alot about writing more maintainable code.