Messages

1

General / Re: SOLVED, SFML on iOS 9.3.5 (armv7, iPad 3), "iOS" requires the "metal" capability

« on: April 07, 2018, 08:16:09 pm »

I can understand the decision to only support 64 bit.

But on the other side it would be really nice if an option would exist to simple compile for 32 bit ;-) (e.g. Current XCode supports a development target downward to iOS 8.0)

Maybe a option to compile sfml as an ios fat binary library for armv7 i386 x86_64 arm64 (like the libs in SFML/extlibs/libs-ios are) would be fine ;-)

2

General / Re: SOLVED, SFML on iOS 9.3.5 (armv7, iPad 3), "iOS" requires the "metal" capability

« on: April 07, 2018, 04:43:00 pm »

Hi Ceylo,

thank you for your reply!

I'm not really familiar with apple's app store but is it today not possible to upload an ios app which includes both binaries, armv7 32bit and arm64 64bit?

This would have the benefit to be downward compatible to e.g. iOS 9.0 devices.

Or is it not possible to support old iOS 9.0 devices per app store?

Currently I find many apps for my iPad 3 in the app store.
Can a developer update its app at the app store without losing the compatibility to iOS 9.0?

3

General / SOLVED, Re: SFML on iOS 9.3.5 (armv7, iPad 3), "iOS" requires the "metal" cap...

« on: April 05, 2018, 01:11:35 am »

Solved ;-)

The problem for "iOS" requires the "metal" capability... was that wenn I create/add the iOS target with the template iOS->Game I didn't change the default value "Metal" for the "Game Technology" :-(

I find no option to change the "Game Technology" after creating the iOS target.
Therefore I create a new "iOS" target with the template iOS->Game and use "SpriteKit" instead of "Metal".

Now the sfml demo app runs on my iPad 3 :-)

Maybe a note/hint should be added at https://github.com/SFML/SFML/wiki/Tutorial:-SFML-for-iOS .

If a old device / old iOS version doesn't support the Metal API but the sfml app should run on it then SpriteKit should be selected for the "Game Technology".

4

General / SOLVED, SFML on iOS 9.3.5 (armv7, iPad 3), "iOS" requires the "metal" capability

« on: April 04, 2018, 10:00:27 pm »

Hi,

I want to compile SFML (and the demo app) for my iPad 3 (armv7, iOS 9.3.5).
I already solved some problems and it runs on the iOS Simulator.

I use the current master branch (from today) and XCode 9.2 and macOS 10.13.3 for XCode.
I used the tutorial „SFML for iOS“ with the iOS.toolchain.cmake file for the upcoming 2.5.0 version. (I have always used the 2.5.0 description instead of the 2.4.2)
https://github.com/SFML/SFML/wiki/Tutorial:-SFML-for-iOS

First I compile SFML and the demo app for the iOS Simulator.
It compiles but the app closed immediately.
It seams like the sfmlMain() was not called. I had included the <SFML/Main.hpp> and have the main() function and I have tried it without the <SFML/Main.hpp> and rename directly from main() to sfmlMain() instead.
I have solved the Problem by removing the libsfml-main-s.a library and instead copy the SFML/src/SFML/Main/MainiOS.mm directly to my iOS subfolder from the SFML demo app.
So the demo app run now perfect on the iOS simulator!

Next challenge is to get the demo app running on my old iPad 3.
There were several problems.
The first problem was that the SFML library was compiled for arm64 only.

$ lipo -info libsfml-graphics-s.a
input file libsfml-graphics-s.a is not a fat file
Non-fat file: libsfml-graphics-s.a is architecture: arm64

I set the iOS Deployment Target to 9.3 and try by Build Settings armv7 for Architectures and Valid Architectures. But armv7 alone doesn’t work. Compiler put an error that arm64 is not possible because only armv7 is valid…

I solved the problem by edit the architecture directly in the iOS.toolchain.cmake from arm64 to armv7.
Now I have the libs for armv7 ;-)

=== 1) Is it possible to create a fat file for armv7 and arm64 (by set both in iOS.toolchain.cmake?) ?

On the SFML demo app I also set the iOS Deployment Target to 9.3 and the arch to armv7.
And now it compiles! But I can’t install/run it on my iPad.

Unable to install “iOS”
“iOS” requires the “metal” capability which is not supported by Jürgen's iPad

It seems like the problem is from the target template iOS Game.
Because wenn I create a new iOS Game Project (without any SFML stuff) and set the iOS Deployment Target to 9.3 and try to run it on my iPad 3 I get the same error message (only the target name „iOS“ is different).

I also have tried another demo app (without sfml). It is an example with cmake (https://github.com/leetal/ios-cmake) and this hello world example works on my iPad 3.

=== 2) Does anybody know which settings must be changed to remove the error message with „Unable to install „iOS“. „iOS“ requires the “metal” capability which is not supported by … iPad“

Best regards
And sorry for my bad English :-)

5

Network / Re: Bug? IpAddress addr(1, 2, 3, 4); on big endian machine?

« on: February 08, 2018, 12:16:12 am »

I have an error in reasoning :-D The current git-code is correct! (NO bug)

example:
little endian:

IpAddress(1, 2, 3, 4);
-->
(1 << 24) | ( 2 << 16) | (3 << 8) | (4 << 0) = 0x01020304
-->
0x01020304 (host order, little endian, in memory: 0x04, 0x03, 0x02, 0x01)
--> htonl(0x01020304) --> 0x04030201 (network order, in memory: 0x01, 0x02, 0x03, 0x04)
0x04030201 (memory: 0x01, 0x02, 0x03, 0x04) in m_address is network order and is CORRECT!!!

example:
big endian architecture (host order = network order. htonl() return the same value)

IpAddress(1, 2, 3, 4);
-->
(1 << 24) | ( 2 << 16) | (3 << 8) | (4 << 0) = 0x01020304
-->
0x01020304 (host order, big endian, in memory: 0x01, 0x02, 0x03, 0x04)
--> htonl(0x01020304) --> 0x01020304 (network order, in memory: 0x01, 0x02, 0x03, 0x04)
0x01020304 (memory: 0x01, 0x02, 0x03, 0x04) is network order and the value (i think) is CORRECT.

Ok both examples have in memory 0x01, 0x02, 0x03, 0x04. So the code should have no bug :-D sorry ;-)

6

Network / [SOLVED its no bug!] Bug? IpAddress addr(1, 2, 3, 4); on big endian machine?

« on: February 07, 2018, 10:03:29 pm »

Hi!

I think I found a bug but I can't really test the bug because I have currently no big endian architecture (like PowerPC).

Bug is in the Constructor of IpAddress(Uint8 byte0, Uint8 byte1, Uint8 byte2, Uint8 byte3) at
SFML/src/SFML/Network/IpAddress.cpp

Current Version of IpAddress(Uint8 byte0, Uint8 byte1, Uint8 byte2, Uint8 byte3):

IpAddress::IpAddress(Uint8 byte0, Uint8 byte1, Uint8 byte2, Uint8 byte3) :
m_address(htonl((byte0 << 24) | (byte1 << 16) | (byte2 << 8) | byte3)),
m_valid  (true)
{
}

I think it should be without the htonl and shift the bytes directly for the big endian format.

IpAddress::IpAddress(Uint8 byte0, Uint8 byte1, Uint8 byte2, Uint8 byte3) :
m_address((byte0 << 0) | (byte1 << 8) | (byte2 << 16) | (byte3 << 24)),
m_valid  (true)
{
}

IpAddress x(1, 2, 3, 4);
x.toString(); // will currently prodoce "4.3.2.1" on big endian machine?

I think this would currently produce "4.3.2.1" on big endian machine. Or otherwise I have an error in reasoning 

7

Audio / Re: How many threads are created for multiple sf::Sound and/or sf::Music?

« on: December 06, 2017, 09:04:05 pm »

Thank you for the info!

This means that a instance of sf::Sound (which is no derivation of sf::SoundStream) with a sf::SoundBuffer creates no additional thread (only the thread(s) which already exist for audio processing are used to play sf::Sound). Is that correct?

8

Audio / How many threads are created for multiple sf::Sound and/or sf::Music?

« on: December 06, 2017, 07:27:01 pm »

The tutorial page "Playing sounds and music" ( https://www.sfml-dev.org/tutorials/2.4/audio-sounds.php ) says that "Sounds (and music) are played in a separate thread."

Is there only one separate thread for all current used sf::Sound's and sf::Music's or create each sf::Sound and sf::Music its own thread?

Best regards

9

Window / Android: java activity doesn't response/react (freeze) after closing native sfml

« on: December 04, 2017, 04:54:16 pm »

Hi sfml community and developers ;-)

Android java activity doesn't response/react (freeze) after closing native sfml activity.

I have two activities. One normal (java) activity and the native (sfml) activity.
The java activity is the main activity. I use this activity to open usb devices (like usb midi device)
and forward the open handle (per file descriptor) to the sfml application.

The native activity is started by a methode from the java activity like this:

   Intent intent=new Intent();
        intent.setComponent(new ComponentName("com.foo.myapp", "android.app.NativeActivity"));
        startActivity(intent);

Everything works great.
At the sfml event loop I set the window active and non-active if the events sf::Event::LostFocus
and sf::Event::GainedFocus happends. Therefore pressing the home button is no problem.
(Without setActive() problems exist. see: https://github.com/SFML/SFML/issues/755 https://pastebin.com/21sChJU6)

The problem begins when I close the native activity.
I close the native activity by closing the Sfml window (with close() member function) and return at the main sfml function.
After this the methode onResume() from the java activity is called (that's fine) but the java activity doesn't react on any touch or back-button.
The main java activity is shown but doesn't react. It looks like it is freezed.
Also if I call finish() at the onResume() methode (for exit the main java activity) only onPause() is called but no onDestroy().
My workaround is to call finish() at onResume() and call System.exit(0) at onPause() if the native activity was closed.
This Hack quits the java activity and clean the process.

What I am making wrong that the java activity is freezed after closing the native activity?

It would be really nice if I doesn't need the dirty exit(0) for closing the java activity.

I use the lastest master branch from SFML for android.

Here my manifest file.

My min sdk api version and my target sdk api version is both 15.

Manifest file:
--------------

<?xml version="1.0" encoding="utf-8"?>
<manifest xmlns:android="http://schemas.android.com/apk/res/android"
   package="com.foo.myapp">

    <uses-feature android:glEsVersion="0x00010001" />
    <uses-feature android:name="android.hardware.usb.host" />

    <uses-permission android:name="android.permission.USB_PERMISSION" />
    <uses-permission android:name="android.permission.INTERNET" />
    <uses-permission android:name="android.permission.ACCESS_NETWORK_STATE" />
    <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE" />
    <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

    <application
       android:allowBackup="true"
       android:icon="@mipmap/ic_launcher"
       android:label="@string/app_name"
       android:supportsRtl="true"
       android:theme="@style/AppTheme"
       >
        <activity android:name=".MyAppActivity" android:launchMode="singleTask"
           android:theme="@style/Theme.AppCompat.Light.NoActionBar.FullScreen"
           >
            <intent-filter>
                <action android:name="android.intent.action.MAIN" />
                <category android:name="android.intent.category.LAUNCHER" />
            </intent-filter>
        </activity>
        <activity
           android:name="android.app.NativeActivity"  android:launchMode="singleTask"
           android:configChanges="keyboardHidden|orientation|screenSize"
           android:icon="@mipmap/ic_launcher"
           android:label="@string/app_name"
           android:theme="@style/Theme.AppCompat.Light.NoActionBar.FullScreen"
           >
            <meta-data
               android:name="android.app.lib_name"
               android:value="myapp-sfml-activity" />
            <meta-data
               android:name="sfml.app.lib_name"
               android:value="myapp-main" />
        </activity>
    </application>

</manifest>
 

styles.xml:
-----------

<resources>
    <!-- Base application theme. -->
    <style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
        <!-- Customize your theme here. -->
        <item name="colorPrimary">@color/colorPrimary</item>
        <item name="colorPrimaryDark">@color/colorPrimaryDark</item>
        <item name="colorAccent">@color/colorAccent</item>
    </style>
    <!-- extra style for fullscreen added -->
    <style name="Theme.AppCompat.Light.NoActionBar.FullScreen" parent="@style/Theme.AppCompat.Light">
        <item name="android:windowNoTitle">true</item>
        <item name="android:windowActionBar">false</item>
        <item name="android:windowFullscreen">true</item>
        <item name="android:windowContentOverlay">@null</item>
    </style>
</resources>
 

10

General discussions / Android: Access / open USB devices (Java Activity instead of native Activity?)

« on: October 05, 2016, 11:51:30 pm »

Hi!

I use SFML for Android. Now I want to access a USB device (MIDI device adapter for my piano). Currently I access the USB Manager from my C++ Code per JNI with GetMethodID, CallObjectMethod, ... etc. That's all no problem. The problem starts with opening the USB device. I insert <uses-feature android:name="android.hardware.usb.host" /> to my manifest file but I have no idea to make the necessary requestPermission() call from JNI to granted the access for opening the device with openDevice from USB manager. If I have a valid file descriptor from the opened usb device then the access per NDK should be no problem using ioctl and bulk transfer (see: http://stackoverflow.com/questions/16963237/passing-usb-file-descriptor-to-android-ndk-program ). For SFML I think the problem could be interresting for the SFML project because SFML maybe want to support joysticks which are connected per USB.

My current solution would be to use a normal/java activity instead of a native activity with SFML and write the necessary code in java to open the usb device and transfer the opened file descriptor to my native code.

Now I have two questions ;-)
1) Is there a possible solution without Java code?
2) Is there a example of using SFML with a activity (java) instead of using SFML with a native activity?

Sorry for my bad english :-)