SFML community forums

General => General discussions => Topic started by: Laurent on March 21, 2011, 08:11:36 am

Title: ATI fix
Post by: Laurent 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.

Title: ATI fix
Post by: devlin on March 21, 2011, 08:59:28 am

Excellent news!

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

Title: ATI fix
Post by: Groogy on March 21, 2011, 09:52:13 am

Hallelujah!

Seems like I got a lot of work to do :)

Title: ATI fix
Post by: Laurent 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.

Title: ATI fix
Post by: Tank 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 (http://dl.dropbox.com/u/10016269/linux_renderimage_warnings.patch).

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. ;)

Title: ATI fix
Post by: Laurent 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.

Title: ATI fix
Post by: Tank on March 21, 2011, 10:14:22 am

Good point.

Title: ATI fix
Post by: Groogy 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!

Title: ATI fix
Post by: Laurent 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.

Title: ATI fix
Post by: pdinklag on March 21, 2011, 03:21:24 pm

I'm so trying this now. :)

Title: ATI fix
Post by: Nemex 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

Title: ATI fix
Post by: Brendon on April 01, 2011, 12:48:24 am

That's wonderful news!

What versions of SFML is this applicable to?  SFML2?

Title: ATI fix
Post by: Laurent 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.