Anyway, I find Tomek\’s comment about his test program for SDL audio interesting. If that isn\’t sufficiently low-latency, then JACK probably is the way to go.

If I were you, I would ship JACK along with Braid, attempt to connect to a running server and start your own copy if there isn\’t one. JACK takes a bit of setup to determine the best latency offered by the hardware available, but once you\’ve determined what latency is available, JACK will guarantee the latency settings you give it. Just spend some time playing with JACK settings in QJackCtl on your own machine to see how buffer sizes can effect latency.

http://bugzilla.libsdl.org/show_bug.cgi?id=1052

It outlines the problems and suggests use of XInput2 as a solution.

As for the mouse what you might need are not events from mouse *cursor* but from *mouse* itself.

I’m not sure how is it implemented in SDL but a quick test I made suggest SDL does not report actual mouse movements. SDL seems to recreate them from mouse cursor movements, which has issues with focus and edges you were experiencing.

I suggest to try this command:

$ xinput test-xi2 “Virtual core pointer”

It should report relative *mouse* movements (event type 17), regardless of mouse cursor position, edges, focus and so on. This is what you’re after if I understood correctly. This also what SDL should report, if you ask me.

Whan the mouse cursor happens to be over the xinput window, you’ll also get mouse *cursor* events reported (event type 6), which contain cursor position, both, absolute and relative to the window.

Cheers,
Tomek

I wrote a small SDL program to test audio latency on Ubuntu Lucid. I can not notice it.

The program is crude but does roughly what you want to achieve. It plays back an audio from a buffer using SDLs callback. On key press it resets the read pointer and additionally toggles background colour. There’s no noticeable delay.

The SDL by default chooses playback through Pulse. I haven’t modified any audio preferences on my box and I was using libSDL from Ubuntu repository.

I can send you the source, if you’re interested.

I remember using the DDD graphical interactive UI for GDB like a decade ago. DDD features debugging data display capabilities that I have never seen in any of these supposedly superior IDEs you mentioned. Oh and I do use Visual Studio 10 on Windows on occasion. The fact is VS isn’t that great a tool for developing C/C++ code. Try merely visualizing a linked list data structure in one of those IDE debuggers and you will see what I mean.

Emacs and Vim with their zillion extensions can do anything an high end C/C++ IDE can do and more. If you have some kind of phobia of multiple CTRL key combos or have a defective Escape key, you can always use Eclipse CDT for C/C++.

As for the solutions to the sound and mouse problems, Ryan C. Gordon said it all here in the start of the thread. Use SDL for everything you can in your game. If you need sophisticated audio use OpenAL. If you need 3D graphics use OpenGL.

Hitting the lower level multimedia API layers in Linux sucks. It also sucks on Windows. Just do not use them unless you are a middleware person, like an SDL or OpenAL developer. Last time I tried that battle (on Windows and Linux) I spent so much time chasing platform dependent bugs and writing backends for zillions of mostly deprecated low level APIs someone, somewhere, still used, that I went back to middleware sound APIs.

I don’t mean to be disrespectful, but that’s extremely easy to do. just keep the old mouse position and subtract it from the new one, each update…

If your patience with Linux isn’t still completely exhausted, you could try to write up the problems you ran into – the most purely technical, non-tool (IDE, debugger) ones at least – with X input and OpenAL as bugs or requests to those respective projects. If the answer you get is the dreaded You Don’t Need That, well, screw them. If not, then maybe someone in the future will find the platform less lacking.

If you’re paying someone else to do a port, definitely get them to write a postmortem or wishlist of “things that would have made this much easier”.

Barely anyone is really thinking strategically about games on Linux right now, whereas there are thousands of people at MSFT whose full-time job is to improve their platforms. So it’s a question of first steps.

My hope is that if a few developers started speaking up with experiences like yours, at least some of the drivers of the big component projects might take notice. Like you said earlier though, it requires some participation on the part of the game devs, and encountering even a bit of regressive resistance is enough to make anyone feel like they’re wasting their precious time.

Linux has grown to where it is now by people scratching itches, though, and if the drivers of this hypercomplex messy amalgam of an OS at least know the itch exists, maybe someday the benefits would start to exceed the costs of said participation.

Until then, though, it’s kind of like volunteering at a homeless shelter, but with more irascible nerds.