Topics

16

General / How to make your IDE output verbose build information

« on: August 07, 2013, 08:24:26 am »

OK... since the staple kind of thread in this subforum seems to be build related and most of the time too many questions have to be asked and/or not enough information is provided, I decided to write this tutorial thread for beginners who don't yet know how to force their compiler to output more useful information that can help them and us to resolve the problem.

Why do I want verbose output?

The idea is that, by default, most IDEs tend not to output the full command line that invokes the compiler and linker. All settings that are configurable through the GUI are ultimately passed on the command line to the compiler/linker. This means that you get to see all settings on possibly a single screen and it is easier to provide information in a forum post if required to do so.

Code::Blocks - all versions, all operating systems

First, open up your compiler settings window.


Go to the "Other settings" tab and change the "Compiler logging:" entry to "Full command line".


Try to build your project and change to the "Build log" tab when it completes.


Copy the output and paste it in your post.

Microsoft Visual Studio - 2008, 2010 and 2012, Microsoft Windows

First, open up your project properties window.


Make sure you selected the configuration you are trying to build. Open up the C/C++ -> General pane and change the "Suppress Startup Banner" entry to "No (/nologo-)".


Open up the Linker -> General pane and change the "Suppress Startup Banner" entry to "No".


Try to build your project.


Copy the output and paste it in your post.

Reminder

It is helpful to paste your log in [code][/code] tags to enable people to handle it easier. Not only does it avoid linebreaks, it is also displayed in a monospace font which makes it easier to read if it spans multiple lines.

17

Network / TCP packet corruption in non-blocking mode

« on: June 06, 2013, 09:17:20 pm »

Hi,

from these 2 threads
http://en.sfml-dev.org/forums/index.php?topic=11072.0
http://en.sfml-dev.org/forums/index.php?topic=11235.0
which have been ongoing for about the last 2 months, I investigated what could be the cause of Jungletoe's issues. At first I thought it might be something connection based but ruled that out after I checked the packet captures. It also wasn't his code because it was too simple to contain any unnoticeable errors. After a bit of testing, Jungletoe determined the errors only occured when transferring data in fairly large blocks (I believe > 2000 bytes) very rapidly which led me to check the buffering and unbuffering of data over a TCP connection using SFML. Normal byte-based data transfers were unaffected, however packet-based transfers were experiencing data corruption if they could not be queued for sending in non-blocking mode. I checked the SFML TcpSocket source and found the source of the error.

In high congestion scenarios the receive buffer of the remote host is full. The send buffer of the local host might be full or only partially full. This means that if the packet is large enough to not fit into the available buffer space, it won't be queued. However, due to the way SFML sends packets over a TCP connection, it sends the size of the packet first in a separate send() call. Because the size of the packet is generally 4 bytes large, chances are it will fit into the available space. The first send() call will thus not return any error or NotReady in non-blocking mode. When SFML tries to send the data, it will fail with NotReady and consequently forward the return value back to the user. The user thus has no way to determine whether the size was sent successfully or not. Most users will then proceed to retry sending the packet, however at the receiving side, the first packet size that was sent is already regarded as the beginning of a new packet and all the following data would be shifted by 4 bytes resulting in packet data corruption.

Here are examples that will cause this to happen. The packet size might have to be changed to be sure the buffer gets filled fast enough due to this being a synthetic scenario.

Sender:

#include <iostream>
#include <string>
#include <SFML/Network.hpp>

int main() {
        sf::TcpSocket socket;
        socket.connect( "12.34.56.78", 4422 );
        socket.setBlocking( false );

        sf::Uint32 counter = 1;
        sf::Clock clock;
        sf::Socket::Status status = sf::Socket::Done;
        sf::Packet packet;

        while( true ) {
                if( status != sf::Socket::NotReady ) {
                        packet.clear();

                        for( int i = 0; i < 4096; i++ ) {
                                packet << counter;
                                counter += 2;
                        }
                }

                status = socket.send( packet );

                switch( status ) {
                        case sf::Socket::Error:
                                std::cout << "Error\n";
                                return 1;
                                break;
                        case sf::Socket::Disconnected:
                                std::cout << "Disconnected\n";
                                return 1;
                                break;
                        case sf::Socket::NotReady:
                                std::cout << "NotReady\n";
                                break;
                        default:
                                break;
                }

                if( clock.getElapsedTime() > sf::seconds( 5 ) ) {
                        return 0;
                }
        }

        return 0;
}
 

Receiver:

#include <cstring>
#include <iostream>
#include <SFML/Network.hpp>

int main() {
        sf::TcpListener listener;
        listener.listen( 4422 );
       
        sf::TcpSocket socket;
        listener.accept( socket );
       
        sf::sleep( sf::seconds( 10 ) );
       
        sf::Packet packet;
        sf::Uint32 counter = 1;
       
        while( !socket.receive( packet ) ) {
                std::cout << "Dequeued packet of size: " << packet.getDataSize() << "\n";
               
                for( int i = 0; i < 4096; i++ ) {
                        sf::Uint32 value = 0;
                        packet >> value;
                        std::cout << value << "\n";
                       
                        if( value == counter ) {
                                counter += 2;
                        } else {
                                std::cout << "Packet data corruption!\n";
                        }
                }
        }
       
        return 0;
}
 

What you would get from the receiver output is something like:

Code: [Select]

...
8189
8191
Dequeued packet of size: 16384
16384
Packet data corruption!
8193
8195
...
16379
16381
Dequeued packet of size: 16383
16384
Packet data corruption!
16384
Packet data corruption!
16385
...

The fix I submitted for pulling concatenates the packet size and packet data into a single block for sending. That way, if the whole packet containing size and data cannot be sent atomically, any future retries will be handled properly at the receiver because no stray data is sent.

https://github.com/SFML/SFML/pull/402

18

General discussions / Updated Code::Blocks project wizard/template

« on: March 22, 2013, 01:13:36 pm »

Hi everyone,

since I had nothing to do recently, I just tried out creating an SFML project using the wizard provided with Code::Blocks (I have no idea when it was made). It is obviously so old that it doesn't work any more, so I took the opportunity to update it myself. Although I don't plan to use it, it might be of use to others.

You can now choose your link type (shared or static) on Windows and it will search for the corresponding library files. On Mac and Linux this makes no sense so only shared linkage is available on those platforms. You don't have to worry about setting SFML_STATIC because this is taken care of automatically as well.

In the default Debug target that it produces, the type is set to Console application. In the default Release target, the type is set to GUI application and sfml-main is also automatically linked in.

The whole idea was that you can create a project from the wizard and it works out of the box, and for most people they won't have to touch any of the configuration relating to SFML for the rest of the project.

I am not really sure whether the Mac part of the wizard still works or not because I don't own a Mac and thus could not test.

I provided the whole wizard directory in a zip. You need to delete the old sfml directory (yes delete it, overwrite is not enough because there is a .bmp that is not used any more) and unpack the new one into your wizard directory which you can find at: <CodeBlocks root directory>\share\CodeBlocks\templates\wizard.
If there was no sfml directory to delete, you will have to additionally add this line

Code: [Select]

RegisterWizard(wizProject, _T("sfml"), _T("SFML project"), _T("2D/3D Graphics"));
to the other lines in the config.script file in the wizard directory as well to register the sfml wizard with Code::Blocks.

Any ways, have fun.

[attachment deleted by admin]

19

General discussions / Broken stuff

« on: April 12, 2012, 09:55:57 pm »

Code: [Select]

#include <SFML/Graphics.hpp>

int main() {
sf::RenderWindow app_window( sf::VideoMode( 400, 300 ), "Ghost Square" );

sf::RenderTexture render_texture;
render_texture.create( 400, 300 );

while ( app_window.isOpen() ) {
sf::Event event;

while ( app_window.pollEvent( event ) ) {
if ( event.type == sf::Event::Closed ) {
app_window.close();
}
}

render_texture.draw( sf::RectangleShape( sf::Vector2f( 200, 200 ) ) );
render_texture.display();
render_texture.clear();

// Just to be sure.
render_texture.display();

// The RenderTexture SHOULD BE cleared to black here right?

render_texture.draw( sf::RectangleShape( sf::Vector2f( 100, 100 ) ) );
render_texture.display();

app_window.clear();

sf::Sprite sprite;
sprite.setTexture( render_texture.getTexture() );
app_window.draw( sprite );

app_window.display();
}

return EXIT_SUCCESS;
}
Hopefully it is obvious what is broken.

And at the same time you can fix https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/RenderTextureImplFBO.cpp#L56, c&p error I guess ^^.