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

Author Topic: We're close!  (Read 9062 times)

0 Members and 1 Guest are viewing this topic.

Jabberwocky

  • Full Member
  • ***
  • Posts: 157
    • View Profile
Re: We're close!
« Reply #15 on: November 29, 2014, 05:11:59 pm »
Good to know!

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10800
    • View Profile
    • development blog
    • Email
Re: We're close!
« Reply #16 on: December 08, 2014, 09:32:17 pm »
The last branch has been merged into master. If nobody finds any really critical issues with the current version, in the next few hours, the current HEAD will turn into the code base of SFML 2.2. :)

If you got some time, why not test the code base again?
« Last Edit: December 08, 2014, 09:42:02 pm by eXpl0it3r »
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/

FRex

  • Hero Member
  • *****
  • Posts: 1845
  • Back to C++ gamedev with SFML in May 2023
    • View Profile
    • Email
Re: We're close!
« Reply #17 on: December 08, 2014, 11:17:23 pm »
It's not much but my BLuaConsole still works.
(And so obviously SFML still compiles, links, works and all for me on Fedora 20 with GCC 4.8.)
Back to C++ gamedev with SFML in May 2023

Jesper Juhl

  • Hero Member
  • *****
  • Posts: 1405
    • View Profile
    • Email
Re: We're close!
« Reply #18 on: December 08, 2014, 11:47:41 pm »
Yeah.
Current master (aka 2.2 to be) is a great improvement over 2.1 - I like it (mostly).
There is one ugly blemish on the 2.2 release though; that's the lack of fixing the networking issue where a failure to send the whole buffer results in corruption.  You can't (won't) change the API in a 2.2 release, but what we have currently is *broken*.
I can think of one dirty workaround (may not apply to all OS's that SFML must support, but I'm throwing it out-there anyway) :
 When being asked to send N bytes of data, peek the underlying socket to see if the socket has enough buffer space for N bytes. If it does, then send() is likely to succeed and there is no problem - if not, just return false at once and don't send anything. If peeking at the buffer size says there's room for N bytes but send then still fails (or only sends some of the data), then put the bytes into an internal buffer, sleep 1ms and retry the send - yes, ugly and will block the caller, but since we can't change the API to say "We sent M bytes" until SFML 3.0 - it's the best we can do - and it's better than being completely randomly broken like currently (IMHO).
Apart from that SFML 2.2 looks good to go from my perspective.

eXpl0it3r

  • SFML Team
  • Hero Member
  • *****
  • Posts: 10800
    • View Profile
    • development blog
    • Email
Re: We're close!
« Reply #19 on: December 09, 2014, 07:56:00 pm »
Thanks alot FRex and Jesper Juhl for the final testing and also thanks again to everyone else who help test SFML! :)

There is one ugly blemish on the 2.2 release though; that's the lack of fixing the networking issue where a failure to send the whole buffer results in corruption.  You can't (won't) change the API in a 2.2 release, but what we have currently is *broken*.
Yes, we're aware of it and it's rather annoying, even more so that it couldn't be fixed for a new release, but we really couldn't delay SFML 2.2 longer, 1y and over 4month is just too long. Let's hope we get some workaround for 2.3 though! :)


Please continue the discussion around the release of SFML 2.2 over at the new thread: SFML 2.2 tagged in repository
Official FAQ: https://www.sfml-dev.org/faq.php
Official Discord Server: https://discord.gg/nr4X7Fh
——————————————————————
Dev Blog: https://duerrenberger.dev/blog/