Posted by Blake on June 15th, 2007 — Posted in lolcats, Code
WWW.CANHASLOL.COM
<SweepingGeneralization>Everybody loves Lolcats. That is, if you know of them, you love them. To Know them is to love them. </SweepingGeneralization>
The concept is simple, take a picture, silly or not, of a cat or not, and caption it. They’re funny, really funny. Rightly so, everybody makes their own, forums have caturday threads that act as warm fertile tidepools for new (and wierd) cliches. BOOM, suddenly you have the meme that somehow sums up everything that Web 2.0 stands for.
Lolcats are the instant viral-meme. Create a site concerning them in any way shape or form and the masses of fans will quite probably follow. The potential boggles me! It was this, and the inspiration of the excellent Lolcat Builder that lead me to throw together the (experimental) CANHASLOL lolcat builder! It’s a flash based WYSIWYG captioning tool. I made this as an experiment in viral memes, (and also as an excuse to finally learn flash actionscript, php, imagemagick voodoo, and javascript).
Here’s how it works. There are some rather annoying, but necessary, limitations in flash that make it a little difficult to use as an editor for personal files. To load an image to edit, it must first be uploaded by flash to the web server hosting the flash file, and then re-downloaded into the flash player. This part isn’t too tough. Then there’s the issue of the image generation. The user needs to be able to get to the image after it’s captioned. It is technically possible to encode jpegs in flash but this puts more bandwidth strain on the server and the user, seeing as the result would then have to be uploaded to the server, and then re-downloaded by the user.. Blech! not to mention, these files can get BIG. So, I got to thinking that Flash can just send the server a representation of the caption, and then server side scripts can render the image, and then flash can pull that image back in, and throw it up onto the webpage for download with some DHTML goodness!
Now, how to render some text on the server? At first, I was planning on using GDLIB for php, since it is pretty ubiquitous and capable.. Except it had a few limitations that I really didn’t like. Namely, blurred drop-shadows, and text outlines seemed difficult to pull off. So, I then investigated the other old standby, ImageMagick. I cannot understate the power of its compositing and mvg rendering language! The only limitation that I found with ImageMagick was that it would be very difficult to render a line of text with formatting/color changes in mid-line.. Kind of disappointing since the flash portion of the tool supported this, but .. OH WELL!
Here’s the plan for getting this thing to go viral: It’s a variation on Photobucket’s method. Allow the user to create images, and then provide a pasteable link to the picture that will display the pic in forums, but provide a link back to the CanHasLol creator. Every image linked externally will be an advertisement. If it takes off, it should conceivably self-propagate. Either way, I’ll be happy if the bandwidth pays for itself 
Right now the software is very very beta, but fully functional, with a smattering of fonts. Drop shadows, picture cropping, and a few other tools are planned for the near future, but I’ve got a 48 hour film project to worry about this weekend.
Stay tuned for follow up posts regarding new features, hit growth, and writeups on flash-php-javascript interaction points of interest!
12 Comments »
Posted by Blake on May 30th, 2007 — Posted in Python, SDL, Code
TrashVac Hero X
Do you want Shoot-em-up? With Physics??
The first pyweek that Donal and I participated in was the off season pygame.draw challenge. This challenge had one heck of a twist: The entire game had to be contained in a single 64k or less python file. That’s it. No images, sound files, text files, or sneaky web connections to stream in content. Thus the name of the challenge, Pygame.Draw. A few clever folks base64 encoded graphics and sound right into the source, however… I wish I had thought to do that. A few vain attempts were made at storing waveform data in strings before forcing myself to get back to the core game coding, but it was just too big and clunky. In a way it’s a shame that the most interesting challenge restrictions were on an un-judged competition. But then again, this may have been merciful, seeing as it was our first foray into rapid game development.
I might also add our shared taste in games is for the twitchy shoot-em ups and platformers as opposed to the slow and contemplative puzzle type games. This meant that whatever it is we were going to make, we would be aiming for some performance. Donal has a write-up on some of the challenges we encountered on this coding sprint.
We had big dreams, which distilled down to two sadistic levels in the final overnight code bender. But the core mechanics of the game came out just as we had hoped. Fast paced shooter action with a swarming physics system. As the TrashVac Hero, the player pilots a garbage attracting gunship that creates a spinning shield of enemy ship remains. The ships sole conventional weapon is intentionally very weak; this encourages heavy use of particle slinging to destroy enemies. That is the handiest way to kill the stronger ones in the first place.
There is of course, also, the ubiquitous ‘Bomb’ of shootemups. There aren’t any bomb-stocks displayed on the screen, but the player gets two of them, with used ones refilling every 20 seconds or so. Use it to get out of tough shaves with too many bullets.
Here, we present an updated TrashVac Hero X, now with gamepad support and SOUND (Music used by the kind licensing permissions of DJ Top-Shelf)!
TrashVacHeroX source (549)
TrashVacHeroX win32 binary (501)
p.s. Leave a comment if you can defeat the VoidStar (The huge gray ball that tries to kill you after level 2). It’s pretty tough unless trash is slung at it with great speed.
Kid Bandyhoot’s Crazy Adventures in Cylindrical Coordinate Space
This little game was based around the concept of Contra wrapped around a tower. A few of the other competitors correctly identified the influence of an old game called nebulus with a similarly cylindrical gameplay theme. However, my experience with that game came not from Nebulus itself, but from a cheesy NES knock off of it called Kyoro Chan Land based around the tower constrained exploits of some candy-representin’ bird thing. Yeah… I had way too much time during certain periods of my life..
It was during this challenge that Donal and I learned the dire importance of making binary images of your Pygame projects! We ended up getting third place, not in regular votes, but in ‘did-not-run-on-my-machine’ votes! This stemmed mostly from PyOpenGL oddness, some bitdepth issues, and the fact that quite a few folks were running python 2.5, which we never tested against. The people that were able to play enjoyed the game well enough, even enough to get decent Fun and Innovation scores in spite of some serious polish-lack. That is, the game is missing score and health meters. Even so, Donal kept the project timing on task and my coding tunnel vision in check, and we were able to finish a title screen for this one. A previously elusive milestone!
On the subject of PyOpenGL: Just before this Pyweek challenge I had made the switch to Windows Vista on a shiny new machine, but no matter what I tried, the OpenGL performance in this game was awful. So much so that I was positive software rendering was being used. Now, I had heard all of the rumors about vista dropping openGL support, and that Vista’s openGL performance was going to be inferior to 9x, and so forth. This was just wrong though, considering other GL programs were working passably. After giving up and doing most of the work on my old system, I tried a binary package on my new Vista system, and BEHOLD, the game ran at full speed! The only explanation that I can gather is that the 3.0 versions of PyOpenGL don’t seem to be grabbing the right opengl32.dll . From what I had read, the 2.0 versions were using Swig to wrap the dll, while the 3.0 tree was using ctypes. If anyone out there has had a similar issue, please do chime in with a comment!
And now, enjoy Kid Bandyhoots Crazy Adventures in Cylindrical Coordinate Space. With a rockin’ soundtrack by the always-savory J, and a surprise end boss!
6/2/2007 :: Now Updated with Health Meter!
KidBandyhootsCrazyAdventures source (698)
KidBandyhootsCrazyAdventures win32 binary (652)
3 Comments »
Posted by Blake on May 24th, 2007 — Posted in Effects, Code
Blobfluid-source (665)
There we go, the source for the blobfluid, in its self incriminating badness. Fast and loose pointer arithmetic, rampant abuse of STL lists, the whole gamut. I release this code under the Creative Commons license.
It has a visual C++ express solution included, so it can be built with the free edition of the compiler. The SDL development libraries just have to be installed with the include and lib seach paths set up in visual studio, and the SDL.dll needs to be in the path somewhere (copy it in to the solution directory, or into your windows\system32\ folder if you’re feeling particularly NAUGHTY).
At some point, the whole mess deserves to be rewritten using shaders and floating point surfaces. The framerate for 320×240 at 3000 blobs is about 100 on my core2duo system, heavily resolution dependent. I would estimate a 30x speedup on decent 3d hardware.
The Fluid System
The xscreensaver package has had a really similar effect to this fluid simulator (theirs is fluidballs)for quite some time (I didn’t know about it, or it didn’t exist back when I wrote mine.. Those times in my life were not the most Linux savvy). Except it doesn’t have the fancy rendering, and I think that the ‘physics’ simulation is carried out rather differently as well. The point is the same in both, though: Fluids act a lot like low friction circular particles pushing each other around. Of course more advanced fluid behavior like viscosity and shear and all those other great things in the stokes equations would make things much more difficult, but to get something that looks recognizably flowey a simple particle system with particles repelling one another when they get within a certain radius fills the bill.
Tons of repulsing objects imparting forces on each other can be solved correctly as a big system of equations, or, thankfully, it can be faked with approximations!
The fun parts are in blobsystems.cpp, for what they’re worth. The trick for colliding so many particles together quickly was to separate them all into buckets for each frame, where the buckets had a size that was a power of two, and the exact index of the ‘bucket’ that a blob was in could be calculated with a simple bit shift. Then you only apply repulsion forces between blobs in the same or immediately neighboring ‘buckets’.
Happy perusing for any that stumble upon it, and have an interest.
No Comments »
