Hi, I save bmp file by two ways. First: windows handle method, Second: ALLEGRO_FILE, and there are some differences. Why?

Windows handle:
{"name":"122.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/9\/394edc1e2178f0ba867142a3ed969b06.png","w":1440,"h":900,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/3\/9\/394edc1e2178f0ba867142a3ed969b06"}

ALLEGRO_FILE:
{"name":"123.png","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/9\/e90ea36612f6db405cdf6312b19faa19.png","w":1440,"h":900,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/e\/9\/e90ea36612f6db405cdf6312b19faa19"}

Why ALLEGRO_FILE method saved crap file?

code:

tut tut tut

use al_load_bitmap() to load bmp types. al_fopen() is for txt or binary data

Isn't that right guys ?

AFAIK it is. Use the structures/functions to do what they are supposed to do. Don't expect an ALLEGRO_FILE handler to open up an image file(which is supposed to be loaded into an ALLEGRO_BITMAP) correctly.

You want to open your file with "wb" aka: binary mode, or windows will convert any and all \n characters it finds into \r\n sequences.

Also, why not just convert the hdc/dib to an ALLEGRO_BITMAP and save using al_save_bitmap?

...yeah, I suppose al_fopen will open anything but if you use it instead of al_load_bitmap you have to deal with the file format bmp before you can do anything with the file.

I think you guys are misunderstanding the problem. He's saving a file. not loading one.

oops... didn't take a good look at the line above it

Okay I changed to binary mode and it's just working. Now When I know that my saving bmp is correct, I changed it to saving in virtual file handle, so:

It crashed at first run of al_fwrite, just out of program. Any error, any message.

Try using al_fopen_interface instead of al_create_file_handle. al_create_file_handle doesn't actually open the file, so any file functions called on it will likely fail and/or crash.

I'm not even sure why al_create_file_handle exists now, after the big file api reorganization. Now theres no way to open an unopened file handle, so its pretty useless.

al_fopen_interface open file on disc, so it useless for me. So if there isn't way for open unopened file handle, I'll save file on disc, and open it from disc.

Out of curiosity, why do you do this ? Is it for a custom utility that needs to embed bitmaps in larger files ?

Ignore what I wrote before.

If you have implemented your file interface correctly, using al_create_file_handle and the al_f* functions should work just fine.

You may want to take a look at your custom file interface, to make sure it works properly.

al_create_file_handle is part of the API change that made it so that you no longer have to have access to the internals to create your own interface. With it, the fi_open method is not used.

It is meant only to be used with your own interface, typically wrapped within your own function that takes the place of al_fopen. For example, al_open_memfile uses al_create_file_handle.

Have you created your own interface? I suspect not. What you are doing will not work with the stdio functions. I think perhaps you are looking for the memfile addon.

Create a memfile, write to it, and then load from it.

Yeah no. I wasn't reading the code correctly. Should your own interface be coded properly, all of the normal file functions should work fine.

Except for al_fopen, but one shouldn't expect it to considering it doesn't take a file handle as a parameter (and therefore makes no sense given the context).

The problem here is I think the OP using it with stdio and assuming some virtual, temporary file is created in the void.

Quite. al_create_file_handle is a replacement for al_fopen.

And yeah, he's probably not quite understanding how it works.