Messages

31

Graphics / Re: how to render line with SFML?

« on: December 03, 2015, 08:46:45 am »

I got it

Code is here:

        public static void DrawLine(this RenderTarget target, Vector2f start, Vector2f end, float thickness, Color color)
        {
            var dv = end - start;
            var dl = (float)Math.Sqrt(dv.X * dv.X + dv.Y * dv.Y);
            var uv = dv / dl;
            var up = new Vector2f(-uv.Y, uv.X);
            var offset = up * (thickness / 2F);
            var array = new[]
            {
                new Vertex(start + offset, color),
                new Vertex(end + offset, color),
                new Vertex(end - offset, color),
                new Vertex(start - offset, color),
            };
            target.Draw(array, PrimitiveType.Quads);
        }
 

So simple primitive and so complicated code with SFML...

32

Graphics / Re: how to render line with SFML?

« on: December 03, 2015, 07:51:11 am »

Can you help me with example. I have two Vector2f for start and end points. How to calculate rectangle position and angle?

33

Graphics / [SOLVED] how to render line with SFML?

« on: December 03, 2015, 01:01:13 am »

I need to render simple line from point V1 to point V2 with thickness N.
How can I do it with SFML?

I know about Window.Draw with primitive type Line, but it render one pixel line. I need to specify line thickness.

34

Graphics / Re: Is there any way to eliminate aliasing?

« on: December 02, 2015, 06:48:11 am »

It seems that AA is a problem here. Because AA=16 leads to moire effect for dynamic objects.
I can eliminate it by decreasing AA level, but it leads to aliasing.
So it seems that there is no way to render lines with no moire and aliasing artefacts...

35

Graphics / Re: sf::Clock and SetThreadAffinity

« on: November 18, 2015, 05:59:01 pm »

After how many countless people have been using SFML and these functions for years and not a single person has claimed there is an issue and now you want to make the OP believe there are problems?

using some code with obvious bugs by many peoples is not indicate that there is no bug 

At least this bug with QPC and using SetThreadAffinity has been discussed by thousands of experienced game developers on forums. It's not just my opinion. It's investigation of many experienced peoples who works on commercial projects.

The best solution to resolve inconsistent values returned by QPC on machine where QPC uses RDTSC is to avoid using QPC from different threads. Another solution is to install patch which will switch QPC to use system timer instead of RDTSC. By the way this problem is not relevant for nowadays CPU. But by using sf::Clock which uses SetThreadAffinity you will add hidden problems into your code.

PS: just visited link from SFML source code (where solution with SetThreadAffinity was taken) and here is a comment from author of this solution:

Thomas Lee: SetThreadAffinityMask is wrong
 

So, even author of this solution has accept that it's wrong solution. But it still not removed from SFML 

36

Graphics / Re: sf::Clock and SetThreadAffinity

« on: November 18, 2015, 05:56:39 pm »

Wait but the official SFML FAQ says to use sf::Clock.
But yeah I'm not sure if it would make a huge difference or not.

it's because they believe that lags added by SetThreadAffinity is ok. But if you want to eliminate such unpredictable lags and possible deadlock, don't use sf::Clock until they will fix it by remove SetThreadAffinity call.

37

Graphics / Re: sf::Clock and SetThreadAffinity

« on: November 18, 2015, 05:44:10 pm »

Alright what about the last question in my last post about vsync and setting the frame limit?
Should I just enable both or just one?

you should enable only one, but you also need to setup both values (if you enable one, then set disabled other), because there is a bug in SFML.
The bug is that if vertical sync is enabled, and you didn't call to SetFrameLimit(0), it will cause lags and jitter of frame rate.

This example will cause lags and movements will not be smooth:

SetVeticalSyncEnabled(true);
 

and this one will works good:

SetVeticalSyncEnabled(true);
SetFrameLimit(0);
 

This bug at least reproduced on CSFML 2.3.

Also notice that different dispay has different refresh rate. For example my samsung LCD has 75 Hz refresh rate. So, you need to call SetFrameLimit with exactly physical refresh rate to get smooth movements.
If you call SetFrameLimit(60) for 75 Hz display it will cause jitter movements on the screen.

38

Graphics / Re: sf::Clock and SetThreadAffinity

« on: November 18, 2015, 05:38:39 pm »

if you really think there a bug then report it properly instead of randomly posting and polluting people's threads with off topic information. I will not start a discussion here about why stuff is working correctly.

I found here 2 bugs:
1) If you want to make sure that your code is executed on specified CPU core, call to the SetThreadAffinity is not enough. Because SetThreadAffinity will not switch CPU core immediately. It will still works on the same core at least till the end of current time quantum. So, there is need to add sleep(0) just after SetThreadAffinity to make sure that the next instruction will be executed on specified CPU core.

There is no call to sleep(0) in the ClockImpl::getCurrentTime().

2) Even if you lock the thread to one processor using SetAffinityMask, QPC can run backwards if you're really unlucky and the hardware sucks. Better to just deal with the case of QPC returning bad values. Because it will not add time lag required to thread context switch.

So, using SetAffinityMask will not fix an issue with different QPC values on differen CPU core. But it will add some lag on each call to sf::Clock.

Also, if you're set the thread affinity, you can deadlock yourself, introduce weird timing and performance bugs, and generally cause yourself grief.

39

Graphics / Re: sf::Clock and SetThreadAffinity

« on: November 18, 2015, 05:00:45 pm »

Try to not use sf::Clock, it has a bug inside (call to setthreadaffinity), so it may cause lags

You know what? I am really getting sick of you posting crap like this around the forums. There is no bugs at all with any of the timing classes, and if there is make a proper report instead of making random replies to threads.

Just use QueryPerformanceCounter instead of sf::Clock.

Just... *facepalm* There is so much messed up in your statements I don't even know where to start.

sf::Clock uses SetThreadAffinity, so it's the reason why it will cause measurement lags and deadlocks.
Microsoft never uses SetThreadAffinity with QueryPerformanceCounter in their code and there is no recommendations to do so stupid thing.

And it's the reason why I'm talking about this issue.
So, what is your reason for "Just... *facepalm*"? 

40

Graphics / sf::Clock and SetThreadAffinity

« on: November 18, 2015, 04:44:51 pm »

Oh god, setting it to fullscreen made all of my windows go to my right monitor, and disabled aero theme.
I also didn't even see my game I just saw a hugely zoomed in version of my desktop.

Force closed it and nothing responded for around 10 seconds.

Don't want to do that again.

So yeah still not sure what to do about the stuttering.

Try to not use sf::Clock, it has a bug inside (call to setthreadaffinity), so it may cause lags.

Just use QueryPerformanceCounter instead of sf::Clock.

Also, add setverticalsync call. It should be called together with setframelimit, because there is a bug in SFML. So if you're using vertical sync enabled, then don't forget to call setframelimit(0)

41

Window / Re: Window resizing?

« on: November 18, 2015, 09:07:33 am »

Just use View and set it's size to window size at beginning of render loop

How is that better than doing it only when the Resized event is triggered, ie. only when it makes sense?

I think that it's better because the code will be short and transparent, it will be better to understand, because it means that view size is always the same as window size

42

Window / Re: Window resizing?

« on: November 17, 2015, 02:37:10 am »

Just use View and set it's size to window size at beginning of render loop. That's all what you need. So you don't need to handle resize event, because your view size will be always correct, even when resize event will not be raised

43

Graphics / Re: Is there any way to eliminate aliasing?

« on: November 16, 2015, 09:40:25 pm »

I'm curious, can you show the result that you get with native 16x AA?

yes:


I magnified it for 4x (with no interpolation of course).
As you can see, there is difference between lines, but actually all they rendered with one call to the RenderWindow.Draw function with the same color. In action it looks much more ugly, because all these artifacts jumping from one line to another and it looks terribly, especially with black background.

PS: just tried to round vertex coordinates to integer and it definitely looks much better, but with some  specific zoom factors, aliasing still exists. I see moire effect with moving view position and zoom.

here is screenshot with integer vertex coordinates (zoom and position is different with previous screenshot, because it's changed everytime)

44

Graphics / Re: Is there any way to eliminate aliasing?

« on: November 15, 2015, 09:42:06 pm »

All those solutions requires direct access to opengl functions. I'm using sfml.net and don't want to inject opengl code into my code. And all those solutions is a bit complicated. I just need to render simple line. So, why I need to implement those shaders, triangulation and complicated render code?

45

Graphics / Is there any way to eliminate aliasing?

« on: November 15, 2015, 01:25:53 am »

I'm already using AA=16, so there is even fonts looks a little blurry.
But when I drawing lines with RenderWindow.Draw (with PrimitiveType.Lines) and change View zoom and position, the result is still aliased. It looks very ugly and each line jumps from pixel to pixel when view position or zoom is changed.
So, how can I draw antialiased lines?