What is SFML_SYSTEM_API for(and others)?

[greeniekin]

I just though i would add a class to my sfml system lib to make some things easier things.

i copied clock and based it off that largely(also editing cmake and system.hpp). It has a sections in the header like this.

class SFML_SYSTEM_API Clock

I have pretty much the same thing

class SFML_SYSTEM_API DateTime

I get this error

error: variable 'sf::SFML_SYSTEM_API sf::DateTime' has initializer but incomplete type

When i remove SFML_SYSTEM_API  from my class definition it compiles and also works in my example program. So i do not really get why it is there and why it will not accept my class.
(I may post full class code later after hearing what it is, and if i can not solve it from that.)

I appreciate any help you guys can give me.

[jDralliam]

It's a platform-dependant macro, defined in Config. It is used to export symbols, when linking SFML dynamically.

[Groogy]

SFML_SYSTEM_API is a define done in Config.hpp that more or less defines that are compiler specific and defines the output of the binary. So for instance if we want to create a shared library(.DLL/.so) we will put in the required compiler flags/defines/declarations in that define. The code for that Laurent have already done so you just have to put that define in front of the class.

Why it isn't working as intended and you get an error I don't know. I've never had any problem and I have defined my own SFML classes(check my SFML github repo where I have added MRT and HDR rendering)

[Nexus]

Is there a reason you want this to be part of SFML? I mean, you can easily implement that class outside SFML, then you have fewer problems when it comes to library distributions or updates.

[greeniekin]

thanks jDralliam. That helped me realize that i had deleted this because i didn't know what it was and figured i did not need it.

#include <SFML/System/Export.hpp>

Groogy it is funny that you mentioned MRT as I had implemented that then and was trying to do Deferred shading.

Nexus I figured this question would come up.
Pretty much I wanted to mainly use openGL and try make some 3d stuff. SFML had these really powerful classes that could simplify some annoying things and I was already using it.
I thought inheriting these classes to add functionality would work. Though it usually doesn't as critical parts are private or the way it is designed makes it not work. So I started editing classes and started making it a personal hacked version. So i figure I may add some features I want elsewhere rather than bloating my project files, or making a separate libraries of my own. Like a dateTime feature and a modified file time function. So I can load changed scripts or files on the fly without restarting the app.

[Groogy]

Groogy it is funny that you mentioned MRT as I had implemented that then and was trying to do Deferred shading.

If you had any problems with it have a look at my MultipleRenderTextures class to see how to get it up and working
I also modified the Shader example to use the MRT to show a usage example of it. I didn't do real deferred rendering with depths, albedo and normals as it would have made the example too complex and it would need it to include opengl but I wrote to a "geometry buffer" and then put it together in an accumulation pass just like in real deferred rendering.

Now I am just waiting hoping that Laurent will have a look at it and say "OKAY! Let's add it in ^^"

[greeniekin]

Groogy I'll have a look at it. I can not imagine MRT would be useful for the 2d api. I could not find MultipleRenderTextures in your github page.

I didn't have much trouble with the MRT and I created the textures for the FBO with opengl. As i wanted floating point for some things. The sfml shader class worked well. Though now I need to attach my g-buffer textures to the shader, and there is no way to do it with the current shader class.

So i'm thinking of makeing an fbo class, as well as a modified texture class with more options and make sure the shader class works with it all. do not know if it is worth having a render buffer class. Maybe make that just part of the fbo.

[Groogy]

My Modified SFML version -> https://github.com/Groogy/SFML
It's in there together with textures that can have different formats.

And you are probably right. I am more a advanced 3D user and thus I like deferred rendering. But let's say we have been seeing awful lot advanced lighting in games. Deferred rendering is a way to remove the complexity of a scene based on geometry and lighting.

The traditional way of doing it have a scene complexity of meshes * lights while deferred rendering have meshes + lights making it much more efficient.

Looking at it from this perspective you can start to see a use of this in 2D games as well I think. Of course right now I am just taking ideas straight from my head as I type. But if we look at the 2D lighting system that has been posted on the project forum and we apply deferred rendering to that one. I am pretty certain that system would be able to handle over 1000 light sources. At least my 3D engine with a naive implementation of deferred rendering can render a 1000 light sources with 400 meshes in view with a FPS of 60.

None the less we shouldn't be thinking of "what can you do with it?" we should be more going in the line of "What tools could you possibly need?" And I will agree that deferred rendering is a bit far-fetched but not that far if you take a step back.

[greeniekin]

I suppose i can see some value of something like this in a 2d engine. For instance even if it is not mesh models being loaded attaching an optional spec map and normal map could make an amazing 2d game. Even not bothering with shadows.

The simple space invaders games could have detailed spacships and as a laser flies by it lights the objects normally.

Though having meshes and models you will probably end up with scene managers and start to become more 3d engine.

Deferred shading will likely be an issue on phones(which i assume is a goal of sfml). Even the xbox360 can not deal with differed shading without doing sections of the screen separately(or so i read).

Maybe it might be worth making something called "graphics3d"
where you only include that and not the 2d api. otherwise it would be confusing with the different classes like shader and texture which will not work that well. Which it sounds like your pretty much doing anyway, as well  as me and probably a couple other people.

Though it is hard to know when you have gone to far and it may as-well be ogre3d.

Edit:


Also i had a look at your classes and tried to compile your stuff. Under mingw i get cimpile errors, because you have "Float" with a capital. I changed it to "float" and it seems better.