Welcome, Guest. Please login or register. Did you miss your activation email?

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.


Messages - FRex

Pages: 1 ... 120 121 [122] 123
1816
General / Re: Class Destructed on Function Return?
« on: August 22, 2012, 06:07:42 am »
I want to yell profanities at you :), you included worthless compiled debug exe but didn't include the images so I had to comment out all of your trolly asserts.  ;D
Anyway, the problem is your GetGameObjectManager(); returns a copy(define a copy c-tor to see for yourself) and you probably wanted a reference, these are two changes that seem to fix the problem:
Line 14 of Game.h should be this:
static GameObjectManager& GetGameObjectManager();
Line 107 of Game.cpp should be this:
GameObjectManager& Game::GetGameObjectManager()

1817
General / Re: box2d
« on: August 22, 2012, 05:12:14 am »
It depends on what you're doing with that sprite, in a side view metroidvania style game most of the sprites never rotate.

1818
General / Re: box2d
« on: August 22, 2012, 02:58:41 am »
1. It's good thing you made gravity positive, one less minus sign to write/forget/cause problems. Try not to listen too much to virtualdragon about that...  :)
2. 1/60 in your step call is integer division, it rounds to 0 so box2d thinks you want to do a time step equal to 0 seconds, that can't be good. ::) Change it to 1.f/60.f or 0.0166666667 and it'll work. Write .f after integer if you mean that it's a float that just happen to also be integer or things like that happen.
3. You should convert body position back into pixels in sprite.setPosition
4. You shouldn't tie your steps to framerate but I understand that's just a test here.
5. If you set origin of sprite to it's center then you CAN just do:
sprite.setPosition(bodyPos.x*M, bodyPos.y*M);

1819
Window / Re: Window Not Displaying?
« on: August 18, 2012, 12:40:56 am »
Add while(1); between return and display.
Or put display in loop or something else to stop return line getting executed just after display.
In no debug launching from vc++ the return; doesn't make console/process go away but the app is closed already so the window is gone.

1820
General / Re: Tilemap showing blue lines when moving sf::view - SFML 1.6
« on: August 17, 2012, 02:41:20 pm »
Do you poll all of your events asap?

1821
General / Re: sfml 1.6 sprite::GetSize equivalent?
« on: August 17, 2012, 01:42:36 am »
I guess it's mostly qeustion for Laurent but I guess it's kind of useless/feature bloat and in 2.0 the rect is defined by left,top,width,height so if you want to move it, it's just 2 changes to left and top and in 1.6 it was defined by left,top,right,bottom so moving it would take 4 changes to each of these, which is a bit much already.

Edit: Again it's very Laurent focused question BUT it seems extremely unituitive to have right and bottom instead of width and height. And it makes getting width and height in 1.6 a pain if you're not careful and use two methods(2 more methods = more feature bloat).

1822
Graphics / Re: sf::Font as static class member problem
« on: August 15, 2012, 11:05:48 pm »
That works too but it kind of abuses class slicing so..  :(
class MyFont : public sf::Font
{
public:
        MyFont(const std::string& font_to_load){loadFromFile(font_to_load);}
};
 

1823
Graphics / Re: sf::Font as static class member problem
« on: August 15, 2012, 10:40:01 pm »
I'm not sure but try removing sf::Font from
sf::Font CRender::openSans.loadFromFile("data/fonts/SourceSansPro-Regular.ttf");
You're not initializing that static sf::Font, you're calling one of it's methods.

1824
General / Re: box2d
« on: August 15, 2012, 07:31:06 pm »
1. Don't assume Box2d has y increasing towards the top, it's much easier this way.
2. #define or (preferably) make const floats to convert between pixels and meters, and radians and degrees to make your life easier.
3. Read sfml tutorials and documentation.
4. Read official user manual from box2d site.
5. Read this tutorials series, it's not for the latest version of box2d but changes are minor and it points out when something is done differently in latest version: http://www.iforce2d.net/b2dtut/

1825
Graphics / Re: Strange behaviour in SFML 2.0
« on: August 14, 2012, 10:55:08 pm »
The only mistake I could spot is:
  sf::Vector2u spriteSize(1.28f, 1.28f);
Unless that changed recently then your 1.28f is rounded down to 1(unsigned int) and then you perform int division 1/2 which is rounded down to 0 but that shouldn't affect the position.

Is your body and fixture of good size, maybe you're making too many world steps per second(like in this example, only thing capping your step rate is framerate)?
From Box2d user manual:
Quote
A variable time step produces variable results, which makes it
difficult to debug. So don't tie the time step to your frame rate (unless you really, really have to).
Are you absolutely sure that GraphicsComponent::UpdateSprite gets given good positions?
Maybe try capping this entire loop with sf::Clock so it runs in 60 fps constantly.

1826
General / Re: Can someoene help with loadFromMemory()
« on: August 12, 2012, 04:57:58 am »
I think that the first argument is supposed to point to array of RGBA pixels not image, image can give you the pointer to pixels it's storing, and second argument, size, is 4*amount of pixels.
So if you want to load from one image into other like that you should do:
sf::Image *image new sf::Image();
image->loadFromFile("file.png");

sf::Image image2;
image2.loadFromMemory(image->getPixelsPtr(),image->getSize().x*image->getSize().y*4);
 
Altho it's somewhat insane to dynamically allocate first image.
getPixelsPtr returns read only pointer but I'm not sure if image2 will make a deep copy for itself so you might want to mess with first image, delete it, ect. and see if the second one still works, or wait for Laurent to clarify that.  :)

1827
Graphics / Re: Slicing/extracting tiles from a grid of tiles
« on: August 11, 2012, 06:12:08 pm »
This code is storing texture once. Amount of sprites doesn't affect gpu memory. Sprites don't store textures, your code does. Sprites hold reference to texture and if texture gets out of scope they won't display properly anymore.

1828
Graphics / Re: Slicing/extracting tiles from a grid of tiles
« on: August 11, 2012, 06:05:32 pm »
This was an example.
Obviously no one does that.
sf::Texture tex;
tex.loadFromFile("whatever.tga");
std::vector<sf::Sprite> sprites;
for (int it=0;i<666;++it)
{
sprites.push_back(sf::Sprite(tex));
sprites[i].setTextureRect(insert rectangle here);
}
 

1829
Graphics / Re: Slicing/extracting tiles from a grid of tiles
« on: August 11, 2012, 05:56:58 pm »
You can have ONE and only ONE sf::Texture and assign it to each of 225 sf::Sprite s and then set each Sprite's rectangle.

1830
Graphics / Re: Slicing/extracting tiles from a grid of tiles
« on: August 11, 2012, 05:47:31 pm »
What? :o
Where is that stated?

Pages: 1 ... 120 121 [122] 123
anything