Jump to content

  • Log In with Google      Sign In   
  • Create Account


Chaosenemy

Member Since 18 Feb 2008
Offline Last Active Jul 12 2014 04:42 PM

Posts I've Made

In Topic: How to capture raw mouse input in X11?

19 January 2011 - 09:42 AM


For the Windows version of my game engine, I'm using WM_INPUT and registering the mouse device directly to get the most precise movements. Anyone know how I would go about doing this in X11 (for Linux)? I've searched Google about as thoroughly as I can, but finding good documentation for X11 is next to impossible.


Well in general, no one ever accesses pure X11 for handling this stuff as there are gui libraries out there for this. Have you thought about using a cross OS gui library rather than rolling your own and just wasting time doing that?

I've always wanted to make a game engine from scratch (well as close to scratch as possible), so I'd rather not mess with anything but the required APIs/libraries. And anyways, I'm getting very close to being done with the X11 stuff, so I've already come too far at this point to switch to something else.


Thanks, that pointed me in the right direction I think, and I've found a few samples. There is one issue though: Link. That guy's post is the only thing I can find on the internet about this issue, and it hasn't been resolved =\ Can you think of any way to get around that? I was thinking something like sending a certain X event before calling XWarpPointer() and then in my event handler, when I get to the event I sent, ignore the next event, which would be the one sent by XWarpPointer(). Not sure if I'm explaining that right, but does it sound plausible?

It sounds like you're jumping through hoops to reinvent pointer grabbing. You may dislike SDL, but if you're keen on reinventing what it does you might want to look at how it does it.

I think what you really want to do is read up on XGrabPointer() and it's wife/sister XUngrabPointer(). They're the preferred way to do X11 active pointer grabbing.

My big issue with grabbing the pointer is that it breaks external keyboard shortcuts like Alt+Tab. Also if I'm not careful enough about error checking and a fatal bug occurs, the user could end up trapped and have to restart their machine. I dunno, XGrabPointer just bothers me.

Anyways though, the solution I proposed in my last post seems to have worked, so I think I've got it all figured out. Thanks again for pointing me to the XInput extension.

In Topic: How to capture raw mouse input in X11?

17 January 2011 - 11:56 PM

Input under x.org (the most common X11 implementation on Linux) is performed through the XInput module, or preferably the XInput2 module. You can google for that: it's documented on freedesktop.org and in the header files. If you want the "raw" input, you need to bypass the X11 stack and connect to the appropriate /dev/input/event pseudofile directly. That's certainly not recommended.

Thanks, that pointed me in the right direction I think, and I've found a few samples. There is one issue though: Link. That guy's post is the only thing I can find on the internet about this issue, and it hasn't been resolved =\ Can you think of any way to get around that? I was thinking something like sending a certain X event before calling XWarpPointer() and then in my event handler, when I get to the event I sent, ignore the next event, which would be the one sent by XWarpPointer(). Not sure if I'm explaining that right, but does it sound plausible?


Any reason why you want to talk X11 directly instead of using a portable wrapper like SDL (or equivalent)?

SDL murdered my parents.

In Topic: [C++] Weird segmentation fault

10 January 2011 - 07:48 PM

Hey guys, sorry it has been a few days. Been a little busy and I've been rewriting some of my code. I think I've got it all sorted out now. The Texture constructor and destructor no longer depend on the existence of the Texture* vector in the Graphics class, so the problem shouldn't happen anymore. I also modified my audio component to follow this specification, to avoid any future problems with this design. Thanks for all the help everyone.

In Topic: [C++] Weird segmentation fault

06 January 2011 - 12:59 PM

Quote:
There are two usual causes -- one is double-freeing. The other is writing to a pointer after freeing. You are almost certainly doing one or the other; 99 times out of 100 that's what's doing this.

I can 100% assure you it's not being double-free'd. As for writing to a pointer after freeing... read below.

Quote:
Install valgrind, run your program through valgrind. (You just go "valgrind ./myprogram.exe"). Valgrind will hook into your program and generate better debugging info. CAUTION: Valgrind will reduce performance, so if you can shrink this to a small test case that's better.

Valgrind will (for example) find you not only the duplicated free operation but also the one it's duplicated, or both parts of the free/write pair and then tell you about them.

Valgrind seemed to point to the issue being in the destruction of a certain vector. This vector held a list of IDs for textures that should be (possibly) deleted in the next Update(). During Texture's destructor, a function is called to queue the Texture's OpenGL textureId for deletion (in the event that textureId is not being used in another Texture object). Valgrind tells me that the problem lies in where I assign the textureId to the "deletion" vector. Apparently the vector has been destroyed already at that point?

I've "fixed" the problem by making sure no Textures can be constructed or destructed before Graphics::Initialize() or after Graphics::CleanUp(). Yeah, this fixed it, but I still don't really understand why it didn't work in the first place. AFAIK, objects in C++ are destroyed in the opposite order that they are created, so if I am able to call on a function/variable during Texture construction, shouldn't I be able to call on it during destruction as well?

:confused:

In Topic: [C++] Weird segmentation fault

06 January 2011 - 03:56 AM

Okay, I downloaded the Eclipse IDE for debugging purposes. I've got some new info. First of all, stepping through my last Texture object's destructor, I see that the original line of code causing the problem actually executes just fine, as well as the rest of the code in my destructor. Once I get to the end of the destructor, the debugger goes into "exit.c" which it can't find the source code for apparently. I have no choice here but to resume execution. Once I do, the debugger haults at "__kernel_vsyscall()" which it also has no source for.

So what exactly do I need to do here?... I'm guessing I need to get the source code for these files/functions that get called at the exit so I can step through them, but how/where do I get them?

Also I enabled the Glibc debugs you mentioned above but I'm not sure it made a difference. I'm assuming the source code I'm missing is the reason why?

PARTNERS