I'm trying to generate fonts for Irrlicht, but I am having problems. I have studied the fonts that come with Irrlicht, and I understand basically how it works. First, I'll explain how I think it works.
The space character is marked as two consecutive RGB pixels: (255,255,0) and (255,0,0). These are normally the upper-left and bottom-right markers, but are consecutive in both of the included Irrlicht fonts; so I have mimicked that behavior in my own font generator.
For all other characters, the upper-left is marked with the RGB pixel (255,255,0) and the bottom right is marked with the RGB pixel (255,0,0). The rest of this post assumes this to be correct. If it isn't, then what follows is moot.
The included fonts span multiple rows, but my reading of the IrrFontTool source code doesn't seem to require it. My font file generator therefore puts all font characters on a single line. I'm not sure whether this is the cause of my problem or not.
When I try to load my custom font, Irrlicht generates an error message: "The amount of upper corner pixels or lower corner pixels is == 0, font file may be corrupted." I have checked my font image, and I can't see anything that might cause this error.
Here's a PNG version of the font image (I've tried saving it as a BMP too, just in case Irrlicht has troubles with PNG):
Any insights are appreciated.
Font File Format
-
Tony O'Bryan
That got me on the right track. The font is used now, but there are still issues.
Irrlicht won't load the font file if I save it as a PNG, which is unfortunate since the file is MUCH smaller than saving it as a BMP.
I get a new message when trying to load the power-of-2 BMP, but it isn't fatal:
"The amount of upper corner pixels and the lower corner pixels is not equal, font file may be corrupted."
This leads me to believe that each font character must be exactly square, so I'm going to modify my font generator to ensure that the width and height of each character are the same.
Irrlicht won't load the font file if I save it as a PNG, which is unfortunate since the file is MUCH smaller than saving it as a BMP.
I get a new message when trying to load the power-of-2 BMP, but it isn't fatal:
"The amount of upper corner pixels and the lower corner pixels is not equal, font file may be corrupted."
This leads me to believe that each font character must be exactly square, so I'm going to modify my font generator to ensure that the width and height of each character are the same.
-
Tony O'Bryan
Font Format
It took some experimenting, but I have it working. Here's what I learned:
The font image itself must not be a PNG (pity). The font loader seems to prefer BMP (ugh).
The font image must satisy OpenGL's texture requirements -- 32 bits, and a width and height that are integral powers of 2.
The first two pixels must be (255,255,0) and (255,0,0) respectively. The first pixel also doubles as the upper-left corner of the space character.
All characters, even the space, must have (255,255,0) at the upper left, and (255,0,0) at the bottom right of the character's extents.
The width and height of the font image do not have to be the same. They just have to be powers of 2. The font image can be either a single row (which is what I have done), or it can be multi-row.
The characters within the font do not have to be square, nor do they have to be powers of 2. The width and height of the characters can be any arbitrary sizes.
I think that's everything.
The font image itself must not be a PNG (pity). The font loader seems to prefer BMP (ugh).
The font image must satisy OpenGL's texture requirements -- 32 bits, and a width and height that are integral powers of 2.
The first two pixels must be (255,255,0) and (255,0,0) respectively. The first pixel also doubles as the upper-left corner of the space character.
All characters, even the space, must have (255,255,0) at the upper left, and (255,0,0) at the bottom right of the character's extents.
The width and height of the font image do not have to be the same. They just have to be powers of 2. The font image can be either a single row (which is what I have done), or it can be multi-row.
The characters within the font do not have to be square, nor do they have to be powers of 2. The width and height of the characters can be any arbitrary sizes.
I think that's everything.
-
Guest
My file gets created with Qt, which saves the file as 24 bits. Irrlicht, however, returns this error message:
"PNG LOAD: Failure - Format not supported - must be 24 or 32 bits per pixel"
If I load it into the GIMP, add an alpha channel, then resave it (making it 32 bits), I get the same error message. I'll attach the file I generated, which works as a BMP and is (except for the file format) unchanged from that version.
"PNG LOAD: Failure - Format not supported - must be 24 or 32 bits per pixel"
If I load it into the GIMP, add an alpha channel, then resave it (making it 32 bits), I get the same error message. I'll attach the file I generated, which works as a BMP and is (except for the file format) unchanged from that version.
-
Tony O'Bryan
Font File Format
What format should I be using that I'm not using already? I save the file as either 24bbp RGB, or as 32bbp RGBA, but Irrlicht insists on generating the error message saying that I need to use either 24bbp or 32bbp. I'm going around in circles.
-
Tony O'Bryan
Font File Format
When all else fails, go to the source code.
Irrlicht has a surprising flaw which is keeping my image from loading. One of the checks that the PNG loader does is to compare the bytes per line in the source file to the number of bytes Irrlicht allocates for reading each PNG line. Irrlicht hard codes the read buffer at 4096 bytes (see CImageLoaderPng.h, line 55 in Irrlicht version 0.14.0). My image is 24 and 32 bits at 4096 pixels wide. In both cases, the number of bytes needed to store each line greatly exceeds the small line buffer given the task.
The comment on that line says "// 32768", so I can only assume that the author of that module mistook 0x1000 (4096) for 0x8000 (32768). I changed the 0x1000 entry to 0x8000, and my PNGs worked.
I had assumed that Irrlicht would allocate its read buffer dynamically, but that is not the case.
Irrlicht has a surprising flaw which is keeping my image from loading. One of the checks that the PNG loader does is to compare the bytes per line in the source file to the number of bytes Irrlicht allocates for reading each PNG line. Irrlicht hard codes the read buffer at 4096 bytes (see CImageLoaderPng.h, line 55 in Irrlicht version 0.14.0). My image is 24 and 32 bits at 4096 pixels wide. In both cases, the number of bytes needed to store each line greatly exceeds the small line buffer given the task.
The comment on that line says "// 32768", so I can only assume that the author of that module mistook 0x1000 (4096) for 0x8000 (32768). I changed the 0x1000 entry to 0x8000, and my PNGs worked.
I had assumed that Irrlicht would allocate its read buffer dynamically, but that is not the case.