Topics

1

General / VisualStudio and STL debug settings

« on: February 24, 2012, 10:42:19 am »

While trying to install and integrate Assimp with SFML, I stumbled upon this post concerning STL in recent Microsoft compilers and that the debug checks are apparently also active in release mode:
http://assimp.sourceforge.net/lib_html/install.html

In VC8 and VC9 Microsoft has introduced some STL debugging features. A good example are improved iterator checks and various useful debug checks. Actually they are really helpful for debugging, but they're extremely slow. They're so extremely slow that they can make the STL up to 100 times slower (imagine a std::vector<T>::operator[] performing 3 or 4 single checks! scary ...).
These security enhancements are - thanks MS! - also active in release builds, rendering ASSIMP several times slower. However, it is possible to disable them by defining
_HAS_ITERATOR_DEBUGGING=0
_SECURE_SCL=0
in the preprocessor options (or alternatively in the source code, just before the STL is included for the first time).
If you're linking statically against ASSIMP: Make sure your applications uses the same STl settings! If you do not, there are two binary incompatible STL versions mangled together and you'll crash.

And here is some information from Microsoft about this:
http://connect.microsoft.com/VisualStudio/feedback/details/524141/serious-bug-when-using-secure-scl-0-c

When changing _SECURE_SCL from its default setting, certain rules need to be followed. These rules are logical consequences of the fact that _SECURE_SCL changes the representations (including the sizes) of STL objects.

The first rule is that _SECURE_SCL must be consistently set throughout each translation unit (a translation unit is a source file and all of its included header files, which is compiled into an object file). That is, _SECURE_SCL can't be changed in the middle of a translation unit. The easiest way to follow this rule is by defining _SECURE_SCL on the command line (or in your project settings) instead of in source files/header files. (This rule is being followed by your case; I mention it for completeness.)

The second rule is that _SECURE_SCL must be consistently set in all of the object files that are linked into a single binary (EXE or DLL). Mismatch will be not detected by the VC8/VC9 linker, and will cause incomprehensible crashes. (In technical terms, _SECURE_SCL mismatch is a One Definition Rule violation.)
The second rule applies to static libraries (which are simply packages of object files).

Question: does this affect SFML in any way? I suspect if I link the standard ASSIMP library (which was compiled with both flags set to 0), it will crash with the SFML libraries as they were compiled with these flags set to their default settings of 1. Anyone already has experience with this?

2

Feature requests / text alignment for sf::Font

« on: January 20, 2012, 11:08:02 pm »

I quickly thought about vertical and horizontal alignment of text (left, center, right / top, center, bottom) and fiddled around with the sf::Text class.

Here is what I came up with:

In Text.hpp I added some more style flags for alignment:

Code: [Select]


enum Style
{
 Regular    = 0,      ///< Regular characters, no style
 Bold       = 1 << 0, ///< Bold characters
 Italic     = 1 << 1, ///< Italic characters
 Underlined = 1 << 2,  ///< Underlined characters
 AlignHCenter = 1 << 3,
 AlignHRight  = 1 << 4,
 AlignVCenter = 1 << 5,
 AlignVBottom = 1 << 6
};


And in Text.cpp I added the following lines to the end of UpdateGeometry():

Code: [Select]


// Recompute alignment
bool alignHCenter = (myStyle & AlignHCenter) != 0;
bool alignHRight = (myStyle & AlignHRight) != 0;
bool alignVCenter = (myStyle & AlignVCenter) != 0;
bool alignVBottom = (myStyle & AlignVBottom) != 0;
float w = 0.0f;
float h = 0.0f;
if (AlignHRight) w = myBounds.Left + myBounds.Width;
else if (AlignHCenter) w = 0.5f * (myBounds.Left + myBounds.Width);
if (AlignVBottom) h = myBounds.Top + myBounds.Height;
else if (AlignVCenter) h = 0.5f * (myBounds.Top + myBounds.Height);
for (unsigned int i = 0; i < myVertices.GetVertexCount(); i++)
{
 myVertices[i].Position.x -= w;
 myVertices[i].Position.y -= h;
}


This allows you to output text aligned relatively to its x/y position in both vertical and horizontal directions by using SetStyle.
For example for right and bottom aligned text:

Code: [Select]


mytext.SetStyle(AlignHRight | AlignVBottom);


I don't know if this is of use for anyone, just wanted to share this if maybe someone wondered as well if or how this could be done. :-)

3

Window / SMFL2: proper handling of 2 simultaneous keypresses?

« on: March 23, 2010, 11:37:05 pm »

Hi!
I am using SFML2 and I am having a problem with GetInput().IsKeyDown() when two keys are pressed simultaneously, in my case the "Left" and the "Up" arrow keys:

In my code I use the following lines:
...
bool key_l=window.GetInput().IsKeyDown(sf::Key::Left);
bool key_u=window.GetInput().IsKeyDown(sf::Key::Up);
...

Now when I press the left and up arrow simultaneously, both bools above will be set to true (correct), but releasing both keys causes only the key_u to be set to false, not the key_l, which will then stay forever in "true" (not good for a jump n run, obviously :-)

Seems to happen only with specific key combinations though. Dunno, maybe it is my computer, but can I do anything about it?

Thx,
Toby

4

Graphics / SFML2: SetZoom in View?

« on: March 17, 2010, 01:08:23 pm »

Sorry, but upon quick glance at the SFML2 view functions, I can only see the Zoom() function for setting a zoom factor relative to the current one, but no SetZoom() function for setting an absolute one. Did I miss something or is it really not there?
For position change, Move() for relative change and SetPosition() for absolute change seems to work fine for example.

Also I noticed that I have to call "App.SetView(View);" after each change to zoom or position change of a view, else the view won't adapt to the changes. In the tutorial on this site for views it is mentioned that changes will be applied automatically? No big deal though, as I have to change/switch the view anyway several times during a frame update.