Are there any volunteers for fixing vfdlib on v3.00?
It does not seem the original author, Richard Kirkby
is on this board.

The rendering of text using this library does not seem to work
anymore with the fonts supplied with v3.00-alpha3.

As a workaround one could probably copy the old fonts
to a separate location and use those, but this is tedious.

Pim

Richard hasn't posted since February (his BBS name is kirkis) but he's always been good about responding to emails. I spoke with Tony F. yesterday about this font issue and said that if the Empeg guys could provide me with the specs for the new font format, I could give it a go.

Yeah, I suspect that what happened is that 3.0 has revamped the font files to use unicode, so if you re-use the player fonts in VFDlib, the 3.0 fonts won't work. The solution would be, as you said, to upgrade VFDlib to support both possible font sets and autodetect which is present. We need only to know the spec for the new font files, and I've already placed a request for this with The Guys. They're pretty busy with some Real Life deadlines right at the moment, so I wouldn't expect a reply immediately.

There's no chance that someone could simply look at the new font files and reverse-engineer the spec, is there? Maybe it's as simple as "the file format is the same, you just have a larger unicode index instead of an 8-bit index"?

There's no chance that someone could simply look at the new font files and reverse-engineer the spec, is there? Maybe it's as simple as "the file format is the same, you just have a larger unicode index instead of an 8-bit index"?

Possible, but more difficult, and if the team isn't in a hurry to release 3.0, I'm not in a hurry to fix vfdlib for 3.0. I'd rather have a spec in front of me than count on Doing the Right Thing with reverse engineering. Or at least someone with a blue nickname to say exactly what you just said about a larger unicode index.

If I recall correctly, the new fonts are smaller. So they might
be encoded more efficiently, while supporting larger character
sets at the same time.

According to this thread, the character sets haven't grown, though.

Pim

Your analysis would seem to be correct about new fonts being more efficiently encoded:

17588 large.bf
15626 large.bf.new
9272 medium.bf
8502 medium.bf.new
6500 small.bf
6102 small.bf.new

My guess is that efficiency comes at the expense of ease in decoding, but I'm sure it's not rocket science.

There's no chance that someone could simply look at the new font files and reverse-engineer the spec, is there? Maybe it's as simple as "the file format is the same, you just have a larger unicode index instead of an 8-bit index"?

I'm sure there's a chance it could be done, but I bet most of the people who could do it are either busy or insufficiently special.

Well, I'm not the best reverse-engineer on the planet, but I can find no obvious file format for the new files. If anyone else wants to try, be my guest, but unless someone can get me a format spec (or the old spec and tell me what the differences are) I won't be the one patching vfdlib.

Cool, thanks for trying.

And by the way, I sent Tony *just* the font files, not a full copy of 3.0.

And by the way, I sent Tony *just* the font files, not a full copy of 3.0.

Rub it in why don't you.

This is a bad week to ask for, well, pretty much anything - but hopefully next week I can dig out the font spec. I also don't mind if someone sends 3.0 to Tony for app fixing purposes.

Rob

Thanks, Rob.

Hi Guys,

I'm still around but have zero time to devote to empeg development. I couldn't even begin to try fixing the problem without v3.00 anyways.

If someone is kind enough to take on the task of doing the fix I'd be happy to put it into a new vfdlib release.

Richard
--

Apply the attached diff. Enjoy, people lucky enough to have the rest of the alpha

And actually, in fairness, it's not done. I'm still trying to figure out what the deal with the last 32 characters is.

In order for this to make sense, see previous patch.

unk2 is an offset. At that offset appears to be a table, which appears to be a pair of char for each entry. I'm not sure what the purpose is, since it appears the first char in the pair counts up from 0, and the other is always 0.

At least, looking at 13pixel.bf and large.bf both seem to indicate this.

Hm. Looking at 13pixelnumeric.bf, I guess the table is actually one which tells us at what offset to fill in the character.

Ok, a little more coding...

Hm. No, I understand now. Finished fix shortly.

Ok, this one should deal correctly with the packing. It appears to work with the v2 and the v3 fonts I have. It's not clear I have all the v3 fonts.

Hey that's great! Unfortunately I won't be able to try it out, as I'm just packing for a short holiday trip to the US (Chicago & New Orleans). I will certainly make a new build of my vfdlib-enabled rsync port when I return.

Thanks,
Pim

Actually, I was lying in bed thinking about it, and there are still 2 bugs. I'll try to get a corrected patch out before I leave for Ohio.

Actually, I was lying in bed thinking about it, and there are still 2 bugs. I'll try to get a corrected patch out before I leave for Ohio.

Great stuff! I had planned to restart emphatic development soon so I'll give this a shot once you've got the bugs worked out.

One is easy. free(cOffset); before the font register routine returns.

The other should also be easy, I'm testing it now.

This one won't write into random memory it shouldn't when it finds a character that shouldn't be mapped.

In reply to:

---

I'm just packing for a short holiday trip to the US (Chicago & New Orleans)

---

New Orleans OK, but holiday in chicago?

From what I hear, it's a toddlin' town.

I saw a man, he danced with his wife.

Okay, vfdlib (as written) doesn't seem to be working for me with 3.0 fonts. Here's where vfdlib_registerFont bombs out:

  if (bfHeader.version == 2) {

    fseek(fp, bfHeader2.offset, SEEK_SET);

    if (fread(cOffset, sizeof(CharOff), totalChars, fp) < totalChars) {

      fclose(fp);

      return -1;

    }

  }

.

I threw in some debug and the fread() call seems to be reading 115 chars, and totalChars seems to always be 200.

I tried having it continue on regardless of what fread() returns, and after everything loads up, this is what I get in emphatic:


The characters all seem to be formed properly (individually) but the character map seems out of place... Watching lyrics scroll by looks pretty funny.

Any idea what's up? I'm using small.bf, medium.bf, and large.bf (the 3.0 versions.)

I'll look later. Maybe when I cleaned it up I broke something.

Oh, sh*t.

It works when I run gpsapp_host on a PC, and fails in the way you describe on an empeg I dropped the fonts on.

Ok, I know why, and given what I was thinking earlier today it makes sense. It's not a table of 2 chars, it's a list of shorts, so presumably it is some encoding supporting more than 256 characters.