Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Android and iOS ports available for testing  (Read 300209 times)

0 Members and 2 Guests are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Android and iOS ports available for testing
« on: November 29, 2013, 03:56:03 pm »
Hi

The iOS/Android ports are finally ready for beta-testing. This happens one month after the expected date, sorry for the delay (everyone is very busy -- more than usual). Until Jonathan pushes the code to the public repository, here is what you need to know if you want to play with them.

Where?

The ports will be available in the ios_and_android branch of the repository. This way it won't bother people who are not interested, and the amount of testers (and reports) is kept under control.

How to compile the iOS port?

To compile the iOS port, you must use the Xcode generator of CMake, and define the "IOS" boolean variable (set to TRUE) before configuring for the first time. The generated projects can then be compiled for x86 (simulator) or armv6/v7 (device) by selecting the target in Xcode; no need to generate multiple builds for that. SFML is built as static libraries on iOS (this is the only option for this OS).

To use SFML in your iOS app project, do as usual: add the include path to your project settings, and drag'n'drop the libraries into your project. Since SFML is linked statically, you'll have to link all its non-default dependencies as well (extlibs/libs-ios).
Note that you'll need a registered Apple developer account in order to copy and run your app on a device; otherwise the simulator will be your only choice.

How to compile the Android port?
How to compile the OpenGL ES port for Linux?
Things to know for Android

Jonathan will explain that as soon as he is available ;)

New API

Only a few things have been added to the public API:
  • The sf::Keyboard::setVirtualKeyboardVisible function
  • The Touch API:
    • A sf::Touch class (similar to sf::Mouse)
    • sf::TouchBegan / sf::TouchMoved / sf::TouchEnded events (similar to mouse events)

General things to know

The sensors (accelerometer, gyroscope, compass, ...) are currently using the Joystick API (see the sources for more detail about the mapping). We'll soon add a sf::Sensor API that better matches the requirements.

The foreground / background events are mapped to the GainedFocus and LostFocus events.

Orientation changes are mapped to the Resize event.

sf::Shader is not available, because the implementation is based on OpenGL ES 1. Shaders are only available in OpenGL ES 2, which would require a major rewriting of the graphics part. So that won't be done in a near future.

Things to know for iOS

On iOS, the working directory is automatically set to the resources directory.

There's no audio module on iOS, I'm still waiting for libsndfile to add a license exception for iOS so that I can use it statically without breaking the terms of the license. The author said it was one of its priorities, but it was months ago and I've got no news...

The implementation should be compatible with iOS 4.0 and more.

The size of the window is ignored, the screen size is always used.

Examples are not available. It seems that CMake is not ready for that, it still requires too many hacks, and even with them, it was still pretty bad.

The ugly hack: you need to include <SFML/Main.hpp> in the file where your main function is defined. This is because SFML has to hijack it, and rename your own main to call it later.

There's no specific support for high-resolution (retina) screens, they currently produce the same output as low-res screens (this will be done later).

Important

Until everything is merged into master, please use the forum for your feedback. You can post here or open new threads. There are still many things to do, I don't want to pollute the task tracker ;)
« Last Edit: December 03, 2013, 07:37:11 am by Laurent »
Laurent Gomila - SFML developer

Sonkun

  • Full Member
  • ***
  • Posts: 241
    • View Profile
Re: Android and iOS ports available for testing
« Reply #1 on: November 29, 2013, 04:42:45 pm »
Note

For those who aren’t familiar with git, once the SFML repo freshly cloned, type: git checkout –b ios_and_android origin/ios_and_android to get the right branch.

How to compile the Android port?

To compile the Android port, you must use CMake with the toolchain configuration script located at cmake/toolchains/android.toolchain.cmake. To do that, define the CMAKE_TOOLCHAIN_FILE variable when invoking CMake and make it point to the android.toolchain.cmake script. You’ll also need to define an environments variable ANDROID_NDK telling where the NDK directory is. There are a few options available to customize the build process:

ANDROID_ABI : armeabi, armeabi-v7a, x86, mips
ANDROID_NATIVE_API_LEVEL:  9, 14, 18, etc.
ANDROID_USE_STLPORT: Make sure this one is set at TRUE because I’m not sure if it’s set automatically. Usage of the STL port is MANDATORY. If you don’t use it, no error will be reported and your application will just.. crash :)

Once compiled, type "make install" to install everything in your NDK directory.

Getting familiar with the compilation process of native Android application isn’t an easy task so, don’t give up and read carefully the NDK documentation. Maybe you should start with compiling an official example such as NativeActivty located in your NDK. You’ll need to get through this because you won’t be able to reuse this CMake toolchain script to compile your own application (unless your application is a library :D).

There’s an example available in the SFML source files directory. I advise you to “create a project from existing source” from the Android IDE (Eclipse). Once the example imported and set up, you can’t simply press the “Run” button, you’ll need to compile the example project first. To do that, open a console, head to the example directory and invoke the ndk-build script located in your NDK:  your command might look like this: $ANDROID_NDK/ndk-build

Things to know for Android

On Android, the working directory is automatically set to the resources directory (assets/).

sf::SoundRecorder won’t record any sounds.

Since recently I no longer get the orchestral.ogg song to play with sf::Music ... but canary.wav does work.

The implementation is compatible with Android 9 or later.

You may have to install some 32bits libs on Linux. I can’t tell which exactly but on Fedora 64bits, type the following: sudo yum install glibc.i686 glibc-devel.i686 libstdc++.i686 zlib-devel.i686 ncurses-devel.i686 libX11-devel.i686 libXrender.i686 libXrandr.i686. If someone could give the list for Debian based distribution, it would great!

How to compile the OpenGL ES port for Linux?

Unfortunately, this isn’t available yet because I need to refactor the EGL code to avoid duplication, as well as time to test the new CMake scripts on a Raspberry Pi. I’ll implement this really soon.

Important

I really am busy right now and I won't be able to provide much support until 8th of December.
« Last Edit: November 29, 2013, 05:26:49 pm by Sonkun »
Interested in using SFML with Python ? Try out its Python binding!

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
Re: Android and iOS ports available for testing
« Reply #2 on: November 29, 2013, 06:08:29 pm »
First: Thanks for your work. :)

I tried to build SFML, however I get errors inside the NDK. Since I'm very unexperienced with it, I ask if something like this is known anyhow:

Code: [Select]
cd /home/stefan/build/sfml-android-release/src/SFML/System && /home/stefan/android-ndk-r9b/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++   -DANDROID -DSFML_OPENGL_ES -DSFML_SYSTEM_EXPORTS -D__ARM_ARCH_5E__ -D__ARM_ARCH_5TE__ -D__ARM_ARCH_5T__ -D__ARM_ARCH_5__ --sysroot=/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm -fsigned-char -march=armv7-a -mfloat-abi=softfp -mfpu=vfpv3-d16 -fdata-sections -ffunction-sections -fPIC -Wno-psabi -frtti -fno-exceptions -mthumb -O3 -fomit-frame-pointer -DNDEBUG -fPIC -isystem /home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include -isystem /home/stefan/android-ndk-r9b/sources/cxx-stl/stlport/stlport -I/home/stefan/projects/SFML/include -I/home/stefan/projects/SFML/src    -fvisibility=hidden -o CMakeFiles/sfml-system.dir/Android/ResourceStream.cpp.o -c /home/stefan/projects/SFML/src/SFML/System/Android/ResourceStream.cpp
In file included from /home/stefan/projects/SFML/src/SFML/System/Android/ResourceStream.hpp:33:0,
                 from /home/stefan/projects/SFML/src/SFML/System/Android/ResourceStream.cpp:29:
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:86:43: error: 'size_t' has not been declared
 int AAsset_read(AAsset* asset, void* buf, size_t count);
                                           ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:94:1: error: 'off_t' does not name a type
 off_t AAsset_seek(AAsset* asset, off_t offset, int whence);
 ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:105:1: error: 'off64_t' does not name a type
 off64_t AAsset_seek64(AAsset* asset, off64_t offset, int whence);
 ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:122:1: error: 'off_t' does not name a type
 off_t AAsset_getLength(AAsset* asset);
 ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:128:1: error: 'off64_t' does not name a type
 off64_t AAsset_getLength64(AAsset* asset);
 ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:133:1: error: 'off_t' does not name a type
 off_t AAsset_getRemainingLength(AAsset* asset);
 ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:140:1: error: 'off64_t' does not name a type
 off64_t AAsset_getRemainingLength64(AAsset* asset);
 ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:150:46: error: 'off_t' has not been declared
 int AAsset_openFileDescriptor(AAsset* asset, off_t* outStart, off_t* outLength);
                                              ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:150:63: error: 'off_t' has not been declared
 int AAsset_openFileDescriptor(AAsset* asset, off_t* outStart, off_t* outLength);
                                                               ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:161:48: error: 'off64_t' has not been declared
 int AAsset_openFileDescriptor64(AAsset* asset, off64_t* outStart, off64_t* outLength);
                                                ^
/home/stefan/android-ndk-r9b/platforms/android-16/arch-arm/usr/include/android/asset_manager.h:161:67: error: 'off64_t' has not been declared
 int AAsset_openFileDescriptor64(AAsset* asset, off64_t* outStart, off64_t* outLength);
                                                                   ^
/home/stefan/projects/SFML/src/SFML/System/Android/ResourceStream.cpp: In member function 'virtual sf::Int64 sf::priv::ResourceStream::seek(sf::Int64)':
/home/stefan/projects/SFML/src/SFML/System/Android/ResourceStream.cpp:66:43: error: 'AAsset_seek' was not declared in this scope
     AAsset_seek(m_file, position, SEEK_SET);
                                           ^
/home/stefan/projects/SFML/src/SFML/System/Android/ResourceStream.cpp: In member function 'virtual sf::Int64 sf::priv::ResourceStream::tell()':
/home/stefan/projects/SFML/src/SFML/System/Android/ResourceStream.cpp:73:56: error: 'AAsset_getRemainingLength' was not declared in this scope
     return getSize() - AAsset_getRemainingLength(m_file);
                                                        ^
/home/stefan/projects/SFML/src/SFML/System/Android/ResourceStream.cpp: In member function 'virtual sf::Int64 sf::priv::ResourceStream::getSize()':
/home/stefan/projects/SFML/src/SFML/System/Android/ResourceStream.cpp:80:35: error: 'AAsset_getLength' was not declared in this scope
     return AAsset_getLength(m_file);
                                   ^
src/SFML/System/CMakeFiles/sfml-system.dir/build.make:402: recipe for target 'src/SFML/System/CMakeFiles/sfml-system.dir/Android/ResourceStream.cpp.o' failed
make[2]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/Android/ResourceStream.cpp.o] Error 1
make[2]: Leaving directory '/home/stefan/build/sfml-android-release'
CMakeFiles/Makefile2:108: recipe for target 'src/SFML/System/CMakeFiles/sfml-system.dir/all' failed
make[1]: *** [src/SFML/System/CMakeFiles/sfml-system.dir/all] Error 2
make[1]: Leaving directory '/home/stefan/build/sfml-android-release'
Makefile:116: recipe for target 'all' failed
make: *** [all] Error 2

CMake config: See attached image.

Sonkun

  • Full Member
  • ***
  • Posts: 241
    • View Profile
Re: Android and iOS ports available for testing
« Reply #3 on: November 29, 2013, 06:18:00 pm »
It seems that NDK version r9b has been released in the meantime. I use version r9 so try to downgrade, even if it's unlikely to be because of this new version.

Try:
export ANDROID_NDK=/path/to/ndk
cd SFML/
mkdir build && cd build
cmake -CMAKE_TOOLCHAIN_FILE=../cmake/toolchains/android.toolchain.cmake -DANDROID_USE_STLPORT=1 ..
make -j8
Interested in using SFML with Python ? Try out its Python binding!

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1486
    • View Profile
    • Blog
    • Email
Re: Android and iOS ports available for testing
« Reply #4 on: November 30, 2013, 01:10:46 pm »
Thanks, will try that.

-j8? I only have 4 gigs of RAM, do you want to freeze my system? :P

Edit: I was able to build SFML with NDK version 9.
« Last Edit: November 30, 2013, 01:58:10 pm by Tank »

AlexAUT

  • Sr. Member
  • ****
  • Posts: 396
    • View Profile
Re: Android and iOS ports available for testing
« Reply #5 on: November 30, 2013, 03:15:55 pm »
Hey, so I followed the Android instructions, nearly the same as for eSFML, so I don't think I did something wrong.

I created a project from the android example, added native support, then compiled it, everything works fine until my phone tries to launch the application.

Here are the logcat logs, I tried it on two phones: Galaxy S (android 2.3.4), and HTC ONE X (tegra 3) (Android 4.2.2).

HTC one X
11-30 14:48:18.740: E/(22467): file /data/data/com.nvidia.NvCPLSvc/files/driverlist.txt: not found!
11-30 14:48:18.745: I/(22467): Attempting to load EGL implementation /system/lib//egl/libEGL_tegra_impl
11-30 14:48:18.765: I/(22467): Loaded EGL implementation /system/lib//egl/libEGL_tegra_impl
11-30 14:48:19.310: D/NvOsDebugPrintf(22467): Library for API 1 exposes function not wrapped: glPointSizePointerOES
11-30 14:48:19.315: I/(22467): Loading GLESv1_CM implementation /system/lib//egl/libGLESv1_CM_tegra_impl
11-30 14:48:19.465: A/libc(22467): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 22489 (om.example.sfml) - sent from sys


Samsung Galaxy S:
11-30 14:48:18.740: E/(22467): file /data/data/com.nvidia.NvCPLSvc/files/driverlist.txt: not found!
11-30 14:48:18.745: I/(22467): Attempting to load EGL implementation /system/lib//egl/libEGL_tegra_impl
11-30 14:48:18.765: I/(22467): Loaded EGL implementation /system/lib//egl/libEGL_tegra_impl
11-30 14:48:19.310: D/NvOsDebugPrintf(22467): Library for API 1 exposes function not wrapped: glPointSizePointerOES
11-30 14:48:19.315: I/(22467): Loading GLESv1_CM implementation /system/lib//egl/libGLESv1_CM_tegra_impl
11-30 14:48:19.465: A/libc(22467): Fatal signal 11 (SIGSEGV) at 0x00000000 (code=1), thread 22489 (om.example.sfml) - sent from sys

 


On a emulator it just get stuck during the launching phase with no error.


P.S. I compile it again to exclude a mistake in the setup

AlexAUT
« Last Edit: November 30, 2013, 03:20:58 pm by AlexAUT »

Sonkun

  • Full Member
  • ***
  • Posts: 241
    • View Profile
Re: Android and iOS ports available for testing
« Reply #6 on: November 30, 2013, 05:03:19 pm »
Quote
added native support
???

You don't need to right-click on the project then "Add native support...". I'll explain how it works internally later.

Quote
P.S. I compile it again to exclude a mistake in the setup
Does that mean it works now? :D
Interested in using SFML with Python ? Try out its Python binding!

AlexAUT

  • Sr. Member
  • ****
  • Posts: 396
    • View Profile
Re: Android and iOS ports available for testing
« Reply #7 on: November 30, 2013, 08:51:55 pm »
No its still not working yet. The ndk examples runs fine, so I guess its not an error in my setup (at least the sdk/ndk part)

When I do not add native support I get an error the phone cant find the shared library...


Btw i test it on windows, tomorrow I will try it on ubuntu...


AlexAUT

Sonkun

  • Full Member
  • ***
  • Posts: 241
    • View Profile
Re: Android and iOS ports available for testing
« Reply #8 on: November 30, 2013, 10:34:48 pm »
For now, you're forced to have your application library named "sfml-example" (libsfml-example.so) because the SFML Activity (libsfml-activity.so) that comes along when you compile SFML doesn't take the customized application name into account.

In the meantime, you can either modify Main/SFMLActivity.cpp line 145 or fix it :D

Good luck!
Interested in using SFML with Python ? Try out its Python binding!

AlexAUT

  • Sr. Member
  • ****
  • Posts: 396
    • View Profile
Re: Android and iOS ports available for testing
« Reply #9 on: November 30, 2013, 10:43:47 pm »
Ok i am currently not at home, out clubbing  ;)

But thanks for your help I will try it later!



Edit: I downgraded my NDK from 9b to 9 and set everything up again and now it works(without setting the native lib support)... Awesome work!



AlexAUT
« Last Edit: December 01, 2013, 03:31:51 pm by AlexAUT »

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Android and iOS ports available for testing
« Reply #10 on: December 01, 2013, 11:42:35 am »
So... since this should also be compilable on a normal system, I went ahead and tried it out.

Didn't compile because <SFML/System/Err.hpp> was missing from GLExtensions.cpp for err() and std::endl.

Fixed that, then went ahead to check out all the warnings I got with my crazy warning settings enabled :).
Code: [Select]
-Wall -Wextra -Wconversion -Wshadow -Wunreachable-code -Wredundant-decls -Wcast-align -Wfloat-equal -Wno-long-long -Wformat=2 -pedantic
First and most importantly, is it necessary to redefine the OpenGL extension function names even if they exist already? From what I understand, the suffix added to the function names just denote which vendor/working group is taking care of the extension before it gets reviewed by the ARB and then put into the core specification. So overwriting say glGenFramebuffers with glGenFramebuffersEXT doesn't seem right to me if glGenFramebuffers already exists. Wouldn't it be nicer to have some form of #if !defined() guards around each function?

I also went ahead and cleaned out many conversion warnings that popped up. Most conversions shouldn't have made a change to behaviour, but some others do in fact change behaviour in slight ways that were probably not noticed by anyone yet ;). Free "bug" fixes.

Here is the diff. When I push my branch to GitHub it completely messes up the line endings, because well... SFML line endings are a mess already :P. Laurent or someone should just tell git to normalize them one day, see: https://help.github.com/articles/dealing-with-line-endings

Patch here: patch.diff
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

wintertime

  • Sr. Member
  • ****
  • Posts: 255
    • View Profile
Re: Android and iOS ports available for testing
« Reply #11 on: December 01, 2013, 12:05:53 pm »
As I read up on ARB_framebuffer_object and EXT_framebuffer_object recently, I can say they are subtly incompatible and should not be mixed up, because they have different internal code. The EXT version gets shared beweens contexts, while the ARB (or GL3.0) version does not and contains other extensions. One should not call functions of one of them, then functions of the other.
And its not the only extension where older extensions were modified, not just promoted.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Android and iOS ports available for testing
« Reply #12 on: December 01, 2013, 04:07:52 pm »
Quote
Didn't compile because <SFML/System/Err.hpp> was missing from GLExtensions.cpp for err() and std::endl.
Ah. Strange thing that it compiled for me (I can understand how <iostream> may be included indirectly depending on the compiler/OS, but <System/Err.hpp>?).

Quote
First and most importantly, is it necessary to redefine the OpenGL extension function names even if they exist already? From what I understand, the suffix added to the function names just denote which vendor/working group is taking care of the extension before it gets reviewed by the ARB and then put into the core specification. So overwriting say glGenFramebuffers with glGenFramebuffersEXT doesn't seem right to me if glGenFramebuffers already exists. Wouldn't it be nicer to have some form of #if !defined() guards around each function?
Yes, it's probably a bad thing to reuse the core name of the function. But I don't think testing it with preprocessor directives would solve the problem: it will be a macro only if defined by GLEW; if it is defined in the GL header, it will be a regular function.

Quote
I also went ahead and cleaned out many conversion warnings that popped up. Most conversions shouldn't have made a change to behaviour, but some others do in fact change behaviour in slight ways that were probably not noticed by anyone yet
I don't understand why so many casts would be needed. As far as I know, "anything op float" yields a float, so there's no need to cast both operands every time.

Quote
SFML line endings are a mess already :P. Laurent or someone should just tell git to normalize them one day, see: https://help.github.com/articles/dealing-with-line-endings
Yep. I thought I had configured git correctly... obviously not.
Laurent Gomila - SFML developer

binary1248

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1405
  • I am awesome.
    • View Profile
    • The server that really shouldn't be running
Re: Android and iOS ports available for testing
« Reply #13 on: December 01, 2013, 04:44:18 pm »
Yes, it's probably a bad thing to reuse the core name of the function. But I don't think testing it with preprocessor directives would solve the problem: it will be a macro only if defined by GLEW; if it is defined in the GL header, it will be a regular function.
But the problem is, it will never be defined in the GL header, at least on Windows, unless Microsoft decides that Windows should support a more recent version of OpenGL than what... 1.1? That would break all their precious customers' systems who don't have cards that can support anything more recent, which is also why DirectX has a hardware emulation layer. If OpenGL had a software rasterizer fallback that took care of newer features it wouldn't be a problem to do so, but it isn't part of the standard and Microsoft hasn't shown any interest in it either.

This is why GLEW goes ahead and defines even core functions. The goal is that every extension that is proposed goes through a sort of standardization process.

First it is probably only supported by a single vendor AMD/Nvidia, then it has the NV or ATI/AMD suffix.
Once the vendor can convince other vendors that what they are doing is good, it gets the EXT suffix.
When it is submitted to ARB for becoming part of the core API, it gets the ARB suffix.
Finally when it gets into the core specification it loses all suffixes.

The function will stay in the GLEW header, probably forever, but over time it will change its name, and maybe even its functionality a bit.

The only reason why the redefinitions that are in GLExtensions.hpp work now, is because the assumption that "if the card supports the core function it supports the EXT variant as well" holds. As wintertime already said, this can be problematic because they are not required to have the same behaviour, and it is up to the card manufacturers to drop support for legacy APIs if they have had core support for a long time. It might just be that at some point glGenFramebuffers will be available from GLEW, but glGenFramebuffersEXT not, and with those redefinitions you are overwriting a working name with a non-working one. This will break things because the redefinition takes place after you include GLEW the first time and if the compiler can't find the definition of glGenFramebuffersEXT after the preprocessor replaces glGenFramebuffers with it, or even worse tries to call glGenFramebuffersEXT although it is not set up, bad things will happen.

I think if you need a common entry point for those different GL functions you should create your own name block for it, something like SFGenFramebuffers and use the GLEW extension probing macros to decide which to assign to it, favouring core functions of course. This is how many other libraries alias lower level functionality in such situations.

I don't understand why so many casts would be needed. As far as I know, "anything op float" yields a float, so there's no need to cast both operands every time.
In the case of a binary operation, yes that is true, but it is also a matter of signalling the programmer's intention, and technically, if you cast one operand on the right-hand-side just to get a floating point operation, you are losing precision over casting the result after the integer operation instead.

When there are more operands involved it sometimes isn't always obvious in what order the implicit casts will take place. The goal is to cast as late as possible to take advantage of lossless integer operations but early enough if you know an integer operation will lose precision because it can lead to a fractional value.

I've just made it a habit to explicitly specify casts for everything so I know exactly what happens. Leaving things up to the compiler to decide works most of the time, but when higher level semantic knowledge gets involved, the compiler doesn't really have many possibilities to be smart about how it generates code, especially in a case where the standard instructs it to do something we didn't expect.
SFGUI # SFNUL # GLS # Wyrm <- Why do I waste my time on such a useless project? Because I am awesome (first meaning).

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32504
    • View Profile
    • SFML's website
    • Email
Re: Android and iOS ports available for testing
« Reply #14 on: December 01, 2013, 05:34:07 pm »
Quote
But the problem is, it will never be defined in the GL header, at least on Windows
But things are not limited to Windows, as you perfectly know ;)

Regarding casts: if nothing's broken then I prefer leaving the code as it is now. I'm not a big fan of those long lines of code where 80% of space is taken by occurences of the "static_cast" keyword. Of course your approach is safer, but I think it's a point where I can make a compromise ;)
Laurent Gomila - SFML developer