Prin-Prin Collides! (2012/02/21)

A few days late accomplishing what I had set out to do this weekend, but so it goes. I had some difficulty with the collision code that ended up being due to a stupid graphical translation I had put in very early for testing. Basically, the character appeared to be 2.5 units lower than she actually was.

I wrote collision functions three times before I finally caught it, even going so far as to build a test rig in SDL to more quickly check my algorithms. Oh well; I learned a lot about collision detection theory in the meanwhile.

Realistically the collision code is just placeholder. At some point I'll integrate a more featureful lib, probably chipmunk.

More OpenGL + Prin-Prin (2012/02/17)

This week saw the expansion of my loader to support tris, quads, and polys as well as texture UV data. The last thing to support will be materials, but I am not really jumping on that one any time soon.

This evening I started to put everything I've learned to use and sketched out a very quick game demo featuring sprite animation (rendered to a single quad) with a camera that loosely follows a player-controlled character on the screen.

The demo is intended as a rough, early showcase in hopes that I can get involved with a certain game project that Josh Lesnick (of webcomic Girly fame) is starting to develop. Specifics can be found at http://prin-prin.tumblr.com

A low-quality video showing off what I accomplished in a few hours.

SDL/OpenGL - A good start (2012/02/12)

I've been putting off learning OpenGL for a long time now. I haven't had a particularly compelling use case, and since my laptop can't run it for crap anyway I didn't worry about it. Most of my graphical code is 2D.

But, yesterday the bug got me, and I decided to really dig into it for once. I'm using SDL as my main lib for setting up everything. At the end of the day (around, oh, 6 AM or so) I had a pretty solid beginning. I started building some functions for handling lists of quads and tris, and was diving into Blender again (an on-and-off love-hate relationship) to find a decent export format to use. I settled on .obj; it is a clean and useful format. I got some small part of a loader finished and went to bed.

Today I've got the loader complete, in a sense. For now it only handles quads, not tris or polys. Adding support for those will only be a modification in one section of the loader, though, because of how .obj organizes itself.

It also doesn't support multiple objects yet, which .obj does. That will come in time.

So, I'm wrapping up for the day and so far I have:

Not bad for about a day and a half's work.

Next up will be adding some basic UI stuff (trivial control stuff via SDL) and building up my scene heirarchy.

"Support" (2011/05/30)

Ok, I get that a company can't always target everything with its software releases. If a codebase is too large and has been very tailored for a specific system (Windows, say), it may require a lot of work just to get it into something resembling compliance so that it will build on other systems. I get that.

But, this kills me: a company releases a Linux build of its software, but ONLY release an x86 build; if you run a pure-64 system, you're out of luck.

But hey, at least they released the source. Too bad I can't get to the game content, since the installer is 32bit also. So I'll poke at the installer with strings(1) and a hex dump and such, determine that the data files are stored in zip format, and write a simple C program to rip the zip structure out into a normal zip file. NO PROBLEM.

Except, HEY, the source code is only for the Windows release. Unless I want to try to parse the vcproj file (yeah, no thanks) out into a normal make file, and then work out all the MS-centric braindamage, and THEN figure out how to strip the Windows-only requirements, then I'm still dead in the water.

This is monstrous failure. Unless you are doing some special ASM magic (and even then maybe not), there is NO excuse for not providing a damned x86_64 executable with the binary release. Especially when the same company HAS provided both 32 and 64 bit binaries for previous products.

BAH.

btrfs on LUKS/LVM (2011/05/13)

About a year ago, when I was first playing with btrfs, I tried all manner of strange situations trying to break it and/or see how it handled various failure scenarios. Standard testing stuff. But, I was able to personally confirm the gotcha on the btrfs wiki regarding having btrfs volumes on top of LVM. I managed to break it in a pretty nasty way.

Which, incidentally, is very unfortunate. I know it’s been a year or so now, and there have been improvements, but until I get around to doing more mean testing on it, I don’t feel safe running it on LVM. Which means I don’t run it on my laptop and workstation, as I require LVM to do a full-disc (minus /boot) LUKS encryption setup. I COULD compromise by having all my data in one partition and not run a swap (or keep a swap file instead of a part), but then I lose my, important, /home separation.

In this case, security wins over utility. For now.