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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - Tank

Pages: [1] 2 3 4
SFML website / Downtime of website
« on: March 19, 2019, 05:17:58 pm »
Hey guys,

today we experienced a DDoS attack at the server that's hosting this website. As a first measure, we are now blocking quite a lot of suspicious IP subnets.

If you or people you know experience connection issues, then please send a mail to tank at sfml-dev.org with your IP address, and we look into it.

SFML website / Planned downtime
« on: September 27, 2018, 09:21:56 am »
Hey guys!

Our last step for improving stability of the SFML website + connected services is — like explained a couple of weeks ago — moving to a new server. This will happen today and shortly.

During that time, the website and forums will not be available. We can't say exactly how long it'll take, but everything should be operational again in a couple of hours max.

See you on the other side! ;-)

SFML website / Maintenance
« on: July 24, 2018, 08:14:55 am »
Hello guys.

The server has a failing HDD which is just being replaced. It's difficult to find out which one of the 2 available is faulty, so we are replacing both.

As both HDDs form a RAID array, synchronization takes some time. Please be aware that the website will be unavailable a couple of times today. IRC will be available again when the whole process has finished.

I will announce further updates in this thread, as well through @sfmldev on Twitter.

Thanks and sorry for any inconvenience this might cause.

General discussions / SFML 2.3 released!
« on: May 09, 2015, 08:01:10 pm »
SFML 2.3

After months of hard work the SFML development team is pleased to announce the release of SFML 2.3 (Simple and Fast Multimedia Library).

The release contains many new features and bugfixes. Some highlights and important changes:
  • Added new events for handling high-precision scrolling.
  • Added support for OpenGL 3 core context creation.
  • Fixed several OpenGL and joystick issues and crashes.
  • Replaced GLEW with loader generated by glLoadGen.
  • Replaced libsndfile by Vorbis, FLAC and OGG native libraries.
  • Switched from Xlib to XCB.
  • Changed the SOVERSION to "major.minor".
  • Bumped back the OpenGL version requirement to 1.1.
  • Updated external dependencies (stb_image 2.02, FreeType 2.5.5).
You can find the full changelog, including detailed descriptions and links for all new features and bugfixes, here: http://www.sfml-dev.org/changelog.php#sfml-2.3
  • API: Compatible to all 2.x versions.
  • ABI: Possibly compatible to 2.3 and older, but not guaranteed.
Known issues:
  • Linux: sf::Event::Resized is also generated when the window is moved.
Visit http://www.sfml-dev.org/ for download instructions and extensive documentation. We hope you enjoy this release and would love to get some feedback in our forums!

SFML development / Unit tests
« on: August 26, 2014, 10:01:34 am »
Hey guys,

I finally had some time to add the Catch framework together with one unit test example to the repository. You can find it here: https://github.com/SFML/SFML/commits/feature/unittest

I've used the BDD style as I find it to be incredibly readable. I think we should agree on the style first before I continue writing tests. I don't want to change millions of test cases. ;)

General discussions / FindGLEW.cmake
« on: February 20, 2014, 11:04:23 am »

is it please possible to use the original (i.e. the one distributed with CMake) FindGLEW.cmake file? You guys use GLEW_INCLUDE_PATH where as the original one uses GLEW_INCLUDE_DIRS.

When SFML's cmake/Modules path is added to CMAKE_MODULES_PATH, CMake will always favor that  instead of the default one.

Deleting the file from the repository should do the trick.

System / sf::String obsolete?
« on: February 06, 2014, 02:23:17 pm »

when this commit was pushed, some guys in #sfgui started discussing about why sf::String is needed at all.

The only data member is a std::basic_string, which makes the class itself a pure proxy. The conversion functions for the Unicode stuff is implemented using free functions, so there's not really a need for sf::String anymore.

I'd therefore ask for a discussion about removing sf::String and simply using std::basic_string<sf::Uint32>.

You may also want to checkout an older thread that was about exactly the same problem.

SFML website / Statistics
« on: May 10, 2013, 08:17:56 am »
I'd like to ask for some website statistics:

- Average visitors per day (unique).
- Average downloads per day (unique, current version, grouped by operating system and architecture, also bindings).
- Total downloads (also grouped and bindings, per version).

Thanks. :)

SFML website / Doxygen default font color
« on: April 23, 2013, 07:49:25 pm »
The Doxygen CSS (not sure if it's the original) does not make sure that the font color is #000. That makes it unreadable for people having a dark background/light font color as default. See the attached image.

[attachment deleted by admin]

General discussions / Z ordering
« on: April 16, 2013, 10:39:23 pm »
Hello guys,

I recently faced the lack of a z ordering mechanism in SFML and want to start a little discussion about

  • the need of such a feature and
  • if it would be still in SFML's scope.

A brief overview of the problem

SFML's graphics module is written for 2D graphics. Although using an OpenGL backend, which is per se a 3D graphics API, it uses 2D vectors for all its high-level features.

One difference between 3D and 2D is that using the third dimension (depth), objects can be in front or behind other objects. That effect is also widely used in 2D applications/games to suggerate depth (e.g. the player in front of a fancy mountain parallax background).

To make objects appear in front of others, SFML makes use of overdrawing: Whatever is rendered last will overdraw what has been rendered before. That, in turn, means that you have to do the depth ordering (or z ordering) yourself, by taking care of the order you render your drawable things.

OpenGL (and other APIs) however offers a so called depth buffer, which will give exactly that task to the graphics processing unit. There are some special cases where you still have to take care of what you send first, but generally you don't have to pay that much attention anymore. The whole process gets easier and also (theoretically) faster.

My question is: Are there users (besides Nexus ;)) who already missed that feature badly? Laurent, would you consider z ordering to be in SFML's scope at all? If not, what can we do to externally extend SFML in a way to support that? (e.g. in extension libraries like Thor, which already has plenty of neat additional SFML candy)

SFML projects / Game Development Design articles
« on: November 14, 2012, 08:34:25 pm »
Hey guys,

I recently decided to do some writing work on some game programming topics. The first article is finished and I'd like to show it to you guys – articles that don't get read are quite useless. :)

Further articles will follow irregularly, when there's time and I'm in the "writing mood".

Feedback is very welcome. It would be interesting to know if the article is of any real help for you and if you'd like to see more of that sort about other topics.

WEBLINK: Game Development Design

Laurent: Not sure if this fits into the projects section, as it's not primarily targeted at SFML. Feel free to move it anywhere you like. :)

General discussions / Linking dependencies
« on: October 09, 2012, 04:13:37 pm »
Hi guys, hi Laurent,

I wanted to ask (again) about changing the way SFML links to dependencies. It has been discussed a bit in this thread already: http://en.sfml-dev.org/forums/index.php?topic=7602.0

When talking with some guys in #SFML (irc.boxbox.org) and ##MinGW (Freenode), and remembering the issues we had with SFGUI (double definitions at the linker stage, i.e. importing GLEW 2 times), I felt like bringing this back to the table again.

Let's identify the problem first: SFML itself links to libraries it's using, also internally only. Those libraries are provided as pre-built static libraries in the releases and also in the source snapshots/SCM.  When building SFML, it links those dependencies in, statically, i.e. the archives (/static libs) are packed into the final SFML library.

I think the main purpose of that is to ease using SFML, so that the user doesn't has to link to GLEW, OpenAL and all the other dependencies.

However, there are some problems that shouldn't be ignored and that can lead to severe errors and crashes under certain circumstances: If the target executable (i.e. the user program) imports the same dependecies that are already being defined in SFML, clashes might happen (especially when using different GLEW versions). Also the developer can't exchange the dependency, e.g. to upgrade to a later version. Both together can lead to severe problems when, for example, the ABI changes. In general the ODR (one-defition rule) seems to be violated.

The solution would be to throw away all target_link_libraries() calls in SFML's CMake scripts. However I'm not 100% sure if that works with MSVC too. Such a change would indeed require the end-user to link to all the deps himself, but in my opinion telling/teaching them the right way is better than going for an easy approach with accepting that fatal bugs might happen.

Graphics / sf::View::getTransform() flagged for internal use?
« on: August 28, 2012, 08:48:34 am »

is there a specific reason why the getTransform() member of sf::View is flagged for internal use in the documentation? Had someone asking on IRC how to transform a mouse coordinate into sf::View space, and using the view's transform for that seems to be quite natural for me. ;)

Graphics / sf::Sprite::setTexture() subrect behaviour
« on: August 24, 2012, 11:55:47 am »
When one calls sf::Sprite::setTexture( ..., false ) the first time (i.e. first time a texture is set), the subrect will be reset, even when that's not intended.

This can lead to problems when one's preparing the subrect before actually setting the texture the first time.

System / How to initialize sf::String with UTF-8-encoded data?
« on: April 02, 2012, 08:11:35 pm »

is it possible to initialize sf::String directly with UTF-8-encoded data?

Pages: [1] 2 3 4