das POX datei format

  • Moin!

    Nach ein paar Tagen Retro Fieber hatte ich mal die fixe Idee, das POX Format zu entschlüsseln.
    Dank des Interactive Disassemblers habe ich auch den RLE "Algorithmus" entschlüsseln können.
    Zunächst der allgemeine Aufbau einer POX Datei mit Bildern (es gibt auch POX Dateien, die nur die Ini Section enthalten):

    POX File:

    type name (value) description
    char[4] MAGIC "POXA" POX header magic
    char[2] type "TT","PR",... POX type identifier
    char[2] indent "\r\n"

    int iniLength size in bytes of the following section
    char[iniLength] iniString the ini file
    char[2] block_end "BB" end of ini file

    int numPics number of pictures/frames
    int dataLength length of RLE section in bytes
    RLEHdr[numPics] headers image headers one after the other
    char[dataLength] RLEData run length encoded img data
    char[2] file_end "BB" end of file

    Zur Erklärung des RLE Algorithmus:
    Wer Pseudo-C++-Code lesen kann ist klar im Vorteil:

    struct RLEHDR
    int SrcX, SrcY; // probably draw offset, not implemented in digifx
    uint width, height; // size of the ouput picture
    int AdjX, AdjY; // pixel offset
    uint PixFmt; // pixel format: PIXFMT_8 = 0; PIXFMT_555 = 1; PIXFMT_565 = 2; PIXFMT_888 = 3; PIXFMT_BGR = 128;
    uint Data; // pointer to rle data, use ONLY as offset, substract RLEHDR[0].data from RLEHDR[i].data

    // der Stream zeigt auf das erste Byte der RLE Daten des Pictures, in der POX
    // Datei sind diese aneinandergehängt
    void UnpackRLE(istream& fin, Bitmap* pixelmap, RLEHDR* rlehdr)
    int x=0, y=0;
    char c;
    short colour;
    int i;

    while(1) {
    c = fin.get();
    switch(c) {

    case 1: // colour/pixel data
    for( fin.read(&i,4); i > 0; i-- ) {
    fin.read(&colour, 2);
    pixelmap->setPixel(x + rlehdr->AdjX , y + rlehdr->AdjY, colour);

    case 2: // add x offset
    fin.read(&i, 4);
    i >> 1;
    x += i;

    case 3: // new line, carriage return (y++, x=0)

    case 0: // end of rle stream


    Bei Unklarheiten einfach fragen, dachte diese Information wäre ganz interessant...

  • I am so happy I found this thread - since I have been looking at the whole DigiFX stuff - and wanted it to just go away - so I could continue doing some more SDL2 stuff - but the access to the POX file through the DigiFX drivers is a pain. So I had fired IDAPro Free up - not looking forward to some disassembling - did a final search in the forum - tada! C pseudo code of the RLE decoding! Just what I needed. So I have created a document in the Github repo: POXFileFormat.md - with Pascal pseudo code :)

    ..and made a small Proof of Concept POX viewer - image attached.

    So no DFX dlls or calls via the DigiFX drivers - finally a chance to port this.

    I did see that savage had planned on converting the to a newer format based on PNG - but I would prefer to keep the assets intact - and you would still need to convert the files on Windows - due to the DigiFX stuff.

    Any interest in that I give the POX Viewer a bit more work, and release the source in the Github repo?

    The working code will surface when I get all the DigiFX stuff replaced - still not that trivial - but I want it done before I go back to the SDL2 stuff - (only Menu, Cursor and Game Loop done - basically where jedi-SDL stopped)

    Sorry for again doing this in English.


  • I would appreciate anything that could simplify the process of creating assets for the game.

    Hi Eustace,

    I have not done very much work with generating/editing POX files yet - so please guide me on the details - which current steps/tools do you need today - and how would you preferred workflow look?

    In the descriptions I have seen, it seems that many of the steps are manual, and more just to please the limitations of the tools, than to produce the end result.

    Looking forward to see your "spec", and then lets see what we can end up with :)

    I will look into testing a bit more today - we might not be cured of the pox yet :lol:


  • I redid the initial POX viewer - so that it could be compiled to macOS/Android/iOS - if that has any interest. Got the colours right, and do parse the ini data - to get some better interaction from the UI. This is just a viewer, but when some feedback on needs arrives - then I will start looking into editing/creation of POX files. Will do a blog post elsewhere on the code, before I do included it on the GitHub repo.

    Did a test run on the +3100 POX files, I had on my disk - seems all fine in terms of bitmap RLE decoding - with no issues.

    Anyone interested in that I upload an .EXE file?

    I have not heavily tested yet - so I might be missing some action types and housekeeping glitches :)


    New Thread:

    -> New POX tooling

    • Official Post

    Looks nice.

    If the new pox-viewer will have an export-option, this would be an advantage. The old ones had a problem with exporting all frames. The first one was skipped evertime. Only solution: Screenshot of the first frame, select a rectancle with the same height and width as the other frames and then save it. Well... Makeable, but laborious.

    Reminds me a little bit of the problem with the rectancle and diamond-tiles in relation to the source code from github which I could solve.
    Continued: SoA Source Code - Bugfixes

    Written by Eustace:

    Hi Steve

    As I said before, creating POX Files from scratch can be quite cumbersome. This is the workflow for creating new ("animated") assets with multiple frames:

    1. Exporting the needed .bmp-images (max. 360) from the external software (in my case Blender)

    2. Preparing the .ini-File

    3. Opening the tool BMPWorks, which is included in the toolset of ChaptEd. And this only works on an emulated machine with 16 Bit color depth, otherwise the colors will not be right.

    4. Importing the frames in BMPWorks, also the .ini-File. Importing more than ~360 images (size 150x150) won't work.

    5. Exporting the whole thing as a .gif

    6. Running the batch tool "Gif2Pox" over it. This tool is also included in the ChaptEd tools.

    7. Done

    If there was a way to simplify this, I would be infinitely grateful.


    Written by Stevenew:

    Thanks Eustace,

    So reading this, my initial take would be a flow like - in a "new" tool:

    1. Import all the external bmps (which are same size) into tool.

    2. Initial preparation of the ini data - image size, transparent and such, done by import.

    3. Group and order frames - by action and direction - setting movementSteps and other properties

    4. Test run and adjust.

    5. Save as POX - doing color convertions and RLE.

    Could that be a target spec?


    Wo ich bin klappt nichts,...
    aber ich kann ja nicht überall sein.

  • Hi Steve

    Yes, that would be awesome already.

    Usually the movement specs in the *.ini files look the same for every item, so I'm thinking it would be more efficient if it was possible to import the whole *.ini at once in the case of items. Being able to edit it within the tool would be awesome aswell.

  • Eustace, would it make also make sense just to load an existing POX file - "import" the new images, and then just let the user adjust the ini data afterwards?

    The main thing I guess I would like is that I actually could test the output - before exporting to the new POX file - otherwise I have to actually put it into the "game".

    I will do some clean-up of my new proposed POX Viewer, but I start looking into writing the POX files - so that I have a better idea of all the variations :D


  • Another idea:

    Having something like user editable templates of *.inis that one could load and edit within the tool, then export the *.pox with the selected and edited template... that would be cool aswell imo. ;)

    Anyway, I'll be looking forward to hearing any news about this.