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

Author Topic: ATI fix  (Read 4398 times)

0 Members and 1 Guest are viewing this topic.

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32397
    • View Profile
    • SFML's website
    • Email
ATI fix
« on: March 21, 2011, 08:11:36 am »
Yes... finally... it's there :D

The other good news is that sf::Context is not necessary anymore in threads. And it was not transformed to sf::GraphicsContext or whatever, I managed to simply get rid of it.

Note that this is a first step, now there might be bugs to fix. My next task is to make sf::RenderImage more robust (and cleaner internally), it has too many bugs and maybe more now with the ATI fix.

Note: I tried to adapt the Linux and OS X code as well but couldn't compile, so let me know if there's something stupid that needs to be fixed.
Laurent Gomila - SFML developer

devlin

  • Full Member
  • ***
  • Posts: 128
    • View Profile
ATI fix
« Reply #1 on: March 21, 2011, 08:59:28 am »
Excellent news!

I'll make sure to give it a try after work ;)

Groogy

  • Hero Member
  • *****
  • Posts: 1470
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
ATI fix
« Reply #2 on: March 21, 2011, 09:52:13 am »
Hallelujah!

Seems like I got a lot of work to do :)
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32397
    • View Profile
    • SFML's website
    • Email
ATI fix
« Reply #3 on: March 21, 2011, 09:57:57 am »
Quote
Seems like I got a lot of work to do

Why? Nothing at all changed in the public API -- only a function in sf::Shader.
Laurent Gomila - SFML developer

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1491
    • View Profile
    • Blog
    • Email
ATI fix
« Reply #4 on: March 21, 2011, 10:05:15 am »
Compiles fine on Linux, also applications seem to be still okay with my NVidia card. ;)

However 2 warnings appeared. Patch here.

Code: [Select]
src/SFML/Graphics/Linux/RenderImageImplPBuffer.cpp: In constructor ‘sf::priv::RenderImageImplPBuffer::RenderImageImplPBuffer()’:
src/SFML/Graphics/Linux/RenderImageImplPBuffer.cpp:43:12: warning: converting to non-pointer type ‘GLXPbuffer’ from NULL
src/SFML/Graphics/Linux/RenderImageImplPBuffer.cpp: In member function ‘virtual bool sf::priv::RenderImageImplPBuffer::Create(unsigned int, unsigned int, unsigned int, bool)’:
src/SFML/Graphics/Linux/RenderImageImplPBuffer.cpp:138:45: warning: passing NULL to non-pointer argument 2 of ‘int glXMakeCurrent(Display*, GLXDrawable, __GLXcontextRec*)’


Edit: Just recognized, the third parameter for the glXMakeCurrent() call may still be NULL. However 0 is just fine for NULL in C++, so I'd propose to get rid of that ugly constant. ;)

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32397
    • View Profile
    • SFML's website
    • Email
ATI fix
« Reply #5 on: March 21, 2011, 10:13:32 am »
Thanks :)

It's hard to see when an integer is hidden behind one of these typedefs, instead of a pointer.

Quote
However 0 is just fine for NULL in C++, so I'd propose to get rid of that ugly constant.

I like NULL especially because of this: we know that it's not an integer. And it will be much easier to replace it by nullptr in the whole project, when it's time to switch to the new standard.
Laurent Gomila - SFML developer

Tank

  • SFML Team
  • Hero Member
  • *****
  • Posts: 1491
    • View Profile
    • Blog
    • Email
ATI fix
« Reply #6 on: March 21, 2011, 10:14:22 am »
Good point.

Groogy

  • Hero Member
  • *****
  • Posts: 1470
    • MSN Messenger - groogy@groogy.se
    • View Profile
    • http://www.groogy.se
    • Email
ATI fix
« Reply #7 on: March 21, 2011, 11:26:32 am »
Quote from: "Laurent"
Quote
Seems like I got a lot of work to do

Why? Nothing at all changed in the public API -- only a function in sf::Shader.


Wut? Oh I missed the not here:

Quote from: "Laurent"
And it was not transformed to sf::GraphicsContext or whatever,


So I have to do nothing? Cool!
Developer and Maker of rbSFML and Programmer at Paradox Development Studio

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32397
    • View Profile
    • SFML's website
    • Email
ATI fix
« Reply #8 on: March 21, 2011, 11:28:33 am »
There's just one modification to report in bindings, in sf::Shader::SetTexture: it's now split in SetTexture and SetCurrentTexture.
Laurent Gomila - SFML developer

pdinklag

  • Sr. Member
  • ****
  • Posts: 330
  • JSFML Developer
    • View Profile
    • JSFML Website
ATI fix
« Reply #9 on: March 21, 2011, 03:21:24 pm »
I'm so trying this now. :)
JSFML - The Java binding to SFML.

Nemex

  • Newbie
  • *
  • Posts: 1
    • View Profile
    • http://www.nexsoft.de
ATI fix
« Reply #10 on: March 27, 2011, 07:38:15 pm »
Absolutely awesome work on this! All works now perfectly for me. Really great job, keep up the hard work :) Even gDEBugger started working again, it segfaulted earlier. I knew switching from SDL to SFML was a good thing even with minor bugs. Now there is not a single reason to go back, thanks a lot^^

Ah forgot, for reference: I'm running an ATI HD4670 on Fedora Core 14 x86_64

Brendon

  • Jr. Member
  • **
  • Posts: 83
    • View Profile
    • http://blendogames.com
ATI fix
« Reply #11 on: April 01, 2011, 12:48:24 am »
That's wonderful news!

What versions of SFML is this applicable to?  SFML2?

Laurent

  • Administrator
  • Hero Member
  • *****
  • Posts: 32397
    • View Profile
    • SFML's website
    • Email
ATI fix
« Reply #12 on: April 01, 2011, 08:18:51 am »
Quote
What versions of SFML is this applicable to? SFML2?

Yes, SFML 1.x is not maintained anymore.
Laurent Gomila - SFML developer

 

anything