16
General discussions / Re: Any workaround for Lion OpenGL 3.2 Support?
« on: January 07, 2013, 04:58:00 am »
Any idea how I could track the 3.2 context issue, as when it will be implemented officially?
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
17
General discussions / Re: Any workaround for Lion OpenGL 3.2 Support?
« on: December 21, 2012, 04:34:41 pm »
Yes, I'm very sure! I'm using a Hackintosh with a Geforce GTX 690 so we might have a problem there but GLview says it's 3.2 capable.
18
General discussions / Re: Any workaround for Lion OpenGL 3.2 Support?
« on: December 20, 2012, 05:50:17 am »
Hello there,
As I'm also seeking a 3.2 context on Mac OS X, I tried the workaround mentioned by Hiura:
As I'm also seeking a 3.2 context on Mac OS X, I tried the workaround mentioned by Hiura:
Quote
just add the following code into sf::priv::SFContext::createContext (src/SFML/Window/OSX/SFContext.mm:150)and rebuild the Window library... but I still get a 2.1 context, is there anyone who made this work successfully?
19
Window / Re: Compiling Window lib on OSX
« on: December 11, 2012, 12:33:11 am »
Might be something around those lines indeed since I compile from the pseudo network sharing... but still, I don't have this error with GCC only.
I'm on to another technique now... I did compiled the SFML libraries statically and I'm trying to link them to my project using Cmake like so:
TARGET_LINK_LIBRARIES(mainLib "${PATH_DEP}libsfml-window-s.a")
and I get this error:
Undefined symbols for architecture x86_64:
"_IOHIDValueGetIntegerValue", referenced from:
sf::priv::HIDInputManager::isKeyPressed(sf::Keyboard::Key) in libsfml-window-s.a(HIDInputManager.mm.o)
sf::priv::HIDInputManager::isMouseButtonPressed(sf::Mouse::Button) in libsfml-window-s.a(HIDInputManager.mm.o)
sf::priv::JoystickImpl::update() in libsfml-window-s.a(JoystickImpl.cpp.o)
"_IOHIDElementGetDevice", referenced from:
___SNIPP
So I'm guessing this is the joystick handling but I don't know how to solve this or even from which framework it comes from.
Any chance someone could help me clear this up?
I'm on to another technique now... I did compiled the SFML libraries statically and I'm trying to link them to my project using Cmake like so:
TARGET_LINK_LIBRARIES(mainLib "${PATH_DEP}libsfml-window-s.a")
and I get this error:
Undefined symbols for architecture x86_64:
"_IOHIDValueGetIntegerValue", referenced from:
sf::priv::HIDInputManager::isKeyPressed(sf::Keyboard::Key) in libsfml-window-s.a(HIDInputManager.mm.o)
sf::priv::HIDInputManager::isMouseButtonPressed(sf::Mouse::Button) in libsfml-window-s.a(HIDInputManager.mm.o)
sf::priv::JoystickImpl::update() in libsfml-window-s.a(JoystickImpl.cpp.o)
"_IOHIDElementGetDevice", referenced from:
___SNIPP
So I'm guessing this is the joystick handling but I don't know how to solve this or even from which framework it comes from.
Any chance someone could help me clear this up?
20
Window / Re: Compiling Window lib on OSX
« on: December 10, 2012, 08:31:50 pm »
Certainly,
First, I'm developing on Windows 8 and I use VMware Workstation 9 to compile on Mountain Lion 10.8.2.
for simplicity sake, installing the CLT prevents me from generating a valid executable because of the error : ld: can't open file (my project lib), errno=35 for architecture x86_64
This error is inconsistent and it seems to rises proportionally with the time it takes to compile. In my rather complex setup, it's very hard to diagnose and there is one thing for sure, it's an Hocus Pocus bug.
What I do know however, is that I can compile my project without the CLT being installed but some dependencies are missing.
Therefore, I'm trying to find a way to compile the Window library on OSX without installing the CLT, if possible.
First, I'm developing on Windows 8 and I use VMware Workstation 9 to compile on Mountain Lion 10.8.2.
for simplicity sake, installing the CLT prevents me from generating a valid executable because of the error : ld: can't open file (my project lib), errno=35 for architecture x86_64
This error is inconsistent and it seems to rises proportionally with the time it takes to compile. In my rather complex setup, it's very hard to diagnose and there is one thing for sure, it's an Hocus Pocus bug.
What I do know however, is that I can compile my project without the CLT being installed but some dependencies are missing.
Therefore, I'm trying to find a way to compile the Window library on OSX without installing the CLT, if possible.
21
Window / Re: Compiling Window lib on OSX
« on: December 08, 2012, 11:11:52 pm »
Note that I wouldn't mind installing the command line tools but when I do, I can compile my project using cmake and gcc (minus window lib) but cannot link the compiled library because of this error:
ld: can't open file (my project lib), errno=35 for architecture x86_64
It looks like a mixed up in the OSX libs which uses old 32bit dependencies and that, I don't know how to solve.
ld: can't open file (my project lib), errno=35 for architecture x86_64
It looks like a mixed up in the OSX libs which uses old 32bit dependencies and that, I don't know how to solve.
22
Window / Compiling Window lib on OSX
« on: December 08, 2012, 09:43:40 pm »
Greetings,
Is there a way to compile the Window library on OS X Mountain Lion 10.8 without the need of:
Foundation/Foundation.h which I think is the objective c framework. The reason behind this is because I must not install XCode and especially the command line tools as I need to stick with GCC only.
Thx
Is there a way to compile the Window library on OS X Mountain Lion 10.8 without the need of:
Foundation/Foundation.h which I think is the objective c framework. The reason behind this is because I must not install XCode and especially the command line tools as I need to stick with GCC only.
Thx
23
Window / Re: Force OpenGL Context
« on: November 30, 2012, 08:03:00 pm »
Any way to prevent this automation from the driver? I tried to Google it but I couldn't find anything useful.
24
Window / Re: Force OpenGL Context
« on: November 26, 2012, 08:09:46 pm »
wait...
Even if I choose any specific version number I always get the higher supported version... I can assure you that this feature worked in the past. I remember creating a 2.1 or 3.3 context without any trouble. Am I taking crazy pills or am I taking a lot of crazy pills?
Quote
Yes, if you need specific features that were introduced in a specific version greater than 3.0.
Even if I choose any specific version number I always get the higher supported version... I can assure you that this feature worked in the past. I remember creating a 2.1 or 3.3 context without any trouble. Am I taking crazy pills or am I taking a lot of crazy pills?
25
Window / Re: Force OpenGL Context
« on: November 26, 2012, 06:35:07 pm »
Oh I see, thank you for your inputs Laurent,
It’s beyond the scope of this thread but I’m guessing you’ve been there before. I’m using VMware 9 on Windows 8 to do testing on Ubuntu and OSX. AFAIK, VMware only supports OpenGL 2.1 and I need to downgrade my OpenGL features for testing purposes. I’m open for suggestions in how to achieve this, if that make any sense to you.
It’s beyond the scope of this thread but I’m guessing you’ve been there before. I’m using VMware 9 on Windows 8 to do testing on Ubuntu and OSX. AFAIK, VMware only supports OpenGL 2.1 and I need to downgrade my OpenGL features for testing purposes. I’m open for suggestions in how to achieve this, if that make any sense to you.
26
Window / Re: Force OpenGL Context
« on: November 25, 2012, 07:32:30 am »Quote
It's then the driver who decides to create a greater version.
Oh, my apologies! As I read your code, it seemed like you where cycling to the highest supported context explicitly. My question is, is there a point in passing the version number when creating a context?
27
Window / Re: Force OpenGL Context
« on: November 23, 2012, 10:38:08 pm »
Don't get me wrong, it’s a very good feature but allowing to create a specific context version (as long as it is supported) would be very handy.
The point is, debugging a 4.2 context to make sure it will run on a system that only support 2.1 is rather painful and It makes a big difference.
I suggest to process the requested context version before:
wglContext.cpp
while (!m_context && (m_settings.majorVersion >= 3))
if the version number is past explicitly and it is supported simply stop there and voila.
The point is, debugging a 4.2 context to make sure it will run on a system that only support 2.1 is rather painful and It makes a big difference.
I suggest to process the requested context version before:
wglContext.cpp
while (!m_context && (m_settings.majorVersion >= 3))
if the version number is past explicitly and it is supported simply stop there and voila.
28
Window / Re: Force OpenGL Context
« on: November 23, 2012, 08:44:38 pm »
hum, the thing is I'd like to test different Opengl configuration depending on the user's machine. Is there a way to set the context version as being requested?
29
Window / Force OpenGL Context
« on: November 23, 2012, 07:36:59 pm »
Greetings,
When creating a window I do:
sf::ContextSettings l_settings;
l_settings.majorVersion = 2;
l_settings.minorVersion = 1;
but when I retrieve the info:
mywindow.getSettings().majorVersion
mywindow.getSettings().minorVersion
I get (4 and 2)
How do I force a 2.1 context?
Thx
When creating a window I do:
sf::ContextSettings l_settings;
l_settings.majorVersion = 2;
l_settings.minorVersion = 1;
but when I retrieve the info:
mywindow.getSettings().majorVersion
mywindow.getSettings().minorVersion
I get (4 and 2)
How do I force a 2.1 context?
Thx
30
Feature requests / Make OpenAL32.dll invisible
« on: July 07, 2012, 10:42:09 pm »
Greetings,
Would be nice to remove the openal32.dll depndency. Could OpenAL be staticly linked against SFML Audio?
THX
Would be nice to remove the openal32.dll depndency. Could OpenAL be staticly linked against SFML Audio?
THX