Messages

16

SFML projects / Re: EmptyEpsilon - Spaceship bridge simulator.

« on: July 19, 2015, 08:35:02 am »

Unfortunately the photo you linked of your setup is on a local host, you might want to push it to the server and adjust the link.

Oops, photo is publicly hosted. But the local. dns is because I cannot reach the external IP when I'm on that network (some NAT router issue)


And it's really fun to control a ship with a group of people. And I think you could even sell it as a team-building exercise As you really need to work together and communicate a lot.

17

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.

18

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?

19

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

« on: July 15, 2015, 10:18:35 pm »

What's odd?

Because on windows and linux, when shaders are not supported, creating an sf::Shader object is just fine, but using it results in warning/error notices that shader support is not working.

Not supported, and crash and burn in hell when you try to use it are two very different things. Especially if the shaders have a function to check if they are available and supported.

(I did assume that "not supported" meant "not implemented", at which point crash&burn is really odd for something that isn't even implemented)

20

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

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

I added the change in the Android/ResourceStream.cpp

////////////////////////////////////////////////////////////
//
// SFML - Simple and Fast Multimedia Library
// Copyright (C) 2013 Jonathan De Wachter (dewachter.jonathan@gmail.com)
//
// This software is provided 'as-is', without any express or implied warranty.
// In no event will the authors be held liable for any damages arising from the use of this software.
//
// Permission is granted to anyone to use this software for any purpose,
// including commercial applications, and to alter it and redistribute it freely,
// subject to the following restrictions:
//
// 1. The origin of this software must not be misrepresented;
//    you must not claim that you wrote the original software.
//    If you use this software in a product, an acknowledgment
//    in the product documentation would be appreciated but is not required.
//
// 2. Altered source versions must be plainly marked as such,
//    and must not be misrepresented as being the original software.
//
// 3. This notice may not be removed or altered from any source distribution.
//
////////////////////////////////////////////////////////////


////////////////////////////////////////////////////////////
// Headers
////////////////////////////////////////////////////////////
#include <SFML/System/Android/ResourceStream.hpp>
#include <SFML/System/Android/Activity.hpp>
#include <SFML/System/Lock.hpp>


namespace sf
{
namespace priv
{

////////////////////////////////////////////////////////////
ResourceStream::ResourceStream(const std::string& filename) :
m_file (NULL)
{
    ActivityStates* states = getActivity(NULL);
    Lock(states->mutex);
    m_file = AAssetManager_open(states->activity->assetManager, filename.c_str(), AASSET_MODE_UNKNOWN);
}


////////////////////////////////////////////////////////////
ResourceStream::~ResourceStream()
{
    if (m_file)
        AAsset_close(m_file);
}


////////////////////////////////////////////////////////////
Int64 ResourceStream::read(void *data, Int64 size)
{
    if (!m_file)
        return -1;
    return AAsset_read(m_file, data, size);
}


////////////////////////////////////////////////////////////
Int64 ResourceStream::seek(Int64 position)
{
    if (!m_file)
        return -1;
    return AAsset_seek(m_file, position, SEEK_SET);
}


////////////////////////////////////////////////////////////
Int64 ResourceStream::tell()
{
    if (!m_file)
        return -1;
    return getSize() - AAsset_getRemainingLength(m_file);
}


////////////////////////////////////////////////////////////
Int64 ResourceStream::getSize()
{
    if (!m_file)
        return -1;
    return AAsset_getLength(m_file);
}


} // namespace priv
} // namespace sf
 

Most likely not the best solution, but this is what I changed to prevent this code from crashing on my build. (SFML-2.3.1)

21

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.

22

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

« on: July 15, 2015, 05:36:05 pm »

Despite that, the mobile ports of SFML are still based on OpenGL ES 1.1, which only supports the fixed render pipeline, which means unfortunately there isn't any shader support.

Which makes the issue even more odd on that end.

You should not use global SFML resources since it can cause many different issues.

Rogger. Wanted to refactor that code anyhow, but it was quick&dirty working quite fine. (But could also explain why OSX is causing issues)

And I think you mean that no SFML objects should be created before main() is run? Cause a private static member isn't strictly global, but constructed at the same point in time and thus will cause the same issues.

23

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)

24

General discussions / Re: Why use SFML over SDL?

« on: July 13, 2015, 04:44:31 pm »

In my experience, SDL gives you more lower level access. Meaning you can do more powerful stuff, but you also need to manage more yourself.

This is with SDL1.2 experience. Not sure if SDL2 improved on that. For example, with SDL it was more tricky to ensure you had hardware acceleration. With SFML this is a given fact. SDL did port to everything including the Wii and some other oddball devices.


In the end, they both serve the same goal quite fine. And I would put the choice on if you like to work with objects&classes or plain C code.

25

General / Re: Getting the android example to work... (no luck...)

« on: July 12, 2015, 09:50:59 am »

Just got it to work!

In the above, I forgot that I also used the android update command.

So my latest working commands are:

export PATH=$PATH:$HOME/android/android-sdk-linux/tools:$HOME/android/android-sdk-linux/platform-tools:$HOME/android/android-ndk-r10e

cd ../examples/android/
android update project --target "android-16" --path .
ndk-build
ant debug
cp bin/NativeActivity-debug.apk ~/public_html/test.apk
 

For some reason, I was targeting "android-15" which caused issues, as well as the release build is causing issues. No clue why, but it works now.

26

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.

27

General discussions / Re: Incredible performace of Lua (luajit) over C++

« on: July 11, 2015, 01:36:18 pm »

I know that. However, once you've compiled C++ to use SIMD you can't run your program on a CPU that doesn't feature those instructions.

Good luck finding a worthwhile x86(-64) desktop CPU with no SSE2 that is younger than 5 years old and faster than 2 Ghz. I'm not even sure one like that exists.

Been using SSE2 compile flags on a project for 3 years now. More then 50.000 daily users (and growing) not a single complain ever.



But the post here has little to do with C++ vs LuaJit. As the performance of that code should not be CPU bound. Most likely the C++ version is doing vsync while the LuaJit version is not or something silly like that.
Or, more likely, you say you have the physics engine enabled on the LuaJit version, making crates fall off-screen. Off-screen rendering is quite fast, as the GPU will say "I don't have to do shit, let's skip this".

28

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

« on: October 05, 2014, 05:43:53 pm »

Yeah... this is a known problem, and short of an API change, there isn't a satisfactory way to fix it. We can't make such a noticeable API change before SFML 3, so until then there is no simple workaround for this.

May I disagree there?

Option A: The sf::TcpSocket::send could store the rest of the sf::Packet if sending partially failed. Reporting success back to the application, and when the next call to any socket function is made it's tried again to send it. No other data is send till this data has been send correctly.
Option B: Add a sf::TcpSocket::send(void *data, std::size_t size, std::size_t &actual_send_size) function to the socket API. Adding functions doesn't break backwards compatibility.
Option C: Add a sf::Conditional so proper threading can be implemented. Still an addition, so no backwards compatibility breaking. Not to mention that I've seen more request for this basic thread synchronization feature.

Yeah... this is a known problem

Documentation! Documentation! Documentation! Would have saved me TONS and TONS of time if the API documentation mentioned this tiny fact. Pretty much spend the whole day yesterday trying to track this down, figuring it was a bug in my own code at first.
Not to mention the few play testing sessions with 6~10 people this bug ruined so far.

One possibility might be to split your huge data up into smaller segments and send explicit acknowledgements back to the sender after the receiver has received a whole segment. This way you can participate a bit in the rate control and try to make sure the send buffer doesn't become full too fast. They typically aren't too small either, something on the order of 64KB, so you would have to send a relatively huge chunk of contiguous data in one burst to cause it to become full.

May I point out that that is a REALLY shitty solution? That implementing part of TCP on top of TCP. Also has the nice potential for race conditions (what if buffers on both sides are full, then you cannot send the acknowledge). Waste of bandwidth, and horrible if your round-trip times are a bit longer.



Think I just figured a workaround. I can overload the sf::TcpSocket class, then I can access the sf::Socket::getHandle() function, which allows me to call the OS ::send function directly, catching the partial sends.


(Sorry that I'm not replying in a nice manner. I can be like that...  )

29

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...