Messages

106

Graphics / Re: GL_MAX_TEXTURE_IMAGE_UNITS?

« on: April 13, 2015, 08:26:19 pm »

A legitimate disadvantage OpenGL has had since the beginning in comparison to DirectX is the lack of a way to check if a feature is truly implemented in hardware or is a mix of hardware/software or even fully implemented in software.

You're such a DirectX fanboy, always going on about how superior it is over OpenGL. 

Heh, seriously though, interesting tidbit of info I wasn't aware of.

instead they sort them into hardware classes for which they had done extensive testing during development.  If you plan on supporting a wide range of graphics hardware generations, this is really the only sane thing to do.

A wide range of hardware is unfortunately, a luxury most indies don't have.

In the past, I've done pretty well just having a min spec machine, and both AMD and NVidia cards, even if it's just to switch them out on the same machine.  These days you should also test on intel graphics too, for games meant to run on low end hardware.  Beyond that, you rely on a lot of beta testing to achieve a wider range of hardware.

In the past, I used DirectX on Windows, and OpenGL on linux.  Honestly, the linux support was far, far more painful.  That wasn't always related to OpenGL issues.  Sometimes.  MESA drivers suck for anything but the most basic graphics functionality.  Other problems were related to distro variations, differences in windows managers, and 32- vs 64-bit interoperability (I couldn't build a 64-bit exe because I used a closed source physics lib which was only available 32-bit).  Fullscreen support on dual-monitor systems was a nightmare.  I only saw it through it as a labor of love.

Windows was actually pretty smooth.  But for the SFML game I'm working on now, we'll have to see how much of a "second class citizen" OpenGL is on windows.  Honestly, I'm not quite sure what to expect, and consider it one of the risks of this project.  That being said, there will be some advantages to using OpenGL across the board.  For example, I won't have to rewrite every shader in both glsl and hlsl.  And certainly, SFML is able to keep it's code cleaner, supporting only OpenGL.

Nothing speaks more words than a bunch of links to the code of SFML projects that all contain the same OpenGL code that is lacking in SFML. Often times, suggestions already fail to gain any momentum at this step, and unfortunately I think your suggestion would to.

Fair point. 

However, it may be a case of "build it, and they will come".  Most of the SFML projects I see are hobby projects with pretty basic graphics.  Not that there's anything wrong with that.  And maybe this is the user base you prefer to cater to. 

I'm actually a bit surprised SFML isn't used by more indie devs, or even full game studios.  The API is so much better than your closest direct "competitor".  If I had to guess, I'd say that many developers are scared off by the OpenGL-only back end.  That may be a combination of legit thinking (e.g. "I can't port to XBox"), and superstition (e.g. "you can't use OpenGL on windows").

I'm not advocating for a DirectX port, as I know most of the SFML team is dead set against it, for both technical and ideological reasons.  That's something I need to accept as an SFML user.  I'm just identifying it as perhaps a factor behind what might steer a professional studio away from SFML.  And how this might thin out the crowd of users interested in more advanced uses of SFML, like we have been discussing.

Maybe a couple breakthrough projects would change all that.  Again, I'm not assuming you guys care or not.  You probably don't.

Anyway, that's all a bit of a tangent.  Incidentally, here's one indie dev who very much agrees with your guys stance on OpenGL.  That post reads very much like it could have been written by the SFML team. 

Oh, and thanks for clarifying the "real programmer" comment.  I thought maybe things were getting a little tense around here. 

107

Graphics / Re: GL_MAX_TEXTURE_IMAGE_UNITS?

« on: April 13, 2015, 10:48:35 am »

In fact, the minimum allowed values are fairly generous for all but the most demanding applications if you ask me. Worrying that a program will fail to function properly because there might not be enough resources to use is not an OpenGL thing.

This doesn't make sense to me.

Maybe an SFML user is working on your new android port.  GLES2 defines a minimum texture size of 64x64.  So by your logic, nobody should use any textures larger than 64x64 on android?  That's absurd, and likely why SFML has implemented a resource check on the max texture size.  I fail to understand what's so different about texture units.

SFML's default OpenGL version on windows is 2.0, which only has a minimum number of 2 texture units for fragment programs.  Obviously most machines you encounter will have more than that.  But again, relying on the minimum isn't useful here. 

Sure, I could just enforce a higher OpenGL version.  But why would I want to artificially limit my game to run on OpenGL 3+ when I can get it to run on 2.x with a few graphics adjustments?  There's lots of old hardware out there.  Those cards may even be powerful enough to run at full graphics settings. 

Anyway, while we disagree on the above, I can respect your decision about what is and isn't in the scope of SFML.  So we can leave it there, if you like.

Having a central location for such a broad range of unrelated attributes isn't good style if you ask me.

Fair enough.
And thanks for listing which functions do already exist, or are planned.

There are 2 kinds of "Simple"...

Good explanation.  I'm glad SFML is taking the route you describe.

I don't know about you, but I find many programmers these days unreasonably assuming that they should only have to use a single library and that library has to do everything they need it to do in their specific project.

Agreed.  In the games industry, indies have flocked to Unity3D, which now also supports 2D stuff.  So yeah, that trend is definitely visible.  I can't stand working in a black box, closed source environment.  Which is why I use middleware like SFML.  It's definitely a lot more work, but the alternative is quite distasteful to me.

Seriously though, the only reason I can think of for why people ask open source libraries to implement application specific feature XYZ is because a) it would be free of charge to them and b) it would save them manhours which they could spend on something else instead. If libraries charged their users for implementing very specific features, they would probably think twice about whether they should implement it themselves instead. We develop with the community in mind, and not single users.

I'm a little disappointed in how you've interpreted this discussion.  I'm not here to get free labor out of you.  Although I do appreciate your expertise and willingness to talk here on the forum. 

Honestly, I already implemented what I needed in a fraction of the time we've both put into this thread.  I just wanted to propose what I thought might be a fairly simple change that would make SFML more useful to many users, not just me.  Shaders are not application specific.  They're a core part of SFML's API.

You may have insinuated I'm not a "real programmer" because I made this feature request.  Or maybe this was just a general rant.  Either way, I think it's best I leave that bit alone. 

Thanks again for your time.

108

General discussions / Re: static analysis of SFML

« on: April 12, 2015, 09:24:19 pm »

As you noted, it looks to me like SFML passed this test remarkably well!  Thanks for the post, minirop.

109

Graphics / Re: GL_MAX_TEXTURE_IMAGE_UNITS?

« on: April 12, 2015, 06:47:59 pm »

The scope question is legit for sure.

In general, I really like SFML's API and level of abstraction from opengl.  I also understand it's a bit of a balancing act to keep things simple, yet also reasonably powerful, flexible. and fast.

I would argue, although partially for self-serving reasons , that hardware capacity checking should be part of SFML's scope.  Even a "simple" program should verify it's ability to function properly, unless it's purely a hobby or learning pursuit.  It wouldn't necessarily have to be a complex implemenation.  It could simply be struct like ContextSettings that gets filled in with stuff like max texture size, GL_MAX_TEXTURE_UNITS, a geometry shader support check (should that be added to SFML), a mipmap support check, shader profiles supported, etc.  Then, push the responsibility to the user to do with this data what they wish.

This would be "simple" in that the casual user could totally ignore this HardwareCapabilities struct.  On the flip-side, for any more serious software release, the programmer could query it and make it's own decisions how to handle this info, and validate or alter the program's functionality (e.g. simpler shaders).  And this could be done without touching any opengl, remaining true to the spirit of SFML's "simple" API. 

By not having it, it's no more simple for a casual user, but much less simple for any programmer who is writing a serious software release.  You're basically "forcing" all those users to write this low level code themselves.  That's the opposite of simple.  Because it's like SFML does 95% of the base functionality that every fully robust app will need, but leaves that 5% where the user must delve into the very low level opengl code that SFML otherwise successfully abstracts away. 

To me, the "S" in SFML is largely about allowing me to avoid low level opengl.  But SFML also allows for layers of depth.  A casual user can create a few sprites and move them around.  A more advanced user can employ VertexArrays, Shaders, RenderTextures, etc.  The casual user can ignore those.  You guys make the use of these more advanced concepts (shaders, render textures, etc) MUCH more pleasant to work with ("simple") than writing the raw opengl.  So again, I think you have been largely successfully here.  Except, perhaps, a few little edge cases like this.

Regardless, I understand there will be different opinions on this kind of stuff.  And you guys have done a remarkable job with SFML.  So I ain't complaining, just offering a point of view on a few of these unaddressed, but arguably essential graphics features.

Once again, thanks for the discussion binary.

110

Graphics / Re: GL_MAX_TEXTURE_IMAGE_UNITS?

« on: April 12, 2015, 07:05:25 am »

Samplers source their data from texture image units.

... (cut) ...

Needing to know how many textures you can use in a specific shader stage is the same as asking how many active sampler bindings can exist for that shader stage.

Right.
i.e. "the number of textures a fragment program can use" (if the stage we're talking about is the fp)
i.e. GL_MAX_TEXTURE_IMAGE_UNITS

I do appreciate you going to the trouble to explain this.  But I'm not sure how or where I conveyed that I didn't understand it.    Anyway, let's move on.  No point debating further something we both agree on.

They also expose each shader individually and let you do things with them. The only point where SFML asks you about a stage is when you have to provide the source for the specific stage. Everything that happens after that happens at a program level. It doesn't matter whether your sf::Shader only has a vertex shader stage or only a fragment shader stage, SFML will treat it the same regardless.

Yep!
However, none of this invalidates the need to make sure my shaders will run on a particular piece of hardware, rather than simply malfunction.

This doesn't seem very user-friendly and should really only happen as a very last resort to avoid undefined behaviour.

Agreed.

The question now then is: If this is possible, why not work bottom up and make sure that the shader stays simple enough to function on all hardware that is potentially supported? The limits these days are getting so large, to the point where I have to ask myself: Are people actually going to make use of this in a real-world scenario?

When you sell a game commercially on somewhere like Steam, it's surprising how old of hardware you'll find, say in eastern European countries.  For some SFML users, maybe you have to consider weaker machinery like tablets, too.  Not that I have any idea what's actually inside those, but I assume it sucks.

As we both agree, it's nice to have a graceful exit or downgraded graphics in the case of weak/unsupported hardware.  Just assuming hardware is good enough is almost always a bad idea.

Also, say in the case of graphics options, you may want to allow a range of shaders, high res textures, etc.  However, you don't want to present those options on a rig that won't run it.  Again, you need to know what hardware capabilities you're working with.  Which all goes back to my original question/concern - "how many texture units have I got to work with in a fragment program?"

You're not going to convince me I don't need to know that. 

In fact, even if you look at the SFML source for Shader.hpp, it comes with this nifty little comment:

    ////////////////////////////////////////////////////////////
    /// \brief Tell whether or not the system supports shaders
    ///
    /// This function should always be called before using
    /// the shader features. If it returns false, then
    /// any attempt to use sf::Shader will fail.
    ///
    /// Note: The first call to this function, whether by your
    /// code or SFML will result in a context switch.
    ///
    /// \return True if shaders are supported, false otherwise
    ///
    ////////////////////////////////////////////////////////////
    static bool isAvailable();
 

It makes no sense to check if shaders are supported, yet not also check that the capabilities are powerful enough to run your shaders.  You with me on this?  If not, we'll have to agree to disagree.

See, the thing about textures is that well... they're textures. The only difference between them and generic buffer objects are the samplers and texture operations that can be performed on them. In fact, OpenGL really doesn't care at all about how you end up using the data, which is why texture buffer objects exist as well. Just because you can make use of 32 samplers in a certain stage, does that mean that there really is no better alternative? I'm pretty sure there always is. The thing with textures is that they are just too easy to use and get away with. Rather than thinking of more clever ways of getting data into the shader, people just push the number of textures they end up using and obviously the GPU vendors follow suit and tailor the hardware/API to the usage patterns of the end users, the typical positive-feedback loop.

Just think about it, even in those big AAA games that are known to push GPUs to their limits, when you look at an object somewhere (normally a shader is used per material, so it is probably rebound whenever new object types are rendered) are you able to recognize all those... what... 8, 16, 32 textures that were potentially used to render it? I think textures are simply abused to do "other things", and given that OpenGL provides so many other (potentially better) ways to get the job done, there is no excuse to have to do things like this if you ask me.

That all makes sense to me. 

I'm not sure if you were suggesting I take the buffer object approach.  I'd happily do it if it was feasible.  Although the reason that I (and I expect most other users) come to use SFML is because:
1.  We don't have the expertise or time to write something better or more complex ourselves.
2.  Our (mostly 2D) games/apps don't need cutting edge optimization to run at a reasonable framerate.

I very much notice and appreciate the optimizations you and the SFML team make.  You know, stuff that all works "under the hood" for us pleebs.    But coding up a solution like this for my game is a little above my pay grade, and probably not an appropriate time sink for an indie game dev in a 2D game  Maybe you weren't necessarily suggesting I do that.  Rather, you just needed to "rant" (in a good way) about the inefficiency of the texture vs buffer object approach.  Although SFML does use this inefficient approach as well.

Regardless, interesting reading!

111

Graphics / Re: GL_MAX_TEXTURE_IMAGE_UNITS?

« on: April 12, 2015, 03:15:03 am »

I appreciate your detailed responses to this, binary.

I think you should do a bit more reading about how samplers and texture image units interact with each other.

I don't think there's any fundamental OpenGL I've misunderstood here.  I'm not sure what samplers have to do with my post at all.  I just want to know how many textures I can use in my fragment programs.  But please feel free to quote and correct any error I've made, I'm always happy to learn.

But you're right, I understand now that the GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS check isn't meant to do what I thought it was.  Maybe that was compounded by the 2.2 release code erroneously checking for GL_MAX_TEXTURE_COORDS_ARB.

Other graphics middleware I've worked with do provide an interface to query the max number of texture units for a fragment program.  So I guess I was looking at the SFML code through that lens.

Also, I'm not sure what you would do even if you did know the limits of each individual stage.

I would check to make sure my fragment programs could run on a particular computer, and if not, either:

• exit with a "hardware not supported" error on startup,
• or better yet, have a simpler fallback shader

Either is a better solution than running broken opengl.

But no worries, it's a simple check and I can implement it myself.

Thanks for your time.

112

Graphics / Re: GL_MAX_TEXTURE_IMAGE_UNITS?

« on: April 11, 2015, 11:45:13 pm »

The problem is that SFML only queries a single limit since it has no knowledge of how you distribute them between the stages

I understand.

I think for most intents and purposes, checking against the combined limit should be enough.

I respectfully disagree.  I have trouble seeing how the current check is of any use at all.

For example, on my machine:
GL_MAX_TEXTURE_IMAGE_UNITS_ARB = 16
GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS_ARB = 96

It seems highly unlikely I would ever be using 96 texture units in any individual shader.  In the unlikely event I was, that check would still be useless as I would very likely have exceeded one of the other limits for vertex, fragment, or geometry shaders.

What does seem a more common use case for a primarily 2D media library is to send multiple textures in a fragment program.  Maybe I'm implementing 2D lighting with a diffuse, normal, spec and occlusion textures, for instance.  Maybe I'm implementing a shadowing solution which requires a texture per visible light.  Maybe I'm multitexturing a single sprite or vertex array. 

Unfortunately, I simply can't trust the current SFML code to tell me how many texture units is safe to use.  It might be 4, 8, 16, 32... I have no idea. 

I understand the limitations behind the current check.  However, that check seems to fail in either the most common use case, or even any realistic use case I can think of.  If this code has any effect at all, it is likely only to mislead the programmer into believing he has made a relevant validation check, when he has not.

It's no problem for me to just change the SFML code for my own purpose, which is likely what I'll end up doing.  But while I was fiddling around with this code, I thought I'd bring up this shortcoming of the SFML code.

113

Graphics / Re: GL_MAX_TEXTURE_IMAGE_UNITS?

« on: April 11, 2015, 10:15:55 pm »

Actually, the updated github code may still be incorrect.

According to opengl.org, that value (GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS) gives the maximum number of textures which can be used between each of the vertex, fragment, and geometry shaders at once, i.e . the combined limit.  The number for any individual pass is less.

From the above link:

Max Texture Units

Never call

 glGetIntegerv(GL_MAX_TEXTURE_UNITS, &MaxTextureUnits);

because this is for the fixed pipeline which is deprecated now. It would return a low value such as 4.
For GL 2.0 and onwards, use the following

 glGetIntegerv(GL_MAX_TEXTURE_IMAGE_UNITS, &MaxTextureImageUnits);

The above would return a value such as 16 or 32 or above. That is the number of image samplers that your GPU supports in the fragment shader.

The following is for the vertex shader (available since GL 2.0). This might return 0 for certain GPUs.

 glGetIntegerv(GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS, &MaxVertexTextureImageUnits);

The following is for the geometry shader (available since GL 3.2)

 glGetIntegerv(GL_MAX_GEOMETRY_TEXTURE_IMAGE_UNITS, &MaxGSGeometryTextureImageUnits);

The following is VS + GS + FS (available since GL 2.0)

 glGetIntegerv(GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS, &MaxCombinedTextureImageUnits);

and the following is the number of texture coordinates available which usually is 8

 glGetIntegerv(GL_MAX_TEXTURE_COORDS, &MaxTextureCoords);

It looks to me like the shader needs to know what kind it is (vertex, fragment, geometry), then use the appropriate value, of:

vertex:  GL_MAX_VERTEX_TEXTURE_IMAGE_UNITS
fragment:  GL_MAX_TEXTURE_IMAGE_UNITS
geometry:  GL_MAX_GEOMETRY_TEXTURE_IMAGE_UNITS  (gl 3.2+, if/when SFML supports geometry shaders).

Alternatively, if we're assuming that this is just for fragment shaders, then GL_MAX_TEXTURE_IMAGE_UNITS appears to be the correct query.

114

Graphics / Re: GL_MAX_TEXTURE_IMAGE_UNITS?

« on: April 11, 2015, 10:01:25 pm »

Ah cool, thanks binary1248.  Nice to know you guys are one step ahead of me. 

115

Graphics / GL_MAX_TEXTURE_IMAGE_UNITS?

« on: April 11, 2015, 08:57:53 pm »

Hi,

From SFML 2.2, Shader.cpp:

    GLint checkMaxTextureUnits()
    {
        GLint maxUnits = 0;

        glCheck(glGetIntegerv(GL_MAX_TEXTURE_COORDS_ARB, &maxUnits));

        return maxUnits;
    }
 

This function is invoked when determining how many texture params I can bind to a shader.  Here's my question, though.  Shouldn't this function be checking GL_MAX_TEXTURE_IMAGE_UNITS instead?  I believe that number is usually higher than GL_MAX_TEXTURE_COORDS_ARB, so this function is artificially limiting the number of textures I can send to my shader. 

116

SFML projects / Re: Let There Be Light 2

« on: March 08, 2015, 10:01:11 pm »

I'm very happy to see you back lolz! 
Your lighting stuff is great.

117

General discussions / Re: GPL Discussion

« on: January 23, 2015, 10:54:00 pm »

Even with the proper context, you can't say it is bad. It's at most not suitable for one's needs.

Alright.  It's not suitable for one's needs, in the same way a canteen filled with sand isn't suitable to a man dying of thirst in the desert.  If we don't want to call that canteen "bad" for the dying man, so be it! 

But point taken - no more argument on GPL.  I've said my piece and of course an author has full right to choose whatever license she likes.

118

General discussions / Re: GPL Discussion

« on: January 23, 2015, 10:35:42 pm »

Heh, fair enough Jesper, although not delivered with the most tact. 

Let me clarify then.

This license is bad for anyone who doesn't wish to release their entire project as open source.  There's nothing subjective about that, and it applies to a lot more people than just me (in fact, probably most).  I just wanted to make sure Mj PsykOo was aware of this.

By the way, looks great Mj PsykOo!  I should have written that in my first post.

119

General discussions / GPL Discussion

« on: January 23, 2015, 09:26:55 pm »

Edit (by eXpl0it3r): Split the topic from here.

GPL is a bad license, as it infects the whole project. 
If someone uses your library, then their entire codebase must also become GPL, which pretty much nobody wants to do.

http://en.wikipedia.org/wiki/GNU_General_Public_License#Linking_and_derived_works

120

SFML projects / Re: Moonman (my sfml game is on kickstarter!)

« on: January 17, 2015, 03:36:56 pm »

Glad to share, eigenbom.

Basically I imagined a publisher could do these things, which I *could* do but would prefer not to

I totally get it.  As an indie, you're already tackling a ridiculous amount of work.  Even more so for you because you're handling code + art.

Still, let's look at what you want to pass off to a publisher:

marketing
If a publisher is willing to spend some money, fair enough (but get the exact responsibilities in writing).  This is probably/hopefully something they're good at. 

Then again, what (likely?) may happen is they just throw up a few banner ads and press releases.  Stuff you may have to provide the content (art, feature blurb, screen shots, press kit, etc) for anyway.  If you took the sales % that you have to pay out to the publisher, and just use that yourself to buy some ad space, it might easily go just as far or further without too much work.

demoing and promoting the game in the states (I live in australia)
Tough one.
You're missing out big-time passing up any opportunity to demo the game yourself, and watch people play it.  You'll learn more about your game doing that than almost anything else.  Also, people will respond far more positively to meeting the developer than some publisher suit.

Personally, I'd prefer not to demo the game at all at a trade show, if I (or a trusted co-worker) couldn't be there myself.

distribution
Yeah, they should be good at this.
The only downside here is losing the opportunity to make these contacts yourself, which will be valuable in your own future career as an indie.

interviews and general promo stuff
Most media, and especially indie sites, aren't going to be too interested in talking to a publisher.  They want to talk to the folks who made the game.

I know I'm painting a dismal picture here.  And there's so many hours in the day.  Another option might be to bring in another team member who can help with other tasks to free up some of your time.  Maybe an engineer who can handle setting up all the builds for your various distribution platforms, and/or any ports (mac, linux, whatever).  Alternatively, hire a business guy who can handle contracts, accounting, general numbers stuff, and help with community and marketing (but try to do the interviews yourself).

This way, you still maintain ultimate control over your game and finances.

I'm going to be cautious about who I sign up with (if anyone) and will be very mindful of the contract.

Alright, here's the last bit of doom and gloom I'll cast out today. 

Rule #1:  If it isn't in writing (contract), it means NOTHING.

Many publishers will make all sorts of promises while talking, emailing, skyping, or whatever.  They'll reassure your every concern.  They'll act like your best buddy. 

Don't buy it.

They might be lying.  They might be telling the truth, but circumstances change when the shit hits the fan.  The publisher could get into financial difficulty or even go bankrupt.  The guy who made all the promises might not even work at the publisher a few months down the road.  Get everything in writing.  If you have a concern, and they say, "no problem, don't worry about it", your immediate response should be "Great!  Let's put that in the contract".

Ok, rant over.   
Apologies for taking up so much space in your project thread.

If you do self-publish, just make damn sure your game is stable and well tested before you release.  This will allow you to switch gears into marketing and distribution mode once the game is ready for release.  There's always going to be some fires to fight, but you don't want to deal with a buggy mess and handle a game release at the same time.  I know this is obvious, but it can't be stressed enough.