That's the point.

In theory, if you open text files in text mode it shouldn't ever matter. >.>

Weird, I tried changing "penis" to "p3n1s" but still won't post. Just get a completely blank page... I think the speedhack website has turned into an evil dictator that refuses to let me criticize it... Oh well.

{"name":"604502","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/9\/19bcff1a59dd9c471d3af2e4f98a2a92.png","w":269,"h":445,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/1\/9\/19bcff1a59dd9c471d3af2e4f98a2a92"}

Weird. I thought sometime before 2004 (my first speedhack) you had done something. There was a speedhack where all the resource files were provided and everyone had to make do... Weird, I can't find that speedhack. Maybe it was something else. xD

Not if the file was created on a different platform. I think that if you open a Windows-style text file in Linux you will have trailing "\r" characters in your lines, which might be a problem if you don't account for it.

In a matter of speaking, yes. The only difference between text mode and binary mode (AFAIK) is that EOLs are converted to and from the native EOL sequence automagically. In Windows, this means converting 0A to 0D0A and back again. In Linux, it's effectively the same as binary mode, AFAIK, because the native newline is the same as the C newline (0A). Expecting anything more is ridiculous; in fact, even that much is ridiculous. If a Linux system encounters 0D0A in a text file there's no real way to know that it isn't supposed to literally be 0D0A. Converting it to just 0A might be wrong. Those aren't the only two EOL "sequences" either. Older Macs used 0D, and I think there might even be a few lesser known systems that use completely different bytes or sequences. You can't possibly expect for every operating system to know about every other operating system's conventions. The only solution is for the application to account for the difference in a special way or to standardize the format so that only one is ever encountered.

52 hours is still a lot of time, and it's not like you were awake the entire 20 hours

Meanwhile, my code looks like a steaming pile of shit with little C and C++ shaped corn, but so far it is working and looking fine

CROSS-PLATFORM TIP:
I've been out of the C++ scene for awhile now, but it appears that MSVC doesn't have snprintf, instead it has sprintf_s (with about the same signature.) I'm guessing *nix doesn't have sprintf_s though, so try this:

#if _WIN32
  #define snprintf sprintf_s
#endif

Actually more like 28 hours with other weekend plans, but still, this is sweet, I'm glad I'm doing Speedhack again.

Stupid question here. Do you use fonts? With a small file-size...? Or is there a sane way to obtain the fonts installed on somebody's system?

For SpeedHack, you need to use bitmap fonts.

As the readme says:

There are a few lines in the Makefile that you could copy and paste for each sub folder to add support.

Or you could dump all your source files into the same main folder.

I'm assuming that's a joke (but I would like to confirm.)

I wish there were, the MAllegro wrapper for .NET that I started writing could export them, but that source is long gone, and it was in VB.NET 2005.

Anyway, most of the .ttf files I've found are ridiculously tiny... The font I'm using is 21K unzipped -- It's from some free-fonts archive (the same site that the allegro 5 tutorial that uses "pirulen.ttf" links to.)

Are we allowed to submit as a 7-Zip archive?

The rules state that all entries must be supplied in a ZIP file. 7z might be problematic, particularly for some Linux users, I guess.

It shouldn't be, since there's a linux version.