Messages

196

Graphics / Re: Problem with RenderTexture's Position

« on: January 26, 2016, 08:55:52 pm »

Can you take a screenshot to show us what you're seeing? I ran your project with a few tweaks. I made it not fullscreen, changed the positions of the yellow and blue rectangles (to the top left, and the bottom right) so the issue would actually be visible.

Works just fine:


Changed code:

(click to show/hide)

using SFML.Graphics;
using SFML.Window;

class Program
{
    public static void Main()
    {
                RenderWindow renderWindow = new RenderWindow(new VideoMode(800, 600, 32), "Minimal Example", Styles.Default);

        RenderTexture renderTexture = new RenderTexture(800, 600);

        Sprite sprite;

        RectangleShape rectangle = new RectangleShape(new Vector2f(100, 100));
        rectangle.OutlineThickness = 5;
        rectangle.OutlineColor = Color.Black;

        renderTexture.Clear(Color.White);
       
        rectangle.FillColor = Color.Yellow;
        rectangle.Position = new Vector2f(0, 0);
        renderTexture.Draw(rectangle);

        rectangle.FillColor = Color.Red;
        rectangle.Position = new Vector2f(350, 150);
        renderTexture.Draw(rectangle);

        rectangle.FillColor = Color.Blue;
                rectangle.Origin = new Vector2f(100, 100);
        rectangle.Position = new Vector2f(799, 599);
        renderTexture.Draw(rectangle);
       
        renderTexture.Display();
        sprite = new Sprite(renderTexture.Texture);
        sprite.Position = new Vector2f(0, 0);
        renderWindow.Draw(sprite);
        renderWindow.Display();
        renderWindow.DispatchEvents();

        while (!Keyboard.IsKeyPressed(Keyboard.Key.Return))
            ;
    }
}

197

Graphics / Re: playing Animations or GIFs

« on: January 25, 2016, 04:52:56 pm »

https://github.com/lucidspriter/SpriterPlusPlus - official implementation

198

SFML projects / Re:creation - a top down action adventure about undeads

« on: January 06, 2016, 03:28:16 am »

Some sort of event/trigger system is the most reusable method I've seen for something like this.

199

SFML projects / Re: Selba Ward

« on: January 04, 2016, 10:15:57 pm »

There you go, make a sw::Quine SFML drawable!

200

Graphics / Re: Access violation when pushing into vector<std::unique_ptr<sf::Text>>

« on: January 02, 2016, 11:42:37 pm »

Can't tell what's going on without a minimal example.

201

General / Re: Linker undefined references

« on: December 26, 2015, 11:56:16 pm »

The SFML version you downloaded is not compatible with the compiler you're using (different versions, 4.x vs 5.x).

For that compiler, you'll need to compile SFML yourself (not difficult at all).

202

SFML projects / Re:creation - a top down action adventure about undeads

« on: December 17, 2015, 04:29:30 am »

^

Can even take it a step further and make a "game save editor" of sorts. That can help with debugging as well. Set the game to be at a certain level of completion or whatnot, and make sure the game loads and starts/runs fine, etc.

(Though, depending on game format, may be as simple as a bunch of checkboxes!)

203

General / Re: New to SFML, creating my own game and guidelines needed!

« on: December 12, 2015, 11:10:33 pm »

That would create/destroy an std::mt19937 every time that function is called though. Which isn't a very good idea, it's not small by any means. And recreating it generally loses the whole point of randomness.

An explanation: http://www.elbeno.com/blog/?p=1325

204

SFML projects / Re:creation - a top down action adventure about undeads

« on: December 05, 2015, 11:54:14 pm »

I just always use '\n'. Everything I've used except Notepad (which no one in their right mind uses for programming) parses it just fine.

205

Graphics / Re: Problem when resizing view to be same size as new window

« on: December 04, 2015, 11:41:03 pm »

Are you seeing what I'm seeing?

206

Graphics / Re: Problem when resizing view to be same size as new window

« on: December 04, 2015, 11:18:45 pm »

I'd try modifying the texture to be power of 2 dimensions.

Though, I made an interesting observation.

I ran your example with the image provided. I only changed the std::cout line to view.getSize().* instead, to see if there was something changing in the view.

The even/oddness of the view size is making the effect, and it's reproducible.

When the new width is odd, the sprite/texture gets shifted noticeably to the right a pixel or so.
When the new width is even, the sprite/texture gets shifted noticeably to the left a pixel or so.

If the current width is already even, and the new width is even, there is no movement, and the same goes for odd.

Same goes for the height.

What graphics card and driver do you have?

For reference, I'm on a GTX 970 with the 359.00 driver. (Tested on Windows 8.1, haven't tried it on Linux)

207

General / Re: Linking on Linux

« on: November 15, 2015, 07:20:11 pm »

You've mixed 32bit and 64bit libraries at some point it looks like. Previously at some point though it seems. I'd do a full clean and rebuild.

208

General / Re: Linking on Linux

« on: November 14, 2015, 11:00:47 pm »

gdi and winmm are Windows only.

209

Feature requests / Re: Int32 overloads for sf::Time *, /, *= and /= operators

« on: November 11, 2015, 11:20:26 pm »

Doxygen I can understand. I have some questions about your other points, but it's getting a bit off-topic!

For now, what about an implicit cast to sf::Int64?

That defeats the entire purpose of having a type-safe time class.
(btw: casts are strictly speaking explicit conversions)
[/quote]
Hmm. True, I guess you guys want sf::Time to be more than just a "unit conversion class" of sorts. Makes sense. (And thank you for the wording correction.)

210

Feature requests / Re: Int32 overloads for sf::Time *, /, *= and /= operators

« on: November 11, 2015, 09:47:43 pm »

The true solution would be a template based on std::is_integral and SFINAE or tag-dispatching. But I don't really like that for something so simple (and I'm sure Laurent does so even less )

Why would it be an issue for something so simple? It's a simple problem, so why not use a simple solution? (minus the waiting for C++11/14/17 though)


For now, what about an implicit cast to sf::Int64? Though, an overload for operator= (or overloaded constructor) would be needed as well.

Here's what I thought:

Time& operator=(Int64 i);

operator Int64() const;

Then that would allow arithmetic with whatever sf::Int64 can work with, and since sf::Time uses sf::Int64 internally, it should(?) work out.

That would allow people to do sf::Time a(5) and wanting 5 seconds, but I think that would be their fault for not reading the docs on what time unit the constructor expects. And I don't think that this would cause any compatibility issues (correct me if I'm wrong though!).