About the integer scaling thing, I just do (x is an uint32_t between 0 and 0xffffffff inclusive):

Code:

(uint32_t)(((uint64_t)x * n) >> 32)

It's as accurate as you can get with just integers, and at least on x86 it can be optimized to a single multiply instruction.

Does c++ have something similar? i'd like to be able to distribute my game as a single exe file, rather than an exe and a bunch of asset folders.

You can use something like PhysicsFS or zziplib. Zip up all your resources and concatenate the zip onto your exe. In your code, open the exe itself as an archive and load your resources through that.

Wouldn't decent compilers automatically optimize such things anyway?

I was going to say the same thing, but then I tested it:

Code:

float div2 (float x)
{
return x / 2;
}

gcc 4.6.1 with -O2 does compile that to a mulss instruction (on x86-64), but clang 2.9 with -O2 uses a divss instruction. clang's a younger compiler though, it'll probably come around in time

Do you unset the FBO (or set it to something else) before using the texture? A shader can't have the same texture as both input and output. Also check if glError has something to say, or try apitrace

What should I do here? Is there something I can do to my Universe executable to make it run libopenal.so.1 out of the current directory (or even better, the Internal/ directory where all my data files are stored?)

Yes, there's two ways. First, you can set an RPATH on your executable when linking it:

Code:

gcc '-Wl,-rpath,$ORIGIN/Internal' ...

$ORIGIN is a linker variable, not a shell variable, so you have to protect it from the shell when setting it (and possibly also from make, etc). Anyway, the runtime linker will expand $ORIGIN to the directory where the executable is located. You can add subdirectories to it, and it'll do the expected thing. (You can check that you set the RPATH correctly by doing 'objdump -x my-executable | grep RPATH', or just doing an ldd and check that it points to your libs)

The other way is to use a wrapper for your main executable that sets the LD_LIBRARY_PATH environment variable. For example:

Code:

#!/bin/sh
cd "$(dirname $0)"
libpath=./Internal
if test '!' -z "$LD_LIBRARY_PATH"; then
    libpath="$libpath:$LD_LIBRARY_PATH"
fi
env "LD_LIBRARY_PATH=$libpath" ./my-executable "$@"

Which method is best depends. RPATH doesn't require a wrapper, but there's a long-standing bug that makes it not work right if the path of the executable contains a colon. On the other hand that should be very rare, since colons are used to break up paths in all kinds of variables it's not really used much in practice. Also, RPATH doesn't apply for libraries opened dynamically at runtime with dlopen.

LD_LIBRARY_PATH is also separated with colons, but you can get around that by changing the current directory to the executable's first (like above). LD_LIBRARY_PATH does affect dlopen, if that matters, but a relative LD_LIBRARY_PATH will always be relative to the current directory, so you'll have to keep that in mind if you use chdir somehow.

I prefer RPATH since there's no wrapper requirement and the colons issue is rare (wrappers can have other issues, like people bypassing them and then sending bug reports when it doesn't work), but if I have to use a wrapper for other reasons, like selecting between 32-bit and 64-bit executables, there's not really any reason not to use LD_LIBRARY_PATH in stead.

Can / should I link against system openal instead of trying to build my own?

Some people will say so, to reuse system resources and all that. I say we live in 2012, and saving those few kilobytes is a lot less important than having your thing work right without people having to mess with installing dependencies manually. I include almost every .so, except for glibc and system specific stuff like OpenGL. This also has the advantage that you know exactly what versions of the various libraries are used by your game, so debugging is easier. You may have to update the libraries from time to time when e.g. stuff like SDL gets a new video driver (Wayland's coming up), but that's a small price to pay, in my opinion. Up to you though!

That doesn't contradict what he said. At all.

Well, I guess that depends on your interpretation, but even at best it's an unsubstantiated claim. I'm not interested in having a long discussion about this though, I don't even like the "indie" label much.

So is the future of indie gaming hanging in the balance now or something?

Yes, it's super important that we all waste our time arguing about this.

the word "indie" as in "indie games" as a buzzword was launched around 2004 by the UBM Techweb group (indiegames.com, gamasutra, gamesetwatch, gdc, IGf, etc, etc...)
it's all a matter of creating a new product and an audience to sell news and stuff to that audience.
Actually noone really talks that much about "indie games" and "indie authors" outside of this news conglomerate properties.

Not sure if you're trolling here or what, but you're wrong on the internets! The Dexterity Software forums (nothing to do with UBM, and predecessor of the indiegamer forums, created in 2004) used the term as early as 2002, and I doubt they were the first either. It's just short for independent, so it's natural to extend that to cover games as well as other things.

MinGW is a truly awful substitute. It's a hack at best to get gcc running on Windows. It has its place, like if large chunks of your code are built on POSIX stuff, but otherwise I don't see why anyone would choose it over vc/vc++ (not the IDE btw, just the compiler).

Are you sure you're not thinking of Cygwin? That's the one with the POSIX support layer (MinGW uses the normal Windows API). Cygwin is a mess, but I've never had any problems with MinGW.

Yeah, just, I'm lazy, and I want to know the framerate I'm using ahead of time, so that I can calculate the dynamics of things on a per frame basis and assume a constant timestep per frame. Also when you force sync in software like that it just blocks until the monitor is ready to update right? So over time you will likely spend a significant of time just hanging, waiting for vsync to unblock you? I could be spending that time doing physics calculations or something.

Yeah, that's right (although i think the driver is allowed to do triple buffering in stead of double buffering behind the scenes, in which case the swap won't block -- i haven't encountered any linux drivers that do this though (though i haven't really looked very hard either, so i guess it's possible))

Aanyway.. [..snip tangent..].. i just use the timing of the swap trick.  It's not too accurate, but it doesn't have to be perfect for this purpose.

OK, I'm pretty sure that this is the goods:

Code:

void get_current_mode(unsigned *width, unsigned *height, short *hz)
{
    // Get the current configuration.
    XRRScreenConfiguration *config = XRRGetScreenInfo(gdk_x11_get_default_xdisplay(),
                                                      gdk_x11_get_default_root_xwindow());
    int size_count;
    // Obtain the dimensions.
    XRRScreenSize *sizes = XRRConfigSizes(config, &size_count);
    Rotation current_rotation;
    SizeID current_mode = XRRConfigCurrentConfiguration(config, &current_rotation);

    // Store the results.
    *width = sizes[current_mode].width;
    *height = sizes[current_mode].height;
    *hz = XRRConfigCurrentRate(config);

    XRRFreeScreenConfigInfo(config);
}

Did a quick test of that here and it seems to work fine here too (except for the wrong hz issue).  

Also! I got inspired to write this little horror to get the current refresh rate with nvidia (there's got to be a better way to do this ..):

Code:

float getCurrentHzNvidia (void)
{
    FILE* fp = popen("nvidia-settings -tq RefreshRate 2>&1", "r");
    float hz = 0;
    if (fp)
    {
        if (fscanf(fp, "%f Hz", &hz) != 1 || hz < 0)
            hz = 0;
        pclose(fp);
    }
    return hz;
}

(it's float because that's what the nvidia-settings util returns.. fractional rates are possible i think, but you can probably just cast that to int or something in practice.  it'll return 0 if an error occurs (like if nvidia-settings doesn't exist and probably if the nvidia driver isn't active))

- Is there a way to identify you're using the Linux driver, or the "bad" Linux driver, so that when the problem mjau hits flares up you know you can mark the refresh rate as untrustworthy?

AFAIK the official (binary) nvidia driver is the only one that has this problem, so you could detect if that's used and treat anything else as trustworthy*. Also, the invalid refresh rates always start at 50.0 and increase by 1.0 for every new mode**, so you could look for that as well. As a last resort you could also just time how long a frame swap takes and see if that agrees (roughly) with what xrandr reports (though timing it like that isn't the most accurate ..)

* Nvidia's vendor string is (currently) "NVIDIA Corporation", and they also put "NVIDIA" plus their internal version number in the opengl version string (eg mine's currently "4.1.0 NVIDIA 270.41.06").  'course, always treating nvidia as bad means your game will still treat it as broken even if they should fix the problem sometime in the future ..

** I think the first mode is always the largest supported resolution and decreasing from there, even if the default mode isn't the largest one, but I'm not completely sure about this. My output above is from a completely autodetected setup (ie there's no xorg.conf at all), so that's how it works by default at least.

Oh also, you can get the actual rate of the current mode with the nvidia-settings utility (part of the drivers, so should be present usually):

Code:

$ nvidia-settings -tq RefreshRate
60,00 Hz

What I think I'm planning to do is set my framerate to the refresh rate or a divisor thereof.

If you just want to vsync your swaps, you can use glXSwapInterval* to set a swap rate, and then just call glXSwapBuffers as normal, and it'll do the syncing for you. No need to worry about the refresh rate, the driver knows the real one. (Also it does the right thing if vsync is forced on by the driver or compositor)

glXSwapInterval is one of these:
GLX_EXT_swap_control extension: void glXSwapIntervalEXT (Display* disp, GLXDrawable drawable, int interval)
GLX_MESA_swap_control extension: int glxSwapIntervalMESA (unsigned int interval)
GLX_SGI_swap_control extension: int glxSwapIntervalSGI (unsigned int interval)

(set interval to 1 to swap every refresh, 2 to swap every other refresh, etc, or 0 to disable sync. also afaik the MESA and SGI versions are the same, except the MESA driver named it MESA in stead for some reason)

clang is awesome, but gcc does a better job at optimizing at the moment (mostly)

If you're only going to do it once, why not just do it in software, on the cpu? No need to require a gpu with shader support then.

Here are the functions I use, which get the current display mode, which includes the refresh rate:
[..]
Linux:

Code:

#include <X11/extensions/Xrandr.h>
#include <gdk/gdkx.h>

void get_current_mode(unsigned *width, unsigned *height, short *hz)
{
    // Get the current configuration.
    XRRScreenConfiguration *config = XRRGetScreenInfo(gdk_x11_get_default_xdisplay(),
                                                      gdk_x11_get_default_root_xwindow());
    int size_count;
    // Obtain the dimesions.
    XRRScreenSize *sizes = XRRConfigSizes(config, &size_count);

    // Store the results.
    *width = sizes->width;
    *height = sizes->height;
    *hz = XRRConfigCurrentRate(config);

    XRRFreeScreenConfigInfo(config);
}

Unfortunately this won't work with the official nvidia drivers, because nvidia decided to abuse the refresh rate field to distinguish twinview modes in stead (even if twinview is not used). All modes have a different "refresh rate", starting at 50 and incrementing for each new mode, regardless of what the actual refresh rate is. (They claim this is a feature, not a bug. <insert rant about this here>)

Here's some output from my system, running at 1920x1080 at 60 hz:

Code:

$ xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 320 x 175, current 1920 x 1080, maximum 1920 x 1080
default connected 1920x1080+0+0 0mm x 0mm
   1920x1080      50.0*    51.0  
   1680x1050      52.0     53.0  
   1600x1024      54.0  
   1440x900       55.0  
   1400x1050      56.0     57.0     58.0  
   1360x768       59.0     60.0  
   1280x1024      61.0     62.0     63.0  
   1280x960       64.0     65.0  
   1152x864       66.0     67.0     68.0     69.0     70.0     71.0     72.0  
   1024x768       73.0     74.0     75.0     76.0     77.0     78.0  
   960x720        79.0     80.0  
   960x600        81.0  
   960x540        82.0  
   928x696        83.0     84.0  
   896x672        85.0     86.0  
   840x525        87.0     88.0     89.0     90.0     91.0  
   832x624        92.0  
   800x600        93.0     94.0     95.0     96.0     97.0     98.0     99.0    100.0    101.0    102.0  
   800x512       103.0  
   720x450       104.0  
   720x400       105.0  
   700x525       106.0    107.0    108.0    109.0  
   680x384       110.0    111.0  
   640x512       112.0    113.0    114.0  
   640x480       115.0    116.0    117.0    118.0    119.0    120.0    121.0  
   640x400       122.0  
   640x350       123.0  
   576x432       124.0    125.0    126.0    127.0    128.0    129.0    130.0  
   512x384       131.0    132.0    133.0    134.0    135.0  
   416x312       136.0  
   400x300       137.0    138.0    139.0    140.0    141.0  
   360x200       142.0  
   320x240       143.0    144.0    145.0    146.0  
   320x200       147.0  
   320x175       148.0

Incidentally, this is also the reason why vsync with nvidia is so hard to get working with compositing desktops

If you use a dedicated desktop (workspace) for GIMP, you should be able to get something like this:
[snip]

You can do that layout with only two tool windows. You can drag tools around between docks to rearrange them as you wish. Drag the tab (or the title bar of the tool, with the [<] menu), and either drop them into existing tab bars, over tool titlebars to create a new tab bar, or over the thick line at the bottom of the tool windows to create a new dock there.

Such a large screen.. My resolution is only 800x600, but I'm using a 1440x900 monitor. It's very fuzzy. I think that's my problem, as GIMP is usually the only thing open on the workspace.

800x600 is pretty small, but you can make things take less space.

* Go into the settings and select the "Small" theme. The tool windows take less space then.
* You can also disable showing rulers and such by default in the settings, if you don't need them (can also do this on a per-window basis in the view menu), to make the image windows take less space. You also don't need the menu bar, it's all available via the right-click pop-up menu.
* Also, learn the keyboard shortcuts, so you don't need the toolbox (watch tooltips to learn them). Once you no longer need the toolbox, you can make it as small as possible and hide it behind another tool window (you can't just make it disappear unfortunately).
* Also, you can toggle the display of all tool windows by pressing the TAB key in any image window.

You're better off using the glXSwapInterval(SGI|MESA|EXT) extension function than doing it manually like that (this is what SDL does when you use SDL_GL_SWAP_CONTROL btw). Then glXSwapBuffers will do the sync for you. Also, you can kinda detect if vsync is in effect by flushing and then timing a few glXSwapBuffers calls (but iirc, drivers are allowed to do triple-buffering in stead of double-buffering, and swap won't block if that's the case)

Anyway, with modern composited desktops, the compositor is in full control of vsync (since everything's drawn using opengl), and individual programs can't override this. You'll have to use the compositor's config to enable/disable vsync, or configure it to automatically disable compositing when something's running in fullscreen mode. (or override at the driver level, like i think RobJinman did)

For the compiz compositor (gnome2/unity), you have to install the advanced compizconfig (ccsm) to configure it; it's not installed by default. (also, with nvidia, you have to disable automatic refresh rate detection and set it manually (probably to 60) for vsync to work properly. compiz is also the only compositor i've tried where vsync with nvidia is actually possible to get working properly at all btw. KDE and xfce's compositors do sync, but at the wrong place, so you get tearing.)