The new graphics API in SFML 2

[Groogy]

If you still want suggestions, how about rendering to multiple buffers using one single draw call? For practical uses of this you look at post processing effects which depend on data available during scene render. Games use this to create true motion blur effect.

I'm just comming with ideas and don't expect you to implement them. Just putting it out there for consideration so to speak. And this suggestion is extra tricky and a bit advanced. But I guess a function to maybe attach a render target onto another. Though. I'm writing this just before going to bed. So I might have a proper design pattern that is fitting tomorrow if you are interested.

I can come with more suggestions like this if you want. Or I can shut up if you feel that I'm making your task so much more irritating.  :roll:

Note: if it helps I can give full implementation details on how it would be used.

[Laurent]

Ideas are always welcome

However the goal here is to find a better API for tasks that SFML already does (= drawing 2D entities easily and efficiently), not to implement fancy new techniques that run only on the most recent GPUs.

Let's focus on the basics for SFML 2.0, and keep this kind of new features for future versions of SFML 2.x

[Groogy]

Ideas are always welcome

Great! At work right now but I can come with some later.

However the goal here is to find a better API for tasks that SFML already does (= drawing 2D entities easily and efficiently), not to implement fancy new techniques that run only on the most recent GPUs.

No problem, what I had in mind with this was actually for 2D. Most effects known in 3D games can be applied in 2D games as well. You would be amazed of how many of these effects are actually done in post-projection space. And I think rendering to multiple targets have been available for quite a long time and most graphics card support it.

True motion blur basics works on that while we are rendering the scene we also compute a velocity value for each vertex by remembering the previous frame transformation and just calculate the difference vector between the positions. To be able to do this you have two buffers you write to, one being the actual fragment color and the second being the velocity buffer(just a texture we interpret in the shader as we want). Then the velocity buffer is bound as a texture to the post processing shader that actually does the true motion blurring depending on the velocity for that pixel. Nothing fancy, nothing advanced. Just a little math and the fact that you render to two targets at the same time. Of course you can do the velocity calculation in it's own draw call as well if you still feel that multiple buffers shouldn't be implemented yet. So it's not a deal breaker ^^
And since we are doing 2D graphics, we got pretty much unlimited juice to squeeze out

Let's focus on the basics for SFML 2.0, and keep this kind of new features for future versions of SFML 2.x

Sure, and I think I have written down something somewhere that is just about that. Don't remember if it was the home or work computer. I'll get back to you

[Tex Killer]

Hello.
I'm sorry for not reading all the messages on the topic, but I have an idea I want to discuss.
Are you planning on revewing the audio API?
As I have checked, you can't play one piece of song right after another piece... you cant mix sounds in the current API. Am I correct?
I have made a little improvement on my local version of SFML code to allow such things. Don't you think it deserves be on the public one too?
Thank you all for your work and dedication.

[Laurent]

Are you planning on revewing the audio API?

Nop. sfml-audio won't be touched in SFML 2.0, but it will probably be improved later in SFML 2.x. However for big changes that break everything, you'll have to wait for SFML 3

As I have checked, you can't play one piece of song right after another piece

True.

you cant mix sounds in the current API

If you mean "play several sounds at the same time", then you definitely can do this.

I have made a little improvement on my local version of SFML code to allow such things. Don't you think it deserves be on the public one too?

I'd be glad to see this. Don't hesitate to create your own repository on github by forking SFML, and send me pull requests, so that I (and everybody) can see what improvements you have there

[Tex Killer]

Well, I'd have to polish my code before showing, mainly because most part of the terms are in portuguese. Basically, in my version you set up a list, and add to that list the files you want played - specifying the start and end millisecs each time you add a file to the list - and then play the list. Once one entry is finished the other starts right away, in the same thread. I've made it buffered, extending the Music class and coding some more things.
I'll show what I did soon, then. Thanks.

[Laurent]

I'll show what I did soon, then. Thanks.

Ok great

But please open a new thread when you do so -- this one is about the graphics API

[Groogy]

And as a nice segway into the graphics api. Will shaders be able to set matrix variables to transform objects? I don't see why you shouldn't be able to.

[Laurent]

And as a nice segway into the graphics api. Will shaders be able to set matrix variables to transform objects? I don't see why you shouldn't be able to

Good idea, indeed.

[Groogy]

Another idea just putting it out there for your consideration.

how about instancing to lower the amount of draw calls to the GPU? Don't know exactly how it's done in OpenGL and that would need a little research but the interface in SFML would be something like this:

Code: [Select]

window.Draw( meshAndAnyOtherValues, arrayOfTransformations );

If you have no clue on how this would work under the hood I can probably do some research for how to actually implement it in OpenGL and also give you the underlying basics behind it.

And yeah it's just a silly optimization but it gave me a huge performance increase with DirectX, something like 30-50 FPS with batching to 500 FPS with instancing.

Update: Little quick look, it's supported trough OpenGL as an extension and it is supported by graphics card since year 2004. So it's pretty old. The OpenGL context you default to was also for instance released that year.

http://www.opengl.org/registry/specs/EXT/draw_instanced.txt

[Laurent]

I think that I'll definitely switch to an OpenGL 2 architecture (with shaders and everything) after SFML 2.0 is released, and I'll seriously consider all these techniques that require GL 2 extensions.

But for the new API that we are discussing here, like I already said, I'm not interested in adding new features, I just want to do the same things as before, but with an API which allows more flexibility.

Little quick look, it's supported trough OpenGL as an extension and it is supported by graphics card since year 2004

The spec says "GeForce 8 series (November 2006)". It seems like a very recent (and unsupported) feature to me.

The OpenGL context you default to was also for instance released that year.

Hum? The default context version is the lowest one that the card can provide, SFML has no limitation on it.

[Groogy]

I think that I'll definitely switch to an OpenGL 2 architecture (with shaders and everything) after SFML 2.0 is released, and I'll seriously consider all these techniques that require GL 2 extensions.

Awesome!

But for the new API that we are discussing here, like I already said, I'm not interested in adding new features, I just want to do the same things as before, but with an API which allows more flexibility.

Noted!

The spec says "GeForce 8 series (November 2006)". It seems like a very recent (and unsupported) feature to me.

Hmm my bad, the wikipedia page said something else but I guess that's incorrect information. The extension is included with OpenGL 3.0 as official extension as well but only depends on 2.0 but I wouldn't say unsupported. It's common and a must for repetitive graphics. Or else you'll walk around in a world with 5 FPS or something no matter how much of a monster of computer you have.

DirectX9 and 10 for instance include it hardwired into the whole thing.

http://en.wikipedia.org/wiki/Geometry_instancing

I would also like to say that since instancing gives this great performance boost by reducing draw calls it should be implemented in the future and maybe provide a just like you did for Shaders, a "IsAvailable" function.

I am actually getting some pretty cool creative ideas that could be done with SFML thanks to instancing. First being simple voxel graphics in 2D(Might sound stupid but don't know what else to call it) But like said, something for the future.

Hum? The default context version is the lowest one that the card can provide, SFML has no limitation on it.

If the user provides nothing else you attempt to create a 2.0 context.

http://www.sfml-dev.org/documentation/2.0/structsf_1_1ContextSettings.php#aafe35f8e257f9d1e496ed64e33e2ee9f

Update: AH! The GeForce 8 is a revised version I think if you look at the bottom:

Revision History

      Rev.    Date    Author    Changes
      ----  --------  --------  -----------------------------------------
      1.5   05/09/08  gold      Removed extraneous parameters to DrawArrays
                                and DrawElements in chapter 2 pseudocode

Which is probably nothing you'll have to worry about using GLEW.

[Laurent]

I wouldn't say unsupported. It's common and a must for repetitive graphics. Or else you'll walk around in a world with 5 FPS or something no matter how much of a monster of computer you have.

For big commercial games it's definitely old enough to be used. But for SFML it's too recent (don't forget that I do simple 2D and that it should work on every platform), it's already lightyears away from my requirements.

If the user provides nothing else you attempt to create a 2.0 context.

No, I create a context (with no requirement) and the driver may choose to give me a 1.2 context. It will work.

The thing that most people don't know is that you can manage context versions only above 3.0. Below (1.x and 2.x) there's no choice, you get what the driver gives you. So the default "2.0" in sf::ContextSettings is purely arbitrary. In fact you can pass any number below 3.0, the result will be the same. You can get 1.2 as well as 4.1, it's up to the driver.

[Laurent]

AH! The GeForce 8 is a revised version I think if you look at the bottom

I'm not sure.
It still says:

Status

    Shipping for GeForce 8 Series (November 2006)

[Groogy]

Hmm true... Which is weird because most of the Instancing is done in the driver and not directly on the GPU. And besides it has been supported by DirectX9 which works with any card that supports OpenGL 2.0 so it's quite confusing.

Anyway I think that all 2.0 compliant drivers will support the extension since that is the dependency and we can only trust that. Because according to OpenGL it has officially supported Instancing since 3.0 (but the extension was created in 2.0).

And actually looking more into it. The first GPU to support 3.0 was Nivida 8 Series so no wonder that's what it says if the extension is integrated in 3.0, I.E it is shipped together with the driver.  Of course I'm no expert on how the extensions in OpenGL works and I am not entirely sure of what GLEW actually does. But from my point of view it looks like the extension would just load nicely. I could attempt and create some example and try it out on different 2.0 machines.

The only loose end that I see is the EXT_gpu_shader4 extension which is also a dependency and which adds more features to the shader language(But it's only dependency is 2.0 but it says something about supporting capabilities of newer hardware).

(Taken from OpenGL's coding resource)
http://www.opengl.org/sdk/docs/man3/xhtml/glDrawArraysInstanced.xml

any which way it's not a big loss. You can fake instancing on the CPU and still get big GPU/CPU performance boost but it costs quite a big amount of memory. (For those that might need it in the future)