Messages

1

Feature requests / System Info

« on: December 14, 2010, 08:04:28 pm »

Why don't you use this library?

Because it's LGPL.

2

Feature requests / System Info

« on: December 12, 2010, 11:34:40 pm »

I'm requesting a SystemInfo class for the System library that ships with SFML, something like: http://www.hyperic.com/products/sigar These systems are not hard to implement, I actually wrote my own LinuxSystemInfo class that uses <sys/sysinfo.h>, with MacOS there is some other things that need to be done, and Windows requires the use of the WinAPI or requires the use of registry searches, which in turn requires a different search method for each Windows OS. At first I figured it would be out of the scope of SFML, but then I understand that SFML has a A+ System library for unicode, and threads mutxes locks and even a clock, so why can't it have a SystemInfo class. Anyways below is a implementation for getting linux system info. http://codepad.org/XtiR8XAn so theres a start, now just fill in for Mac and Windows and you have a SystemInfo class that people like me would love to use.

3

Feature requests / Re: Direct3D Support

« on: December 11, 2010, 12:59:20 pm »

I would be glad to help you do this, I have already done this a few times myself for game engine ports, I just wish you could use a more 'open' version control like git ( see www.github.com ). So I'm just going to ask do you want another developer to help you with Direct3D support.  Please note that it will not break any cross platform compatibility it's just an option for those on Windows or are developing for Microsoft's game console, in addition it would introduce a lot more Direct3D fan boys, and would probably help with game console support once others see such feature.

Here you have a statement of Laurent concerning distributed version control systems:

I agree with this. Distributed systems like Git / Mercurial make branching and developing your own contribution really easy.

However I don't really want people to start creating branches, developing their own stuff (sometimes huge contributions), and submit it to me. SFML is not a community project, I like controlling and implementing stuff myself, and I like the current system where people write their requests or submit their patches here

I can still svn import that into a git branch and fork,thats the beauty of opensource.

4

General / It's a Driver issue

« on: December 11, 2010, 08:22:36 am »

the output of the backtrace looks like a driver issue, what does glxinfo report? if you don't have glxinfo installed use sudo apt-get install mesa-utils

chances are you're using some Ubuntu driver which are usually outdated, anyways just run glxinfo and paste it on pastebin and paste the pastebin link in here.

5

Feature requests / DO NOT USE BOOST

« on: December 11, 2010, 07:55:04 am »

Boost is a nice set of libraries, but I would never recommend them to anyone unless they're lazy, a FileSystem class is pretty simple to write, and should not be out of the scope for SFML at all. I had to write one awhile back for my 3d Engine, anyways if you're interested you can get it here:

https://github.com/graphitemaster/Kill--Field-Engine/blob/master/Source/Tools/FileSystem.hpp
https://github.com/graphitemaster/Kill--Field-Engine/blob/master/Source/Tools/FileSystem.cpp

you will need to do some editing to the Engine::Print and Tools::FormatString functions, and also some types which should not be hard.

Types::uint    = unsigned int
Types::uchar = unsigned char
Types::ulong = unsigned long

also what good is a file system without some type of compression system, without further ado here ya go a full GZip class requires ZLIB
https://github.com/graphitemaster/Kill--Field-Engine/blob/master/Source/Tools/Compression.hpp
https://github.com/graphitemaster/Kill--Field-Engine/blob/master/Source/Tools/Compression.cpp

6

Feature requests / Direct3D Support

« on: December 11, 2010, 07:40:48 am »

EDIT: I see stb_image use in the SFML2 branch, this also will work with Direct3D, so no need to use DirectX at all.

7

Feature requests / Direct3D Support

« on: December 11, 2010, 07:35:35 am »

It has come to my understanding many times that SFML is a OpenGL inspired multimedia library, and I accept this as I find OpenGL a much more solid structured library to work with when it comes to graphics not to mention that fact that is multiplatform compatible, I.E Windows, *Nix and Mac.

However I have hit a snag at porting my 3D engine to the Microsoft XBOX360 game console, see Microsoft is the proud producer of Direct3D and they decided to keep OpenGL based applications from running as official released games on their platform.  So I have performed what any sane man could attempt, recreate a context using the WinAPI and Direct3D, however this is far from anything sane, considering I still have to process events, input, not to mention SFML only has a OpenGL shader system and texture loader / binder plus the sprite system and a umpteen of other things that are OpenGL only.

So I was considering the possibility of abstracting the OpenGL stuff into it's own class that can inherit a RendererOpenGL or RendererD3D class to perform it's hard work, I've looked at the code base a few times and 99% of the work is done, the window handle and context is all there and because of this a simple Direct3D option could be a toggleable option using a preprocessor directive such as #define SFML_OPENGL or #define SFML_DIRECT3D.  In addition the Music / Network systems don't even have to be touched, since the music uses OpenAL which is perfectly fine as a stand alone things and the Network system again applies. As for texture loading and mapping you can just wrap those up and write alternatives, or even use some stuff found in DirectX, but I rather you stayed away from the entire library because it changes too often to keep up with.

I would be glad to help you do this, I have already done this a few times myself for game engine ports, I just wish you could use a more 'open' version control like git ( see www.github.com ). So I'm just going to ask do you want another developer to help you with Direct3D support.  Please note that it will not break any cross platform compatibility it's just an option for those on Windows or are developing for Microsoft's game console, in addition it would introduce a lot more Direct3D fan boys, and would probably help with game console support once others see such feature.

What do you think, the context is there, the process events are there the network, sound, music, and system core's don't need to be touched the only thing that needs to be changes is the graphics area by abstracting everything and using those and then everything itself can be changed in only 4 files, 2.hpp and 2.cpp a set for OpenGL and a set for Direct3D, I would be glad to help, I'm around all the time, let me know what you think.

8

General discussions / Window Resize, Causes Major Window Glitching

« on: October 15, 2010, 03:40:35 pm »

Anyone care to exaplain this; http://dl.dropbox.com/u/9008220/whatthehellisthiswhatwhatwhat.ogv

9

General discussions / SFML needs a glGetProcAddress();

« on: October 13, 2010, 08:58:58 am »

SFML doesn't handle OpenGL extensions, there are already good libraries dedicated to this job (GLEW, GLEE).

BOTH BAD LIBRARIES, REALLY BAD LIBRARIES
GLEW, and GLEE, are the worst things anyone
could, and should ever use.

10

General discussions / SFML needs a glGetProcAddress();

« on: October 13, 2010, 08:03:31 am »

This has been bugging me for quite some time, SFML does not have it's own variant of glGetProcAddress(), which can be really annoying at times, especially when coding minimal applications that greatly depend on the use of OpenGL extensions.

As far as I remember SDL has it's own glGetProcAddress(), and it's just a macro hack really, my game engine has its own I wrote nothing hard at all, putting this somewhere in the source, such as inside a Tools.hpp file or something could clean up 9% of SFML's platforms specific glX() and wgl() calls to get proc addresses from GL.

Pasted below is my version of a simple work around for this, note other platforms that come and go, just need their own #ifdef #endif

#ifdef WIN32
   #define glGetProcAddress(a) wglGetProcAddress(a)
#endif
#ifdef X11
   #define glGetProcAddress(a) glXGetProcAddress((const uchar*)a)
#endif

Now for those whoa re wondering about the cast, it has to be done like this because of the way X11 expects it's arguments, do note that uchar ( is a unsigned char ) I have all unsiged types typedefed in my code, because it gets repetitive writing things like:
const unsigned long:

Which would be cool if SFML did for you to, it'll make programming things for beginners a heck of a lot simpler, since they don't have to manually typedef things, note even OpenGL has it's own types, why can't SFML not?

11

General discussions / SFML: X11 Window Class does not free X11 properly!

« on: October 13, 2010, 07:53:12 am »

graphitemaster: As I told Trina last night, the only time you really need to use free is when you have an associated new as well. Just because something has a pointer doesn't mean you always need to free it, which is what it appears that you are assuming.

Perhaps reading up on pointers and memory allocation/dynamic memory a little more might make things clearer.

I am, however, glad to see that your picking through the source code has uncovered a few bugs.

You'll have to forgive me, I try to avoid pointers very much, only because they're the number one cause for memory leaks, and issues. Passing by reference is usually the smart thing to do in C++. However there is times when pointers are needed, and when then are, I usually code it to free it regardless of whether or not it should be. If she seg's then I give it a whirl in gdb where it usually tells me something like a double free, or free where there should not be, and I remove it.

the above may not always be a smart idea, but at least in the end I know everything I used has been freed properly, and we can all get on with our lifes, without worrying about memory leaks, which come and go. Please note some have come to me in the past and told me that the above was the dumbest idea that they have ever herd, I'm sorry it it is, but it was a trick that I was taught by from my teacher, and it has never failed me yet.

12

General discussions / SFML: X11 Window Class does not free X11 properly!

« on: October 12, 2010, 01:26:07 pm »

my bad, I thought we were working with memory, Tank just reminded me that
glXCreateContextAttribsARB is a const literal, sorry Laurent

13

General discussions / Re: yep and another one

« on: October 12, 2010, 01:21:09 pm »

yes in that same while loop, you need a
delete [] name; that's also not freeded

const GLubyte* name = reinterpret_cast<const GLubyte*>("glXCreateContextAttribsARB");

line 229,

http://sfml.svn.sourceforge.net/viewvc/sfml/branches/sfml2/src/SFML/Window/Linux/GlxContext.cpp?revision=1579&view=markup

String literals are not allocated dynamically, they don't need to be freed.

Maybe you should investigate a little bit more about the "leaks" that you report

thats a byte which is a uchar* which does need to be freed, in this case it's being used to store memory, thus it has to be freed.

14

General discussions / yep and another one

« on: October 12, 2010, 01:19:03 pm »

in that same while loop, you need a
delete [] name; that's also not freeded

const GLubyte* name = reinterpret_cast<const GLubyte*>("glXCreateContextAttribsARB");

line 229,

http://sfml.svn.sourceforge.net/viewvc/sfml/branches/sfml2/src/SFML/Window/Linux/GlxContext.cpp?revision=1579&view=markup

15

General discussions / another one!?

« on: October 12, 2010, 01:14:51 pm »

XVisualInfo* bestVisual = NULL;  line 184

http://sfml.svn.sourceforge.net/viewvc/sfml/branches/sfml2/src/SFML/Window/Linux/GlxContext.cpp?revision=1579&view=markup

not freed!?