Hello,
I'm trying to save some allegro images directly in my save game data file.

I have Deserialiser/Serialiser class that works as stream and is basically wrapped FILE* f, so I thought this won't be hard.

I used the custom data pointer to store pointer to the the (De)serliaser and mapped all the methods of the FILE_INTERFACE.

 this->fileInterface = new ALLEGRO_FILE_INTERFACE;
  this->fileInterface->fi_fopen = &AllegroFileToDeserialiserConnection::fi_fopen;
  this->fileInterface->fi_fclose = &AllegroFileToDeserialiserConnection::fi_fclose;
  this->fileInterface->fi_fread = &AllegroFileToDeserialiserConnection::fi_fread;
  this->fileInterface->fi_fwrite = NULL;
  this->fileInterface->fi_fflush = &AllegroFileToDeserialiserConnection::fi_fflush;
  this->fileInterface->fi_ftell = &AllegroFileToDeserialiserConnection::fi_ftell;
  this->fileInterface->fi_fseek = &AllegroFileToDeserialiserConnection::fi_fseek;
  this->fileInterface->fi_feof = &AllegroFileToDeserialiserConnection::fi_feof;
  this->fileInterface->fi_ferror = &AllegroFileToDeserialiserConnection::fi_ferror;
  this->fileInterface->fi_fclearerr = &AllegroFileToDeserialiserConnection::fi_fclearerr;
  this->fileInterface->fi_fungetc = NULL;
  this->fileInterface->fi_fsize = &AllegroFileToDeserialiserConnection::fi_fsize;
  this->file = al_fopen_interface(this->fileInterface, (const char*)(&serialiser), "rb");

On the last line I use trick, I use the file name parameter to actually pass the pointer to the serialiser that will be used.

Saving of the bitmap worked fine, and it was saved in nice single call of fi_fwrite (with length of 50kb).

When I tried to load the bitmap, it just didn't work, I observed several calls of ftell (I just return 0, as it calls in the beginning), then reads and fseeks.

After that the result bitmap has 0 width 0 height (and it was saved as 2048X2048 bitmap), and not only that, the stream it reads from is left in some inconsistent state (It doesn't read exactly the same as it wrote to the stream).

Any ideas?
Can this work at all? Am I not using some obsolete method that is not working anymore?
Thanks for any pointers.

In the worst case, I can save those bitmaps as separate files, but I would really like to avoid that, it would be messy.

Well I see it the other way around
I want to wrap the C insanity in C++ objects as soon as possible
Rest of the game is completely in C++ (several MB of codebase now) so I hardly want to rewrite it to C

Yes, I use the al_get_file_userdata and reinterpret it to the serialiser. This works fine, I checked that the object I get is the correct one.

I don't really need any other data then the pointer itself, so I don't need to allocate any memory.

I don't want to/can't use new serialiser, because I want to save the data of the picture(s) to the opened and half-filled file.

These are the (static) methods used by the interface:

This is the order of calls

fi_fopen
fi_fseek(offset = 0, whence = 1 (Current))
fi_fsize() (I return -1, as can't be determined)
fi_fread(size = 88)
fi_fseek(offset = 0, whence = 0 (Set?))
fi_fread(size = 22)
fi_fseek(offset = 0, whence = 0 (Set?))
fi_fread(size = 18)
fi_fseek(offset = 0, whence = 0 (Set?))
fi_fseek(offset = 0, whence = 0 (Set?))
fi_fread(size = 44)
fi_fseek(offset = -44, whence = 1)

The problem might be the fsize as well maybe.
I could wrap the file more.
While saving, I would just save it all into memory first instead to file directly, then I would save the count of bytes and the memory.

While loading, I would load the whole batch from memory, and those functions would just fiddle in the reserved memory for the file.

This way, I could return the value of fsize (unknown otherwise, when using it as stream) and I would also don't mind that it wouldn't leave the file marker at the right position. (Not even mentioning that the (De)Serialiser, will have also different sources than just file where seek will not be possible).

I'm afraid, that this might not be solvable at all, and I would have to save/load those pictures somewhere aside the data file, but I wouldn't be happy with it at all.

You can read/write multiple packed files in a single stream, but there can be problems due to the image loaders not necessarily being native to Allegro and not playing nicely with the concept.

An image loader may very well expect to be able to seek to the end of a file, back up, read a few bytes, seek to the beginning of the file, etc. If your custom I/O treats "seek to beginning" as "rewind to the start of my multi-file stream," it will fail with some loaders.

To get around it, you can use a file slice (a thin wrapper over any file):

ALLEGRO_FILE *fp_custom = open_custom_stream();

int32_t size = al_fread32le(fp_custom);

ALLEGRO_FILE *fp_image = al_fopen_slice(fp_custom, size, "r");
ALLEGRO_BITMAP *bmp = al_load_bitmap_entry(fp_image, ".png");
al_fclose(fp_image);

al_fclose(fp_custom);

When closing the slice, the outer stream will advance to the end of the slice. This requires that the outer supports random access.

Note that technically, this applies to writing files as well. A writer could seek to the beginning of the file and overwrite the wrong portion. You can use an expandable, writable file slice to avoid that.

Finally, while you could do this all in memory, there's no reason when writing that you couldn't store 0x00000000, write the file (to a slice), close the slice, go back fill in the size, and then seek to end of file.

I can't express how much am I thankful for your advices. I had to do few changes, but the beast is now working.

The slicer works differently than I thought, it still calls fseeks on the custom stream, but yes, it sets the file position to the end after fclose is called, so it is working correctly.

There is one main problem I had to fix from the start (stupid me for not realizing it earlier):

When the whence was CUR (relative), it was working correctly.
But when the whence was SET (absolute), my call to fseek of the custom stream set the position relative to the start of the whole stream, not to the beggining of the part of the stream containing the image (the slice).

I solved it by creating custom variable called shift, I set it to 0 at the start, and I update it along any operation (read, seek).

Then, I used this shift variable to convert the seek with absolute set to the call of the relative seek, I can also use it to simulate the ftell function properly.

Thank you for the help, I got really frustrated and now I can move to the more creative tasks of the game making again

I would expect that, but it doesn't, I'm using the slice, and it still calls the SET version of seek.