Messages

1

Audio / Listener Orientation

« on: October 12, 2011, 03:45:51 pm »

Thank you for considering it and also for your patience  

2

Audio / Listener Orientation

« on: October 11, 2011, 10:58:10 pm »

is not normal and could be solved without hacking in SFML.

I know, I said that:

I could, of course, put the listener at (0, 0, 10), but it's just that +Y being down makes more sense when using a physics engine.

I'm just asking that you consider this feature. Not to solve my problem (that's not really a problem per se), but because it's useful, as my example shows you.

Perhaps a sf::Listener::SetListenerOrientation? One that does the same thing as SetListenerDirection, but with the option to also change the up vector, the default would still be (0, 1, 0).

3

Audio / Listener Orientation

« on: October 11, 2011, 07:43:53 pm »

I apologize if I'm not being entirely clear  :oops:  But even nitram_cero mentions what I'm talking about, and I'm already using this system on my game, it works the way I said, even the cool effect works fine...

To me it's ok to have the up vector hard-coded, this is like a physical constant (just like gravity for example).

In 3D, gives you the hability to roll your head (e.g. Peeking from a corner of a wall).

In 2D gives you freedom to define which sound-coordinate axis is associated with a screen-coordinate counterpart. I like using x for x and y for y, it's more confortable to work this way.

Also to let you "reverse" the speakers (Up = -Up), for configuration and also could be used for a weird powerup effect.

Now, how could I implement the effect I mentioned with the current implementation of sf::Listener? Imagine a sound coming from the right speaker, I want it to rotate around the "front" axis, in clockwise direction. So the sound would be heard from top, then from the left, ending by being heard from below.

4

Audio / Listener Orientation

« on: October 11, 2011, 03:58:08 pm »

What do you mean?  :?  In my scenario, using the (0, 1, 0) up vector makes objects to the left of the listener emit sounds through the right speaker.

As an example, the listener is at (0, 0, -10), looking at the +Z axis, and the object is at (-5, 0, 0) for example. Now, using the default up vector (0, 1, 0), makes the listener's head point down, what I don't want.

I could, of course, put the listener at (0, 0, 10), but it's just that +Y being down makes more sense when using a physics engine.

Other use I could think of is to do a rotation effect of the entire screen, think about it, imagine rotating the entire game world, hard. Now imagine rotating just the graphics with a simple transformation and rotating the listener's up vector, both can be done easily. It's a cool effect, by the way.  

5

Audio / Listener Orientation

« on: October 11, 2011, 04:25:51 am »

Hello! I've just started using the Audio module of SFML2 and so far everything is fine, I'd just like to know why isn't there an option to set the up vector of the Listener's orientation.

sf::Listener::SetDirection assumes it's (0, 1, 0), but my game, for example, is entirely built around the (0, -1, 0) up vector.

Code: [Select]

////////////////////////////////////////////////////////////
void Listener::SetDirection(float x, float y, float z)
{
    priv::EnsureALInit();

    float orientation[] = {x, y, z, 0.f, 1.f, 0.f};
    ALCheck(alListenerfv(AL_ORIENTATION, orientation));
}

For now I'm using a modified version of SFML with an overloaded SetDirection that takes another sf::Vector3f as the Up vector. So, why isn't this implemented?  :?:

6

Graphics / Pixel-perfect Sprite SubRect

« on: September 28, 2011, 04:13:16 pm »

I thought I'd post this here since it shows the result of the problem on topic. This is a modified code from SFML 1.6 Sprite's tutorial, now upgraded to SFML2, that shows a tile from my sample spritesheet (get it here). It draws the tile using SFML2's Sprite and then it draws it again using pure OpenGL with the half-pixel epsilon applied. Try moving both around, see how the artifact only shows up on the left one (SFML2 Sprite).

Code: [Select]

////////////////////////////////////////////////////////////
// Headers
////////////////////////////////////////////////////////////
#include <SFML\Graphics.hpp>
#include <SFML\OpenGL.hpp>

////////////////////////////////////////////////////////////
/// Entry point of application
///
/// \return Application exit code
///
////////////////////////////////////////////////////////////
int main()
{
    // Create the main rendering window
    sf::RenderWindow App(sf::VideoMode(800, 600, 32), "SFML Graphics");

    // Load the sprite image from a file
    sf::Texture Tex;
    if (!Tex.LoadFromFile("platform.png"))
        return EXIT_FAILURE;

    // Create the sprite
    sf::Sprite Sprite(Tex);

    // Change its properties
    Sprite.SetPosition(64.f, 64.f);
    Sprite.SetSubRect(sf::IntRect(0, 16, 16, 16));

    // Start game loop
    while (App.IsOpened())
    {
        // Process events
        sf::Event Event;
        while (App.PollEvent(Event))
        {
            // Close window : exit
            if (Event.Type == sf::Event::Closed)
                App.Close();
        }

        // Get elapsed time
        float ElapsedTime = App.GetFrameTime() / 1000.f;

        // Move the sprite
        if (sf::Keyboard::IsKeyPressed(sf::Keyboard::Left))  Sprite.Move(-100 * ElapsedTime, 0);
        if (sf::Keyboard::IsKeyPressed(sf::Keyboard::Right)) Sprite.Move(100 * ElapsedTime, 0);
        if (sf::Keyboard::IsKeyPressed(sf::Keyboard::Up))    Sprite.Move(0, -100 * ElapsedTime);
        if (sf::Keyboard::IsKeyPressed(sf::Keyboard::Down))  Sprite.Move(0, 100 * ElapsedTime);

        // Rotate the sprite
        if (sf::Keyboard::IsKeyPressed(sf::Keyboard::Add))      Sprite.Rotate(- 100 * ElapsedTime);
        if (sf::Keyboard::IsKeyPressed(sf::Keyboard::Subtract)) Sprite.Rotate(+ 100 * ElapsedTime);

        // Clear screen
        App.Clear();

        // Display sprite in our window
        App.Draw(Sprite);

        // Now that SFML set-up the viewport, bound the texture and everything, just draw directly
        sf::Vector2f v = Sprite.GetPosition() + sf::Vector2f(64.f, 0.f);
        float Epsilon = 0.0078125;

        glBegin(GL_QUADS);
        {
            glTexCoord2f(0.f, 0.25f); glVertex2f(v.x, v.y);
            glTexCoord2f(0.f, 0.5f - Epsilon); glVertex2f(v.x, v.y + 16);
            glTexCoord2f(0.25f - Epsilon, 0.5f - Epsilon); glVertex2f(v.x + 16, v.y + 16);
            glTexCoord2f(0.25f - Epsilon, 0.25f); glVertex2f(v.x + 16, v.y);
        }
        glEnd();

        // Display window contents on screen
        App.Display();
    }

    return EXIT_SUCCESS;
}


7

Graphics / Pixel-perfect Sprite SubRect

« on: September 28, 2011, 03:45:57 pm »

The "right" value should be 0.0078125, which is 0.5 / size (from your screenshot your texture looks like it is 64x64), that's why it's called the half-pixel trick

Ooh, I didn't know that! I think I'll implement an epsilon that's based on the texture size  :idea:  It's not as ugly as I've thought!

So it's not a ugly hack, but rather a well-known technique to align pixels and texels -- which are initially aligned differently (one is aligned at the center of a pixel, the other is aligned on the top-left corner of a pixel).

But I'm surprised it works because that's the first thing I tried in order to solve this problem.

Now that you mention it, I remember seeing something similar on HLSL shaders when I did some work with XNA, but I think it was a translation of half-pixel, and not a subtraction.

8

Graphics / Pixel-perfect Sprite SubRect

« on: September 28, 2011, 03:33:07 pm »

But something is not clear: do you subtract this offset from pixel coordinates (0 .. size), or normalized coordinates (0 .. 1)?

Normalized, as I said I'm using my own implementation of the drawing stuff, with pure OpenGL calls, so I subtract that epsilon directly at glTexCoord2f().

I started subtracting 0.0001, nothing changed, then I increased that value until it actually cut a pixel from all sprites, that was at 0.01, and 0.005 didn't fix it, so I tried 0.0075 and ta-da!    Haha I hate these ugly hacks.

Don't worry, I'll do the tests

Be sure to let us know the results!  :wink:

9

Graphics / Pixel-perfect Sprite SubRect

« on: September 28, 2011, 03:08:36 pm »

Doesn't the problem reappear if you offset your sprite by this value?

I read your questin and went test it fearing it would make sense and the problem would reappear, to my surprise it did not. I tried drawing the same subrect as I did on my first post at .0075f and .9925f (1 - .0075) coordinates and no signal of the artifact.

My theory is that I am removing a really small area of the subrect so in the end it doesn't affect anything, but it's enough to impact rasterization when it tries to exceed the borders. Even if I draw the vertices at that offset, nothing happens since the area is actually cut down, and not just translated.

I'd love to know if this works on high-res stuff, but as I'm fed up with this graphical stuff I'll just leave the testing to someone else  :wink:

10

Graphics / Pixel-perfect Sprite SubRect

« on: September 28, 2011, 02:15:24 am »

Oh, I didn't know that, is it available for testing? And by the way, I just found a temporary (or maybe permanent, I don't know) solution for my problem: if I subtract exactly 0.0075 from the right and bottom coordinates of the subrect, the sprite remains the same if drawn on whole coordinates, and there's no artifact if it's drawn on fractional coordinates.

I've tried to add these little offsets before, but always at the vertices positions, never at the source rectangle. To test, I've been zooming in and out with a few different sprites on the screen, rotating and moving them, and no signal of the rasterization artifact. As I want to resume development ASAP I'll just leave this 'epsilon' there  :roll:

Maybe it only works in my low-res spritesheet scenario, who knows?


EDIT: Forgot to say that I'm doing that subtraction in the current implementation of my drawing system, the one with pure OpenGL stuff, so that epsilon is applied directly at glTexCoord2f calls.

11

Graphics / Pixel-perfect Sprite SubRect

« on: September 27, 2011, 11:12:04 pm »

I'm not 100% sure if it got to do with this but I remember one of my class mates talking about something similar or maybe the exact thing(It's about a year ago now) and he said he fixed his problem by offsetting the sprite with 1 pixel. So instead of having origo at 0,0 it was at 1,1

I didn't quite get what you mean, is it like just a simple translation?

Anyhow, going with the padding solution didn't help you?

You mean the padding on the spritesheet? I could do that, it's just that I have a whole lot of animation and spritesheets ready.

The truth is that what I'm doing is rewriting an old game of mine from scratch and porting it to OpenGL (it was made with D3D), so I'd do anything possible to don't even touch the artwork. Well, if in the end nothing works...  :?

12

Graphics / Pixel-perfect Sprite SubRect

« on: September 27, 2011, 11:04:49 pm »

I think this is the same problem I already had here.

Do the issues persist exactly as they were in the new graphics API? Would the possibility for customization be too low-level?

I've seen your topic before, my engine was entirely built around SFML 1.6, when that problem came along I decided to refactor it around SFML2. The problem persisted even though it didn't happen as often.

To reproduce the problem I used the tutorial I mentioned, in the original SFML 1.6 code, upgraded to SFML 2 and now with the rounded coordinates modification. Nothing fixed it completely. I also tried it with almost no SFML code, only direct OpenGL stuff, and the artifact was still there.

What annoys me most is that I can't find anything related to this, what I could find was here in the forums. I've never played an OpenGL game with that problem either, even the ones that look just like my game, that use spritesheets, physics, and have smooth motion. And I also never had this problem when my engine was based on Direct3D 9.

I'll have to take a day off just to think about this...

13

Graphics / Pixel-perfect Sprite SubRect

« on: September 27, 2011, 10:50:52 pm »

Yes, and that was even done before. If you look at the Git log for Renderer.cpp you can find a revision which contains this code (it's two additional lines in ProcessVertex).

I just tried that today, but I didn't like the result... First, the movement is weird, but I can live with that. The problem is that rotating the sprite, even with all vertices having rounded coordinates, can still produce the artifact.

To complicate things even more, the way my engine draws the sprites introduces a new problem: sometimes there's a space of 1 pixel between the tiles, result of rounding the coordinates.

My conclusion is that this drawing approach I'm using doesn't go well with the spacial freedom of a physics-based game. I'll have to find another way...

14

Graphics / Pixel-perfect Sprite SubRect

« on: September 26, 2011, 02:57:24 pm »

I've been reading SFML2's code and noticed that the Renderer makes the Model View transformations itself, and not OpenGL anymore, is this correct?

If that's the case then all I'd have to do is implement my own ProcessVertex, with floor() at the end, this way everything would be pixel aligned, does that make sense? What would be the best way to do that? I don't mind rewriting a few classes, it's still simpler than handling alignment physics-side.

15

Graphics / Pixel-perfect Sprite SubRect

« on: September 26, 2011, 12:11:37 am »

I'm trying to solve a little problem that I have with SFML Sprites and low-res spritesheets (e.g. pixel art). I'm using a Sprite to draw a 16x16 subrect of a spritesheet and getting weird texture mapping results.

For example, if I draw this 16x16 subrect at a position with rounded coordinates (5.0, 5.0), everything goes fine, but when I draw it at (5.5, 6.5), the subrect exceeds its borders. Here's a screenshot of the problem reproduced using the Sprite Tutorial's code:



When I move the sprite, that line appears. I've seen another topics on this subject here, with mixed results. Some say SFML 2.0 corrected this problem, but I upgraded the tutorial's code to 2.0 and the problem persisted (but it doesn't happen as often). Some say that pixel-aligning the sprite fixes it, which is true, but trying to align sprites that represent physics entities is complicated and movement becomes weird, not as smooth as I want. Oh, and enabling nearest neighbor filtering does not fix it either.

My current workaround is by using a SFML2's 16x16 RenderTexture, I draw the tile on it, then draw it on the window, this way the problem is 100% fixed no matter where I draw it, but now my render logic is ~33% slower, and memory consumption is also higher.

So I come here today to ask you guys if there's another fix, another technique, something I've missed, anything... Development's going really fast with SFML, I love it.

Thanks in advance.