Torque 1.4rc2 on linux

#1 Incidentally, we're working closely with Ron to get this stuff fixed - a Linux update is imminent, complete with the unicode and font stuff at least up to a point where it's usable. (Don't want to promise too much without Ron around. :P)

I'll make sure we take a look at this! Thanks for posting it!

#2 I'll have a look at this later this evening. Currently I have the engine running with unicode fonts, but they need some ovious tweaking. You can read the fonts etc.. just the spacing between characters is off a bit and is proving to be a major thorn in the side to get right.

-Ron

#3 You using the XFD stuff or XFT to deal with the font stuff?

#4 Where are you guys downloading SDK 1.4 from?
Only thing I can see on the download page is 1.3.
I've bought a license and all that, so what gives?

Thanks.

#5 @Sorin Daraban:

1.4rc2 is the current CVS HEAD. This means you need to checkout the CVS repository for the latest code. There is a resource called Configure CVS To Download Latest Torque that may be what you need to get you started.

If you don't know what CVS is then you should probably wait until 1.4 is released as an official installer package (in which case it would be on the download page you mentioned).

#6 @Gregory,

Using standard Xlib calls: XLoadFontQuery, XCreatePixMap, XTextExtents16, XDrawString16, XGetImage and XGetPixel

Right now have an issue with getting the correct offset for each font so it looks proper when displayed. I have a few snapshots, but no hosting to put them up to share from

-Ron

#7 @Ron
Ahh that explains it, probably should use the new XFT stuff as its a tad more sane then that crusty old XFD stuff. :)

XFT Offset calcs:

top = y - glyphInfo.y;
	left = x - glyphInfo.x;
	bottom = top + glyphInfo.height;
	right = left + glyphInfo.width;

Thats the rectangle of the glyph, and

x = x + glyphInfo.xOff;
	y = y + glyphInfo.yOff;

Is the normal offset to the next glyph.

But thats really a GG call everyone _should_ be using X 4.0. I toyed around with it a bit but didn't understand how to do the leap from the xft stuff to torque renderable font. And when I investigated the Xlib stuff for dealing with the fonts well my head started hurting :) See slyvester.gxsnmp.org/torque/patches/font.patch For something I worked up to do a better job at finding a font and not crashing when the font config of the xserver is screwed up.

Theory holds that the next characters origin (offset) should be in the per_char->width of the XFontStruct, of course this value has slightly different meanings depending on the per_char->direction (positive or negative depending on right -> left vs left <- right rendering)

I host my own mail so I can take just about anysize attachment, send me a diff and I'll have a peek at whats going on. (email is in my profile)

Greg

#8 Gregory,

Can you shed some insight as to how you are getting the glyphInfo? what calls are you useing to load the font etc..???

-Ron

#9 @Ron,

Those are XFT calls, using those will update the requirements to using XFree 4.0/Xorg 6.0 or higher, not a bad thing IMHO but thats not our call thats something someone at GG will have to decide.
www.keithp.com/~keithp/render/Xft.tutorial has the comparison to the core font stuff with X.

#10 @Gregory,

Sorry I have not sent the patch I mentioned above, life has been very hectic in my world the past few days. Have had just enough time in the evening to read/reply (not always) to e-mails.

This weekend is looking decent for some serious TGE code crunching, hope to investigate XFT further and see if GG would like me to pursue a design/imp for it. Tossed Ben G and Josh W an e-mail on the subject, not sure when a reply will come. They appear to be swamped and rarely see them online these days.

-Ron

#11 I submitted this a resource, but till that gets looked at I have a 1.3 replacement that uses XFT to do the font mojo.
slyvester.gxsnmp.org/torque/patches/x86UNIXFont.cc

Only problem with it appears to be something odd going on with closing the font. If you uncomment the XftFontClose line it will do the arial fonts fine and toss a Xlib error (bad polygon??!!??) re-runing after that and it works so I'm mystified.

Other potential things that could be done with it.

1. It hard codes the dpi to a low setting (seems windows and linux have different ideas about dpi vs font sizes). Could probably make this a pref of some sort.
2. It don't specify a rgba value, which could also be a pref so that if the user is on a laptop, they set this pref and we use the subpixel stuff to get decent looking fonts there.

Thanks
Greg