Android and iOS ports available for testing

[binary1248]

But things are not limited to Windows, as you perfectly know

But Windows is supported, and should not break even in such situations, as you perfectly know

[Laurent]

But Windows is supported, and should not break even in such situations, as you perfectly know

I just said that your solution based on the preprocessor might not work on Linux and OS X. I never said that I didn't want to solve this issue; sorry if it was not clear.

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.

[binary1248]

I just said that your solution based on the preprocessor might not work on Linux and OS X. I never said that I didn't want to solve this issue; sorry if it was not clear.

Why wouldn't it work? The names are part of the OpenGL extensions that are quasi-standard and the preprocessor should work the same on all platforms unless you have a really broken compiler . I haven't seen any special versions of said functions that only exist on a certain platform... There is only one GLEW header that you use on all platforms and it defines the same functions that are available.

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.

Actually, now that I checked, when you include glew.h it basically "pretends to be gl.h" by defining __gl_h_ itself so that if you include gl.h after glew.h it does nothing. If you do the opposite and include gl.h before glew.h an #error will be triggered so that isn't even possible. So as long as you include glew.h you will have access to all the functions and definitions no matter what gl.h version you have. There is no way to prioritize one or the other. You can't use both at the same time anyway, either you use glew.h or gl.h but not both.

[Laurent]

Why wouldn't it work? The names are part of the OpenGL extensions that are quasi-standard and the preprocessor should work the same on all platforms unless you have a really broken compiler . I haven't seen any special versions of said functions that only exist on a certain platform... There is only one GLEW header that you use on all platforms and it defines the same functions that are available.

If you include an OpenGL 2+ header, it will declare these functions directly, not as macros. The preprocessor won't see them, and your test will fail although the functions are already defined.

Actually, now that I checked, when you include glew.h it basically "pretends to be gl.h" by defining __gl_h_ itself so that if you include gl.h after glew.h it does nothing. If you do the opposite and include gl.h before glew.h an #error will be triggered so that isn't even possible. So as long as you include glew.h you will have access to all the functions and definitions no matter what gl.h version you have. There is no way to prioritize one or the other. You can't use both at the same time anyway, either you use glew.h or gl.h but not both.

Interesting. So I guess this closes the discussion

I'll rename my own identifiers so that no confusion / conflict is possible anymore.

[Lo-X]

Hell yeah, I'll test that android port this evening !

Thanks a lot to all of you for the job done ! That's amazing =)

[Laurent]

Nobody for iOS?

[eXpl0it3r]

Nobody for iOS?

We don't sell our souls to Apple.

[Laurent]

Let's see the positive side of this situation: more work for Jonathan, less work for me

[Lo-X]

Let's see the positive side of this situation: more work for Jonathan, less work for me

Of course my thanks were for the iOS port too, but like eXpl0it3r, I do not use any apple devices so I can't test it.

[AlexAUT]

So I have tried to port Kroniax for Android, and found a few bugs in SFML   


1.) The SFML app crashes when you try to change the orientation, e.g. turn the phone to landscape mode. Error code in logcat: "validate_display:294 error 3008 (EGL_BAD_DISPLAY)"

Current fix: Force one orientation, e.g. "android:screenOrientation="landscape" "

2.)sf::Sprite doesn't support transparent images, the transparent pixels are black or white instead of transparent. Also the non transparent colors aren't drawn correctly. See attachments(the sprite in the app, and the raw image)

3.)I think Jonathan already mentioned it that sf::Music can't play *.ogg files. the openFromFile always return false.

4.)I dont know if its just because of the license of GNUSTL(good c++11 support) but it would be nice if SFML wouldn't force us to use the STLPORT(little c++11 support). (not really a bug)

EDIT:
5.)Fonts/Text seems not to work too -> (http://i.imgur.com/fx9lCMg.png)


But anyway great work, thanks!


AlexAUT

[spacechase0]

Nobody for iOS?

I'll probably try later. I've been waiting on this for a while.

I only have access to the simulator though.

[Laurent]

I only have access to the simulator though.

For those who don't know: you can also run your compiled apps on a jailbroken device.

[lockandstrike]

I'm trying to build the android port but it is not working. Cmake says that the CMAKE_TOOLCHAIN_FILE  isn't being used by the project

[spacechase0]

There

At first it was having issues finding the OS X 10.9 SDK. I don't know if it is my computer, but I found it in "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk". I think it has something to do with XCode coming through the app store now, but that's just a random guess.

Then I had this:

CMake Error at CMakeLists.txt:231 (install):
  install FILES given no DESTINATION!


CMake Error at CMakeLists.txt:232 (install):
  install FILES given no DESTINATION!


Configuring incomplete, errors occurred!
See also "/Users/Chase/Desktop/Programming/build/SFML-ios/CMakeFiles/CMakeOutput.log".
See also "/Users/Chase/Desktop/Programming/build/SFML-ios/CMakeFiles/CMakeError.log".

After looking at CMakeLists.txt I tried defining INSTALL_MISC_DIR manually, which worked.

Also this.

Other than that it built successfully, but I'll have to actually try it another time later today.

[Laurent]

I think it has something to do with XCode coming through the app store now

Hmm I've never had problems with that. My Xcode was installed with the app store too, and as far as I remember the SDK was found at the same location -- automatically of course.
However I'm not up-to-date: Xcode 4.6 (I think ) and OS X 10.7.

After looking at CMakeLists.txt I tried defining INSTALL_MISC_DIR manually, which worked.

Fixed.

Also this.

Fixed.

Thank you