Messages

1

Graphics / Re: xcb_wait_for_reply deadlock

« on: March 09, 2014, 11:50:18 pm »

Yeah, it is odd. Are you able to revert back to a 3.13.5 kernel? That's the only other difference I see... I was going to update tomorrow, but, now I'm kind of worried about doing so.

I'd consider going to the Arch forums and asking there.

Code: [Select]

[chaosed0@ChaosArch whateven]$ uname -a
Linux ChaosArch 3.13.3-1-ARCH #1 SMP PREEMPT Fri Feb 14 08:19:35 CET 2014 x86_64 GNU/Linux



I think you're good.

EDIT: Posted to the archlinux forums. (Was "Multimedia and Games" the correct section?)

2

Graphics / Re: xcb_wait_for_reply deadlock

« on: March 09, 2014, 08:09:03 pm »

Hmm. It runs fine for me:
Arch Linux x86_64. 3.13.5-2-ck
X: 1.15.0
xcb: 1.10-1
SFML: 2.1 from repos, and git version
WM: Openbox
g++ 4.8.2-20140206

Major differences I see are you built X and xcb from source, and that I'm on a ck version of the kernel (I'm a minor version behind too apparently).

That's really odd... And a bit disturbing. Actually, the only reason I'd built them from source is to get more info from the traces (I ended up building Xorg not as debug, because it didn't seem like that would be the problem). I was running into the same issues on the packages straight from pacman. I'm kind of at a loss now... I wouldn't think it's the kernel version, but maybe I'll give it a try.

EDIT:

Code: [Select]

[chaosed0@ChaosArch ~]$ uname -a
Linux ChaosArch 3.13.6-1-ck #1 SMP PREEMPT Fri Mar 7 16:05:57 EST 2014 x86_64 GNU/Linux

Still no luck. Maybe it's time for a fresh reinstall.

3

Graphics / xcb_wait_for_reply deadlock

« on: March 09, 2014, 07:30:13 pm »

Getting an error just creating a window. Here's the code I'm running:

#include <SFML/Network.hpp>
#include <SFML/Window.hpp>
#include <SFML/Graphics.hpp>
#include <stdio.h>

void SFMLWindowTest() {
        sf::RenderWindow window;
        bool running = true;
        sf::Time minFrameTime = sf::seconds(1) / sf::Int64(60);
        sf::Clock frameClock;

        window.create(sf::VideoMode(800, 600, 24), "SFML window", sf::Style::Resize | sf::Style::Close);

        while(running) {
                printf("Running\n");

                sf::Event anEvent;
                while(window.pollEvent(anEvent)) {
                        if(anEvent.type == sf::Event::Closed) {
                                running = false;
                        }
                }
                window.clear();
                window.display();

                if(frameClock.getElapsedTime() < minFrameTime) {
                        sf::sleep(minFrameTime - frameClock.getElapsedTime());
                }

                frameClock.restart();
        }
}

int main() {
        SFMLWindowTest();
        return 0;
}
 

The run loop spits out "Running" exactly three times and then deadlocks. Here's the output from gdb (some newlines added for emphasis):

Code: [Select]

[chaosed0@ChaosArch whateven]$ gdb bin/test
GNU gdb (GDB) 7.7
Copyright (C) 2014 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-unknown-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from bin/test...done.

(gdb) r

Starting program: /home/chaosed0/Code/whateven/bin/test
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".

Running
Running
Running

<EXECUTION STOPS HERE, AFTER SEVERAL SECONDS I INTERRUPT IT>

^C
Program received signal SIGINT, Interrupt.
0x00007ffff6a21340 in __poll_nocancel () from /usr/lib/libc.so.6
(gdb) bt

#0  0x00007ffff6a21340 in __poll_nocancel () from /usr/lib/libc.so.6
#1  0x00007ffff2e68992 in poll (__timeout=-1, __nfds=1, __fds=0x7fffffffe0e0) at /usr/include/bits/poll2.h:46
#2  _xcb_conn_wait (c=c@entry=0x466790, cond=cond@entry=0x7fffffffe200, vector=vector@entry=0x0, count=count@entry=0x0) at xcb_conn.c:447
#3  0x00007ffff2e6a21f in wait_for_reply (c=c@entry=0x466790, request=91, e=e@entry=0x7fffffffe2c8) at xcb_in.c:490
#4  0x00007ffff2e6a332 in xcb_wait_for_reply (c=0x466790, request=91, e=0x7fffffffe2c8) at xcb_in.c:520
#5  0x00007ffff5837117 in _XReply () from /usr/lib/libX11.so.6
#6  0x00007ffff5f985d3 in ?? () from /usr/lib/libGL.so.1
#7  0x00007ffff5f95f6b in ?? () from /usr/lib/libGL.so.1
#8  0x00007ffff0fb76db in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#9  0x00007ffff0fb7a33 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#10 0x00007ffff0fac6e5 in ?? () from /usr/lib/xorg/modules/dri/i965_dri.so
#11 0x00007ffff7bb62ae in sf::RenderTarget::clear (this=0x7fffffffe670, color=...) at /home/chaosed0/Code/SFML/src/SFML/Graphics/RenderTarget.cpp:62
#12 0x00000000004044cc in SFMLWindowTest () at test.cpp:28
#13 0x0000000000404aa4 in main () at test.cpp:67


The same behavior does not occur right away if I try to use sf::VideoMode::getDesktopMode() in place of my custom video mode. However, if I resize the window in certain ways, it will lock up in the exact same place. I say "in certain ways" because I haven't figured out exactly when it happens; all I know is that if I resize it from the top-left, it's fine, but if I resize it from the bottom-right, it locks up.

Here's some information about my system:

• OS: Archlinux, kernel 3.13.6-1
• X Version: 1.15.0, built from source on this machine
• XCB Version: 1.10-1, built from source, debug version
• SFML Version: 2.1, built from source from the repo, debug version (also tried SFML 2.1 from the arch repo)
• Desktop environment/WM: XMonad, also tried under LXDE/OpenBox
• Compiler: Tried both Clang++ 3.4 final and g++ 4.8.2 20140206 (prerelease)
  

No idea how I can fix this; not even really sure what's causing it. Might be an issue to take to the Arch forums, but hopefully someone here can help out. Let me know if you need any more information.

EDIT: Added compiler versions.

4

Graphics / Re: Setting origin of View

« on: June 21, 2013, 01:37:15 am »

Fair enough. I think I'm just too used to always having the View as my camera class; I didn't even know that you could pass a Transform in a RenderStates. Thanks for the input.

Edit: To make the camera follow the player, I had to pass the inverse of the player's transform. It makes some intuitive sense after making a custom camera in SDL (you have to move the scene in the opposite direction that the player's moving, etc), and it works, but is this the best way to do it? Additionally, is taking the inverse computationally expensive?

5

Graphics / Setting origin of View

« on: June 20, 2013, 03:19:13 am »

I'd like to have a view follow the player, but the player should be at the bottom of the screen. This works ok when I only set the position of the view - I just need to translate the center of the camera up a bit. However,  when I attempt to set the rotation of the camera, the camera rotates around its center, as one would expect, resulting in the player rotating around the center of the view.

Is there a way to set the origin of the camera to the player's location, instead? Ideally, I'd like to set up a scene graph where the view is just another node, with the player as the parent. However, it's not really possible since the view's transform is not available through its interface. EDIT: I guess you can actually get the view's transform, but (1) you can't set it and (2) it says it's for internal use only.

I suppose I could modify the source to expose the view's transform and just use that, but that's not really an ideal thing to do. Is there something I'm missing, or is this functionality not there?