|
|
We now can use Vampyre Imaging Library to load and save images in various formats. After some testing, I’m very impressed with how easy it is to use Vampyre, and we are already:
- Using it with Delphi by default (no need to do anything).
-
Vampyre source code is bundled with CGE, so you don’t need to set up / download anything extra. Vampyre is just automatically used under the hood by CGE to load/save some image formats. It is in src/vampyre_imaginglib of CGE, and CGE build tool automatically passes paths to it when building CGE applications.
For FPC:
I have also tested using Vampyre with FPC, and our build tool already contains the necessary paths. Every FPC user of CGE can just define USE_VAMPYRE_IMAGING symbol to use it. There are a number of ways to define it, the advised is to define it in CastleEngineManifest.xml, like here.
In the near future we will likely just use Vampyre with FPC by default, so the need to define USE_VAMPYRE_IMAGING is just a temporary thing. We just need more testing, with various FPC versions and platforms (see lower for examples).
In the more distant future, we may also remove the code to use FpImage with FPC, even as a fallback, since Vampyre seems just better than FpImage in every way.
Advantages of using Vampyre:
- Vampyre Imaging Library is cross-platform.
-
Works with both FPC and Delphi. Unlike FPC-specific FpImage or Delphi-specific PngImage (and other stuff in Delphi
Vcl.Imaging). -
Supports many image formats, both reading and writing. It even supports a bit more than FpImage, e.g. we added now loading TIFF, JPEG 2000, XPM without any extra tools.
-
It has really good and simple API. Almost entire CGE + Vampyre integration code is in this include file.
-
It is well documented on https://imaginglib.sourceforge.io/ , with manual and reference.
-
It is efficient. Unlike e.g. FpImage from FPC — which turned out to be very inefficient when it comes e.g. to PNG image reading (despite our efforts to make it fast, using
TFPCompactImgRGBA8Bit, using format detection inInternalDetectClassPNG). -
It doesn’t require any external libraries. Unlike LibPng approach in CGE.
Help us test!
I’m eager to hear about your tests of Vampyre on various platforms, with various compilers, with your images.
You can use e.g. our castle-view-image (image viewer) for easy testing. It compiles now with both FPC and Delphi.
You can also use a new cross-platform example: examples/images_videos/image_display . This loads the image in a number of formats (making sure we support them all), and can perform speed testing – to compare loading times of various libraries, so you can verify the speed of Vampyre vs FpImage vs LibPng yourself.
What about LibPng, DDS, KTX?
Vampyre is still a bit slower for reading PNGs than LibPng (about 2x slower on Linux/x86_64, which is anyway better than FpImage that was 4x slower), so we will keep relying on LibPng for PNG. Still, Vampyre is a much better fallback than FpImage when LibPng will be missing.
We may rely on Vampyre for some formats that are currently built-in in CGE code, too. This includes BMP, RGBE, PPM.
We will likely keep our own CGE code for loading DDS and KTX though. (Vampyre can handle DDS. But we want DDS and KTX to go though a similar code path in CGE, and we want to efficiently use all their features — cubemaps, texture compression, 3d textures, mipmaps.)