1
Graphics / Re: SFML textures not loading
« on: October 08, 2014, 01:09:16 pm »
The documentation is always a good place if you don't know exactly what each class does 
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
2
General / Re: Help with Linking Error..
« on: October 07, 2014, 05:17:59 am »
The linker is what tries to match a function call with a function definition. Most linker errors you will run into is often due to the fact that it can't find the definition. This is mostly because you forgot to include some files, or forgot to link some libraries. Since your error states that it cannot find sf::Color::Green and sf::RenderStates::Default, which are from SFML, it's probably because you did not link the SFML library correctly.
As for how to link it correctly, read the tutorial.
The third linker error (about MSVCRTD.lib) is not SFML related and can be easily googled
As for how to link it correctly, read the tutorial.
The third linker error (about MSVCRTD.lib) is not SFML related and can be easily googled
3
Graphics / Re: Box2d body and sfml sprite drift out further away from window origin
« on: October 07, 2014, 05:06:19 am »The bounding boxes as in the box2d body boxes? These are drawn with box2ds debug draw and all the collisions work with them so I don't think its this.Hmm, I should take a look at that since I wrote the bounding box displaying myself
This might be your problem though. The box2d debug draw might have a conversion unit defined somewhere. If your own conversion unit does not match theirs, both will differ more and more the further you are away from the center.Using the screens provided above, the characters feet don't quite touch the ground, maybe by a pixel or 2.You mean the small space in between the 2 bounding boxes in your third image from your OP? That's because of how Box2D works. Page 17 of their manual. They call it polygon skin.
4
Graphics / Re: Box2d body and sfml sprite drift out further away from window origin
« on: October 06, 2014, 01:28:03 am »
Are you using any views and does the current view exactly match the window size? Keep in mind that the bounding boxes could be drawn wrong instead of only the sprite.
5
Window / Re: Best way to draw at pixel position instead of world position?
« on: October 05, 2014, 06:24:40 pm »
As far as I know, changing the view will only translate/scale everything you draw next. Thus using setView is not compute intensive.
6
Graphics / Re: Rotating a sprite is causing some really weird bugs
« on: October 05, 2014, 12:27:36 pm »
Are you sure you read the tutorial about transformables? I think you are forgetting that changing the origin also relatively changes the position of the sprite.
Just draw a sprite at (0,0) with it's origin at (0,0) and then with it's origin changed. See what changes. Hapax last suggestion should not change anything because of how casts work is C++, but it's safer anyway how he writes it.
Just draw a sprite at (0,0) with it's origin at (0,0) and then with it's origin changed. See what changes. Hapax last suggestion should not change anything because of how casts work is C++, but it's safer anyway how he writes it.
7
Graphics / Re: Capture the whole level
« on: September 27, 2014, 12:42:04 pm »
Isn't this what you need?
http://sfml-dev.org/tutorials/2.1/graphics-view.php#defining-how-the-view-is-viewed
http://sfml-dev.org/tutorials/2.1/graphics-view.php#defining-how-the-view-is-viewed
8
General / Re: Starting on my first project!
« on: September 23, 2014, 06:59:36 pm »Since this is your first project, I'd recommend developing through trial and error. See what works and what doesn't and plan for new things when you move from one iteration to another.I agree. OP: you've probably read on some site which said good programmers can design everything up front and then start programming it. What they always forget to mention is how you actually become good. If you don't have enough experience you just can't plan/design everything up front and you have no choice but to learn through trail and error. The more you learn the more easier it will become to actually design parts of your program up front.
I was stuck for almost a full year simply trying to design a game. But every time I started to code I missed something and the design simply failed. This is simply due to lack of experience and knowledge and you won't get it if you don't start to code and learn through trail and error
9
Graphics / Re: Getting boundaries of non-rectangular sprite?
« on: September 23, 2014, 04:54:12 pm »
Searching for Tetris collision detection gives you this article: http://gamedevelopment.tutsplus.com/tutorials/implementing-tetris-collision-detection--gamedev-852
This is a grid-based tetris, not sure if that's what you want.
But in any case, you can diminish the amount of rectangles easily to a maximum of 2 (green rectangles):
Of course the line and the square blocks can be reduced to 1 single rectangle. Or you could use an AABB (axis-aligned bounding box) to simplify the collisions at first. If the AABB's collide, then go into a more detailed collision check. But I don't think that's necessary for a tetris clone.
This is a grid-based tetris, not sure if that's what you want.
But in any case, you can diminish the amount of rectangles easily to a maximum of 2 (green rectangles):
Of course the line and the square blocks can be reduced to 1 single rectangle. Or you could use an AABB (axis-aligned bounding box) to simplify the collisions at first. If the AABB's collide, then go into a more detailed collision check. But I don't think that's necessary for a tetris clone.
10
General / Re: Main Menu Buttons
« on: May 20, 2014, 05:26:50 pm »
It's not this is it? 
On the console you normally have an error code. Microsoft does a very good job documenting the occurrences of these errors with an explanation and examples.
if(menuEvent.ype == sf::Event::Closed)
On the console you normally have an error code. Microsoft does a very good job documenting the occurrences of these errors with an explanation and examples.
11
General / Re: Question about lighting in 2D game.
« on: May 18, 2014, 10:51:52 pm »
Well in this case you have no choice but to work with a 3-coordinate system. You need to know the distance to the floor, the wall and the horizontal placing to place the lighting. So it's impossible to work with less than 3 coordinates.
But as stated, you don't need any 3D engine of the sorts to do the lighting: for the lighting on the floor you can find it's middle point by using the distance to from the wall and the horizontal placing, the strength of the light casted on the floor (radius) by the distance to the floor. Then skew the circle of light proportional to the angle of the floor. In the screenshot it's clear they simply shortened the height. This should give a decent result as far as I can tell.
But as stated, you don't need any 3D engine of the sorts to do the lighting: for the lighting on the floor you can find it's middle point by using the distance to from the wall and the horizontal placing, the strength of the light casted on the floor (radius) by the distance to the floor. Then skew the circle of light proportional to the angle of the floor. In the screenshot it's clear they simply shortened the height. This should give a decent result as far as I can tell.
12
General / Re: Treating all sprites in a group as one sprite
« on: May 04, 2014, 12:51:48 pm »
Never did this myself, but my guess is to replace all bricks with 1 new object which holds a vector of all the locations. In the collision check, this object should be regarded as 1 object so it will not interact with itself.
13
Graphics / Re: Velocity not working out as hoped. Flappy bird type game.
« on: May 02, 2014, 07:32:52 pm »
Hmm, why do you use 2 bools up and down when 1 is enough? And why do you only restart your clock when the up-key is pressed?
I don't think you have the correct formulas to calculate your position and velocity. You use velocity = velocity*acceleration which seems very strange to me. Velocity is in m/s and acceleration in m/s², thus your new velocity is now in m²/s³ which doesn't make a lot of sense. The correct formula for calculating your velocity:
with a the acceleration, v0 the starting velocity and t the time. Mind that sf::Sprite::move needs a position to move to and not a velocity.
Also, if you want to have a little bit of accurate physics you should only change the acceleration. Calculate the correct velocity under the new acceleration and with that velocity the position to move to.
I don't think you have the correct formulas to calculate your position and velocity. You use velocity = velocity*acceleration which seems very strange to me. Velocity is in m/s and acceleration in m/s², thus your new velocity is now in m²/s³ which doesn't make a lot of sense. The correct formula for calculating your velocity:
with a the acceleration, v0 the starting velocity and t the time. Mind that sf::Sprite::move needs a position to move to and not a velocity.
Also, if you want to have a little bit of accurate physics you should only change the acceleration. Calculate the correct velocity under the new acceleration and with that velocity the position to move to.
14
General / Re: Various fast ways of collision detection?
« on: April 30, 2014, 10:15:05 pm »
I don't know how you handle collisions, but you could check for collisions in a couple of steps. You could start with getting the maximum radius from an object (e.g. half diagonal length of a square) and do a circular collision check. This is easy and fast. If they do not collide, you can be certain all the more detailed collision checks will also fail.
Problem with this method is that it's probably less stable in terms of fps. When suddenly lots of objects are close to each other it also suddenly has to do a lot more checks.
Problem with this method is that it's probably less stable in terms of fps. When suddenly lots of objects are close to each other it also suddenly has to do a lot more checks.
15
General / Re: Collisions?
« on: April 28, 2014, 01:06:05 pm »
There are a number of ways to do it.
If you are working with tiles you can simply flag a tile as 'collidable' and when anything tries to move to its location, handle the collision.
Or you could use a library. Here are a couple of them listed.
- Rectangular collision: use sf::Rect::intersects
- Circular collision: compute the distance between the centers of the object, if it's smaller than the sum of the radius of both circles, they collide
- Pixel perfect collisions, not recommended since it's slow and probably overkill for most situations
If you are working with tiles you can simply flag a tile as 'collidable' and when anything tries to move to its location, handle the collision.
Or you could use a library. Here are a couple of them listed.