First off: FANTASTIC util - thanks Secondly, the problem: Scenario: I am programming for the Wii. The Wii Texture Palette uses percentages to display portions of a texture, not offsets. So if I want to print "A" ...I cannot use x=19, y=20, w=10, h=12 To convert the x,y,w,h to texture regions you must say: topleft_x=(1.0 / texture_width) * 19, topleft_y=(1.0 / texture_height) * 20, etc. Problem: The BMF header does not contain the original size of the image - so it is not possible to calculate the regions. Solution: My request is that the BMF header file gets the canvas width & height added to it BC

Having gone to the effort to try and word that well - I have just dumped the header as plaintext and discovered ScaleH and ScaleW ...which seem to hold the CanvasHeight and CanvasWidth respectively.

Sorry for the dead post - please don't hate me :(

BC

::so much hatred::

haha jk (:

Don't worry. I'm just glad you found the solution. :)

If you have any other suggestions for improving BMFont I'll be happy to hear them.

Hi WitchLord,

Before I say anything, please be assured that the following are suggestions or maybe even requests, they are most certainly /not/ complaints or criticisms. Your util has already saved me a lot of time and effort, the last thing I want to do is risk causing offence.

But as you have asked...

The first thing I would do is make it so that when you change the font, the main character map updates immediately ...perhaps even have a little "free text" box at the bottom of the main screen which updates at the same time ...at the moment I use a.n.other app to choose the font I want before I load BMFGenerator.

Why not make the font dialog modeless (much like the Image Manager) so I can leave it open while I work? Great for when I'm starting a new game and trying to pick the right three-or-four fonts with the right "feel" :)
...In fact, I see no harm in having the Export and Visualise boxes as modeless also.

The only other change I would like to see is to make the resultant image auto-scale. But I think this would be considerably more work to do /and/ get right. I guess the dialog for this would look something like:
Width : Min [-a-] Max [-b-] Stride [-c-] [x] Float-friendly
Height: Min [-x-] Max [-y-] Stride [-z-] [x] Float-friendly
Where 1 <= a <= 65535 and 0 implies "no limit"
1 <= b <= 65535 and 0 implies "no limit"
1 <= c <= 255 such that {strideok = !(width % c) ?true:false;}
...same for x,y,z
The reason for c and z is (by example from Wii dev) image dimensions need to be a multiple of 4.

The Float-friendly box relates to my original post. When calculating offsets in to the resultant texture - if you are using a width of (Eg) 300, the resultant math is:
{offx = (1.0f / width) * x;} => (1.0f / 300) => 0.0033333333
...which is an irrational number and liable to rounding errors ...I've not cottoned the algorithm yet, but the following is a non-exhaustive list of float-friendly numbers:
{1, 2, 4, 5, 8, 10, 16, 20, 40, 50, 80, 100, 160, 200, 250, 400, 500, 800, 1000, ...}
That is: 1/n is rational
Have we got any math gurus here?

As an interface change, I don't think you have enough options to require a menu-system ...why not have a line of icons, so any option is only ever one-click away?

I hope those thoughts are read in the same good spirit as they were written - thank you for your hard work - I will post back here with links to the Wii font routines when they are ready, I'm *hoping* that'll be well before the end of September :)

BC

Don't worry so much about offending me, your suggestions are very reasonable. :)

Quote:
The first thing I would do is make it so that when you change the font, the main character map updates immediately ...perhaps even have a little "free text" box at the bottom of the main screen which updates at the same time ...at the moment I use a.n.other app to choose the font I want before I load BMFGenerator.

I see what you mean. I've already thought about adding a 'free text' box for testing the font. But the ability to see the font before actually choosing it in the font dialog would be nice too.

Quote:
Why not make the font dialog modeless (much like the Image Manager) so I can leave it open while I work? Great for when I'm starting a new game and trying to pick the right three-or-four fonts with the right "feel" :)
...In fact, I see no harm in having the Export and Visualise boxes as modeless also.

Making these dialogs modeless is not as easy as one might think. But I'll see what I can do about it.

Quote:
The only other change I would like to see is to make the resultant image auto-scale. But I think this would be considerably more work to do /and/ get right. I guess the dialog for this would look something like:
Width : Min [-a-] Max [-b-] Stride [-c-] [x] Float-friendly
Height: Min [-x-] Max [-y-] Stride [-z-] [x] Float-friendly
Where 1 <= a <= 65535 and 0 implies "no limit"
1 <= b <= 65535 and 0 implies "no limit"
1 <= c <= 255 such that {strideok = !(width % c) ?true:false;}
...same for x,y,z
The reason for c and z is (by example from Wii dev) image dimensions need to be a multiple of 4.

It's a good idea, but I think it would be difficult to implement, at least without forcing the user to wait long times for the font to generate. I may do this in the future, but before that I need to improve the performance for the algorithm used for fitting the characters into the texture.

Quote:
The Float-friendly box relates to my original post. When calculating offsets in to the resultant texture - if you are using a width of (Eg) 300, the resultant math is:
{offx = (1.0f / width) * x;} => (1.0f / 300) => 0.0033333333
...which is an irrational number and liable to rounding errors ...I've not cottoned the algorithm yet, but the following is a non-exhaustive list of float-friendly numbers:
{1, 2, 4, 5, 8, 10, 16, 20, 40, 50, 80, 100, 160, 200, 250, 400, 500, 800, 1000, ...}
That is: 1/n is rational
Have we got any math gurus here?

I think your problems with rounding errors is because you calculate 1.0f/width and then multiply it with x, instead of simply dividing x with width.

offx = float(x) / width;

Quote:
As an interface change, I don't think you have enough options to require a menu-system ...why not have a line of icons, so any option is only ever one-click away?

I agree, but a text menu is much easier to implement than a toolbar. Especially since I'm not that good with coming up with understandable icons. ;)

I look forward to seeing your Wii game. I don't have a Wii though, so I hope you'll post a video off it when it's done.

Regards,
Andreas

Quote: Making these dialogs modeless is not as easy as one might think. But I'll see what I can do about it.

Ah. All my Windows programming experience was 12 years ago at uni (I do embedded for a living now). I forgot how apparently trivial things can be nightmarish in Win32.

Quote: Width : Min [-a-] Max [-b-] Stride [-c-] [x] Float-friendly
Height: Min [-x-] Max [-y-] Stride [-z-] [x] Float-friendly

Quote: It's a good idea, but I think it would be difficult to implement, at least without forcing the user to wait long times for the font to generate. I may do this in the future, but before that I need to improve the performance for the algorithm used for fitting the characters into the texture.

The output is near instantaneous on my 2.6GHz dev machine - but I'm never going to knock a fellow coder for well-optimised code!

Regarding the algorithm - I (obviously?) have no idea how you are actually doing this, but have you seen Cushion Treemaps?
http://blog.thejit.org/2009/02/05/cushion-treemaps/
I first encountered them with the SequoiaView disk-analysis tool
http://w3.win.tue.nl/nl/onderzoek/onderzoek_informatica/visualization/sequoiaview/

Regarding canvas size:
I just noticed that BMFGenerator does not (!)Error if the canvas is too small for all the characters. I think it should :/
If the canvas is too *big* you can simply trim it after, by removing all blank pixels from the right and bottom of the image (I presume you fill from the top-left)

Quote: I think your problems with rounding errors is because you calculate 1.0f/width and then multiply it with x, instead of simply dividing x with width.

offx = float(x) / width;

Ah! Yes! Thank You ;)

Quote: I agree, but a text menu is much easier to implement than a toolbar. Especially since I'm not that good with coming up with understandable icons. ;)

I too lack the skill to produce good icons, but if you would like to go that way at some point, there are many online resources such as:
http://www.freeiconsweb.com/free_icons.html

Quote: I look forward to seeing your Wii game. I don't have a Wii though, so I hope you'll post a video off it when it's done.

My game will not be done for some time yet. But I am also a part of the GRRLIB team
http://code.google.com/p/grrlib/
...so the font routines are likely to be publicly available much much sooner.

When the Library Demo is ready I will make a video for you :) ...BTW. Do you have an Approved Logo I can use to credit your work? The howto docs for the library code already have "step 2 - download BMFGenerator" (step 1 is "choose your font")

BC

Quote: Original post by csBlueChip
Ah. All my Windows programming experience was 12 years ago at uni (I do embedded for a living now). I forgot how apparently trivial things can be nightmarish in Win32.

No, no, it's not because of Win32. It's more the complications of having user interaction while doing processing in a separate thread.

Quote: The output is near instantaneous on my 2.6GHz dev machine - but I'm never going to knock a fellow coder for well-optimised code!

For simple latin languages the output is near instantaneous, but hardly so for Chinese language. :)

Quote:
Regarding the algorithm - I (obviously?) have no idea how you are actually doing this, but have you seen Cushion Treemaps?
http://blog.thejit.org/2009/02/05/cushion-treemaps/
I first encountered them with the SequoiaView disk-analysis tool
http://w3.win.tue.nl/nl/onderzoek/onderzoek_informatica/visualization/sequoiaview/

My algorithm is nothing fancy. I'm basically just sorting all the characters by height and then adding them to the texture from left-to-right as far up as possible. This simple algorithm works remarkably well when there are only small differences between character sizes.

I have not done much optimization though, so it's doing quite a bit of unecessary checks when looking for free space.

I'll have a closer look at the Cushion Treemaps, though at first glance they seems to do the inverse than what I need. Thanks for the links.

Quote:
Regarding canvas size:
I just noticed that BMFGenerator does not (!)Error if the canvas is too small for all the characters. I think it should :/
If the canvas is too *big* you can simply trim it after, by removing all blank pixels from the right and bottom of the image (I presume you fill from the top-left)

I do not give an error, because for many languages it is impractical to fit all characters into a single texture, so BMFont needs to support multiple pages when necessary.

Quote: I too lack the skill to produce good icons, but if you would like to go that way at some point, there are many online resources such as:
http://www.freeiconsweb.com/free_icons.html

Thanks once more for the link. This one looks useful for GUI development. :)

Quote: My game will not be done for some time yet. But I am also a part of the GRRLIB team
http://code.google.com/p/grrlib/
...so the font routines are likely to be publicly available much much sooner.

When the Library Demo is ready I will make a video for you :) ...BTW. Do you have an Approved Logo I can use to credit your work? The howto docs for the library code already have "step 2 - download BMFGenerator" (step 1 is "choose your font")

BC

I don't really have an approved logo. I'm just an individual, not a company, so it would probably be more appropriate to credit me by name. :)