I wasn't quite happy with any of the current C++ signal/slot systems, so I wrote my own. It's gone well:

Code:

struct Tester : public arch::IHasTrackedConns
{
void doTesting(float wat)
{
cout << "Testing: " << wat << "\n";
}
};

int main (int argc, char** argv)
{
arch::Signal<void(float)> sig;
Tester t;
sig.connectTracked(&Tester::doTesting, &t);
auto myScopedLambdaConn = sig.connectScoped([](float wat){cout << "lambdas work too, wat = " << wat << "\n";});

sig.call(4.2);
}

Now I have to decide if I want to allow return values, because if I do then I have to make a combiner system and it would start to lose the simplicity I wrote it for.

Beware if you compile with MSVC, the granularity of std::chrono is very bad and will be in the next version too. Source: https://connect.microsoft.com/VisualStudio/feedback/details/719443/

I've hit some time precision problems because of this recently. The simplest solution is to use boost::chrono instead as it is very precise, but it forces you to use boost::thread instead of std::thread if you are using timing facilities like std::condition_variable or std::this_thread::sleep_for/until().

Just know that current std::chrono implementaitons are not yet all equivalent. Unfortunately I think it will be true until next year  

Nope, I'm using GCC on all platforms and it's plenty accurate. But that might be a problem, because I was wanting to package up my various helper classes and release them as "handylib". I don't want to use boost so that leaves me rolling my own cross-platform timing system if I want it to be MSVC-compatible. I'll see.

My current version of GCC for windows doesn't support std::thread, so I've rolled my own crude threading wrapper for Windows and eventually POSIX. It leaves much to be desired- in particular, you can't yet pass an arbitrary thread function (must be void(void)). I don't intend to use it for much except animated loading screens, though.

Encapsulated my framerate-limiting code into a Throttle class.

Code:

Throttle throt(33);
while(myGame.isRunning())
{
    auto deltaMs = throt.wait();
    myGame.doSomething(deltaMs); // will run no more often than every 33ms
}

Makes use of my Stopwatch class which makes use of C++11's std::chrono.

Don't pass header files to gcc/g++. Pass it the cpp files, which should #include the headers.
So

Code:

g++ main.cpp -lSDL -o piman

, and in main.cpp:

Code:

#include "objects.h"
#include "player.h"

#include'ing a file using quote marks looks relative to the .cpp file.
You can also use angle brackets:

Code:

#include <objects.h>
#include <player.h>

But if you do that, gcc won't look in the current directory (".") by default; you'll need to tell it by adding

Code:

-I.

I wrote one. Feel free to use it as-is or as an example: http://sacredsoftware.net/svn/misc/StemLibProjects/gamepad/trunk/source/gamepad/

Getting raw input from a gamepad isn't too hard, though you'll have to use a different API on each platform you support. My library provides a thin abstraction layer, which allows you to use the same API on the 3 big desktop platforms, but doesn't do any additional translation or mapping or anything. The tricky thing about gamepads is that they're wildly inconsistent. A typical gamepad will most likely have different button mappings across platforms, report phantom buttons that don't actually exist, map its axes in unintuitive/backward ways, and give you no hint whatsoever about its physical layout. Dealing with these things is tricky, but not impossible. If you have the player set up their gamepad by pressing each button you want to map to an action rather than trying to autoconfigure it, it can work. If you want to provide sensible defaults, you'll need either an enormous database of controller layouts, or to restrict your support to only a few devices.

Totally worth it to be able to play your games with a gamepad, though!

Doesn't look like yours fully supports the very popular 360 controller, unfortunately. I was making a 360-only library (with guide button detection, even!) which I can finish and release if there's interest, but XInput is quite easy to use anyway.

edit on preview: But you don't need XInput if you don't need to support the triggers or vibration.

As well as reinventing the "vector/matrix class" wheel yet again, I'm also making a header-only class to simplify binary file I/O.

Code:

BinaryFile test("test.dat");
int32_t val1 = test.read<int32_t>();
uint16_t val2 = test.read<uint16_t>();
test.skipBytes(3);
uint64_t var3 = test.read<uint64_t>();

The idea is to avoid having to worry about file modes, endianness, etc.

Here's some complete C example code. You don't need to link with XInput or anything, it just uses the WinAPI to load the function at runtime.

Code:

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <stdio.h>

static const int guide_button_value = 0x0400;

/* the secret function outputs a different struct than the official GetState. */
typedef struct
{
    unsigned long eventCount;
    WORD                                wButtons;
    BYTE                                bLeftTrigger;
    BYTE                                bRightTrigger;
    SHORT                               sThumbLX;
    SHORT                               sThumbLY;
    SHORT                               sThumbRX;
    SHORT                               sThumbRY;
} XINPUT_GAMEPAD_SECRET;

// returns 0 on success, 1167 on not connected. Might be others.
int(__stdcall *secret_get_gamepad) (int, XINPUT_GAMEPAD_SECRET*); // function pointer to secret (guide compatible) getstate */

int main(int argc, char** argv)
{
TCHAR xinput_dll_path[MAX_PATH];
GetSystemDirectory(xinput_dll_path, sizeof(xinput_dll_path));
strcat(xinput_dll_path, "\\xinput1_3.dll");
HINSTANCE xinput_dll = LoadLibrary(xinput_dll_path);
secret_get_gamepad = GetProcAddress(xinput_dll, (LPCSTR)100); // load ordinal 100

XINPUT_GAMEPAD_SECRET pad1;

if (secret_get_gamepad(0, &pad1) != 0)
{
printf("Error, make sure your player 1 pad is connected.\n");
return -1;
}

for(;;) // forever
{
secret_get_gamepad(0, &pad1);
if (pad1.wButtons & guide_button_value)
{
printf("Guide button is down.\n");
}
Sleep(33);
}

// you should probably clean up by unloading the DLL.
return 0;
}

// Due to the nature of the types in Game Maker, the zero-th element of an array is
// accessed when you don't use brackets, so I'm leaving them out for readability.

[offtopic]
In this particular case it's clear, but generally I wouldn't make use of such a "feature" because it would be quite confusing coming back to such code after forgetting that foo is an array and not a scalar. Fewer characters doesn't necessarily mean more readable.
[/offtopic]

Just gonna bump this 'cos I found out and people might be interested.

Use LoadLibrary to load xinput1_3.dll from the system directory and use GetProcAddress on the resultant handle to load a function from ordinal 100 matching this signature:

Code:

__stdcall int secret_get_gamepad (int, XINPUT_GAMEPAD_SECRET*);

function pointer syntax:

Code:

int(__stdcall *secret_get_gamepad) (int, XINPUT_GAMEPAD_SECRET*);

The int is the controller index.
The struct it outputs to (I called it XINPUT_GAMEPAD_SECRET) is very similar to but different from XINPUT_GAMEPAD and looks like this:

Code:

typedef struct
{
    unsigned long eventCount;
    WORD                                wButtons;
    BYTE                                bLeftTrigger;
    BYTE                                bRightTrigger;
    SHORT                               sThumbLX;
    SHORT                               sThumbLY;
    SHORT                               sThumbRX;
    SHORT                               sThumbRY;
} XINPUT_GAMEPAD_SECRET;

Create such a struct and pass its address to secret_get_gamepad. It returns 0 on success or 1167 on failure.

Then bitiwse AND wButtons against 0x00400 to see if the guide button is down.

With thanks to this code on some guy's github: https://github.com/DieKatzchen/GuideButtonPoller/blob/master/GuideButtonPoller.cpp
No clue how he figured it out.

I made a Game Maker DLL to do this: http://gmc.yoyogames.com/index.php?showtopic=570472&st=0&p=4210058&#entry4210058 (source also available).

[To The Top]

To The Top
Stupidly hard vertically-scrolling platformer, both generally tricky platforming and some rare IWBTG-style fuck-you can't-possibly-see-it-coming tricks. No/very few checkpoints, one really really tall level, if you fall too far you fall all the way to the bottom/the last checkpoint.

Sorry man... I'm not usually a graphics snob, but this looks like a Windows3.1 game. I'm not going to download it because I know I won't be able to get immersed in it when it looks like this.

http://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.reference.xinput_gamepad%28v=vs.85%29.aspx doesn't list the xbox button as one of the standard 'buttons' or other pieces of data returned by the XINPUT state, but it's possible that it's encoded into the state as an undocumented enumeration value. Have you tried logging the state when the button is held?

If you're using XNA, the xinput state is in a hidden field of GamePadState.

It's also possible that presses on the xbox button are treated as keypresses (like a keyboard key); maybe you have to fetch them with http://msdn.microsoft.com/en-us/library/windows/desktop/microsoft.directx_sdk.reference.xinputgetkeystroke%28v=vs.85%29.aspx ?

Tried both already, sorry...

This is not officially supposed to be possible, and XInput certainly doesn't define any way to do it. But GFWL games (such as GTA IV) use it, so clearly it's possible somehow. I'm making a small library to simplify using the 360 controller, and I'd like it to be able to see the guide button; anyone here found any clever hack to use it?

How do you do the curved CRT effect? I assume you render to a texture and slap that texture on the surface of a curved plane?

This looks neat. I have a question, bearing in mind I haven't read the whole thread: Is it Splinter Cell style stealth or Hitman style stealth? There seems to be a focus on guns and other offensive weaponry; will it be possible to do stuff like disguise yourself and walk around "hidden in plain sight", or poison your target's drink instead of shooting him?

Dataflashsabot, you've got a lot of unnecessary verts going on there. You could probably halve the tri-count if you get ride of all those extra loops, and even have enough room to add some to the wheels to get them rounder.

I was trying to keep the topology clean, but I think I went overboard.
I did this:

100 triangles, but no wheels included.
Also, I am not good at designing tracks:

I made an extremely low-poly pickup truck.

196 quads. I had a vague idea of an Android racing game. There are no textures, it's all vertex colours. I might add a texture for dirt and windscreen reflection, and add something in the back (not that's it'd be smart to race with that extra weight, but it seems strange to have a pickup with nothing in it).

As far as I'm aware 16:10 (as in 1920x1200) is much more common as the native resolution for computer monitors, while 16:9 (1920x1080) is the standard for other displays like TVs and movie projectors. I don't expect those two fields to agree on the one true aspect ratio any time soon.

I've heard this multiple times, and would like to point you to the Steam hardware survey. Notice that 1920x1080 (16:9) is by far the most common resolution among Steam users. Whether that maps to being more popular among everyone is another matter, but 16:9 is undeniable everywhere and if you're providing a wallpaper, it'd be silly not to provide a 16:9 version.

(I am admittedly a tiny bit biased on the issue as I just got a new 16:9 monitor.)

Given lots of artist effort (two textures for everything)

I'm sure it would be easy to have a tool that creates and updates the smudged versions automatically.

Oh for fuck's sake.
[spoiler below; select the area to reveal the text]
I had a feeling it was just going to be another pointless meta-artgame, but in the desperate hope that it was in fact a fun escape-the-room adventure, I tried all sorts of possibilities (trying to climb a bundle of keys, throwing a key backwards while jumping to exploit momentum, you get the idea) before finally resorting to looking for some meta-solution, and lo and behold...