Messages

1

System / Problems with controller on linux (ubuntu / SFML2.0)

« on: September 03, 2014, 11:42:54 pm »

Hello,

I implemented controller support for my game, and it was working correctly on windows.
I tried it on my laptop running ubuntu, and there was a strange behaviour:

My USB mouse is detected as a controller by SFML on ubuntu, having the contrer ID 1.
The X and Y axis return -100 and the GetButtonCount function said the controller had 320 buttons.

As a workaround, in my initialization I just check if the controller has less than 20 buttons. If it has more, the engine will ignore it. But I'm not really happy with this solution as I don't know if it would work for all possible scenarios (a controller with 13 buttons might be generated by another device, for example)

Do you guys have any idea what could be happening here or how to fix it?


Thanks!


Edit: Forgot to mention that I made sure to call sf::Joystick::update() during the initialization, before checking for any plugged in controllers.

2

Graphics / Re: Vertex properties

« on: September 06, 2013, 03:32:16 pm »

Will this be implemented in future version of SFML?

3

Graphics / Vertex properties

« on: September 06, 2013, 03:04:54 pm »

Hello,

I'm using SFML 2.0. I am not an expert on openGL, so please correct me if I'm wrong.

As far as I know, there are multiple properties for vertex in openGL. From what I have seen, in SFML, only texture coords, position, and color are used.

I need to make use of some extra attribute in order to use it in a vertex shader.

From this tutorial I saw this list of attributes:
http://www.opengl.org/sdk/docs/tutorials/ClockworkCoders/attributes.php

I would like to use the gl_normal, or gl_fogcoord, or just use my own attribute, but I see no way to set these attributes on vertex by using SFML.

Is there any way to modify these attributes or using custom attributes on vertexes using SFML?


Thanks,

4

Graphics / Re: Texture coordinates on GLSL (shaders)

« on: April 14, 2013, 10:27:03 pm »

The texture coordinates are inverted because the texture produced by sf::RenderTexture is inverted (because of FBO). So I don't know what your initial idea was, but don't do it this way

I see, as long as this behaviour is consistent with sf::renderTexture's texture I can live with it on my code. I ran into this when I decided to draw a mask (renderTexture) I was using over a sprite's texture (loaded from a file), in order to check if it was correctly aligned, just to debug it.

So no real harm. Just wanted to let you guys know, just in case someone ran into this. Loving the library so far, so I was eager to report a bug, knowing I would be of some help.

Thanks!

5

Graphics / Re: Texture coordinates on GLSL (shaders)

« on: April 14, 2013, 07:19:32 pm »

Here is a complete and minimal code of the issue at hand:

#include <SFML/Graphics.hpp>





int main()
{

    sf::RenderWindow m_window;

    sf::Sprite maskSprite;
    sf::RenderTexture maskRender;
    sf::Texture maskTexture;

    sf::Shader shader;

    m_window.create(sf::VideoMode(800, 600), "Fragment shader!");


     //Setup our file-loaded mask
    maskTexture.loadFromFile("mask.png");

    //Setup our renderTexture-made mask
    maskRender.create(maskTexture.getSize().x, maskTexture.getSize().y);
    maskRender.clear(sf::Color(0,0,0,255));
    maskRender.display();


    //Load the shader
    shader.loadFromFile("fragment.frag",sf::Shader::Fragment);

    while(m_window.isOpen())
    {
        sf::Event event;
        while(m_window.pollEvent(event))
        {
            if(event.type == sf::Event::Closed)
                m_window.close();
        }

        //We load the mask texture loaded from a file into the sprite and draw it, so we can compare it to the result
        maskSprite.setTexture(maskTexture);
        maskSprite.setPosition(256,300);
        m_window.draw(maskSprite , &shader);

        //We load the render-made mask into the sprite and draw it, so we can compare it to the result
        maskSprite.setTexture(maskRender.getTexture());
        maskSprite.setPosition(0,0);
        m_window.draw(maskSprite, &shader);

        m_window.display();
    }

}

 

The shader is the following:

void main()
{
        vec2 position = gl_TexCoord[0].xy;
       
       
       
        vec4 pixel;
       
        pixel.r=position.y;
        pixel.a=1.0;


       
        gl_FragColor = pixel;
}

You just need an image with the name "mask.png"

6

Graphics / Re: Texture coordinates on GLSL (shaders)

« on: April 14, 2013, 04:18:06 pm »

Are you sure you called ".display()" on the renderTexture after drawing to it?

I checked and double checked, and this was not the case.

In the vertex shader you must apply the texture matrix to your texture coordinates. Look at the Shader example of the SFML SDK.

Shouldn't the default vertex shader apply the appropiate matrix on the target texture?

I have used the following shader, over a file loaded texture and over a renderTexture made texture:

        vec2 position = gl_TexCoord[0].xy;
        vec4 pixel;
       
        pixel.r=position.y;
        pixel.a=1.0;
       
        gl_FragColor = pixel;
 

The following image is the result of the shader being applied to different textures:


The top rectangle is the renderTexture-made texture, and the bottom one the one loaded from a file.
As you can see from the shader, the color red of each pixel is equals the y value of the texture's coordinate.
Only the shader has been cutomized, and in the openGL documentation you can read the following (http://www.opengl.org/sdk/docs/manglsl/ in "gl_FragCoord" under the "Built-in Variables") :

By default, gl_FragCoord assumes a lower-left origin for window coordinates and assumes pixel centers are located at half-pixel centers.

As far as I know, this looks like the default behaviour of gl_FragCoord is not being respected, something is changed in the loading process of the textures in SFML that is modifying the default behaviour on GLSL.

7

Graphics / Texture coordinates on GLSL (shaders)

« on: April 14, 2013, 01:31:48 am »

Hello,

I think I have run into a bug, or at the very least an inconsistency in the behaviour.

The scenenario is the following:

• I have a sprite, with some kind of drawing.
• I want to use a shader on it, using another texture as a mask

I was not able to make it work correctly, and the mask texture seemed to be upside down. I though that this was because I forgot to use the .display() function on my rendertexture after drawing the mask on it. That was not the case, and decided to construct a minimal example, and I found out the following behaviour:

When you pass a texture to a shader, the coordinate system is different depending on the texture loaded:

• If the texture was loaded from  a file, the top-left corner of the texture is the point (0,0) and the bottom-right corner is the point (1,1).
• If the texture is from a renderTexture, the bottom-left corner of the texture is the point (0,0) and the top-right corner is the point (1,1).
  

This means that one of the coordinate system is upside down.
Since this example needs of several files (the code, the shader and a couple of images) I have packed them into a file and attached it to the post.

Here is what is displayed in the example:



1. The target sprite
2. The renderTexture mask
3. The renderTexture's texture drawn over the target sprite
4. The texture loaded from a file
5. The texture drawn over the target sprite


Is this behaviour expected? Should one of the coordinate system be changed to be consistent between each other?


I hope the example is clear enough. If you have any question about it, please ask so I can clarify it.


[attachment deleted by admin]

8

Graphics / Re: View problems

« on: March 26, 2013, 04:09:07 pm »

I was building a minimal and complete example and I realized something about my code:

-For each polygon on view, I would draw the shadow it casts on a intermediate texture.
-This texture was then drawn on my shadow texture for the final result (while applying a shader)

This intermediate texture had it's view not updated before drawing the shadows on it, but it was later used (and properly set the view on it) for another task that required an intermediated texture. This resulted on the shadows being displayed from the lastest drawn cicle view, and therefore, it seemed to "fall behind".


Bottom line: I'm retarded.




PD: Is there a way to close/delete threads? I mean, this one is pretty useless after all.

9

Graphics / View problems

« on: March 26, 2013, 01:13:53 pm »

Heeello,

I'm using a sf::view as a camera that follows the player. The update on the different components are done in the following order:
1) The player's position might be updated in a game cicle.
2) Set the view's center to the player's position
3) Set the window's view to the updated view
4) Calculate the line of sight of the player, calculate shadows (do_FOV)
5) Draw everything

The shadows casted from the player's field of view are not draw globally. With this I mean that the shadow's RenderTexture is not as big as my map, but as my window, so the texture for the shadows has the same side of the window.

This means that in order to draw the shadows on my shadowTexture, I must also set the RenderTexture's view the same as my window:

shadowRepresentationRender.setView( engine->view );
shadowRepresentationSprite.setPosition( engine->view.getCenter().x , engine->view.getCenter().y );
//shadowRepresentationSprite's origin is set to it's center  

This is done in the do_FOV function (which is executed after the view and the player's position has been updated).

The problem comes when I draw the shadows on my screen. While standing still, everything is working fine. The problem comes when the players moves. In the following screenshot I'm walking to the left:



As you can see inside the red area, it looks like the shadow's sprite is falling behind the actual movement of the player. If I walk to the right, that gap appears at the right. Same applies when moving up and down.

I have tried setting the sprite's position (and the sprite's origin) to 0,0 and then change the window's view to the defaut view, so it's back in the origin. The exact same error happens.

I think this problems comes from setting the view for the shadow's RenderTexture the same as the window view.


Anyone has any idea of what could be wrong here?

10

Graphics / Re: Cuting an area out depending on another texture

« on: March 24, 2013, 02:19:19 am »

Ok, here is the solution I came up with.
Not claiming is the best solution, since its the first time I ever use shaders and I have been extremelly confused in the last couple of hours:



First of all I created a mask (the colored lines) that pretty much locates of all the candidates for shadow to be removed: Walls that are just above an empty cell.

The purple line indicates how tall the wall is, you can put this like higher or lower depending of the type of cell, so it won't mess up different walls depending on their height.

When I draw the walls I use the following shader:

uniform sampler2D texture;                //Texture to draw
uniform sampler2D filterTexture;        //Texture of the masks
uniform vec2 textureSize;                   //Size of the texture
uniform float cellSize;                         //Size of a cell in pixels
uniform sampler2D shadowTexture;  //Texture were the shadows are drawn



void main()
{
        vec2 position;
        vec4 filterPixel;
        vec4 shadowPixel;

        bool aboveRed=false;
        bool belowPurple=false;


        vec4 pixel = texture2D(texture, gl_TexCoord[0].xy );

       
       
        for( float i=0 ; i<=cellSize*2 ; i++)
        {
                position = gl_TexCoord[0].xy;
                position.y = position.y - (i/textureSize.y);
                filterPixel = texture2D( filterTexture, position );
               
                position.y = position.y + (1/textureSize.y);
                shadowPixel = texture2D( shadowTexture, position );
               
                if (shadowPixel == 0){
                        if( filterPixel.r == 1.0 && filterPixel.b == 0.0 )
                        {
                                aboveRed=true;
                        }
                }
               
                position = gl_TexCoord[0].xy;
                position.y = position.y + (i/textureSize.y);
                filterPixel = texture2D( filterTexture, position );
               
                if(filterPixel.r == 1.0 && filterPixel.b == 1.0)
                {
                        belowPurple = true;
                }
                if(belowPurple && aboveRed){
                        pixel.a = 0;
                        break;
                }
        }              
        gl_FragColor = pixel;
               
}

 

This shader pretty much looks for a red pixel (in the mask) bellow the current pixel within a cellSize*2 range. If it finds the red line, it check the shadow in the pixel just below it.
It also looks for a purple pixel above the current pixel within the same range.

If the current pixel meets this two conditions, the current pixel is drawn on the screen.


I don't know if this is a really dirty way to solve the problem, since, as I said, I never used shaders and i'm still pretty ignorant of it's usage.

If someone more knowledgeable on SLGL can comment on the shader, and also point me in the right direction for a good tutorial which could be useful for SFML users, that would be awesome!

11

Graphics / Re: Cuting an area out depending on another texture

« on: March 23, 2013, 03:10:47 pm »

I have tried that solution.

Everything is 2d in the map. If I cast the shadow from the top of the wall I get undesirable results like incorrect field of view over corners.

I have been fiddling with shaders (never used them before), and I think I already know how to solve it.
If I manage to do solve this problem using shaders I will post the result in case anyone is curious/need a similar solution.

I'll let you know once I'm done.

12

Graphics / Cuting an area out depending on another texture

« on: March 22, 2013, 10:57:01 pm »

Hello,

I have a problem that is giving me hard time.



Here you can see the scenario (sorry for the eye-hurting textures), and at the bottom, the field of view applied on the scenario.
As you can see, the wall that should be visible, are not, giving a really weird look to the scene. I need to cut from the shadow texture the area of the visible walls.

One solution that I thought about its the following:

The idea should be to check the pixel just below the walls. If the pixels are NOT darkened by the shadow, the area above should be deleted from the shadow texture.

Pretty much, if the checked area (ONLY check for the pixels just below walls) in the shadow texture is not obscured, then make the X pixels above that point transparent.

I'm really lost and I don't know how to deal with this.. I though that shaders may be useful here, but I have no experience with them, and I don't really know if they fit this task.


Do you guys have any ideas?


Thanks,

13

Graphics / Re: Good praxis for editing and drawing

« on: March 20, 2013, 04:29:01 pm »

I see.

I guess the limitations of using a RenderTexture is the bigger the map grows, so does it's texture (which i guess can give you some problems depending on your graphic card), while the VertexArray will be using the same small tileset no matter how big the map is.

If that's the case then it surelly sounds like the best option!

14

Graphics / Re: Good praxis for editing and drawing

« on: March 20, 2013, 04:01:59 pm »

Why would there be other (and why "better"? what's wrong?) classes that do the same thing?

I was just wondering if there was another class that would be faster of less heavy weight that this one.

Vertex arrays are the best solution. What's your problem with them?

Currently I load my map in the following way:
1)I load my tileset into a Sprite
2)Create a RenderTexture
3)Iterate through my map info (a 2d array that contains integers representing each cell's type)
      3a) Move the textureRect in the sprite to hold the desired tile depending on the type of cell read
      3b) Move the position of the sprite to the position of the cell
      3c) Draw the sprite over the RenderTexture

This way I have a Texture that has the map representation, so it can be drawn into one big chunk instead of drawing each cell individually.

I say that i don't see how the VertexArray can help here because, intuitively, I think it would be faster to draw one big prerendered image, than composing the image from small chunks using a VertexArray.

Of course I could be wrong, but thats why I'm asking here on the forum about it

15

Graphics / Good praxis for editing and drawing

« on: March 20, 2013, 01:25:22 pm »

Hello,


I have several questions about efficency and praxis in general. I know (more or less) how to use the different classes, but i'm not sure about what kind of component to use for different tasks.
(SFML 2.0)

• Dynamic FOV:

Please excuse my cruce and inaccurate MS paint drawins

I have the scenario (1), and I draw the shadows the scenario would cast (2), then draw the shadows over the scenario (3).
The shadows (2) have to be redrawn each time the light source moves, which could be every game cicle. This means that I need to draw over a texture and then draw the texture over the screen.

Which classes fit this task. Currently I'm using a RenderTexture and a Sprite that share the same texture. I draw the primitives over the renderTexture, and then draw the Sprite over the window.
Is there a better class for this kind of task?

• Map representation:

My map is tile based. Currently, when I load the map, I draw all the tiles over a RenderTexture, then load it's texture into a sprite. I use this sprite during the execution to draw the map in the screen. This is ok for a small map, but if the map grows bigger this will turn into a problem, or so I think.
I was considerng having a matrix of textures, of 500x500 pixels, and load the sections as you advance and unload them as you leave them behind.
Is there a better approach for this matter? I keep reading about Vertex Arrays, but I fail how they are helpful in this scenario (related to last point).

• Image manipulation:

As a rule of thumb, when I want to manipulate an image regulary and display it, I make a RenderTexture and a Sprite share a texture, and use the RenderTexture to draw on it, and the Sprite to display it on screen.
I have seen the Image class, but I'm not really sure about the difference between it and the RenderTexture class. What kind of task do they fit better?

• Vertex Arrays and ConvexShapes:

I'm drawing the shadows mentioned in the first point ConvexShapes. I have seen the VertexArray class, and using the trianglestrip primitive type could be used to draw the shadows, and it would let me draw non convex shadows in one go, but besides that I don't really see an advantage on using VertexArrays.
Are ConvexShapes heavier than Vertex Arrays?
[/list]


I bet most of my questions are dumb/basic, but until now I have just blited my way through using the allegro library for basic stuff



Thanks for the help!