[SOLVED] SFML 1.2 RC

[Laurent]

Hi

I'm going to release the version 1.2 of SFML (probably by the end of the month).

Before releasing it, I need to make sure that everything is still working fine and no new bug have been introduced.

So, everyone who can use SVN is invited to get, compile and run the current version, and report any bug.

The list of what have been done since last version is still on the roadmap page of the website.

The C wrapper for SFML is also available, under the CSFML folder. All the packages except Graphics have been wrapped and are ready to be tested. I'm going to finish the Graphics wrapper very soon.

Please note that the MacOS port, as well as RubySFML have not been updated yet.

Thanks

[Lord Delvin]

Ubuntu 7.10 am64:
I had to change graphics to shared lib to build at all. I got

Code: [Select]


/usr/bin/ld: ./libjpeg/jcapimin.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
./libjpeg/jcapimin.o: could not read symbols: Bad value
(this will appear for all libs, tried that:) )

After some changes regarding windowstyle and rebuilding my project I got the following error during startup:

Code: [Select]


BF][: SOIL/stb_image_aug.c:1568: fill_bits: Assertion `code_buffer < (1U << num_bits)' failed.
./valtest.sh: line 1: 15033 Aborted                 (core dumped) valgrind --log-file-exactly=valgrind.txt --leak-check=full ./BF\]\[ > out.txt


Edit: graphics is build with(dont know if this is really usefull information)

Code: [Select]

g++ -shared -Wl,-soname,libsfml-graphics.so.1 -o ../../../lib/libsfml-graphics.so.1 Color.o Drawable.o FontManager.o GraphicsDevice.o Image.o ImageLoader.o PostFX.o RenderWindow.o Sprite.o String.o VideoResource.o View.o ./libjpeg/jcapimin.o ./libjpeg/jcapistd.o ./libjpeg/jccoefct.o ./libjpeg/jccolor.o ./libjpeg/jcdctmgr.o ./libjpeg/jchuff.o ./libjpeg/jcinit.o ./libjpeg/jcmainct.o ./libjpeg/jcmarker.o ./libjpeg/jcmaster.o ./libjpeg/jcomapi.o ./libjpeg/jcparam.o ./libjpeg/jcphuff.o ./libjpeg/jcprepct.o ./libjpeg/jcsample.o ./libjpeg/jctrans.o ./libjpeg/jdapimin.o ./libjpeg/jdapistd.o ./libjpeg/jdatadst.o ./libjpeg/jdatasrc.o ./libjpeg/jdcoefct.o ./libjpeg/jdcolor.o ./libjpeg/jddctmgr.o ./libjpeg/jdhuff.o ./libjpeg/jdinput.o ./libjpeg/jdmainct.o ./libjpeg/jdmarker.o ./libjpeg/jdmaster.o ./libjpeg/jdmerge.o ./libjpeg/jdphuff.o ./libjpeg/jdpostct.o ./libjpeg/jdsample.o ./libjpeg/jdtrans.o ./libjpeg/jerror.o ./libjpeg/jfdctflt.o ./libjpeg/jfdctfst.o ./libjpeg/jfdctint.o ./libjpeg/jidctflt.o ./libjpeg/jidctfst.o ./libjpeg/jidctint.o ./libjpeg/jidctred.o ./libjpeg/jmemmgr.o ./libjpeg/jmemnobs.o ./libjpeg/jquant1.o ./libjpeg/jquant2.o ./libjpeg/jutils.o ./libpng/png.o ./libpng/pngerror.o ./libpng/pnggccrd.o ./libpng/pngget.o ./libpng/pngmem.o ./libpng/pngpread.o ./libpng/pngread.o ./libpng/pngrio.o ./libpng/pngrtran.o ./libpng/pngrutil.o ./libpng/pngset.o ./libpng/pngtrans.o ./libpng/pngvcrd.o ./libpng/pngwio.o ./libpng/pngwrite.o ./libpng/pngwtran.o ./libpng/pngwutil.o ./SOIL/image_DXT.o ./SOIL/SOIL.o ./SOIL/stb_image_aug.o ./zlib/adler32.o ./zlib/compress.o ./zlib/crc32.o ./zlib/deflate.o ./zlib/inffast.o ./zlib/inflate.o ./zlib/inftrees.o ./zlib/trees.o ./zlib/uncompr.o ./zlib/zutil.o -lfreetype

[Laurent]

Code: [Select]

/usr/bin/ld: ./libjpeg/jcapimin.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC

Oops, I forgot to use -fPIC for external C libraries in the Linux makefiles. I'll add it, thanks.

Code: [Select]

SOIL/stb_image_aug.c:1568: fill_bits: Assertion `code_buffer < (1U << num_bits)' failed.

What type of image are you trying to load ? Are you sure it is a valid one ? Can you upload it somewhere, so that I can do more testing ?

[Lord Delvin]

What type of image are you trying to load ? Are you sure it is a valid one ? Can you upload it somewhere, so that I can do more testing ?

[...]

Edit:
It crashs before main in normal execution and using valgrind it passes until initialisation of the window(it pops up and imidiately crashes without any texture creation so I'd guess I missed to link with something).

[CareBear]

Hurray!

I'm happy to hear that the C-Interface is implemented.
I hope somebody will make bindings for "D" (http://www.digitalmars.com/d/index.html), otherwise I'll need to try it

[Srejv]

Code: [Select]

make[1]: Entering directory `/root/sfml/src/SFML'
make[2]: Entering directory `/root/sfml/src/SFML/System'
g++ -o Clock.o -c Clock.cpp -W -Wall -pedantic -fPIC -I../.. -DNDEBUG -O2
g++ -o Lock.o -c Lock.cpp -W -Wall -pedantic -fPIC -I../.. -DNDEBUG -O2
g++ -o Randomizer.o -c Randomizer.cpp -W -Wall -pedantic -fPIC -I../.. -DNDEBUG -O2
g++ -o Sleep.o -c Sleep.cpp -W -Wall -pedantic -fPIC -I../.. -DNDEBUG -O2
g++ -o Unix/Mutex.o -c Unix/Mutex.cpp -W -Wall -pedantic -fPIC -I../.. -DNDEBUG -O2
g++ -o Unix/Platform.o -c Unix/Platform.cpp -W -Wall -pedantic -fPIC -I../.. -DNDEBUG -O2
g++ -o Unix/Thread.o -c Unix/Thread.cpp -W -Wall -pedantic -fPIC -I../.. -DNDEBUG -O2
g++ -shared -Wl,-soname,libsfml-system.so.1 -o ../../../lib/libsfml-system.so.1 Clock.o Lock.o Randomizer.o Sleep.o ./Unix/Mutex.o ./Unix/Platform.o ./Unix/Thread.o -lpthread
make[2]: Leaving directory `/root/sfml/src/SFML/System'
make[2]: Entering directory `/root/sfml/src/SFML/Window'
g++ -o Input.o -c Input.cpp -W -Wall -pedantic -fPIC -I../.. -DNDEBUG -O2
g++ -o OpenGLCaps.o -c OpenGLCaps.cpp -W -Wall -pedantic -fPIC -I../.. -DNDEBUG -O2
g++ -o VideoMode.o -c VideoMode.cpp -W -Wall -pedantic -fPIC -I../.. -DNDEBUG -O2
g++ -o Window.o -c Window.cpp -W -Wall -pedantic -fPIC -I../.. -DNDEBUG -O2
g++ -o WindowImpl.o -c WindowImpl.cpp -W -Wall -pedantic -fPIC -I../.. -DNDEBUG -O2
g++ -o Linux/Joystick.o -c Linux/Joystick.cpp -W -Wall -pedantic -fPIC -I../.. -DNDEBUG -O2
Linux/Joystick.cpp:36: error: expected constructor, destructor, or type conversion before 'namespace'
make[2]: *** [Linux/Joystick.o] Error 1
make[2]: Leaving directory `/root/sfml/src/SFML/Window'
make[1]: *** [sfml-window] Error 2
make[1]: Leaving directory `/root/sfml/src/SFML'
make: *** [sfml] Error 2

Using gentoo, gcc. Latest svn (362).  

[Lord Delvin]

Hurray!

I'm happy to hear that the C-Interface is implemented.
I hope somebody will make bindings for "D" (http://www.digitalmars.com/d/index.html), otherwise I'll need to try it

Isn't C a subset of D as in C++?

[CareBear]

...

Yes, but they still need by declared by a "extern (C)".

See: http://www.digitalmars.com/d/interfaceToC.html

So should no big thing.

[Laurent]

Linux/Joystick.cpp:36: error: expected constructor, destructor, or type conversion before 'namespace'

Yep, a bad copy and paste. It's ok now.

[T.T.H.]

Hi there!

I recently stumbled over SFML and have to admit that I really, really like its OOP design and intuitive API (after spending weeks over weeks on getting SDL surfaces in the right color layout pattern which fits my needs regarding performance and transparency *ugh*)

All the packages except Graphics have been wrapped and are ready to be tested. I'm going to finish the Graphics wrapper very soon.

Please give us a hint when you're done with that because I'd be most/only interested in the graphics part of SFML and would happily test your RC (if my spare time before christmas permits *sigh*)

In addition I'd really welcome if the "SFML vs SDL benchmarking tool" you wrote will get part of the SFML repository, just like all the other examples. I intend to experiment a bit with that because after I ported my little prototype from SDL to SFML the performance actually got much, much worse and currently I have absolutely no clue why the software rendering of SDL is so much better than the OpenGL powered hardware rendering of SFML in my personal case. And I want to find out why.

Finally I'd suggest to put some images/screenshots in the tutorial section of the SFML website (at least the graphic related part) because a picture can say more than thousand words. Most people looking for multimedia libraries want to see what the advertised library can accomplish and not necessarily read how the coding part works (well, real geeks go nuts about such stuff, too).

Bye,
T.T.H.

[Laurent]

Please give us a hint when you're done with that because I'd be most/only interested in the graphics part of SFML and would happily test your RC (if my spare time before christmas permits *sigh*)

Sure

In addition I'd really welcome if the "SFML vs SDL benchmarking tool" you wrote will get part of the SFML repository, just like all the other examples

You can get the latest version here, compiled with SFML 1.2 RC :
http://sfml.sourceforge.net/temp/bench-sdl-sfml.zip

I intend to experiment a bit with that because after I ported my little prototype from SDL to SFML the performance actually got much, much worse and currently I have absolutely no clue why the software rendering of SDL is so much better than the OpenGL powered hardware rendering of SFML in my personal case. And I want to find out why.

If you really get problems with it, you can post your code here on the forum, so that we can have a look at it.

Finally I'd suggest to put some images/screenshots in the tutorial section of the SFML website (at least the graphic related part) because a picture can say more than thousand words. Most people looking for multimedia libraries want to see what the advertised library can accomplish and not necessarily read how the coding part works (well, real geeks go nuts about such stuff, too).

In fact there is not much to show, even in the graphics tutorials. For people who want to see screenshots, I've put some old ones on the SF.net page (there's a screenshot page).
I think the most impressive to show will be the coming real-size projects using SFML

Thanks for your feedback.

[Laurent]

The C wrapper is now 100% complete.

For the moment, only Visual Studio 2005 project files are provided, but I'm going to add Linux makefiles soon.

[T.T.H.]

If you really get problems with it, you can post your code here on the forum, so that we can have a look at it.

Ooookay, that's an offer

I've now (within the last 2 hours) written a minimalistic program to demonstrate my performance issues. Sourcecode can be found here and a ZIP file including a VS2005 project, an image, the required libraries and a precompiled binary can be found here.

There is two variables called SPRITE_WIDTH_DEST and SPRITE_HEIGHT_DEST at the beginning of the code which define the output size of the sprite which then gets drawn all over the 800x600 screen. The input size of the sprite is 32x32 pixel from the center of a 96x96 pixel image. The results are the following (numbers are the output sprite size):

SFML 100x100: 106 FPS
SDL 100x100: 103 FPS
SFML 32x32: 11 FPS
SDL 32x32: 122 FPS
SFML 10x10: 2 FPS
SDL 10x10: 114 FPS

As you can see SFML gets a major drop in FPS when you scale down the output sprite size while SDL can keep up nearly the same FPS. I am really wondering why...

SFML version: subversion repository as of 1. December 2007
SDL version: 1.2.11
SDLgfx version: 2.0.16

My computer is a AMD Athlon XP 2000+ running at 1.7 GHz with 1 GB Ram and a Sapphire ATI Radeon 9800 Pro with 128 MB Ram. Operation system is Windows 2000 and I am using Visual Studio 2005 Express.

[Laurent]

The new version introduces a safer but slower code (related to internal states). If you're not going to mix with custom OpenGL calls, you can disable it to get the maximum performances.
Try to add this magic line after the RenderWindow creation :

Code: [Select]

MyRenderWindow.OptimizeForNonOpenGL(true);

[T.T.H.]

Try to add this magic line after the RenderWindow creation :

Code: [Select]

MyRenderWindow.OptimizeForNonOpenGL(true);

Ooookay, nice hint:

SFML 100x100: 106 FPS -> 1170 FPS
SFML 32x32: 11 FPS -> 500 FPS
SFML 10x10: 2 FPS -> 70 FPS

Why not make this the default? Performance is one of the key features people do care about when stumbling over new libraries.

Can you maybe automatically disable that optimization when you "give out" the handles one needs for custom OpenGL calls?

If developers came so far to cram custom OpenGL calls into SFML's API then they should have already come across the warning in the documentation "to ensure safe mixing SFML and custom OpenGL calls please disable optimiziation by...".

Just my 2 cents. And thanks for the hint!