Author Topic: ATI fix (Read 7646 times)

Laurent · « **on:** March 21, 2011, 08:11:36 am »

Yes... finally... it's there

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.

devlin · « **Reply #1 on:** March 21, 2011, 08:59:28 am »

Excellent news!

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

Groogy · « **Reply #2 on:** March 21, 2011, 09:52:13 am »

Hallelujah!

Seems like I got a lot of work to do

Laurent · « **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.

Tank · « **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 · « **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.

Tank · « **Reply #6 on:** March 21, 2011, 10:14:22 am »

Good point.

Groogy · « **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!

Laurent · « **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.

pdinklag · « **Reply #9 on:** March 21, 2011, 03:21:24 pm »

I'm so trying this now.

Nemex · « **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 · « **Reply #11 on:** April 01, 2011, 12:48:24 am »

That's wonderful news!

What versions of SFML is this applicable to? SFML2?

Laurent · « **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.