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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - graphitemaster

Pages: [1]
1
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.

2
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.

4
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?

5
General discussions / SFML: X11 Window Class does not free X11 properly!
« on: October 12, 2010, 05:58:14 am »
It's come to my concern that SFML causes tons of problems when running the simplest of things through valgrind. It seems as if SFML is not freeing X11 properly period, now I could be wrong about this I never looked at the source as I don't have it available, I do however have the headers, so I decided to take a peek it seems as if

 priv::WindowImpl* myWindow;         ///< Platform-specific implementation of window

which is a pointer, is never freed, now this could be handled somewhere else, and freed I'm not exactly sure. Valgrind reports tons of errors, regarding libX11 which can be seen is handled by libSFML. I went out of my way and made a mini test using libX11 and freeing everything myself and it passed valgrind -100%- however the same usage in SFML reported tons of errors, this is how I know SFML is not freeing X11 properly.

I have included a link below of the valgrind output on pastebin.com
I would like to see this fixed because I'm very retentive about memory
leaks and corruption, and when I'm testing my own code in valgrind I hate to
see my console, or a file that I have piped the valgrind output to be filled
with issues regarding SFML and X11, but rather the issue involved in my
code, so I can fix it.

VALGRIND: http://pastebin.com/hZ198eL4

Pages: [1]
anything