1
General / Re: Update origin in sprite before rendering?
« on: September 02, 2015, 02:55:06 pm »
Thanks for you answers guys.
I understood what's the point.
I understood what's the point.
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.
#include <SFML/Graphics.hpp>
#include <iostream>
#include <vector>
#include <tuple>
enum class ID
{
Background,
Player
};
std::vector<std::tuple<ID, sf::Texture, sf::Sprite>> drawables;
void add(ID id, const std::string &path)
{
sf::Texture texture;
if(!texture.loadFromFile(path))
throw std::runtime_error("Could not load: " + path);
sf::Sprite sprite(texture);
drawables.push_back(std::make_tuple(id,texture,sprite));
}
int main()
{
add(ID::Background, "Data/Background.png");
sf::RenderWindow window(sf::VideoMode(500, 500), "Test");
window.setFramerateLimit(60);
while(window.isOpen())
{
window.clear();
window.draw(std::get<2>(drawables[0]));
window.display();
}
return 0;
}
Unless you're counting parents of parents, each child should only really have a single parent. *rereads first post. *realises mParent can only reference a single parent *realises you probably are talking about parents of parents *facepalms
The point here I think is more clear if you think of it in one dimension.
If one object has an absolute position of 10. It's child has a relative position of 20 and it's child has a relative position of 5. The absolute position of the child's child is not 25 (the result of just combining the child's transform and it's parent's), but is 35, as each offset is combined with all of the previous. I may be completely wrong but you did say we may need more code.
A node's transform is always relative to its parent. And the parent node is relative to its own parent. And so on until you reach the root node. So you have to combine the whole chain of transforms up to the root to get the final world transform of a node. Combining the parent's transform only would yield a transform relative to the node's grand-parent.
QuoteFor example our position is (50, 50), position of our parent is (10, 10).No. A transform is a matrix, so multiplying two transforms is equivalent to multiplying two matrices, which has nothing to do with multiplying two numbers.
So transform * child-transform is (500, 500).
Anyway, you don't have to know the underlying math involved here, just take what the documentation says: multiplying two transforms combines them. In other words, applying transform A * B is equivalent to applying transform A followed by transform B.
To come back to your example, it would be equivalent to a translation of (50, 50) followed by a translation of (10, 10), which is a combined translation of (60, 60).
Also check out this thread: http://en.sfml-dev.org/forums/index.php?topic=12209.0 - lots of great stuff listed there.
I want to create a game and then sell it for a bit pocket money.Unless you're building a triple-A 3D game for a console, choosing SFML or SDL (or any other established, high level library) won't have much impact on the quality of the game you want to make.
But is this posible with SFML or is there a better alternate for SFML?
I dont want to leave SFML because it has graphics, audio, network... and it's easy to use , so should I give a try?
SFML.NET 1.5 - http://store.steampowered.com/app/55020/
SFML.NET 1.6 - http://store.steampowered.com/app/55040/
I don't have names right now but there are some SFML games that are on Steam, yes.
Often the devs of these games don't post often around here, so it's impossible to keep track of all of them.
But if you go on the project section you'll find some (indie) games that are sold. I don't know about any AAA game that uses SFML, as they usually use "big" engines like Unity/Unreal/...
I would say that these two qualify:
http://en.sfml-dev.org/forums/index.php?topic=14614.0
http://en.sfml-dev.org/forums/index.php?topic=15600.0
and you can find more in that sub-forum.
snag the 'MinGW TDM GCC 4.7.1 64bit' and redo the tutorial. Looking at your linker settings you have quite a bit wrong.
1. You said you defined SFML_STATIC but you are not linking to the static libraries. you should be linking to "sfml-graphics-s-d" for STATIC DEBUG and "sfml-graphics-s" for STATIC RELEASE and so forth with the rest. the Tutorial describes all this if you actually read it and not just look at the pictures. "sfml-main-d" has no "-s" in it even when statically linking.
2. your linker setting should look like they do in the tutorial, just "sfml-graphics-s-d", "sfml-window-s-d", "sfml--mainsystem-s-d" and so forth. you need to get rid of the "..\..\sfml20\lib" and the " .a" on each entry.
You need to grab one of the nightly builds from here http://sfml.my-gate.net/nightly/ for your version. The build linked off the official site does not work with the current version of code::blocks.
I had this same problem but snagging a new build fixed it. You could also recomplile SFML from source to work with your code::blocks if you know how.
Could also be Linker settings.