Messages

1

Graphics / Issue with sf::View and pixel perfect texCoords

« on: May 11, 2018, 01:19:57 am »

Hello there.

After introducing scrolling via sf::View to a tile based scene, I discovered sporadic occurence of artifacts. It took me a while to find the source via experimenting a lot but now I have come to the conclusion that occasionally, my View is set in such an unfortunate way that some transformations cause additional pixels to be drawn.

A bit more detailed:

I've got a bunch of Tiles using Quads with texCoords which are a multiple of some integer tile size referring to a tilemap texture. I made sure that the float values actually are integers. Something like [0, 0], [0, 16], [16, 0], [16,16] and the likes.

Now, I set the View every frame before drawing and occasionally tiles are drawn with pixels that belong to the next tile on the texture (like [17, 16] instead of [16, 16] for the bottom right pixel). Generally, those additional pixels are completely unrelated thus leading to artifacts.

Do you have any ideas from preventing this to happen?

I think the problem does not occur if I set the View's top left corner as an integer. However, this causes other problems because my View follows some Sprite with float (actually double) position (resulting in serious jittering). Or I might convert all the positions to integer for drawing (but this might also be a problem because of rounding issues).

Or shall I try setting the tex coords to the center of the pixels (like [0.5, 15.5])? Sounds off to me.

2

Graphics / Re: Qt & SFML in 2.4

« on: May 01, 2018, 12:44:36 pm »

It's been a while, but I could finally reproduce the problem with a minimal example. Minimal as in how minimal it can be with a qt application (requires moc to compile).

Failed to create input context for window -- TextEntered event won't be able to return unicode


comes up for every second canvas I create (in this example, I create four canvases in MainWindow::MainWindow()). Does not occur on Windows but on Ubuntu linux.

Any idea on this?

My point still stands. Start a debugger and check what's going on, you know basic programming things.

I can see that

m_inputMethod = XOpenIM(m_display, NULL, NULL, NULL);

in void WindowImplX11::initialize(), line 1267 of WindowImplX11.cpp seems not to be true when the error occurs, but I have no knowledge about those low level things. The circumstances of my own code are always the same.

3

Graphics / Re: Qt & SFML in 2.4

« on: February 09, 2018, 07:40:38 pm »

Thank you for your reply.

I found that the wrong position / scale is a different issue not connected to the error message at all, sorry for that. I updated my original post.

The error implied by the message does not seem to have any effect.

4

Graphics / Qt & SFML in 2.4

« on: February 09, 2018, 05:57:29 pm »

Hello there.

I am afraid that this problem might be very difficult to solve because I can barely give you any information, but maybe you have got an idea on how to solve it.

Quite a while ago, I successfully managed to integrate SFML into Qt (see https://en.sfml-dev.org/forums/index.php?topic=19163.msg138596#msg138596 and https://github.com/SFML/SFML/blob/master/src/SFML/Window/Unix/WindowImplX11.cpp).

I did it on Windows (MinGW), SFML 2.3.2, but it also worked on linux (g++).

Currently, I am working on linux. I compiled SFML 2.4 for myself with Clang. Now, when I start my Qt/SFML application, as soon as the GUI shows up, I get the error message

Failed to create input context for window -- TextEntered event won't be able to return unicode

exactly once, while I have two QWidget/sf::RenderWindow elements.

Edit: Actually, I found out that this happens once for every second QWidget/sf::RenderWindow element I add, which is very odd (or rather: even).

The application continues to run, however, the contents of those windows are not positioned correctly and the proportions are off. properly without any issues.

I tried debugging but I cannot find out at which point the problem arises. I think it is somehow triggered by Qt when it starts displaying the application gui. Still, I do not think I changed anything of the window creation process since I worked with the older SFML version, so I wonder if something in the new SFML version changed the behavior.

Unfortunately, I cannot provide any minimal example code (as I cannot narrow down the problem's origin), but I can show you my Qt/sf::RenderWindow implementation class, which I attach to this post.

I also welcome general ideas on when the error message mentioned above can occur.

5

General / Re: Game Loop Lag

« on: December 28, 2017, 03:49:28 pm »

@achpile: I don't want to tie the game loop updates per second to the graphics.
@ fallahn: Thank you. However, I already implemented interpolation and it works fine.

After trying various things, currently, the problem seems to occur when the window's draw function is blocking the game because it cannot draw instantly, for instance because of vsync.

Currently, I've got the drawing in another thread. However, as I need to synchronize data, the drawing thread locks a mutex and the game loop can't advance. I think that a solution is for the mutex to be only locked when the window ACTUALLY draws and not just has to wait for the next time to draw. However, it appears to be that this is not possible with setVerticalSyncEnabled or setFrameLimit.

//drawing thread
mutex.lock();
window.clear();
window.draw(*GAME); // << this method waits for the vysnc or whatever before drawing and thus the mutex is locked for longer than necessary, causing a delay in the game update loop
window.display();
mutex.unlock();

EDIT: Wait, I made a mistake. It should be the display that causes the lag. I will try locking the mutex only around .draw but not .display.

6

General / Re: Game Loop Lag

« on: December 24, 2017, 12:47:08 pm »

Thank you for your answer.

7

General / Game Loop Lag

« on: December 11, 2017, 07:39:05 pm »

Hello there.

Does anyone see what mistake I made in my game loop? I thought it to be a standard approach, yet I get a periodic micro-lag roughly every second.

I have already played around with various things like integer positions, sleeping for some milliseconds, enabling v-sync, drawing in a separate thread, interpolating the movement. Yet it must be some different problem as nothing helped so far.

Minimal example (for better readability, all the variables are declared in the beginning):

#include "SFML/Graphics.hpp"

const int FPS = 60; // frames per second
const double SPF = 1.0/FPS; // seconds per frame
const double MSPF = 1000.0/FPS; // milliseconds per frame

bool quit = false; // quit flag

sf::Clock timer; // timer to measure lapsed time
int delay = 0;  // delay to determine when to update physics
int carry = 0; // leftover of delay from last update

// object to be drawn
sf::RectangleShape rect = sf::RectangleShape(sf::Vector2f(200, 200));
double rectSpeed = 200;
double x = 0;

// physics update
void update() {
    x += rectSpeed*SPF;
    while(x > 1200) {
        x -= 1400;
    }
    rect.setPosition(x, 0);
}

// draw to screen
void draw(sf::RenderWindow &window) {
    window.clear(sf::Color::Black);
    window.draw(rect);
    window.display();
}

int main()
{
    sf::RenderWindow window(sf::VideoMode(1200, 900), "Test");
    //window.setVerticalSyncEnabled(true);
    //window.setFramerateLimit(60);



    carry = 0;

    while(quit == false) {
        sf::Event event;
        while(window.pollEvent(event)) {
            if(event.type == sf::Event::Closed) {
                quit = true;
            }
        }
        delay = carry + timer.getElapsedTime().asMilliseconds();
        if(delay >= MSPF) {
            timer.restart();
            while(delay >= MSPF) {
                update();
                delay -= MSPF;
            }
            carry = delay;
        }
        draw(window);
    }
    window.close();
    return 0;
}
 

Regards,

sb

8

General / Re: [SOLVED] SFML inside QT: sf::RenderWindow and QScrollArea

« on: July 25, 2016, 07:08:08 pm »

I also experienced the same problems as you did (I'm especially referring to the white trail). RenderWindows should really be only as big as what you are supposed to see "through" them (like an actual window ), it seems.

Using a QAbstractScrollArea seems to be "semantically more correct" than my solution, however, I guess the actual implementation will need the same or similar steps.

9

General / Re: [SOLVED] SFML inside QT: sf::RenderWindow and QScrollArea

« on: July 22, 2016, 04:44:03 pm »

I think I did it.

You will find my solution in this post's attachments.

The QSFML class is almost the same as in the tutorial mentioned in the original post, I think. As for the class ScrollCanvas: The header file explains all the functions and members, so I will restrict myself to outlining how to use it:

Basically, you must assign the ScrollCanvas a content (sf::Drawable*) and the content's dimensions. The latter is important for adjusting the QScrollBars. Whenever the content's dimensions are changed (via the setter method), the QScrollBars adjust (if you take a look at the implementation file, you will see the not-so-clear formulas). By changing the QScrollBars' values, a signal is sent to the ScrollCanvas scroll() method, which changes the contentOffset members and updates its View. The View shall not be changed manually as all the methods rely on the member variables.

You can also zoom via setContentScale() (it will always zoom into the widgets center), however, I don't provide a GUI element for this.

To integrate into your Qt window, you need to create a ScrollCanvas object and add both itself and its two scrollBar members to where you want it to appear (they are all QWidgets). Deleting the ScrollCanvas object should also delete the QScrollBars.

For drawing the assigned content, you can consider the ScrollCanvas' View as it should be usual in SFML.

If there is anything that's unclear, please ask.

10

Graphics / Re: General question: RenderTarget/~Texture/~Window and Views

« on: July 22, 2016, 04:23:58 pm »

Thank you for your reply.

It seems you're right. Some time before I made a mistake and scaled the RenderWindow to the size of  the scene which caused Windows 7 to change display settings or something like this, but apparently, this is neither required nor a good idea.

I tried to set up a big scene and as long as I only draw objects that lie inside the RenderWindow's View, I don't have any problems or experience bad performance.

11

Graphics / [SOLVED] General question: RenderTarget/~Texture/~Window and Views

« on: July 21, 2016, 05:10:59 pm »

Hey there.

Until now, I used a RenderWindow to draw my scene and manually moved it by applying a transition to the scene (which inherits from Drawable). However, apparently SFML provides the View class.

Now I wonder what kind of RenderTarget I should pick to draw my whole, possibly very large scene. RenderWindow seems to be unfit as this seems to be supposed not to be bigger than an actual display screen. Now there's also the RenderTarget base class and a RenderTexture class. I really can't figure out what to pick! I also think that there must be kind of a GPU limit to the dimensions.

If that's important: I draw into a Qt window and the only way to integrate I know is https://github.com/SFML/SFML/wiki/Tutorial%3A-Integrating-SFML-into-Qt , which uses a RenderWindow object.

12

General / Re: [SOLVED] SFML inside QT: sf::RenderWindow and QScrollArea

« on: July 21, 2016, 03:42:56 pm »

Hey, Yohdu.

My implementation works but I recently realized that it's not compatible with sf::View. I will try to solve this and then provide the code. Until then, I'll just explain my solution informally and in short:

1. ScrollCanvas inherits from QSFMLCanvas and adds a pointer to a sf::Drawable object named content, it also has two QScrollbars and a member function scroll().
2. Set the Scrollbars' ranges from 0 to the contents width/height.
3. connect(...) the scrollbars value-changed-signal to scroll(), which then stores the new scroll values. This is a Qt mechanism that looks like

connect(this->horizontalScrollBar, SIGNAL(valueChanged(int)), this, SLOT(scroll()));

4. Consider the scroll values when drawing the content in the ScrollCanvas.

13

SFML wiki / Tutorial: Integrating SFML into Qt: FrameTime = 0

« on: July 15, 2016, 09:15:35 pm »

Hi there.

Regarding https://github.com/SFML/SFML/wiki/Tutorial%3A-Integrating-SFML-into-Qt , I think one could suggest changing the constructor

QSFMLCanvas(QWidget* Parent, const QPoint& Position, const QSize& Size, unsigned int FrameTime = 0);

such that default value is

unsigned int FrameTime = 1000/frames_per_second

or something alike.

The reason is that with a zero FrameTime, at least in my case (Windows 7), the program uses a whole lot of CPU time without actually doing anything. Changing it to a value like 1000/60 drastically reduces the CPU usage, and 60fps should be really enough for drawing in a GUI.

If you agree, you could update the tutorial (I won't as I don't want to register there), however, if my suggestion is not reasonable, please explain.

14

General / Re: SFML inside QT: sf::RenderWindow and QScrollArea

« on: July 15, 2016, 04:15:36 pm »

Probably. In fact, this is what I am trying right now.

15

General / [SOLVED] SFML inside QT: sf::RenderWindow and QScrollArea

« on: July 15, 2016, 03:52:46 pm »

Hey there.

Last year, I asked for help as I wanted to integrate SFML into QT. The post can be found here: http://en.sfml-dev.org/forums/index.php?topic=19163.msg138596#msg138596
We kind of concluded a way to do this and someone wrote it down as a tutorial here: https://github.com/SFML/SFML/wiki/Tutorial%3A-Integrating-SFML-into-Qt

My QWidget, which also is a sf::RenderWindow at the same time, is inside of a QScrollArea. If the QWidget/sf::RenderWindow is bigger than the QScrollArea, scrollbars appear and behave as expected.

However, I want to draw a really big object (multiple displays in size). I figure that the solution is not to set the QWidget/sf::RenderWindow that big (you usually don't have windows bigger than your screen can display).

I think I know how to implement a RenderWindow that only shows a portion of the object and scrolling by translating the object relatively. However, as the QWidget/sf::RenderWindow now is only as big as the actually seen portion, the QScrollArea around it doesn't need to provide any scrollbars as the object insinde fits into it.

So I wonder if there is a way to tell the QScrollArea that the size of the QObject/sf::RenderWindow inside is actually bigger (as big as the object I want to draw) without having the RenderWindow explode in size. If I found a way to do this, I guess I could connect the scrollBar to a function that perfoms the relative translation of the drawn object inside the RenderWindow.

Does this make any sense to you? It seems to be rather a Qt than a SFML question, but in my opinion it is of interest to everyone who wants to integrate SFML into Qt. If someone found a comprehensive way to achieve this, it could be added to the tutorial I mentioned above. I think that without this, integration is not fully achieved yet.