First impressions

[Igonicol]

I converted over from SDL using OpenGL to try SFML and the following 3 things presented themselves:

1.  SFML does not support the 'PrtScrn' key

2.  SFML does not support 1-bytepp bitmaps

3.  SFML Clock function return type is 'float'

Otherwise the initialization was much less code than SDL.

I'm not sure how to handle double buffering or as it relates to the RenderWindow.Display() function

[Laurent]

1. SFML does not support the 'PrtScrn' key

True, but why do you want to use this key for something else than printing the screen?

2. SFML does not support 1-bytepp bitmaps

Do you really need to use this format?

3. SFML Clock function return type is 'float'

So?

I'm not sure how to handle double buffering or as it relates to the RenderWindow.Display() function

Double buffering is handled automatically, you don't have to do anything.

[Igonicol]

1.
I see that PrtScrn actually works when using SFML (with SDL it would not copy a screencapture to the clipboard) which is nice.
My program however has a function to save a .bmp in the application directory when 'PrtScrn' is pressed.  So I don't want to use it for something other than taking a screenshot, but I wanted to have this functionality associated with it.  However, since the OS PrtScrn functionality seems to still work, this is acceptable.

2.
No, but it makes for smaller filesize by a factor of 4.  I suppose if it was necessary I would write my own saving and loading scheme for 1-bit per pixel which is the format for glDrawBitmap();

3.
Less convenient to deal with than with integers.  Growing inaccuracy over time.

[Laurent]

No, but it makes for smaller filesize by a factor of 4

Another option is to use PNG instead of BMP.
Anyway, SFML uses an external library for loading images, so I can't add support for more formats.

Less convenient to deal with than with integers.

Why?

Growing inaccuracy over time.

Theoretically it is true, but I wonder if it is really noticeable.

[l0calh05t]

Growing inaccuracy over time.

Theoretically it is true, but I wonder if it is really noticeable.

With a floating point accumulator this can quickly turn into a problem, especially for a game server, since beyond ~4 hours millisecond precision becomes impossible and any time delta information below that precision will be lost as well, causing drift. This does not happen with integer accumulators, but if using an integer accumulator, recieving the deltas in integer format is definitely "easier". Personally I'd avoid floats for time as well, even if it usually isn't  a problem.

[Laurent]

So, you say that ~4 hours is the limit for safely storing milliseconds in a float? In other words, numbers higher than ~14400000 may not be accurately stored in a 32-bits float?

If the limit is that low, I agree that this is a problem.

[l0calh05t]

So, you say that ~4 hours is the limit for safely storing milliseconds in a float? In other words, numbers higher than ~14400000 may not be accurately stored in a 32-bits float?

If the limit is that low, I agree that this is a problem.

Well, it's actually 4.66 hours and numbers higher than 16777216, but yes, that's the problem.

[Laurent]

Ok, thank you for the information.

In fact, I already thought about switching to integers, but I was not really convinced/motivated. At least now I have a good reason to do it.

[Xorlium]

Mm, why not doubles?

[l0calh05t]

Mm, why not doubles?

Why doubles?

Every timer, on every system returns an integer in the first place, there is no reason to convert it to a floating point type. btw, even when using a 32 bit integer which will still have precision worth only a couple of days, if you handle the wraparound, you also never lose precision. with 64 bit ints you might as well count in nanoseconds, as it will still last for centuries (doubles: 104 days at nanosecond precision)