New Commands: PNGLOAD (& maybe PNGSAVE)

[Anonymous]

you should add a command to directly load PNG files into a GET/PUT buffer conform string, i.e. "PNGLOAD", maybe also "PNGSAVE" for saving buffers as PNG bitmaps. BMP version 4, that supports alpha channel, is almost unsupported by any graphic program. PNG is the actual standard graphic format.

- Seems as if this won't be posted in "open discussion", there might be a forum configuration issue...

[Markus Hoffmann]

I do not have code for png which i could use for that. Do you know any? It needs to be public domain or at least GPL so that I would be able to include it into the X11-Basic package. I do not want to use separate .dll files (which wouldnt work under Android anyways).

[Markus Hoffmann]

You need to get an account on sourceforge to be able to post into all forums. Anonymus posts need to be manually approved. This can take very long.

[Anonymous]

There's a lib for SDL https://www.libsdl.org/projects/SDL_image/ But I don't know much more about it except that SDL is based upon the Windows/IBM BMP format. But I don't think it can't support the alpha channel because it's used for computer games.

• And I've had an even better idea: using "LOAD" as a multi-purpose loading function primarily determining the file type by the file extension. Syntax "LOAD <string:filename>, <string destination="" variable="">". This way you may once also load a BASIC program in a string and execute it somehow. Or a multimedia file, formatted text document... Of course it only supports files you decide that they should be supported this way.

[Markus Hoffmann]

Thank you for your suggestions. I have myself done some investigation about this new feature and think it could be implemented as two functions: PNGDECODE$() and PNGENCODE$(). This would be more consistent than modifying LOAD. This woulod mean you would load a file into a string (with BLOAD, BGET etc..) and then do a
PUT x,y,PNGDECODE(a$)
to display it. On the other hand, you could grab the sreen with
SGET s$
d$=PNGENCODE$(s$)
and then save it with

BSAVE "my.png",varptr(d$),len(d$)

For the coding, the lodepng code could be used. The downside is, that it makes the X11-Basic excecutables 80kBytes larger.

[Mr. B.B.C.]

I think X11 Basic should be a BASIC, i.e. as easy as possible. There aren't compatibiliy issues further, because the original LOAD/SAVE only worked in direct mode IIRC, and didn't "like" an additional parameter.

The only disadvantage would be the blackbox nature of such an instruction, but you might add a function that puts out what file formats are supported by LOAD/SAVE, maybe just a "LOADABLE(<file path="">)" that's including the functionality of "EXISTS()" too. Of course you should get an error message if you try to load/save in an unsupported file format anyway...

The new LOAD/SAVE would let you support loads of file formats without introducing new instructions and functions. For example you would need a "JPEGDECODE()", "MP4DECODE()" and so on too if you want to support these file formats. The smart LOAD/SAVE won't require new instructions for such.

BTW: I've had once an idea for a platform independent DLL support, to load libraries/plugins during runtime. The key is that they are almost working like a shell/command line instructions; you may implement this concept and e.g. introduce these instructions in X11 Basic:

PLUGINLOAD "libzip", $ziplib
PLUGINUSE $ziplib, "open", "myfiles.zip", $zipfile
PLUGINUSE $ziplib, "getnext", $zipfile, $file

This dynamically loads for example a plugin to handle ZIP files that would be named "libzip.dll" on Windows systems for example. - Won't work with the original pkzip.dll of course; you have to write such plugins specifically for this plugin concept.

$ziplib would hold the handle for the plugin then. "open" is an instruction for the plugin to open the file "myfiles.zip", which returns the ZIP file handle $zipfile. "getnext" is the instruction to return the first/next file in the given zipfile. $file would get then a string like this: "/boot.ini\nsize=114\nchanged=1428746400..." - i.e. all stored file informations (where e.g. "changed" is the last access in Unix time).

Not the quickest communication, but you won't write an extra plugin just to calculate the sinus of an angle anyway. And it's darned flexible.

[Markus Hoffmann]

OK, there is already a way to use external plugins (.dll on WIndows) in X11-Basic: see the LINK command.

[Mr. B.B.C.]

Just an annotation; this plugin concept was more thought for C/C++; as you know it's not trouble-free to dynamically link libraries platform-independently.

This whole VARPTR() stuff is a very not-so-clean hacking like using an inline assembler. I'd make a "BASIC solution" for nearly everything - easy and safe - and only offer hacking possibilities to do things that might be not supported by the language.

So I'm still favouring the LOAD/SAVE solution, even if you never want to add another file format plugin than PNG.

[Markus Hoffmann]

I have now implemented PNGENCODE$() and PNGDECODE$() in Version 1.23-22.

Function: PNGENCODE$()
Syntax: png$=PNGENCODE$(bmp$)

DESCRIPTION:

Converts bitmap data in bmp$ into the Portable Network Graphics format.
The content of png$ can then be saved into a file with ending .png.

EXAMPLE:
SGET screen$ ! save the graphics screen content in screen$
png$=PNGENCODE$(screen$)
BSAVE "screen.png",varptr(png$),len(png$)

Function: PNGDECODE$()
Syntax: bmp$=PNGDECODE$(png$)

DESCRIPTION:

Converts the content of png$ which should contain data of a 
Portable Network Graphics format into a bmp data format which then
can be pasted to the screen with PUT.

EXAMPLE:
OPEN "I",#1,"image.png"
png$=INPUT$(#1,LOF(#1))
CLOSE #1
bmp$=PNGDECODE$(png$)
PUT 32,32,png$ ! display the image
SHOWPAGE