Messages

1

General discussions / Re: SFML 3 - What is your vision?

« on: July 15, 2014, 04:41:54 pm »

now i am ashamed ... Listener did had direction, not SoundSource ...

It still has, but that doesn't change the fact that it doesn't make sense to store sprites and sounds or sound listeners together. What you actually want is an abstraction layer in between, most likely a scene graph. This is definitely not SFML's task.

i also did thought about some kind of SceneGraph ... currently i dont know if i can get it working right impl drawable into that SceneGraph might not be a problem, but Transformable for sample is, because its functions are not virtual for overloading ... :/
but like i said i need to test stuff until it works right

hmmm now i am thinking if SoundSource should have a direction too, so like you can only hear it if the speaker is showing into your direction ...

This doesn't make sense (even in real life), sounds propagate in all directions.

Doppler effect is supported by OpenAL but it is not exposed by SFML.

i was thinking in form of PC speakers ... like for them you cant hear them (right) when you are on the wrong end ...
Oh ok if doppler already exist in AL then its okay ... i didnt know that and i thought SFML might need more work than just "exposing"

2

General discussions / Re: SFML 3 - What is your vision?

« on: July 15, 2014, 04:14:42 pm »

i was thinking a bit about Spites and SoundSource and SoundListener ...
hm first, make a BaseInterface moveable, its for controling the Position and Direction of Sprite/(BigSprite)/SoundSource ..

No no no... Sounds have 3D positions, sprites have 2D positions. Sounds have no direction. And most important: there's no dependency between the audio and graphics modules, and there will never be. It's up to you to synchronize audio and graphics, this is a high level task.

  now i am ashamed ... Listener did had direction, not SoundSource ... and yeah i did think about to connect them, but i did also think about that it might be complications with other stuff like Thor Animation and Particle System i did use so when they should animate the object, the Sound might not follow the Sprite
(i need to experiment a bit with that)

hmmm now i am thinking if SoundSource should have a direction too, so like you can only hear it if the speaker is showing into your direction ...
hmmm2: i also did think there might be some value for the current acceleration of the SoundSourceObject so it might the detect if its moving to you or away from you, (for the Doppler Effect) or is that already managed by AL?

PS: thats my thoughts as i did thougt about a 3d-sound sample for SFML itself

3

General discussions / Re: SFML 3 - What is your vision?

« on: July 15, 2014, 05:48:43 am »

i was thinking a bit about Spites and SoundSource and SoundListener ...
hm first, make a BaseInterface moveable, its for controling the Position and Direction of Sprite/(BigSprite)/SoundSource ... so you can both add Sprites and SoundSources into an Array and move them around ...

then i was thinking about a helper template like SpriteWithSound<sf::Sprite,sf::SoundSource> ... with that you have a moveable sprite and the SoundSource is always connected to the Sprite postion and location, same for SpriteWithSoundListener<sf::Sprite> (because the Listener is some kind of singleton?)

my idea was so that you can move around the WithSound objects and the 3d sound effect is already managed for you?

PS: that was only an idea, i dont know if its to high or low for SFML itself (only the Moveable interface might be interesting, but it might be collide, with Transformable)

4

General discussions / Re: SFML 3 - What is your vision?

« on: July 03, 2014, 05:22:51 pm »

Adding Thor ParticleSystem & Animation

SFML is a multimedia library, not a game library
So let's keep these more advanced concepts in add-on libraries like Thor.

oh ok i didn't consider it "game libary" only stuff, i thought that would be basic enough for multimedia lib

Ogre CompositorChain with that you can have multiple gpu programs/shader for rendering one viewport

This is a bit too high-level.

Dammit ok it might be but as far i dont know if it can be emulated with addons for sfml, like binary said:

The main idea is to add features to SFML that extension libraries wouldn't be able to implement because of a limitation within SFML itself.

currently i dont know if it can be done with extension libraries

does SDL2 have something we might need?

SDL 2 is always an interesting source of inspiration, but we'd like to avoid "please implement X because SDL has it"

i looked myself what we could need ... SDL2 has gamecontroller support (we only have joystick, that might be a bit different), otherwise i didnt find anything what we might need.

Have Styleable Text where TextSections can be styled differently

This is also a bit high-level in my opinion. You can easily make your own with what SFML provides.

hm okay if its simple to make it might be able to add to thor or similar,
i thought it would be low enough (simple enough) for SFML

add more samples, specially from the new features, but i would also like to see the SoundListener features in action

Feel free to provide a more detailed list of what you'd like to see

i might look what i can do ... mostly currently i am thinking how to combine sf::Sprite with sf::SoundSource
(and maybe with some kind of LightSource too? i was thinking about some fireplace where you could get near)

5

General discussions / Re: SFML 3 - What is your vision?

« on: July 03, 2014, 02:38:52 pm »

what i would like:

• Adding Thor ParticleSystem & Animation: but try to add DefaultConstructor and setter methods, the thor classes does miss them
• adding more sound formats, specially midi, might be pluginable for other stuff like gstreamer, pulseaudio or JACK
• if thinking about Video, a render video to RenderTarget would be fun
• Ogre CompositorChain with that you can have multiple gpu programs/shader for rendering one viewport
• sf::Shader add way to get the type of a parameter from the program if possible
• does SDL2 have something we might need?
• Have Styleable Text where TextSections can be styled differently
• add more samples, specially from the new features, but i would also like to see the SoundListener features in action

6

Graphics / Re: Image too large?

« on: September 09, 2013, 09:23:59 pm »

and wouldn't be some kind of TextureInterface/SpriteInterface class would be more nice for the programmers?

What would it look like? Or how would it differ from thor::BigTexture and thor::BigSprite (see link in my first answer)?

if you compare them you will see that they are a bit different but not the same (some functions from Texture are missing in BigTexture, and some setter does not have corresponding getter methods), and i wanted to use something that automatically uses BigTexture if the Texture you want to use is to big ...

7

Graphics / Re: Image too large?

« on: September 09, 2013, 08:43:19 pm »

hm about Texture and BigTexture, exist a way to check if an Texture is to big to be an normal Texture from inside the program?
and wouldn't be some kind of TextureInterface/SpriteInterface class would be more nice for the programmers?

8

General / Re: Linux Permission Denied

« on: September 09, 2013, 05:52:38 pm »

how did you use chmod? did you escape the name correctly?

it seems that the file has " " inside, so you may need:

chmod +x sfml\ test

9

Graphics / ShaderChain Project

« on: August 07, 2013, 06:04:25 pm »

currently i planing an ShaderChain class what uses RenderTexture and Sprites to draw an chain of Shaders into an output (Render)Texture, but i also want to publish the code where so other sfml users can use it, or maybe intigrate it into sfml itself if is good.

there are a list of fuctions that are currently available, others may follow:

• ShaderChain
  • Copied from RenderTarget, bad that i cant inherit from an interface
  • getSize() returns the size of the first RenderTexture
  • clear(Colour) clears the first RenderTexture
  • draw(Drawable,RenderStates) draws other drawable into the first RenderTexture
  • getTexture returns the texture of the last RenderTexture
  • Inherit from Drawable
  • draw(RenderTarget,RenderStates) draws the ShaderChainDrawableInstance stored in this chain and it makes sure that the ShaderChain is updated before the Drawable inside the ShaderChainDrawableInstance is drawn (i mean that the content is drawn from the first RenderTexture to the last, it only does it when needed)
• ShaderChainShaderInstance  holds the Shader objects with an name, so they can disabled or removed later
• ShaderChainDrawableInstance  combines ShaderChain with an Drawable object, it

critic and ideas are wanted

10

Graphics / Re: SFML 2.1 & 2.0? issue with rendertexture inside functions? White background?

« on: July 31, 2013, 01:28:59 pm »

There is the Tutorial link
infomation shorted: you need to define the Texture outside of the loop or you use an Pointer instead than an reference (and create the Texture with new)

11

Window / Re: Weird bug on AMD E6760 GPU

« on: July 29, 2013, 06:15:57 pm »

hm what sfml version did you use? the sf::VideoMode i have seen only support 2-3 parameters not 4

http://sfml-dev.org/documentation/2.0/classsf_1_1VideoMode.php

12

Graphics / Re: [SOLVED] Using SFML with OpenGL (conflicts with GL states)

« on: July 29, 2013, 03:30:38 pm »

sorry that i reopen this Thread, but i have a question about this ...
i thought i need to do it in the other direction like

window.pushGLStates();
  glFunctionsThere();
window.popGLStates();
window.draw(text);

or is that interchangeable?

13

Feature requests / Re: Geometry shader

« on: July 20, 2013, 07:50:57 am »

huch ok you are right

this is a part of the code i currently use in my binding

VALUE _loadFile(int argc,VALUE *argv,VALUE self)
{
        sf::Shader *image = new sf::Shader;

        VALUE vert,frag;
        rb_scan_args(argc, argv, "11",&vert,&frag);

        if(!NIL_P(frag))
        {
                if(image->loadFromFile(unwrap<std::string>(vert),unwrap<std::string>(frag)))
                                return wrap(image);
        }else if(rb_obj_is_kind_of(vert,rb_cHash))
        {
                VALUE temp;
                if(!NIL_P(temp = rb_hash_aref(vert,ID2SYM(rb_intern("vert")))))
                        if(!image->loadFromFile(unwrap<std::string>(temp),sf::Shader::Vertex))
                                return Qnil;

                if(!NIL_P(temp = rb_hash_aref(vert,ID2SYM(rb_intern("frag")))))
                        if(!image->loadFromFile(unwrap<std::string>(temp),sf::Shader::Fragment))
                                return Qnil;
                return wrap(image);
        }

        return Qnil;
}
 

so it seems that the second part does not work if you use an Hash with both "vert" and "frag" keys ...

imo its a little bad but i think i can write around of that :/

14

Feature requests / Re: Geometry shader

« on: July 19, 2013, 11:38:30 pm »

you can not? i thought that is what sf::Shader is for that you can use an vertex and fragment program together ... or did i get it wrong?

15

Feature requests / Re: Geometry shader

« on: July 19, 2013, 10:28:11 pm »

i would like to stay with

loadFromFile(const std::string& filename, Type type);

so it could be easly addable if there are other shader types in the future

like ogre3d trunk has

                GPT_DOMAIN_PROGRAM,
                GPT_HULL_PROGRAM,
                GPT_COMPUTE_PROGRAM

i dont know that they do, but if they are usefull for sfml too, than its good if the api is easier to extend