SFML community forums
General => General discussions => Topic started by: grandmasterhack on June 10, 2011, 05:46:27 pm
-
Hello, i've been wondering this but i can seem to get a hold of the concept of programming a 2d platformer. jumping and maps dont seem to be the problem its just the screen( or camera) moving i dont understand. can someone break down the theory of this. do i need an offset, becasue i heard one way of doing it is basically the character doesnt move at all but you essentially moving the map itself.
-
Actually, sf::View does everything you need for a 2D camera. How it works is explained in the tutorials and in the documentation.
-
Actually, sf::View does everything you need for a 2D camera. How it works is explained in the tutorials and in the documentation.
i've read that but when i do use that how do i detect collision since every thing is off? does it matter? when i wrote my editor i had an offset value that moved the tiles over instead of view.
[pseudo code]
if(key_press.RIGHT)
offset_x++;
tile.setpostion(x + offset_x);
-
i've read that but when i do use that how do i detect collision since every thing is off?
Game logics like collision detection and response are normally independent of the graphical representation (i.e. also of the sf::View).
-
i've read that but when i do use that how do i detect collision since every thing is off?
Game logics like collision detection and response are normally independent of the graphical representation (i.e. also of the sf::View).
what about zooming in? i know that affected it(but that was in 1.5).
-
what about zooming in? i know that affected it
Why should zooming in behave different? What does it affect?
I think you haven't understood what I wanted to tell you. I meant that game logics like collision are handled on your own side, while SFML is primarily used to draw the scene. So sf::View just cannot affect the collision detection in any way, because it is computed completely separate from any SFML stuff.
-
Normaly what we do is, dont move the camera nor the player ( in some cases ), move the world instead.
-
Normaly what we do is, dont move the camera nor the player ( in some cases ), move the world instead.
And the advantage over moving the camera is where?
People, don't make stuff more complicated than necessary. sf::View is designed as a 2D camera, so use it ;)
-
Normaly what we do is, dont move the camera nor the player ( in some cases ), move the world instead.
And the advantage over moving the camera is where?
People, don't make stuff more complicated than necessary. sf::View is designed as a 2D camera, so use it ;)
well, yes, if there is a class that makes everything easier go ahead :D, i just said this to sugest other ways of doing it :),
besides i never really messed arround with views much so thats how i do it for now.
-
For my 2d top down tile based game I take the players position, and the camera's center then I subtract the two and I do camera.move * difference * delta time
gives a nice effect and works well!