Messages

31

Graphics / Rotated SubRect

« on: May 16, 2009, 09:14:20 am »

I'm packing several images into one texture for better performance. Currently I'm not rotating them, but if I rotate some of them in this packed texture I can fit more in each texture.

32

Graphics / Rotated SubRect

« on: May 16, 2009, 01:35:29 am »

I'm using a packed texture to hold my sprites, and some sprites are rotated.

Is there anyway to set the SubRect of the sprite so it reads in the rotated image correctly? I thought I could just reverse the top and bottom of the sub rect to make it work, but it seems to have no effect.

I know I can load the rotated image and then rotate the sprite, but then I'd have to keep adding 90 to any SetRotations I do later; it'd be a messy solution.

Thanks.

33

Graphics / Changing Image of a Sprite do not work

« on: April 08, 2009, 04:38:35 am »

I'm also using the library like Aval. I do several image changes, and I certainly don't want the sub-rect jumping around on me.

I think the rest of you guys should use Hiura's function, or use images of the same resolution. Isn't it kind of sloppy to be changing image resolutions anyway?

34

General / SFML and Box2D

« on: April 07, 2009, 07:18:14 am »

You should read the sf::View tutorial. Then I'd recommend making a view in your meter units.

So you might make a view with:
sf::View v(-5, 10, 5, 0);
To view an area 10 by 10 meters. Then when you draw your sprites, you can draw them in meters. So you'll have to really scale them down a lot. e.g. if you sprite is 100 pixels wide, but it represents and object 1 meter wide, you may scale it with by .01.

35

General / SFML and Box2D

« on: April 03, 2009, 06:58:16 am »

Let me give you a hint that would have saved me some time: SFML defines rotation as degrees going clockwise, Box2D uses radians going counterclockwise.

Other things to consider: It's nice for game logic to have the ground level be at 0. SFML, by default, has Y getting greater towards the bottom of the screen. You can either tweak the numbers yourself, or use a sf::View to mirror the Y. Also, in Box2D, you'll want sizes to be in meters, not pixels. Again, convert between by yourself, or just use a sf::View.

You may also want to consider Chipmunk, if you haven't. Box2D has many more features, but for collision detection you probably don't care about them.

What kind of game are you making?

36

Window / Question About SFML Internals

« on: March 31, 2009, 09:35:06 pm »

You may want to check out Benchmark : SDL vs SFML.

37

SFML projects / // TetriBattle3 100%™-3 Player Tetri_ - Win Beta85% + SOURCE

« on: March 30, 2009, 11:21:32 pm »

I played the game too. I guess I should have commented sooner.

It runs smoothly and works great. It's also kind of you to make the game open source.

Good work.


P.S. My only criticism is that a lot of your text seems inane and superfluous. Also, I think you've been told this before, but some of the symbols you're using have an actual meaning. Like the (R) means registered trademark, and you didn't actually register Silent Hero Productions. I don't think anyone will really care, but it just seems silly to use it.

Anyway, good work on the game.

38

Graphics / moving a sprite relative to another.

« on: March 28, 2009, 06:43:03 pm »

When you override the Render method, you draw only the lights in that function.

So your code may look like:

Code: [Select]

class Ship : public sf::Sprite
{
    public:
        Ship(const Image &Img,
        const Vector2f &Position=Vector2f(0, 0),
        const Vector2f &Scale=Vector2f(1, 1),
        float Rotation=0.f,
        const Color &Col=Color(255, 255, 255, 255))
            :Ship::Sprite(Img, Position, Scale, Rotation, Col)
        {
            //Load your light here and set its position relative to the ship.
            light = sf::Sprite(XXXXX);
        }

        virtual ~Ship()
        {}

    private:
        sf::Sprite light; //Stores the light to draw.

        virtual void Render(sf::RenderTarget& Window) const
        {
            Sprite::Render(Window); //Draws the ship.
            Window.Draw(light); //Draws the light.
        }
};
In your main loop, you then move, scale, rotate, and draw one ship object. The light will be moved along and drawn with it automatically.

39

Graphics / moving a sprite relative to another.

« on: March 28, 2009, 09:59:49 am »

One way to do it, is to make a space ship class that inherits from either sf::Drawable or sf::Sprite. Then override the Render method and do your drawing there. When the object is moved, scaled, rotated, etc, it will apply to everything drawn inside of that Render method too.

Otherwise, there is no easy way, other than just calculating it yourself. This would be a good reason for SFML to make the matrix class public.

Hmmm, since your case is so simple, the TransformToGlobal function may work. You would give it the local coordinates that you want draw on your ship's sprite, and it will give you the global (actually just up one in the hierarchy, which may happen to be global) coordinates.

40

Window / wxWidgets and sf::Input

« on: March 26, 2009, 08:47:58 am »

Thanks for the quick reply.

I'm sure that would work, but it seems like a bit of a hack. Besides, sf::Input is much nicer for what I'm doing, and I've already written a lot of code for it.

I think it should be possible for sf::Input to work with wxWidgets, I just need to figure out how. I still can't get the canvas control to accept focus, and I've tried everything I can think of.

41

Window / wxWidgets and sf::Input

« on: March 26, 2009, 05:47:58 am »

I'm using wxSFMLCanvas with wxWidgets. Drawing works great, but I'm having trouble getting input to work.

If I manually call wxWindow::CaptureMouse(), then mouse input will work, but it block mouse input to other controls.

I've noticed that I can't get the canvas to even accept focus.

Any help would be greatly appreciated.

42

Feature requests / Manually setting Z-order

« on: March 22, 2009, 08:18:57 pm »

The downside there, is that I'd have to control the movement manually of all the sprites. For example, I'd have to manually set the position of a "foot" sprite when the "leg" sprite moves.

I don't really understand the connection with Z-order... You'd have to move a "foot" anyway after moving the "leg", wouldn't you? And besides, you could automatize that...

In SFML, if you draw a sprite inside of another Render() call, it will inherit its parent's properties (scale, position, rotation). So basically, just by having one object own a sprite as a member, that is taken care of automatically, provided you don't care too much about Z-order.

That is all calculated on the graphics card, and it works the same way with 3D models. You can even nest many levels deep, like rotating a shoulder rotates an arm which rotates a forearm which rotates a hand... all automatically.

So now it looks like I'll have a person class that holds all of its body parts, instead of a person class only holding a torso (which in turn holds arms and legs, etc).

43

Feature requests / Manually setting Z-order

« on: March 21, 2009, 10:12:02 pm »

Sure, storing all the sprites and sorting by Z-order is probably best. I could probably just keep pointers to them in a std::set<> sorted by Z-order.

The downside there, is that I'd have to control the movement manually of all the sprites. For example, I'd have to manually set the position of a "foot" sprite when the "leg" sprite moves. The best way I see to do that is to override GetMatrix() and make it public, then just multiply the matrices together. However, if matrices might disappear in future versions, that scares me.

My other option is to treat SFML as just a pure rendering library, and not use it to store any position information. The would mean simply creating a new sprite every frame. It seems like a shame to duplicate all that though, and it might run slightly slower.

Hmmmm.

Thanks.

44

Feature requests / Manually setting Z-order

« on: March 21, 2009, 10:13:57 am »

Laurent, thanks for the definitive answer.

I'm still looking for advice then, from anyone, on workarounds. Should I implement my own scene graph? Are there decent libraries out there for that already?

45

Feature requests / Manually setting Z-order

« on: March 21, 2009, 04:35:55 am »

I'm working on my game again after a hiatus with another project.

This Z-ordering is still an issue for me. What is the best way to do what I'm looking for? If I draw in order, it seems that I'll have to forgo using nested Render() calls, which would be a shame. Any advice would be appreciated.

Surely other people have this problem. There must be a reasonable solution.

Why doesn't SFML allow arbitrary Z-ordering, though? It seems like it would be free, performance wise.

Thanks.