Latest articles

I'm not interested in your transitions and animations. In fact, nobody is.

Now, I get that your industry (Film and TV) is still relatively new to this whole "interactive" thing. So, speaking as someone who has spent their life working on mediums that have always been fundamentally interactive, let me give you a little tip:

200ms

That's a basic rule of thumb here in the interactive world. The longest amount of time a user-triggered animation or transition can take before it feels sluggish and unresponsive for the user is 200ms. That's one-fifth of a second. And that includes loading. And that's maximum. Even 200ms is often pushing it. Frequently, you want less.

Yes, I know, you're from a visual medium and you desperately want your "viewers" to see, erm, I mean "experience" every bit of your beautiful painstakingly-crafted animating artwork in all its full glory. And the "viewers" can't see it if you rush through in a split second...

Tough shit.

You're in the interactive wold now bitch, not visual arts. You don't have a viewer, no matter how much you crave one. You have a user. And your User is your God. User is the alpha and the omega: Everything revolves around User, because there is no other way.

When our User decrees an action, it is our place to comply and let them get back to being User. It is not our place to fuck Them around with "Look what I can do! Look what I can do!" when they've already told us what we can go do.

Welcome DVD/BluRay creators. We are the authors of the interactive: We are the User's bitch.

Always remember that.

Read more

Supper: It's like "dinner", except annoying.

Crazy: "Crazy" is not an adverb. When you use it as one (ex: "You language butchers are crazy stupid"), you sound like a moron. Which you clearly are if you use "crazy" as an adverb, but that doesn't mean I want to hear about it. I know it's just a fantasy, but sometimes I like to pretend I'm not surrounded by idiots. Hearing people advertise their stupidity via gross misuse of "crazy" makes it difficult to maintain that blissful delusion.

Sopping: As if just hearing the word wasn't grating enough, what does it even mean? It certainly can't mean "wet" because then "sopping wet" would be redundant. You wouldn't be saying something that pointlessly redundant, would you? Fortunately, nobody born after 1960 actually uses this word.

Cloud (except as water vaper): The word you're looking for, dumbfuck, is "Internet".

Tween: The word you're looking for is "preteen". "Tween" is an animation term. No, it can't mean both - because I said so. And I say so because you already have "preteen" - use it.

Ibibyte: If you kids these days really want your goofy SI-imitating "bytes", you can go call them "decimal bytes" (as in 5MB₁₀). And I'll call mine "binary bytes" (5MB₂). Hell, write them as 5MB10 and 5MB2 if you must. But ibibytes can fuck off.

PostgreSQL: How the hell am I supposed to pronounce this?!? (Yea, yea, I know, but still...)

SQL: "Sequel" (ironically) was its predecessor. Stop calling it "sequel".

Synergy: What is this, an MBA convention?

"Acrosst": "Across" has no "t". So why are you pronouncing one? My fourth grade teacher used to say this. All the damn time. Fuck, I hated her.

"Heighth": "Height" does not end in "th". Nobody around you pronounces it "th". So why are you pronouncing it "th"? Yes, I've actually heard people consistently pronounce it like this. (Is this possibly a Pittsburgh thing? Like "wush", "warsh" and "ruoin"?)

Anything ending in "-izzle": It began stillborn, and now...even as a joke it's painfully old. Can we please just let it finally die?

Pwned: Just...let...it...die.

Pr0n: Is it delightful porn or delicious seafood? Stop confusing me!

Read more

Did you know...?

10. The name "PHP" is an acronym that stands for "Perpetually Horrid Programming".

9. PHP is the world's only Esolang to be used in actual production software.

8. Every time you create a variable in PHP, three puppies are killed.

7. PHP is not FDA-approved to diagnose, treat or cure any disease.

6. PHP was originally created as a practical joke. It grew out of hand because the memo announcing "April Fools!" was accidentally sent through a PHP mailing script and was thus never actually received.

5. You loose five strands of hair for every minute you spend writing PHP code. You do the math.

4. PHP is not, strictly speaking, kosher for Passover.

3. Historians believe Joseph Stalin had been a major early supporter of PHP.

2. PHP is the world's leading cause of impotence.

1. Thirty Helens agree: "PHP is for the birds!"

Bonus: PHP is a fractal of bad design.

Read more

Quake 2 has been made to run in a browser using JavaScript. Old news, granted, but for reasons I cannot fathom, hordes of webdev kiddies have been holding it up ever since as evidence that JavaScript somehow isn't slow as shit.

Years later and that still chafes my ass.

Look, fifteen years ago, my 200MHz Pentium 1 (which was more than twice minimum spec) was running Quake 2 at fully playable speed, using purely software rendering. Not long after, I tossed in a 1998 Voodoo2 card, and had it running a full 60 frames per second at what today would be considered HD resolution. (Yea, I used to be a hardware whore, believe it or not.)

"Oh look how much processing Quake 2 shows JavaScript can do! JavaScript is therefore plenty fast!"

Are you shitting me?

You can squawk all you want about "good enough UI speed": But what Quake-2-in-a-browser demonstrates (aside from the browser window being a shitty way to play a game), is that JavaScript and the "web is for applications!" nutjobs pushing it have all taken your 64-bit multi-core gigs of RAM machine, skewered it by the balls, and turned it into a damn Pentium 1.

Oh, and what exactly do you think all that computational masturbation is doing to your battery life?

So...how much exactly did you pay for that shiny new 2012-model Pentium 1 of yours? Congratulations, you got yourself shafted. You must be proud.

Ok, but wait, there's also WebGL Quake 3. Hmm, yea, running the CPU-side of a GPU-bounded program in JS really proves your quad-core isn't getting castrated into a battery-guzzling Pentium 2.

So, web 2.0 clouds-for-brains, how about writing an HD video transcoder in JS that actually compares to real software? Or hell, a JS version of any native code that actually requires a CPU from this fucking decade. Basically what we're looking for is a "JS isn't slow" demonstration that's not constructed out of strawmen. Do that, dear web crowd, and then I'll accept that you ignorant assholes aren't ruining technology.

Actually, no I won't. Because JavaScript is still a shit language regardless of speed.

Read more

The bullshit claims echoed by every mention of "hg-fast-export" on the web: "It works great and it's so easy! All you have to do is this:"

/path/to/fast-export/hg-fast-export.sh -r /path/to/your/mercurial/repository

Uh huh. The reality:

Traceback (most recent call last): File "C:\DevProj\fast-export\hg-fast-export.py", line 6, in from mercurial import node ImportError: No module named mercurial

Wow! If that's a Python program "just working", then Python can properly fuck off. Note that I'm not writing any goddamn Python here, just trying to use some Pythoner asshole's useless script.

So ok, an hour dicking around on StartPage later, and I find some vague mention of solving the problem by (re?)installing a fairly specific version of Python, and a very specific mercurial installer (Yes, I already had Mercurial installed - no idea what version and honestly don't give a fuck). The Mercurial installer, naturally, failed to install. Found another (purely by guessing) that did work.

So try again:

[/path/to/fast-export]/hg-fast-export.sh -r [/path/to/your/mercurial/repository] Error: No --marks option given Usage: hg-fast-export.py [options] Options: blah blah blah jerk off blah blah blah

Note that not one fucking mention of hg-fast-export anywhere on the goddamn web makes any fucking mention of any "--marks" parameter, let alone that it's required. Let's see what the help screen says:

--mapping=MAPPINGFILE File to read last run's hg-to-git SHA1 mapping --marks=MARKSFILE File to read git-fast-import's marks from --heads=HEADSFILE File to read last run's git heads from

Holy fucking useless bullshit, Buttman! So I'm supposed to know and give a fuck what that shit's all about? And naturally, the included readme file makes absolutely no mention of this flag whatsoever. In fact, the example in the readme file doesn't even fucking use it!

Fine, kiss my ass you piece of shit:

[/path]/hg-fast-export.sh -r [/path/repo] --marks=i_dont_give_a_fuck Error: No --mapping option given [/path]/hg-fast-export.sh -r [/path/repo] --marks=fuckyou --mapping=fuckyou Error: No --heads option given

FUCK! The hell with this shit. Not like I don't have better things I should be doing instead.

The fact of the matter is, all VCS conversion tools/processes are worthless garbage (yes, I've tried many others in the past, going in many different "VCS A -> VCS B" directions). There isn't a damn one that actually works worth a shit, let alone without a pile of unnecessary hoops and such bullshit. Speaking of which, you can cram Cygwin up your ass.

A large part of the blame lies with that piece of shit Python. I don't care what good things anyone has to say about Python: When you have to know anything about language X in order to use a tool merely written in language X, then there's something horribly fucking WRONG with language X. Fuck language X.

Fuck Python, fuck Python scripts toys, and fuck the pathetic state of VCS conversion tools.

(Phew. There, I feel better now...)

(PS: Why was I converting a project from Hg to Git? Certainly not because I like Git - because I don't. I'm just tired of TortoiseHg's shittiness. It's allegedly a Tortoise* tool, but the damn thing can't quite seem to figure that out. TortoiseGit, OTOH, irritates me much less.)

Read more

I've spent the last month or so on a project that, due to factors beyond my control, must be in C++ and not D.

A little of my background first: I used C/C++ as my primary language in the late 90's and early 2000's. Liked it at the time, but then got fed up certain aspects and went looking for alternatives. Long story short, I found D, fell in love with it, and have been using it extensively for years.

Now that I'm back in C++-land (hey, it beats the hell out of writing a whole game entirely in a dynamic service/server-compiled toy from the same jokers folks who brought us the wonderful Flash), I've built up a list of the top things I miss from D when using C++. There's plenty of other great stuff in D that I miss, but these are the ones...so far...that are proving to be the most painful to live without in the particular project I'm working on (An iOS/Android puzzle-ish game). Other projects would likely have very different lists, of course.

Incidentally, this also serves as a deeper explanation for anyone who didn't understand the vague heckling of C++ in my previous post.

Top D Features I Miss In C++

1. Proper module system: One of the main things that drove me away from C++ in the first place. The header-file/text-inclusion hack is a colossal, anachronistic pain in the ass. There are so many problems with this one issue alone, I'm not sure they're even worth listing. But I will anyway because they deserve public ridicule:

   C++'s "Module" System Sucks

   • #ifndef _FILENAME_H_: All the reason you need to know C++'s module system sucks. Retarded hack.

   • Identifiers prefixed with psuedo-module vomit: Let's see... CIwFVec4... CIwGameActorImage... WTF? Can I haz FVec4 and ActorImage, plz? Yea, I know there's namespaces, but not everyone seems to use them. Somehow I have a feeling there's a good reason for that - besides just easier interfacing with D.

   • DRY? What's DRY? Derp derp durrr....

   • Scrambled modules! Let's chop up our module and play "What goes where?!?" Implementation files: non-inlined function bodies, non-member variables (which aren't evil globals in a language with proper modules), and private preprocessor directives. Header files: member variables, inlineable function bodies, public preprocessor directives, member accessibility (public/private), non-DRY duplication of non-inlined function signatures, plus includes and forward declarations that should be private but must be leaked out due to something else in the header needing to use them. Whee!

   • Header files are interface documentation? LIES! Seriously, look at your header files. You're really going to try to tell me that only contains the public interface? Then what's that private: section doing in there? And that forward declaration for an external class? If you want automatic documentation, run a damn documentation generator. They exist.

   • Headers affected by whatever headers were included before it: Hygiene? What's hygiene? And why is this compiling so slow? Durrr...I wonder why?

   • Fuck precompiled headers: Talk about "solving the wrong problem".

   • No RDMD (automatic dependency finding): Every...fucking...source file must be manually specified. I remember to do this about half the time.

   • And the #1 reason C++'s "module" system sucks: What is this, 1970?

2. Actual properties:

   foo->setX(foo->getX() + 1); // Suck my nutsack, C++

3. Metaprogramming that doesn't involve a text preprocessor or gobs of excessive template instantiations.

4. Sane type-name syntax: In C++, how do you spell int*[]* delegate()[]* (Ie, a pointer to an array of delegates which take no params and return a pointer to an array of int pointers)? Wrong! The correct answer is "Fuck you, I'm not attempting that shit in C++!"

5. Type deduction: Unfortunately, Marmalade doesn't yet support C++11, so I don't even get auto.

6. Closures, lambdas, nested functions: There's a good reason Qt in C++ requires a special preprocessor. (Yea, I'll care about C++11's features when I can rely on them actually existing in my compiler.)

7. No forward declarations: Was I wrong before? Maybe this is still 1970?

8. Actual reference types: And no, I don't mean Foo&.

9. Non-schizo virtual: C++'s member funcs are non-virtual by default...except the ones that are virtual by default and can't be sealed as final. WTF? WTF indeed. (Yes, I do understand how it works, but it works stupidly.)

10. Default initialization: Granted, I'd rather be told at compile-time about possibly using non-inited vars (ie, C#-style)...But garbage-initialization? Screw that. Especially for pointers, I mean, fuck, really?! Pain in the damn ass.

11. Fast compilation: Hooray for the world's slowest-compiling language! Whee!!

12. Polysemous literals: C++ can barely figure out that 2 can be a float. Gotta babysit it with 2.0f. Great.

13. Ranges: Fuck iterator pairs.

14. Named immutables/constants that actually exist in the real code, not just the preprocessor.

15. Designed by someone who actually fucking understands proper engineering.

Things I'm surprised I don't miss yet (but may still miss later and would undoubtedly miss if my project were for a different domain or maybe even just using different engine):

• Slices and string/array manipulation: Fuck null-terminated strings, fuck pointer/length pairs, and fuck everything in string.h.

• Associative arrays: Just works. Any key type. No syntactic bullshit.

• Scope guards: Also known as "RAII that isn't a contrived syntactical kludge".

• GC: You can pry manual memory management from my cold dead hands, but that doesn't mean I always wanna fuck with it.

• Foreach: I'm still convinced foreach(i; 0..blah) is essential for any modern language, but my prior experience with C/C++ seems to have left for(int i=0; i<blah; i++) irreparably burned into my brain.

And ok, to be perfectly fair to C++, let's turn things around a bit...

Things from C++ I miss when I go back to D:

• .......
• Ummm.....
• Not a fucking thing.

UPDATE (2012-09-12): Added "RDMD" to reasons C++'s module system sucks. Can't believe I forgot that before, that's a big one.

Read more