Archive for: June, 2006

Template Parameter Types

I just had a case where I wanted to make sure that a C++ template parameter was of a certain type. The template should be used for pointers to instances of class “Base” and its derivates so that I could call a method of Base on the object provided to the template class.

template< class T >
class MyTemplate
{
public:
    MyTemplate( T object )
    {
        object->baseClassMethod();
    }
};

First, I thought there would be no way to achieve this, but then I tried a static_cast which turned out to be the solution: using the static_cast ensures that the type casted to is used at compile-time. Isn’t that beautiful? If you don’t need to access the object but constrain the template to a certain type, you could use the d’tor to implement some dummy code.

template< class T >
class MyTemplate
{
public:
    MyTemplate( T someObject )
    {
    }
    virtual ~MyTemplate()
    {
        // constrain parameter type to "Base"
        // and derivates
        static_cast< Base* >( static_cast< T >( 0 ) );
    }
};

Using this template with a type which is neither “Base” nor inherited from “Base” leads to a compiler error like “can’t convert ‘bad type’ to ‘Base’.

Tool Enhanced Again

Tonight, I added the batch processing. On the left image, you can see a set of six input images on the left, and three output images on the right (all images at 50% zoom, another feature I added).

Free Image Hosting at www.ImageShack.us Free Image Hosting at www.ImageShack.us

The packing is not optimal in a mathematical sense, but it’s effective anyway, as the shot on the right shows. These (100% zoom) images were randomly picked from a set of output images which were created when I reorganized all of the plants we have in DVW to test my tool.

Tool Enhanced

Tonight, I enhanced the tool (codenamed TexTorture, hehe) with a little rectangle packing algorithm. Taking an unsorted list of sprites (i.e. rectangles), the outcome is already quite lovely. Next, I will try how presorting of the rectangles by width, heigth or area will affect the result. Finally, I want to be able to merge n input textures into m output textures, where m<<n, hopefully.

Rectangle Packing applied

Exe Packers

Yesterday I searched for PE EXE packers. UPX is certainly the best known candidate, but it has a quite restrictive license when it comes to changing the loader code or preventing unpacking of the compressed EXE somehow. After digging through some commercial tools like Armadillo (which features were impressing!) and shady tools like morphine which are usually used to hide trojan horses, worms and the like, I found PackMan – a nice packer with source and dedicated to the public domain.

Q’n’D Java Tool

I just wrote a quick and dirty Java/Swing tool. It loads and autodetects DVW sprites from a texture file and allows to reorganize them. This is useful for stupid programmers like me who don’t want to mess around with mspaint.exe or The GIMP but feel the urge to move sprites around for whatever reason. I am planning some improvements like a textual export of the rectangle coordinates and a cool algorithm to align the sprites automatically including batch processing, but for now, manual moving of the sprites is exactly what I wanted.

The autodetection is done using a simple floodfill approach which proved to be sufficient for my test texture. I might find other textures where this approach isn’t enough, therefore I will provide means to apply a dilatation operation on an image and to merge detected rectangles.

A little tool I wrote

While I wrote this tool, I recognized a little problem in the AWT drag and drop framework, java.awt.dnd.DropTargetListener in particular. I used DropTargetListener#dragOver(DropTargetDragEvent) to listen for dragging but found that there was no (direct) way to find out which object was actually dragged (those objects implement java.awt.datatransfer.Transferable).

I was not the first one who stumbled over this, like the entries in Suns bug database showed, and fortunately one suggestion from this page worked for me:

DropTargetDropEvent tempDTDropEvent = new DropTargetDropEvent( dtde.getDropTargetContext(), dtde.getLocation(), 0, 0 );
Transferable dragData = tempDTDropEvent.getTransferable();
MyTransferable trans = (MyTransferable) dragData.getTransferData( MyTransferable.DATA_FLAVOR );

This issue was fixed in Tiger where an appropriate getter for Transferable was added.