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.

Messages - Yours3lf

Pages: [1] 2 3
System / Re: Can't hide fullscreen window
« on: July 04, 2013, 03:25:33 pm »
oh well stupid me :D
thank you :)

System / Re: Can't hide fullscreen window
« on: July 04, 2013, 02:32:04 pm »
Well, stable means that the release is labeled as stable. Not as release candidate or something like that. (I know RC has been around for a while)
I'd need the stable labeling, because the lead programmer on our project only allows using such software :)

As for SDL, I will try it.

For now I solved the issue by caching the OpenGL resources in system memory, so that when I close the SFML window I still have the data around, and next time, I just need to re-upload the data.

System / Re: Can't hide fullscreen window
« on: July 04, 2013, 02:06:38 pm »
thanks for the replies!

@Hiura: I can't unfortunately :( I'm only allowed to use stable versions of software. Is SFML 2.0 stable already?
@Laurent: No way, I'm not going back to SDL :P

System / Can't hide fullscreen window
« on: July 02, 2013, 07:27:11 pm »

I'm trying to hide a fullscreen window I've created with SFML 1.6 (stable, Linux), but the window won't disappear. When I create a simple window (not fullscreen) it works fine.

here's what I'm doing:
//the_window is and sfml window, doesn't work like this
the_window.Create( sf::VideoMode( w, h, 32 ), "test", sf::Style::Fullscreen );

//this works
/*w = 800;
h = 600;
the_window.Create( sf::VideoMode( w, h, 32 ), "test", sf::Style::Titlebar | sf::Style::Close );*/

if( !the_window.IsOpened() )
  std::cerr << "Couldn't initialize SFML." << std::endl;
  exit( 1 );

sf::Event ev;
show(); //show the window
glClearColor( 1, 0, 0, 1 ); //fill with red
the_window.Display(); //display it
while( the_window.GetEvent(ev) ); //make sure events are processed
sf::Sleep(3); //the window should stay up for 3 seconds
hide(); //then disappear
while( the_window.GetEvent(ev) ); //process events again
show(); //show again, etc.
glClearColor( 1, 0, 0, 1 );
while( the_window.GetEvent(ev) );

while( the_window.GetEvent(ev) );

So basically for the full screen it shows up once, and it stays like that until I close the window (the_window.Close();)

Is this a bug in SFML? Or just how fullscreen windows work (in linux)?

Best regards,

Audio / Re: program crashes on exit
« on: November 02, 2012, 05:09:40 pm »
It's a known bug, that you can find in the (SFML) bug tracker.

ok, thanks!
waiting for the fix :)

Audio / program crashes on exit
« on: November 02, 2012, 11:26:57 am »

I wrote a small app that plays a music file. Now my problem is that when the app exits it crashes somewhere in ole32.dll...
This is confusing because csfml plays the audio fine...
But I think it is related to csfml somehow, as the app executes fine without playing the music.

here's the vs solution:

best regards,

Well, the relevant bit can be found in the OpenGL 4.2 specification appendix E.

So basically if you create a 3.3 context with the core profile set, then you'll only have the 3.3 functionality.
If you call older (removed from 3.3) functions such as glBegin() it will generate a INVALID_OPERATION error. Further errors will be generated if you call a core profile function with old parameters, such as glTexImage2D with GL_LUMINANCE as format.
If you create a 3.3 context with compatibility profile set, then you'll have the functionality of 3.3 and the functionality that is described by the GL_ARB_compatibility extension. This means that you can have the functionality of a 3.3 context AND of older versions. So calling glBegin() will not generate an error.
There is functionality that is only marked as deprecated, however it may still be present in the core profile. The forward compatible option enables you to remove these functions, thus create a context that is free of deprecated functionality.

This is great because the deprecated functionality is often more cumbersome to use, or slower, so this will force you to use the modern features of the api.

as for the debug context creation, here's the relevant specification:
it is meant to be used during application development, and they provide additional runtime checking, validation and logging functionality. It may include possible performance penalties. However the behavior of the debug contexts is implementation defined, so they may act as non-debug contexts.

I guess only people who understand what you're talking about should be interested in this, right? ;D
Well, yes. Anyone who considers OpenGL 3.x+ development.


I've made a small modification to the latest SFML snapshot that allows me to create a core profile context. It also allows me to create a debug context, or a forward compatible context.
Note that if you use this, then you need to explicitly ignore the OpenGL errors generated by GLEW. (due to depracated functionality usage)

So here's the code:
Code: [Select]
GlxContext.cpp around line 240

        if (glXCreateContextAttribsARB)
            int nbConfigs = 0;
            GLXFBConfig* configs = glXChooseFBConfig(m_display, DefaultScreen(m_display), NULL, &nbConfigs);
            if (configs && nbConfigs)

                int profile = GLX_CONTEXT_COMPATIBILITY_PROFILE_BIT_ARB;
                int flags = 0;
                  profile = GLX_CONTEXT_CORE_PROFILE_BIT_ARB;
                  flags |= GLX_CONTEXT_DEBUG_BIT_ARB;
                  flags |= GLX_CONTEXT_FORWARD_COMPATIBLE_BIT_ARB;

                // Create the context
                int attributes[] =
                    GLX_CONTEXT_MAJOR_VERSION_ARB, m_settings.majorVersion,
                    GLX_CONTEXT_MINOR_VERSION_ARB, m_settings.minorVersion,
                    GLX_CONTEXT_PROFILE_MASK_ARB, profile,
                    GLX_CONTEXT_FLAGS_ARB, flags
                m_context = glXCreateContextAttribsARB(m_display, configs[0], toShare, true, attributes);

            if (configs)

Code: [Select]
ContextSettings.hpp around line 35

struct ContextSettings
    /// \brief Default constructor
    /// \param depth        Depth buffer bits
    /// \param stencil      Stencil buffer bits
    /// \param antialiasing Antialiasing level
    /// \param major        Major number of the context version
    /// \param minor        Minor number of the context version
    explicit ContextSettings(unsigned int depth = 0, unsigned int stencil = 0, unsigned int antialiasing = 0, unsigned int major = 2, unsigned int minor = 0, bool profile = false, bool debug = false, bool forward = false) :
    depthBits        (depth),
    stencilBits      (stencil),
    majorVersion     (major),
    minorVersion     (minor),
    core_profile     (profile),
    debug_context    (debug),
    forward_context  (forward)

    // Member data
    unsigned int depthBits;         ///< Bits of the depth buffer
    unsigned int stencilBits;       ///< Bits of the stencil buffer
    unsigned int antialiasingLevel; ///< Level of antialiasing
    unsigned int majorVersion;      ///< Major number of the context version to create
    unsigned int minorVersion;      ///< Minor number of the context version to create
    bool core_profile;
    bool debug_context;
    bool forward_context;

With this now you can create a compatibility profile context:
(24 depth bits, 8 stencil bits, OpenGL 4.2 compatibility profile context)
Code: [Select]
sf::Window the_window;
the_window.create( sf::VideoMode( SCREEN_WIDTH,
                                       BPP ),
                                       TITLE, MODE,
                                       sf::ContextSettings( 24, 8, 0, 4, 2, false, false, false ) ); //relevant bit, notice the "false" parameters

Querying the video card gives the following result:
Code: [Select]
  std::cout << "Vendor: " << glGetString( GL_VENDOR ) << "\n";
  std::cout << "Renderer: " << glGetString( GL_RENDERER ) << "\n";
  std::cout << "OpenGL version: " << glGetString( GL_VERSION ) << "\n";
  std::cout << "GLSL version: " << glGetString( GL_SHADING_LANGUAGE_VERSION ) << "\n";

Vendor: ATI Technologies Inc.
Renderer: ATI Radeon HD 5670
OpenGL version: 4.2.11631 Compatibility Profile Context
GLSL version: 4.20

or if you want to create a core profile context:
(24 depth bits, 8 stencil bits, OpenGL 4.2 core profile context, with debug and forward compatible options)
Code: [Select]
sf::Window the_window;
the_window.create( sf::VideoMode( SCREEN_WIDTH,
                                       BPP ),
                                       TITLE, MODE,
                                       sf::ContextSettings( 24, 8, 0, 4, 2, true, true, true ) ); //relevant bit, notice the "true" parameters

This gives the following result:
Vendor: ATI Technologies Inc.
Renderer: ATI Radeon HD 5670
OpenGL version: 4.2.11631 Core Profile Forward-Compatible/Debug Context
GLSL version: 4.20

This modification only works on Linux for now, but you may implement it on Windows and OSX in a similar manner. The reason I didn't implement them, is that I don't have these OSs right now. I hope this will make its way into the core SFML.

Best regards,

General discussions / Re: New naming convention
« on: March 25, 2012, 09:13:38 pm »
you should definitely decide it now
Hum? It's decided, and it's changed now. So what do you mean?

I only meant that a naming convention should be chosen and sticked to, so that if now everybody updates to the new convention it will be consistent later on (and compatible with apps written with older versions of SMFL). But if you decided then it's cool :)

General discussions / New naming convention
« on: March 13, 2012, 08:17:57 pm »
Hi Laurent,

I've just checked out the new SFML snapshot with the new naming, and I just thought about posting about it when I saw this thread.

I've experienced other renamings in the past (in connection with SFML) so this didn't catch me off guard, and I don't want to tell you which convention to use, but you should definitely decide it now.

Personally I prefer the lower_case writing of everything, I don't even use Class names, I only like to use UPPER CASE for #define stuff, except header guards. For example:

Code: [Select]
#ifndef header_h
#define header_h

#define ZERO 0

const int global_variable = 1;

namespace a_name_space
  class a_class_name
       int this_is_a_long_variable;
      a_class_name() : this_is_a_long_variable( 1 )


and since I use KDevelop I can use its handy reformat source functionality, which lets me set up a personalized code look.

Also it has a nice auto-completion feature, so no matter what convention you use I'm perfectly comfortable with it :)

Another thing is function names, those should be made permanent as well.
For example the recent ShowCursor vs. setMouseCursorVisible
and sf::Timer::Reset vs Restart vs restart

I'm really looking forward to the stable SFML 2.0 :)

Window / cannot see window
« on: December 23, 2011, 01:10:36 pm »
Thanks, now it works :)

Window / cannot see window
« on: December 22, 2011, 07:57:23 pm »

I've just ported my app from Linux to Windows, everything went fine, except when I start the app I can't see the window it creates.
I suppose it does create the window successfully because when I switch to it it can recieve keystrokes, and I can also load in OGL stuff using the created context.

So I checked with winlister (http://www.nirsoft.net/utils/winlister.html) if the window is alive and stuff, and I found out that the position of it is [32767, 32767] (I guess it is pow(2, sizeof(unsigned short)*8) / 2 - 1). When I centered the window, it worked displaying everything, but I don't know how to make sure that it displays the window at [0, 0].

Best regards,

Audio / can't play music files
« on: December 17, 2011, 08:57:45 pm »
yup it was local :) now it's working, thanks Laurent :)

Audio / can't play music files
« on: December 17, 2011, 07:18:45 pm »
no I didn't but now I did and it works, it could play both the wav and the ogg files.

I took a look at the example's source, and the only difference was the while loop after you called music.play(). But shouldn't playing music create a separate thread?

anyways I changed my code to this:

Code: [Select]

sound_stream asound;


    while (asound.get_status() == sf::Music::Playing)
        // Leave some CPU time for other processes

        // Display the playing position
        std::cout << "\rPlaying... ";

and now it plays the song, but while it does I can't render the scene...
any ways to get around this?

Pages: [1] 2 3