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: https://github.com/SundeepK/Clone/blob/wip/add_splittable_enviroment/src/Game.cpp#L58. 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: http://i.imgur.com/umME791.png?1 . 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?
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.
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.