Topics

1

Graphics / sf::Shader::setUniform with bool parameter -> bug source?

« on: November 01, 2016, 11:28:58 am »

First off, let me say I love the improvements in SFML 2.4.0, nice upgrade compared to 2.3.x on the shader interface.

However, I just spend half an hour trying to find out why my shader was not rendering with a texture. I finally found out that I was passing an sf::Texture pointer instead of a reference to the setUniform function. And, as C++ does implicit type conversions of pointers to booleans, it was calling the setUniform(name, bool) instead.

With all the new setUniform functions, maybe setUniform(name, bool) is a bit out of place due to the very easy mistake of implicit pointer casts of all the other objects you can pass as parameters to this function.


Possible ways to prevent this problem are:

• Make the setUniform for bool more explicit -> setUniformBool. But this breaks with the rest.
• Add a private setUniform(string name, void*), so the pointer gets implicit cast to a void pointer and thus throws a compile error.
• Tell idiots like myself to depend less on pointers.

(I know I should prefer references. But that is not always a possibility in this case)

EDIT: I just realized. This is also inconsistent with the sf::Texture::bind API, which uses a sf::Texture pointer instead of a reference.

2

Audio / Rare crashes in shipped OpenAL dll

« on: September 03, 2016, 09:48:27 am »

Simply put, I'm having this issue:
https://github.com/daid/EmptyEpsilon/issues/390

For the last year, my project at http://emptyepsilon.org/ has been growing in the amount of users. But 1 problem seems to persist, depending on the user, I'm getting random crashes in OpenAL.
I've noticed that for the users that do not have this problem, there is actually a different OpenAL.dll in windows/system that is being used instead of the one provided with SFML.

I don't have a specific code example that is triggering this, after all, this is a rare crash. But my code that does sound isn't that complex. It runs a single sf::Music and a maximum of 16 sf::Sound items. The sf::SoundBuffer objects are not moved around in memory. Everything is allocated in the heap. The sf::Music and sf::Sound objects are allocated on start. Everything is single-threaded.
I mixing positional sounds and non-positional sounds.

https://github.com/daid/SeriousProton/blob/master/src/soundManager.cpp



In the end, I cannot think of anything I did wrong in my code anymore. And the problems seems to be gone with a different OpenAL library of which I don't know the origin.
But I don't know the origin of this OpenAL library beyond the fact that they are in the SFML repository and not updated for a while.

3

Network / Problem with sf::UdpSocket::Send with sf::IpAddress::Broadcast on Windows + fix.

« on: July 19, 2015, 09:10:57 am »

Discovered and worked around this issue a while back. But putting it here for reference.

When using sf::UdpSocket::Send with the target address of sf::IpAddress::Broadcast on windows. You would expect the UDP packet to be broadcast to the whole network you are connected to. However, this isn't happening. What is happening is that it is broadcast on the first enabled network adapter. And nothing else. This is extremely evident when you are connected to both wifi and wired network, or have VirtualBox virtual networks setup.

The end result is that local server discovery did not always for for me. Now, even with this fixed (fix below), broadcasting on windows only works if the network is not classified as "public network". So for the broadcasting server discovery implementors out there, I do recommend you broadcast both ways, from the server to let them know you are there, and from the clients to let them know you are looking for a server. This gives the highest chance of success.

The fix isn't that complex to code. You need to iterate on all networks, and broadcast your packet per network:

#ifdef _WIN32
#include <winsock2.h>
#include <iphlpapi.h>
#endif
[code]

[code=cpp]#ifdef _WIN32
    //On windows, using a single broadcast address seems to send the UPD package only on 1 interface.
    // So use the windows API to get all addresses, construct broadcast addresses and send out the packets to all of them.
    PMIB_IPADDRTABLE pIPAddrTable;
    DWORD tableSize = 0;
    GetIpAddrTable(NULL, &tableSize, 0);
    if (tableSize > 0)
    {
        pIPAddrTable = (PMIB_IPADDRTABLE)calloc(tableSize, 1);
        if (GetIpAddrTable(pIPAddrTable, &tableSize, 0) == NO_ERROR)
        {
            for(unsigned int n=0; n<pIPAddrTable->dwNumEntries; n++)
            {
                sf::IpAddress ip(ntohl((pIPAddrTable->table[n].dwAddr & pIPAddrTable->table[n].dwMask) | ~pIPAddrTable->table[n].dwMask));
                socket.send(packet, ip, port_nr);
            }
        }
        free(pIPAddrTable);
    }
#else
    socket.send(packet, sf::IpAddress::Broadcast, port_nr);
#endif

And you need to link to "iphlpapi" as well for the GetIpAddrTable function.

4

SFML projects / EmptyEpsilon - Spaceship bridge simulator.

« on: July 18, 2015, 11:24:19 pm »

For about a year now. I've been working on this hobby project of mine. Or, ours so to say.

It's a spaceship bridge simulator. It's a bit like star-trek, where you gather your friends to play a starship bridge together.

We totally stole the idea from Artemis: http://www.artemis.eochu.com/
But we didn't like some of the shortcomings of that implementation. So. Programmer that I am, I wrote my own version. And thanks to SFML, that was quite doable.

The game is free and open-source (except for some of the 3D assets).
It can be downloaded from:
http://emptyepsilon.org/

We play it with touch screen setup in consoles like this:

(old photo, now we have 5 touch screen consoles, painted white)


As for the code, it's available from:
https://github.com/daid/EmptyEpsilon (game code)
https://github.com/daid/SeriousProton (engine code)

As of the last week, I've been trying to get the Android version to run. With already some success. So that's why I'm visiting this forum a bit more frequent.

As for the code itself, it's a bit of a mess in some places, nothing is documented. But there are some cool things in there. For example, I'm using basic SFML rendering primitives and the stencil buffer to do masking:
https://github.com/daid/EmptyEpsilon/blob/master/src/screenComponents/radarView.cpp#L129


Main screen for your viewing pleasure:

The radar at the top right is masked with the above stencil buffer code.

5

General / [Android] Best way to handle sf::Event::LostFocus and sf::Event::MouseLeft

« on: July 18, 2015, 10:19:07 pm »

A bit of searching let me to the following. On Android, SFML currently generates the following events:
* sf::Event::LostFocus when the main window is destroyed, but the Activity is still active
* sf::Event::MouseLeft when the application needs to "pause"

The pause is clear to me, explained quite well here: http://developer.android.com/training/basics/activity-lifecycle/pausing.html
But I have no idea when the main window is destroyed but the activity keeps being active.

Right now, my application does not handle these events yet. And this caused my application, while not being visible, to drain my phones battery over night.


Now, I could just go into a sf::Window::waitEvent() loop till I get the corresponding "counter" event. But if I look at the code:
https://github.com/SFML/SFML/blob/master/src/SFML/Window/WindowImpl.cpp#L128
It seems that waiting for an event still causes the application to live 100x per second. Which does not feel that good for battery life.


So I'm not sure what's the best way to handle is. Just close the application on sf::Event::LostFocus? And "wait-loop" on sf::Event::MouseLeft?

6

System / [Android] Crash when trying to open none-exsisting asset. sf::InputFileStream

« on: July 15, 2015, 07:20:51 pm »

I think I've finally run into something while trying to port my code to Android which I really think is an SFML bug.

Getting this backtrace:

signal 11 (SIGSEGV), code 1 (SEGV_MAPERR), fault addr 00000000
Stack frame #00  pc 00008f60  /system/lib/libandroid.so (AAsset_getLength+1)
Stack frame #01  pc 0000873f  /data/app-lib/eu.daid.emptyepsilon-2/libsfml-system.so (sf::priv::ResourceStream::tell()+18): Routine sf::priv::ResourceStream::tell() at ??:?
Stack frame #02  pc 00007c63  /data/app-lib/eu.daid.emptyepsilon-2/libsfml-system.so (sf::FileInputStream::open(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&)+38): Routine sf::FileInputStream::open(std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) at ??:?
 

https://github.com/SFML/SFML/blob/master/src/SFML/System/Android/ResourceStream.cpp#L45
Can clearly result in m_file being a nullptr when the file is not found.

And the asset manager functions don't do any pointer checks:
http://osxr.org/android/source/frameworks/base/native/android/asset_manager.cpp

https://github.com/SFML/SFML/blob/master/src/SFML/System/FileInputStream.cpp#L64
Finally, this code uses "sf::priv::ResourceStream::tell()" to check if the file has actually opened, which results in the segfault, as it tries to call AAsset_getLength with a nullptr.


Added nullptr checks in all functions in
https://github.com/SFML/SFML/blob/master/src/SFML/System/Android/ResourceStream.cpp#L45
Which solves the crash for me.

7

Window / [Android] Issue or not? static sf::Shader creation results in crash.

« on: July 15, 2015, 10:19:35 am »

Extremely simple. I'm not sure if it is allowed or not. But when I have a global sf::Shader object defined somewhere in the code, the Android version of SFML crashes during startup somewhere in the SFML-Window code (backtrace is sadly useless in this case, so took me quite a while to track down)

Example is simple, just modify the android example code do this:

#include <SFML/System.hpp>
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
#include <SFML/Audio.hpp>
#include <SFML/Network.hpp>

sf::Shader test_shader;

int main(int argc, char *argv[])
{
    return 0;
}
 

(Tested on a S3 phone, which runs the example fine)

8

General / Getting the android example to work... (no luck...) EDIT: WORKING NOW!

« on: July 11, 2015, 01:46:32 pm »

I've been trying to get the android example to work, to see if I can port the game I'm working on to android as well.

However, I've been running into an issue. I've compiled SFML-2.3 just fine following this tutorial:
https://github.com/SFML/SFML/wiki/Tutorial:-Building-SFML-for-Android
Build both for armeabi and armeabi-v7a with the following commands:

export PATH=$PATH:/home/daid/android/android-sdk-linux/tools:/home/daid/android/android-sdk-linux/platform-tools:/home/daid/android/android-ndk-r10e
export ANDROID_NDK=/home/daid/android/android-ndk-r10e
mkdir armeabi
cd armeabi
cmake -DANDROID_ABI=armeabi -DCMAKE_TOOLCHAIN_FILE=../../cmake/toolchains/android.toolchain.cmake ../..
make
make install
cd ..

mkdir armeabi-v7a
cd armeabi-v7a
cmake -DANDROID_ABI=armeabi-v7a -DCMAKE_TOOLCHAIN_FILE=../../cmake/toolchains/android.toolchain.cmake ../..
make
make install
cd ..
 

Then I move to the example directory and try to build that with the native tools and ant:

cd ../examples/android/
ndk-build
ant release
 

With results in the code being build, the libraries being copied and and .apk being build in ./bin

However, when I try to install this apk on my phone, I get the following exception (in logcat)

    java.lang.SecurityException: Permission Denial: get/set setting for user asks to run as user -2 but is calling from user 0; this requires android.permission.INTERACT_ACROSS_USERS_FULL
            at com.android.server.am.ActivityManagerService.handleIncomingUser(ActivityManagerService.java:13140)
            at android.app.ActivityManager.handleIncomingUser(ActivityManager.java:2038)
            at com.android.providers.settings.SettingsProvider.callFromPackage(SettingsProvider.java:607)
            at android.content.ContentProvider$Transport.call(ContentProvider.java:279)
            at android.content.ContentProviderNative.onTransact(ContentProviderNative.java:273)
            at android.os.Binder.execTransact(Binder.java:388)
            at dalvik.system.NativeStart.run(Native Method)
 

I have very little knowledge about android development. And all I can find is that the above error means that the application is trying to do something with requires system level permissions (by being signed by same key as the system) so something is clearly going wrong. But I have no clue what.

9

Network / sf::TcpSocket, sf::Packet and NonBlocking behavior...

« on: October 05, 2014, 01:56:10 pm »

I'm trying to use SFML's TCP networking implementation to do client/server code for a game I'm working on.

However, I ran into a problem. I made all code single threaded, so I put all sockets into NonBlocking mode with setBlocking(false); And then I send sf::Packets trough it.
However, it looks like I'm getting corrupted packets at the receiving end when I try to send a lot of data at once (usually at the initialization of the client state, which needs a lot of data)


I think I tracked it down to the sf::TcpSocket::send function:
https://github.com/SFML/SFML/blob/master/src/SFML/Network/TcpSocket.cpp#L220

The problem here, is that when you are in NonBlocking mode, you can have a partial send on the ::send() function. As the buffer at the OS level is full. On the next retry of ::send it will return -1 with an EWOULDBLOCK error. And thus exiting the send function. Reporting to the caller a status of "NotReady", however, it did partially send the message. Thus corrupting the packet on the receiving side. (And pretty much corrupting the whole stream)


I do not want the send function to block (else I could put it into blocking mode before sending) as this could block the whole server if 1 client went missing (which fills up the OS buffer, a block before the socket is disconnected).
Sending with threads could be done, but as SFML lacks a Queue or Conditionals then this could become very tricky very fast, not even sure it can be done without polling, which I rather avoid.

And as TcpSocket::send also fails to report how much data it actually send, else I could keep track of how much I still needed to send myself.


Not sure where to go from here...