Messages

1

Graphics / Re: Binding real position to shader

« on: June 01, 2013, 01:38:16 pm »

Ok, so after your post, I went back and cleaned up my code, passing only the exact position as I've passed it into the CircleShape.

This didn't work, but since I assumed you are correct (it is your code), so I went to check my other code - namely my shader code.

My problem was in the vertex shader.. I had accidentally written

Code: [Select]

fragPos = gl_Vertex * gl_ModelViewMatrix;in my hurry to test this. The correct line is of course:

Code: [Select]

fragPos = gl_ModelViewMatrix * gl_Vertex;
So, problem fixed, thanks! It's still good to know that the exact world position as I pass it into shapes is what I need to pass in to the shaders.

2

Graphics / [Solved] Binding real position to shader

« on: June 01, 2013, 02:34:39 am »

I'm having a small issue, maybe someone can help me.

I set a custom view on my window, then I draw a CircleShape at a certain position, using a custom vert/frag shader.

I wanted to pass the information of that position into the frag shader, in such a way that its compatible (meaning accurate) with the positional information given by gl_Vertex in the vertex shader.

When I pass just the position, exactly the same as I set it on the circle shape, it seems that the 'center' doesn't appear to be in the center of the circle shape, and even more oddly moves around when the circle shape's position changes.

I figured I'd try the getView().getTransform().transformPoint(..) on the position, but that also yields strange results. The 'center' doesn't move when the circle shape moves, but still appears to be somewhere in the far upper left of the circle shape, and not the center. Yet I have set the circle shape's origin, via setOrigin to be so that it's center appears exactly at the given position.

I realize this isn't that easy to describe, but the screenshots I took aren't really clear either... hopefully someone can figure out what I'm talking about and offer advice. Thanks.

Edit: Basically I want to take a sf::Vector2f I pass as position in c++, and then give the accurate information on where that position is to opengl's shaders, in world space (not screen space)

3

General discussions / Re: A new logo for SFML

« on: February 02, 2013, 09:16:25 pm »

I was rather bored, and I have squircle shaped plates in my apartment.

4

General discussions / Re: A new logo for SFML

« on: February 02, 2013, 01:53:19 am »

Started off with the idea of laying out SFML on a keyboard, plus the warm fuzzy feeling I got when I found SFML the first time. Just my two cents

5

SFML projects / Re: SimpleSprite

« on: February 01, 2013, 09:26:14 pm »

I see, I should do that, but I'm not sure how how (if at all possible) to upload files there, so I'm just going link to this thread for this.

6

SFML projects / SimpleSprite

« on: February 01, 2013, 07:26:04 pm »

I was doing some testing yesterday on a project I'm working on, and I realized that drawing the sf::RectangleShape (which I had a lot of) wasn't performing as fast as using a sf::Sprite. However, I also wanted a setSize functionality and I was planning to do something which would have benefited from a setVertexColor function.

So, this isn't exactly a project, but I wrote a SimpleSprite class which fullfills those needs.
It should also duplicate all functionality of a sf::Sprite, so you should (in theory) be able to replace any sf::Sprite objects with SimpleSprite and would not be required to do any other code changes. I've seen a couple of posts where people were talking about stuff like this, so I decided to post this.

Here's the public functionality of SimpleSprite:

Code: [Select]


    SimpleSprite ( );

    explicit SimpleSprite ( const sf::Texture &texture );

    SimpleSprite ( const sf::Texture &texture, const sf::IntRect& rect );

    void setSize ( const sf::Vector2f &size);

    void setSize ( float size_x, float size_y );

    void setTexture ( const sf::Texture &texture, bool updateTextureRect = false );

    void setTextureRect ( const sf::IntRect &rect );

    void setColor ( sf::Color color );

    void setVertexColor ( unsigned int index, sf::Color color );

    // getters

    const sf::Vector2f& getSize () const;

    const sf::Texture* getTexture () const;

    const sf::IntRect& getTextureRect () const;

    // Warning: This function may not return correct results if you have used setVertexColor(..)
    // This function is the equivalent of calling getVertexColor(0)
    const sf::Color& getColor () const;

    const sf::Color& getVertexColor ( unsigned int index ) const;


The .hpp and .cpp are attached.
Edit: Updated - the default behavior of setTexture so that updateTextureRect is false by default.

[attachment deleted by admin]

7

Feature requests / Support for OpenGL Array Texture in future SFML2.x

« on: January 18, 2013, 01:54:26 pm »

I don't think this will be the easiest thing to integrate with the current setup of image/texture/sprite - but I think it may be beneficial to add support for http://www.opengl.org/wiki/Array_Texture - or at least, support for the array of 2D textures (the 1D variant has its uses, but i think is not nearly as commonly used)

By support, I mean allowing the creation of something like sf::ArrayTexture and allowing sprites/shapes to have their texture set in the form of  Sprite::SetTexture ( ArrayTexture &arrayTexture, unsigned int level )
This, as far as I know, would also require that all drawing be done with a custom shader.

The main reason for this request is that it would provide possibilities for speed optimizations in certain, though not very common, cases.

For example, and what caused me to think of this request:
I currently have a tile-based game, where there are 34 different tile types. Each tile type has its own texture, for a specific 'theme' - i.e. dirt tiles, concrete tiles, glass tiles, metal tiles etc.
Currently, each theme is stored 1536x1536px texture atlas, and drawing a variety of tile types that all have the same 'theme' (i.e. they're all dirt tiles) is quick.
However, drawing tiles that all have different themes still requires a number of texture switching between the texture atlas for each theme. (a workaround to minimize this would be to sort the tiles by type when drawing, but it's still not as efficient as using a array texture)

Since all of my texture atlases are the same size, it would ideal to stick them in an Array Texture - and I would, except there's no easy way to supply this information to the sf::Sprite class.

Thanks!

8

Graphics / Re: Shaders: General questions

« on: January 11, 2013, 02:51:48 pm »

...
There are other solutions for clipping but I don't think they are compatible with SFML.
...

I'm doing rendering with sfml2.0 for my UI, and I use glScissor to clip the rendering area (with a Textbox in my case) like this:

glScissor(position.x, position.y, size.x, size.y);
// do my background/text rendering using sfml here
glScissor(0,0,appw, apph);  // where appw and apph are the window's width and height, respectively.
 

The downside with using glScissor is that you can only clip to a rectangle area, but that's what I needed in my case.

9

Graphics / Re: How to best handle Textures

« on: January 03, 2013, 02:07:43 pm »

Yes.
SFML binding a texture should not be alot different from what you'd do in raw OpenGL code.

I'm just going to assume you're more familiar with sfml than I, but it's certainly no stretch of the imagination that it works like that. Thanks.

Edit: Actually I've already coded most of it and it should be functional, I just haven't tested it.

Heh, reminds me of the quote from Donald Knuth - "Beware of bugs in the above code; I have only proved it correct, not tried it."
But no thanks, really sf::Sprite does 99.9% of the things I need, and the one thing that's slightly bugging me about it - the lack of setSize - is easily circumvented with setScale.

10

Graphics / Re: How to best handle Textures

« on: January 03, 2013, 05:04:23 am »

I didn't say anything, except that texture switch is expensive. Which is true

I was looking through these forums, and this topic seems to be quite related to what I was wondering - so I'm going to ask here instead of making a new thread.

If I draw 50 sf::Sprite in immediate succession (i.e. nothing drawn in between them) would the drawing be faster if all 50 were set from the same texture (but potentially different texture rectangles), than if all 50 had individual textures?

I'm aware in pure OpenGL the above would be faster due to not having to re-bind textures for drawing, but I'm not 100% familiar with all the code in SFML (especially 2.0 RC), so I'd thought I'd ask directly.
Thanks.

11

Window / Window Not Opening

« on: February 05, 2012, 04:08:02 pm »

I ran into this problem a while ago, and one solution was to download an older version of atigktxx.dll, and put it in the same folder of the executable.
I recently updated my ATI graphics driver to the newest, and they seem to have fixed this, as my program runs without problems.

But, I just want to make sure I got this: SFML 2.0 does not have this window creation issue?

12

SFML projects / Human Skeleton Animator

« on: February 05, 2011, 10:44:26 pm »

Update again: I actually completed the algorithm.
It attaches a model to the skeleton automatically. Each vertex is attached to up to 3 bones, allowing for smooth model movement. Here's the updated video:


And, again the website if anyone's interested:
http://www.milchopenchev.com/projects/HAP/index.htm

- Thanks.

13

SFML projects / Human Skeleton Animator

« on: January 30, 2011, 03:43:35 pm »

Thanks, ActionBoy. The interface is all my work, transfered and improved from a past project.

The next part of the project, which I'm working on now, is to animate a mesh.The idea is to have a modular design, so you can exchange model parts (i.e. torso, arm, hand, leg etc)
Not that it's a big deal, though someone might find it interesting.

14

SFML projects / Human Skeleton Animator

« on: January 23, 2011, 08:05:44 pm »

Hi everyone, I found SFML right before new years, and I decided to use it for a project I had JUST started.

In brief, the project is an attempt to create an easy to use character animation, based on a rigid skeleton structure.

It uses OpenGL for 3d graphics.
SFML for the window and event handling, and I further plan to use it for the loading textures.

The project site can be found Here
Or if you're just interested in a quick view, there's a video

On the site you can find links to download the win32 release, and the source code, as well as a far more detailed description and instructions on how to animate.

The project is a little over 3 weeks old at this point, and I've reached a snag that I don't have the ability to create a human model for the project.
There's also a larger project which this is the first part of.
So, besides comments and criticism, if anyone's interested in helping me, you can find a place to talk on the project's site.

Thanks.

15

Window / fullscreen and opengl

« on: January 09, 2011, 05:18:46 pm »

Well, I have separated my opengl init, all except light setup, which is a different class, I suppose I can try to re-initialize all the states after a switch. Or alternatively just care about the stored startup state in my ini file, and not allow runtime switching, until after a restart.

I'm not aware of any such functionality in Linux or OS X, especially since I have little no experience coding on OS X.

Thanks for your help, it's cleared up my problems, now I just have to find solutions.

- Zenon