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

Author Topic: First impressions  (Read 4611 times)

0 Members and 1 Guest are viewing this topic.

Igonicol

  • Newbie
  • *
  • Posts: 2
    • View Profile
First impressions
« on: July 08, 2010, 11:22:30 am »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
First impressions
« Reply #1 on: July 08, 2010, 11:39:39 am »
Quote
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?

Quote
2. SFML does not support 1-bytepp bitmaps

Do you really need to use this format?

Quote
3. SFML Clock function return type is 'float'

So?

Quote
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.
Laurent Gomila - SFML developer

Igonicol

  • Newbie
  • *
  • Posts: 2
    • View Profile
First impressions
« Reply #2 on: July 08, 2010, 11:55:47 am »
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
First impressions
« Reply #3 on: July 08, 2010, 12:12:45 pm »
Quote
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.

Quote
Less convenient to deal with than with integers.

Why?

Quote
Growing inaccuracy over time.

Theoretically it is true, but I wonder if it is really noticeable.
Laurent Gomila - SFML developer

l0calh05t

  • Full Member
  • ***
  • Posts: 200
    • View Profile
First impressions
« Reply #4 on: July 08, 2010, 01:53:05 pm »
Quote from: "Laurent"
Quote
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

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
First impressions
« Reply #5 on: July 08, 2010, 02:09:51 pm »
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.
Laurent Gomila - SFML developer

l0calh05t

  • Full Member
  • ***
  • Posts: 200
    • View Profile
First impressions
« Reply #6 on: July 08, 2010, 02:32:38 pm »
Quote from: "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.


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

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32498
    • View Profile
    • SFML's website
    • Email
First impressions
« Reply #7 on: July 08, 2010, 02:42:07 pm »
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.
Laurent Gomila - SFML developer

Xorlium

  • Jr. Member
  • **
  • Posts: 84
    • View Profile
First impressions
« Reply #8 on: July 20, 2010, 03:50:12 am »
Mm, why not doubles?

l0calh05t

  • Full Member
  • ***
  • Posts: 200
    • View Profile
First impressions
« Reply #9 on: July 20, 2010, 08:18:02 am »
Quote from: "Xorlium"
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)