Number formats are little endian.

For Doom II, the image directory begins at 3080128 DEC (2EFFC0 HEX) in my ROM. I sourced my GBA Doom II ROM from a questionable site almost a decade ago, so I'm not 100% certain what version it is, but given the lack of a language select, I suspect its the US release. (the EU versions of at least Duke Nukem Advance carried several language translations, compared to the US version which was english only)

The format of a directory entry is as follows: (There are 3699 textures. I suspect this value is stored at 2EEFB2 HEX, as a int32. Its hard to tell for certain how all of this works, since everything's stored slightly differently in the Duke Nukem Advance ROM. I also have no idea what the data in between means, but it seems to be a progressively increasing table of numbers. )

int32 width;
int32 height; //both of these are always powers of two
int32 flags; //estimate, its 8 for almost every graphic in the game except for skies, where it is 1
int32 xoffset;
int32 yoffset;
int32 ptr1; //These are the pointers to the bitmap data. Subsequent pointers are to smaller mip levels
int32 ptr2; //Note: ptr1 is always 0 on a flat (but can be 0 for nonflats, so I'm not certain how a flat is identified), only mip level 1 and above exist, so flats are 32x32 scaled to fit the 64x64 grid
int32 ptr3;
int32 ptr4;
int32 ptr5;
int32 ptr6;
int32 ptr7;
int32 ptr8;
int8[8] name; //Note: name does not seem to be referenced ever, and oftentimes is nonsensical. The same name is even used on multiple sprites frequently
int32 unknown; //I seriously have no clue what this does

Textures have the same names as their Doom II names. no patches are used, all textures are precomposited, and textures with NPO2 dimensions were edited to fit a PO2 resolution. All flats use names from Doom II, including those in the other southpaw engine games, Duke Nukem Advance and Ice Nine. I am not certain if this is a limitation of the engine, I don't remember seeing the flat names stored elsewhere in the ROM files.

Pointers are relative to the end of the directory, 3316928 DEC (329CC0 HEX)

The image format is simpler than Doom's, but it carries a few oddities.

Images start out with a table of pointers to columns of pixel data. These pointers are relative to the end of the image directory in the ROM. If a pointer is 0, the column seems to be skipped entirely.
int32[image_width] pointers;

From there, the columns are stored as raw sets of 8 bit pixel data (except for skies, which will be described below). Palette index 0 is treated as transparent. Palette index 10 carries special meaning, which varies based on the position of the byte. If its at the start of a column, it defines a partial column, in this format

int8 header = 10;
int8 offset; //How far down the column starts
int8 length; //How many pixels in this column.

If 10 is encountered later within a column, it has a different meaning (I don't know how both of these meanings work together, I don't recall encountering it in any of the game's images). In these cases, it causes the image to skip over pixels to a certain position.

int8 header = 10;
int8 skipto; (0-based, so the first pixel in the column is 0)

When index 10 is encountered within a column, not at the start, the image reader will skip over bytes until it reachers the position of skipto within the column. (Any pixel skipped over is treated as transparent). Confusingly, things like rail textures in Duke Nukem Advance will have a index 10 pixel skip to the point where the rail begins, then the rail's color bytes, and then another series of index 10 pixels which skip to the end of the column. I really don't understand 10 when its used within a column, since it doesn't actually save any space (all those transparent pixels still exist in the ROM), maybe its just a convenience for the renderer, instructing it not to bother processing the transparent space at all.

Skies (the only way I know how to identify them is to look at the "flags" variable in the directory, which is 1 for skies) are mostly the same, but they carry one difference: The width of the sky is cut in half in the directory, but confusingly pixel data is provided for the full width when doubled. In this case, columns interlace the bytes for one column, as well as the column next to it. The image is treated as twice as wide, and instead of defining every nth column in the pointer table, they define every n*2 columns. Each column then defines the pixels as the first pixel for the defined column, and then the first pixel for the next column, then the second pixel for the defined column, then the second pixel for the next column, and so on. I have not noticed pixel index 10 being used at any point in skies, which makes sense since they usually aren't transparent. I do not know how the renderer would treat palette index 10 if it was used.

Flats do not seem to be too special, except for the fact that the pointer for the 0th mip level is 0. In this case, you must start from the first mip level, which is half the defined resolution. Palette index 10 probably has no meaning in flats, but I am not certain. It does not appear in any flat to the best of my knowledge. Many flat names have a * at the end of the name, either appended onto the end of the original name or replacing the last character if the original flat name was already 8 characters, but not every flat has the *.