Messages

1

General / Re: Thor make error - Undefined symbols. (Mac)

« on: October 23, 2014, 10:13:13 pm »

hey, just as you replied i fixed it.

Quick summary of what I did for anybody else who gets these issues;

build and install sfml with the c++11 features enabled (included in tutorial)

when configuring thor in cmake add THOR_CLANG_STDLIB = libc++ uncheck THOR_SHARED_LIBS.

for me, when i unchecked the shared libs option i had to set GLEW_LIBRARY and JPEG_LIBRARY manually. These were both found in the SFML-master/extlibs/libs-osx/lib/ folder.

Thank for the input Hiura and Nexus and hope the above helps people in future.

2

General / Re: Thor make error - Undefined symbols. (Mac)

« on: October 23, 2014, 09:44:27 pm »

Also, make sure you have properly set up your compiler to use the correct stdlib. SFML, Thor and your project should all use the same one.

This was it. Thanks.

Although Thor now builds to 100% but *just* fails with the same error but for the below

Code: [Select]

[ 96%] Building CXX object src/CMakeFiles/thor.dir/Trigonometry.cpp.o
[100%] Building CXX object src/CMakeFiles/thor.dir/UniformAccess.cpp.o
Linking CXX shared library libthor.dylib
Undefined symbols for architecture x86_64:
  "sf::Image::loadFromFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)", referenced from:
      thor::BigTexture::loadFromFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in BigTexture.cpp.o
***so close***

3

General / Thor make error - Undefined symbols. (Mac)

« on: October 22, 2014, 11:38:09 pm »

Hi

Been struggling through with this for couple of nights, forum searches and googles got me through a couple of previous issues but no joy with this one.

I've downloaded SFML and Thor, both the latest from Github.

Built and installed SFML with Cmake.

Generated Thor Makefile with Cmake.

My issue is when i run make in Terminal I receive the below error.

Code: [Select]

Linking CXX shared library libthor.dylib
Undefined symbols for architecture x86_64:
  "sf::Image::~Image()", referenced from:
      thor::BigTexture::loadFromFile(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) in BigTexture.cpp.o
      thor::BigTexture::loadFromMemory(void const*, unsigned long) in BigTexture.cpp.o
      thor::BigTexture::loadFromStream(sf::InputStream&) in BigTexture.cpp.o
  "sf::operator/(sf::Time, sf::Time)", referenced from:
      thor::getElapsedRatio(thor::Particle const&) in Particle.cpp.o
      thor::getRemainingRatio(thor::Particle const&) in Particle.cpp.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [src/libthor.dylib] Error 1
make[1]: *** [src/CMakeFiles/thor.dir/all] Error 2
make: *** [all] Error 2

I've completely started the whole process a couple of times, I've read the installation tutorial and *pretty* sure I understand it. The note on Thors download page that says the development version is not compatible with sfml 2.1 confused me slightly as I had seen other places that the sfml and thor github versions should work.

Any help would be appretiated.

4

Graphics / Re: Box2d body and sfml sprite drift out further away from window origin

« on: October 07, 2014, 09:05:47 pm »

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.

This was it! Thanks alot 

And thanks for the link about the polygon skin too.

5

Graphics / Re: SFML textures not loading

« on: October 07, 2014, 09:04:15 pm »

Could you try adding the extension to the filename?

eg.
!texture.loadFromFile("TextureImage.png")

The way I think of textures and sprites is the sprite is the object that you move, the texture is its "skin" - or what you see. You can't see a sprite.

Hope that makes sense.

6

Graphics / Re: Box2d body and sfml sprite drift out further away from window origin

« on: October 07, 2014, 07:51:14 pm »

Well I was convinced it wasn't that but now that you say the debug draw has a conversion rate I seem to remember seeing something.

I'll report back shortly.

7

Graphics / Re: Box2d body and sfml sprite drift out further away from window origin

« on: October 06, 2014, 10:12:59 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.

No views at the moment, just drawing to and viewing the window directly. I have an evolutionary style with these things lol.

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. Unless i'm misunderstanding you.

I have been using 30.f as my conversion figure, I changed this to 32.f and the effect is drastically reduced but its still definately present.

Using the screens provided above, the characters feet don't quite touch the ground, maybe by a pixel or 2.

Admittedly its alot better than it was but I'd still like to eliminate it totally.

Thanks for reading.

8

Graphics / Re: Box2d body and sfml sprite drift out further away from window origin

« on: October 05, 2014, 09:22:05 pm »

Apologies for the gap in posting.

I have edited my op with some screens and code.

9

Graphics / Re: Box2d body and sfml sprite drift out further away from window origin

« on: October 04, 2014, 09:14:03 am »

Hey, thanks for replying.

I'll post some code up when I get to my computer shortly now.

Yeah the 30 pixel conversion scale is consistent across all interaction between sfml and box2d.

To move the box I apply an impulse to the body then update the sprites position as stated in my op.

It's just strange how at 0,0 the sprite is perfectly inside the box but the further away the more offset it is. There's definately a direct link. I'll post some screens aswell or maybe a vine.

Thanks for baring with me.

10

Graphics / Box2d body and sfml sprite drift out further away from window origin

« on: October 04, 2014, 12:09:04 am »

Hello

I'm having an issue at the minute with a prototype I'm working on with box2d.

I create a dynamic box and a sprite, these are to act as one object with the sprite for visuals and the box for collisions etc. pretty standard stuff.

The issue is, the further away from the windows origin (top left) the box goes, the further offset the sprite is from the box. So in the top left corner the sprites texture is inside the body's box then in the bottom right corner the textures totally out of the box.

The sprites origin is set as the centre.

In my update function I set the position of the sprite using;
Sprite.setPosition(Body->getPosition().x * 30.f, Body->getPosition().y * 30.f)

Sorry for semi-pseudocode but I just rage quit my laptop and don't want it back in until I have some ideas to try out.

I've hit up Google and read box2d and sfml docs with no joy to why these 2 components would drift out like this.

Thanks for your help.

EDIT:

Code provided below.

entity creation

//body creation
b2BodyDef bodyDef;
bodyDef.position = b2Vec2(pos.x/SCALE, pos.y/SCALE);
bodyDef.type = b2_dynamicBody;
bodyDef.fixedRotation = true;
b2Body* body = world.CreateBody(&bodyDef);

b2PolygonShape shape;
shape.SetAsBox(((size.x)/2)/SCALE, ((size.y)/2)/SCALE);
b2FixtureDef fixtureDef;
fixtureDef.density = 4.f;
fixtureDef.friction = 3.f;
fixtureDef.shape = &shape;
body->CreateFixture(&fixtureDef);

//sprite creation
texture.loadFromFile(filename));
sprite.setTexture(texture);
sprite.setOrigin(_size / 2.f);
sprite.setPosition(spawnPos);

update function

b2Vec2 pos = body->GetPosition();

sprite.setPosition(SCALE * pos.x, SCALE * pos.y);
 

And some screens

Close to origin


Furthest point from origin


Collisions between bodies working fine