Showing posts with label annoyances. Show all posts
Showing posts with label annoyances. Show all posts

Tuesday, 20 May 2008

For the love of eye-candy

Compiz-fusion is lovely, it really is... spinny cube, sproingy windows, neat effects - and even some stuff that's genuinely useful when it comes to organising today's clutter of windows. In short, I like it and find it just useful enough that I'd really hate to have to do without it.

Of course, since this is a Really Cool Thing that I really like, there are some problems. And, of course, these are problems that nobody else in the whole wide world seems to have suffered from, at least as far as google can see (and I've searched and searched and searched...).

I'm actually fairly used to not finding stuff with google - generally when I have a funky problem all I can find is forum posts by other people with the same problem, and maybe something in a language I don't understand that looks like it might be relevant, but isn't.

What makes my compiz woes so much more interesting is that for once I can't even find other people with the same problems. Sure, I can find a few people with problems that look a bit similar at first glance but turn out to be quite different, and I've read plenty of those pages just in case their problems actually turned out not to be that different after all. No joy.

It's not even one thing, either. There are three major problems I had with compiz, of which one is solved, one is mostly worked around, and one continues to baffle and frustrate me. Since I had such a bad time of searching for help on these problems, I figured it was probably worth writing them up a bit. Maybe I'm not so alone after all and somebody will descend from heaven to tell me how to fix them properly. Or maybe what I've discovered will help somebody else in the same position that I was.

Just to add to the fun, I'm unable to reproduce these problems on other boxen locally, even with cloned configuration. And, speaking of configuration, the problems exist for a completely 'clean' user also, so it's not some hairy old piece of config lying around in my setup. But, of course, only on my box.

Anyway... First of all, some background info: I'm using x86 Fedora 8, which has compiz-fusion 0.6. My boxen are all AMD/Nvidia based. The specific box that has the trouble is an Athlon64 X2 5200 with 2GB of RAM and an 8600GTS card (I'm using the x86 architecture to keep things homogeneous here). My desktop environment of choice is KDE (3.5.8), but again that seems to be irrelevant - the 'clean' user has the Fedora default of GNOME.

"Problem 1, if you were an ice-cream, what flavour would you be?"
"Choc-chip, so I could get smeared all over you and leave big splotchy marks."
Problem number 1 is the solved one - a simple change to my xorg.conf file sorted this one out, but I'm getting ahead of myself.

Shortly before I started using compiz in earnest, I discovered VirtualBox and was happily using it to host various OSes for testing/compatibility/whatever. With compiz on the scene, it all started going a bit wrong... whenever the VB window resized there was heavy screen corruption around it. Occasionally the whole X server would crash. Not good, in other words. Smacks of driver/X bug, or similar. It's also worth noting that this problem isn't actually a compiz problem - the exact same thing happens with KDE's compositing manager - it's just that compiz is probably the most common compositing manager out there, and the one I had the problem with.

As it happens, as part of troubleshooting problem 2, I'd made some changes to my xorg.conf file as recommended in one of those 'not quite the same problem' forum topics. The specific change that lead to the problem seems to have been enabling backing store, thus:
Option "BackingStore" "True"
(Incidentally, that didn't make any difference to the problem). Removing that line from the xorg.conf file sorted out the corruption, and now VirtualBox is running just fine again. Yay.


"Problem 2, what would you be doing while you waited for me to get ready to go out?"
"I'd be looking at pictures of old flames."
Problem 2 is my "mostly worked around" one, for those keeping score at home.

I use the 'Animations' plugin in order to have the beam effect for minimised/restored windows, and the burn effect for closed ones. Oh, and some zooming for newly opened windows. All in all, it makes for a visually cool desktop that somehow feels a little more 'tactile' than one where windows just appear/disappear 'whole'. It gives the windows some sort of 'life', elevating them above being mere rectangular regions of a rectangular screen. And, naturally, I'm not willing to do without it. If my windows don't burn when I close them, they might as well not do anything.
So, what's the problem? Well, if I leave my box idle for any significant length of time, for instance overnight (or overday, I suppose - I tend to being nocturnal) then the next animation to be displayed gets jammed for several seconds. The length of the 'jam' seems to be proportional to the period of inactivity, and until it sorts itself out the entire X session is wedged. The effect is noticeable after even an hour or two of inactivity, but really comes into its own after a night/day or so.

What happens is that the effect begins to play, then freezes. So, if I close a window then the fire effect will render its first frame and then everything comes to a complete standstill. The same happens with the other effects provided by the Animations plugin, but not for ones provided by other plugins. My wobby windows are fine, my cube rotates, etc., etc. But that first 'animation' effect gets stuck, with 100% CPU load.

The box is still running fine while this is happening - I can ssh in to it just fine, for instance. I can't switch to a VC though - X handles that, and X is frozen until the effect finally deigns to finish playing several seconds later.

So, what's my workaround? Well, since the Animations plugin is the only one affected, and since I'm hardly likely to miss it when the machine is sitting there with the monitor off, I knocked up a little script that watches for the monitor being turned off by DPMS and disables the Animations plugin. When the monitor is turned back on, the script (re-)enables the plugin. Overall effect: problem solved as long as DPMS corresponds to idle time, which it pretty much does.

The script (and a little more info) can be found here.


"Problem 3, sometimes I feel like my clique is out of control. What alternative could you provide?"
"None. And I'd be sure to get you out of those shift dresses, too."
Ah yes, problem 3. My current Nemesis. The Unsolved One. The great Dunno. Etc.

I make heavy use of VNC: my 'media player' box runs Amarok in a VNC session, my IRC client is also running on that box and accessed via VNC. VNC is great - it's screen for X servers, and what's not awesome about that? Nothing, that's what. Sadly, VNC becomes a good deal less useful if you can't actually use it properly, say if certain mouse-clicks or key presses didn't work. And that's what's happening to me.

Specifically, I can't use the Control, Shift or Alt keys in combination with the mouse buttons. They just get ignored completely and the click happens as though I wasn't pressing any keys at all. Naturally, this makes it rather hard to do various things that require shift/ctrl/alt-clicking/dragging something - and there's actually quite a lot of things like that, as becomes abundantly clear when your ability to do them goes away.

My VNC client of choice is the standard RealVNC vncviewer as installed from the Fedora repos. Before compiz all was well, but now no modifiers. Naturally, I've tried some other VNC clients with mixed results. TightVNC has the same problem, but a really old tightVNC client I have lying around for some reason doesn't. Vinagre doesn't have the problem, either, but it's not really useful for how I use VNC.

So currently I'm stuck using an old tightVNC whenever I think I'm going to want to shift/ctrl/alt-click /drag anything, which sucks.

Try as I might, I can't get the other F8 box here to behave like this - it just works there.

Gah.

Friday, 14 December 2007

Hosting UT3 games... a truly daft solution!

Update: it now seems that one can simply remove the STUN server address in the ini file in order to get rid of the message and host games successfully. I.e. change "StunServerAddress=stunserver.org" to "StunServerAddress=" in UTEngine.ini

So... read on if you like - there's info there on what the error message actually means, and why it's totally stupid - but the solution below is now even dafter than before ;)

(end of update)

Well, last night I finally got sick of that stupid UT3 error message telling me that my NAT was incompatible with hosting games, and that I should check my router's manual about setting up 'port forwarding' and 'DMZ'. Oddly enough, you see, I actually know all about that. You'll also note that at no point does it bother to mention which ports need forwarding, making this particular error doubly crap: it's misleading as well as eroneous.

Anyway, all this malarky started when Patch 1 beta 1 was installed, and one of the things that patch did was to add STUN support for hosting games behind NAT. None of the later betas or the final patch have improved matters in this respect, BTW.

Now, you may well be wondering what STUN is and why it's useful in this context. I know that I was. And, quite frankly, I still am. STUN (more info here) basically just lets an application find out the machine's public IP address (i.e. the address that the NAT results in) and what sort of port-forwarding is in operation. OK - so far, so good.

Where it all goes a bit wrong is that if, like me, you're behind a 'restricted' NAT (and you probably are, if you have any useful sort of NAT at all - especially the type that acts as a very primitive 'firewall') then UT3 throws its chubby little hands up in despair and gives that error message. Even that isn't the real problem, annoying as it is. No, the real problem is that UT3 then will not let you untick the 'LAN' option when creating a game.

STUN might be useful for some things... but in this context, it really doesn't help.

So, like I said way back at the beginning of this entry, I'd had enough. If UT3 wanted to use STUN to annoy me, then I figured that I'd also use STUN to shoot that stupid error down.

I'm on a LAN here, which is why I have NAT in the first place. And on that LAN I have a linux box, ee-i-ee-i-oh. Well, actually I have quite a few linux boxes, but just one will suffice. You can certainly do what I'm about to describe using windows, and even on the same PC as you're running UT3 but, since I haven't tried that yet, I'll stick to describing what I have done.

I've set up a STUN server on the LAN, is what I've done. It's not visible to the outside world, which makes it utterly pointless as a STUN server since the only applications that can query it are also running on machines on the LAN, and thus the result will always be "open internet" (unless some firewall rules on the box(es) interfere, of course). Just for added value, the STUN server isn't even configured quite properly either.

I'm sure you can see where this is going ;)

So now my UT3 is configured to query the local STUN server, which leads it to believe that it has a direct connection to the internet with no NAT. UT3 then quite happily hosts games because, coming back to the original point, I have read my router's manual and set up 'port forwarding' properly (screw using a DMZ - that's way beyond what's actually required).

BTW, hosting games matters to me because the only way to really enjoy the single player campaign is to play it multiplayer. Yeah, I know. But then using a STUN server on the LAN makes no sense either. I'm getting almost used to that with UT3 now.

OK, so here's the juicy details, step by step, of what I did:

  • Download the STUN server/client from here
    Obviously, I downloaded the source and compiled it. If you're using windows, you'll probably want the precompiled windows binaries.

  • The STUN server wants to use two IP addresses on the box it's running on. Luckily, by stretching the point a little, you already have two with no need to muck about: your ethernet interface & the loopback interface. In my case, those IP addresses are 192.168.3.86 and 127.0.0.1, so I run the server like this:
    ./server -h 192.168.3.86 -a 127.0.0.1 -v
    (that -v is just for verbose output so that I can see what's going on).
    NB
    you do NOT need to be root to do this.

  • Check that the server is 'working':
    ./client localhost
    That should return "Open".

  • Next up is editing UT3's configuration to tell it to use the local server instead of stunserver.org (the default). This is set in UTEngine.ini, which you'll find in My Documents\My Games\Unreal Tournament 3\UTGame\Config (phew). Searching that file for "stunserver.org" is probably the easiest way to find it. Replace stunserver.org with the hostname (or IP address, I guess - I haven't checked that) of the machine your STUN server is now running on.

  • Now you need to actually forward the relevant ports from the outside world to the machine that you're playing UT3 on. All the ports are UDP and their numbers are:
    7777, 7778, 7787, 6500, 13000, 27900
    Disclaimer: I'm not 100% certain that all of those ports are required. Some of them probably aren't. I arrived at that list thanks to enough trial and not enough error, i.e. it works with those ports forwarded, but I haven't tried closing them to see what makes it break ;)

  • Enjoy public, non-LAN games! I know that I do :)

In conclusion: my 'solution' is hacky, dumb and should never have seen the light of day. Much like UT3 in its current state. -- zing! --

Wednesday, 5 December 2007

zomg UT3 is teh sux0rz :( Epic FAIL.

Sad, but true: UT3 is 90% suck.

The eye-candy is spot on, for the most part: it does look very pretty indeed. Certain elements of the game's looks have come on in leaps and bounds - vehicles, for instance, look pretty frickin' sweeeet now. The maps are detailed and gorgeous to look at. The characters are pretty good looking too, although their animation still looks clunky and cartoonish.

Over all, visual quality is top notch. Indeed, reviewers everywhere seem to have noted this and heaped praise upon it, and for good reason.

Sadly, there's very little else positive to say about it. Vehicles (for the most part) handle a lot more like vehicles and less like bricks. That's good. Some have fared better than others in the "upgrade" though.

Scorpions have received possibly the most mixed blessings of the "upgrade"... Their blades are now at the front, making them look like Scorpions in an "Oh, yes! Now I see it!" kinda way. On the other hand, they no longer fire those tricky to use (but powerful) energy string jobbies. Now they fire frickin' Oreo cookies. I mean, really.

Not that those Oreo cookies aren't deadly. In fact, on higher difficulty settings in the Campaign mode you'll be hard pressed to find an instance of a bot missing its target with them. Ah, let me rephrase that: you'll be hard pressed to find an instance of an enemy bot missing. "Your" bots, your team, your AI chums... ah, not so much. Turns out that they're semi-catatonic retards.

That bot "AI" is a real bastard. UT3 has four difficulty levels: "Easy" (i.e. walkover), "Normal" (i.e. tricky at times, but not that hard), "Hard" (i.e. massively frustrating) and "Insane" (which I have yet to try, but based on previous experience I'm not expecting it to be even remotely possible).

Here's one of the things that's wrong, and really badly wrong: no matter how good you are, you'll struggle on "Hard" difficulty because your bot team mates are so mind-numbingly retarded that you'll wish you could teamkill them. If you're anything like me, once a match is beyond the point of no return, you'll spend those last few minutes (in overtime, natch) contriving ways to punish them. For some reason, the enemy AI seems to be spot on, however.

Time after time after time I've seen my "team" doing such retarded things as:
Dropping the flag (knocked off a hoverboard) and not bothering to pick it back up but just running back to base without it.
Deploying the Leviathan in a location where it simply cannot see anything it might want to fire at, such as nodes, cores, or even enemies. Hell, I'm sure that they only deployed it there (FOUR times in one particular match) because they couldn't figure out how to wedge it somewhere so stupid so that it was unrecoverable.
Picking up the orb right next to a critical node, and then running away with it. Go bots! That'll stop the enemy in their tracks.
Sitting in powerful vehicles firing shot after shot into the walls/floor. Keep it up bot, I'm sure that the seven-hundredth shot into that wall will actually hit whatever the fsck it is that you think you're targetting.
Jumping in the path of my just fired rockets/flak causing my messy death and a cry of "same team!" from them.
Taking the enemy flag and yelling "I'm under heavy attack here!" for as long as they live. You know why they're under heavy attack? Because the retards haven't even tried to leave the enemy base.
Sometimes they do try to leave the enemy base. But then tragedy strikes! Maybe they left their wallets in there, or something, because right back in they go! One time the retardobot made it all the way back to the flag stand, no mean feat I might add - and only thanks to my covering fire.

I'll not get into the whole "trying to cast a tournament game as a single-player 'story' like game" thing. The story kinda works in the sense that it more or less justifies the series of tournament games you actually play. I could have done without the cries of "fo' shizzle" and "you da man, daaawg", etc. mind you. What really spoils the "story", such as it is, is that it's short. Oh, and it has a blatant "sequel" ending on a par with Merchandising, oops, Pirates Of The Caribbean 2. After fighting both annoyingly good enemies and amazingly bad friends to get that far, you deserve more.

OK, so single-player kinda sucks. The single redeeming feature of UT3 over 2k4 in this regard is that you "can" now play the campaign through with your friends (or even complete strangers on the internet) replacing any/all of the bots on your team. That alone fixes the single-player campaign, by making it not single-player. Oh. Um. Errrr.... And, you see how I said "can" with the quotes and everything? Well, that's because it's supposed to be possible, but might not work out so well. My UT3, for instance, fortified as it is with the 1.1 beta 1 patch simply refuses to let me host anything because it's got some insane notion that my router doesn't have port-forwarding enabled properly for UT3 (which it does).

Anyway, enough "single-player" bitching.

Sadly, multi-player is annoying as hell too.

UT2k4 requires finesse... you have to flow around the maps... UT3, well... the vehicles might not move like bricks now, but the players certainly do. It feels like UT99 with lead boots on. There's no fluidity at all.
I read one review where the reviewer liked this because it meant that movement was no longer a vital skill in the game. Really.

Then there's the changes to the weapons... they feel nowhere near as meaty as they did in 2k4 (or even 99). It's a bit subjective and hard to pin down, but they just feel more tacky.

We've lost Assault, Onslaught, Double Domination, and Bombing Run and gained... Warfare. Okay, so WAR is supposed to be a mishmash of AS, ONS, and, to a certain extent, 'classic' DOM - and for the most part it is. But BR is just gone. *poof* It's a crying shame since BR is one of, if not the, most skilled gametypes in the 2k4 collection.

Movement, strategy, teamplay, thoughtfulness under pressure - all are vital to success in BR. And all seem to be playing a dim second-fiddle to the eye-candy and "mayhem" of UT3. This is most obvious in the WAR gametype... AS and ONS both required finesse and skill. In WAR the orbs turn the whole game into a much more frantic, deathmatch-like experience. The same's true of the translocator in CTF - it sucks now. Yeah, you can get around with it, but it no longer requires skill and finesse to use effectively, because you simply can't use it anywhere near as effectively as in 2k4.

I would say that UT3 is the UT2003 of 2007, but that would be being unkind to UT2003. Sure, UT2k3 was a massive leap forward in graphics quality, just as UT3 is, and yes it also sucked, just as UT3 does... but
oh boy does UT3 suck.

You might have noticed that I haven't mentioned the menus and UI at all so far. There's not anything in particular wrong with them, honestly. There's everything wrong with them. They're an abomination that should never have seen the light of beta-testing, never mind release. The only thing that's any good at all about them is that they whoosh around in a quite unnecessary manner. For that matter, that gets old pretty damn quickly and goes from being 'good' to being a bloody pain.

The whole GameSpy ID thing is a damn nuisance too, and adds nothing to the experience. Sometimes it completely replaces the experience with a login failure, for instance. Other times you might think that it's logged in OK only to find that your "Friends" list is now empty. Turns out that it isn't logged in anymore. No idea why. The only positive aspect that I can think of is that player's names will now be unique. Having been impersonated in the past (and by a foul mouthed, racist bot at that) I'm all for there only being one {R$A}Adny, however it's really not worth this much hassle and frustration.

Even the sound is a pain in the ass. There is no comfortable setting for volume. Everything is either too loud or too quiet. The announcer overwhelms everything.

Speaking of the announcer, one of the improvements in UT3 is that announcements now get 'queued' so that they don't get lost. On the face of it, this is a good thing - it always bugged me in UT2k4 that getting a killing spree, etc. with a headshot (very common for us snipers) would basically seem to pick which of the two announcements to play at random. Where this goes horribly wrong is when there's a lot of announcements quickly, and/or when some of the announcements are important and 'time-limited' in their usefulness. OK, a "killing spree" is nice to be informed of - but the enemy flag is probably more important. Throw in that bots' messages (and therefore presumably other players') get queued as well and you have near zero chance of a message concerning the flags, etc. actually being meaningful when you hear it. You can, of course, by means of fragging real hard manage to get so many announcements queued up that the pain never seems to stop. Yay. Bear in mind that the bloody announcer is so damn loud that it's overwhelming. Wonderful, it isn't.

Auto-taunts are a pain. Seems like every 13 year old prat just wants to sit and hammer those "taunt" keys at the end (or even during the normal gameplay) of a game. This is, to say the least, annoying. At least in ut2k4 you had some control over which taunts got played... fresh out of luck in UT3 - yet another feature lost. Maybe there's a cryptic ini setting you can twiddle - it's hard to tell, frankly. But I'm extremely annoyed that I even have to think about ini files in this context.

Something I've noticed, switching between UT3 and UT2k4 is that in UT3 everything is "bigger" and more cramped. It's all huge, pretty and in-your-face. Even the menus are 'designer' and intrusive (which is no mean feat when you consider that what they're intruding on is, in effect, themselves). Playing a game of 2k4 after UT3, all the characters look small and the corridors look massive. You know, with room to move.

My overall feeling about UT3 is that it is an epic failure. Epic/Midway have basically turned the magic that is Unreal Tournament into Yet Another Crappy Console Shooter Game. But, oh my, it is pretty. Sadly, pretty though it is, it stinks.

One word review: FAIL.

Thursday, 22 November 2007

Sound issues (or doesn't, as it happens)

Well, it looks like I hadn't sorted my sound problems out, after all. Today when I started KDE I got that old corker: "CPU overload" and artsd quit. It did this several times, pummelling the CPU as it did so, of course.

"Enough's enough," I thought (well, in between the obscenities there was probably a couple of "enough"s, anyway).

I have a sound card that handles mixing in hardware. ALSA supports it quite nicely, so why am I having problems? Why does sound lag in KDE unless I set arts to use ESD (which leads to a slightly shorter lag rather than a full cure)? Why do I keep seeing things like "connection refused" when things try to use sound? Why is artsd suddenly burning up my CPU? Was there a second gunman?

All this trouble started with the new machine and new OS combo. As far as I'm concerned, I should be golden: I have a properly supported sound card (Audigy 2 ZS, SB0350 if you care) and I know from past experience (with SuSE / Fedora Core 6 + SB Live!) that this setup should "just work". For that matter, I have an SB Live! in another box that should also "just work".

So I'm looking squarely at Fedora 8 "Werewolf" as the culprit here... and Fedora 8 installs/uses Pulse Audio by default. Think you're using ALSA? Well, think again: the "default" device is... "pulse".

Maybe Pulse Audio will eventually be the answer to our prayers and bring Linux sound support bang up to date and even beyond the competition... but right now I just want rid of it so I can go back to my cosy ALSA world.

One quick "yum remove pulseaudio" later, which for some reason also took "kino" with it, but nothing else that wasn't an obvious part of the pulseaudio system, I was feeling a little happier. OK, so my sound was more broken now than before (OSS was fine, but ALSA was in trouble), but at least I'd taken some affirmative action and kicked some package butt.

Looking into the ALSA thing (strange that ALSA's OSS emulation would be fine, but ALSA itself wasn't, eh?) I was seeing "connection refused" errors. "Connection"? Ah... let me guess, it's still trying to use pulseaudio, isn't it? Yep. "Kino" might be so heavily dependent on pulseaudio that it had to be removed at the same time, but alsa-plugins-pulseaudio wasn't. Once more unto the yum: "yum remove alsa-plugins-pulseaudio"

And now I'm happy.

Let's see how long it lasts ;)

Tuesday, 13 November 2007

I hate "upgrades"

The new box is built and working... so that means that it's time to install Linux and settle in. Naturally, the distro I'm currently using is being end-of-life'd very soon, so it's time to upgrade. Should be good, right? Shiny new hardware to run a shiny new Fedora?

Well, it isn't.

There's always some gotchas when moving from one distro to another, even when moving from one version to another. It's not that I expect things to just magically "pick up where I left off", or anything. I'm quite happy to do a little tweaking to bring things back to how I like them... but this "upgrade" has frustrated and annoyed me quite enough already - and I've barely started the process.

Sound support has always been a problem for me in the past, so naturally that was one of the things I was most concerned about with the new machine. One "quick" Fedora 8 install later (after one slow, painful failure to install - you'd think I'd have learnt by now not to add repos until after the initial installation, no matter how much the installer tempts you to) I was ready to go.

I'll skip the sorry tale of "The i586 Driver Packaged As An i686 One" because it's not terribly exciting. And besides, if livna didn't screw up at least one nvidia driver package for each fedora release people would start to think they'd got the wrong repo, or something.

I created a user (I'll move my own stuff in later, so just a test user for now) and logged in.... to be greeted by GNOME. Hmm. I don't like GNOME, and I keep forgetting that Fedora just adores it for some reason, so of course it's the default session type. Oh well, never mind - it's not exactly rocket science to select a KDE session instead, which I did. Safely back in my KDE desktop I opened up the Control Centre's soundsystem module and, with baited breath, clicked the "Test Sound" button... and heard nothing. My poor little heart sank.

And then suddenly the test sound started up. "Oh!" I thought, ever the optimist - heart in boots or not, maybe the sound system just took a while to start. So I tried it again. Same result. A little more testing confirmed that sounds did indeed play just fine - but about 2 seconds after they should have done. So I tweaked arts options a bit, but to no avail. It just wouldn't start playing sounds until it was good and ready to. Grrrr. Mr Google didn't have anything useful to say (at least not in english - I have no idea what all the non-english results said, but the fact that almost all the results fit into this category should provide some insight into just how little google had to offer. So, thoroughly miffed, I went to bed. It was, after all, 6am by this point.

Next day... Since I wasn't convinced that arts wasn't indeed the culprit, I tried sound in GNOME... and it worked perfectly. So arts was the problem. Bah. Some very careful googling turned up a page that mentioned in passing that you can make arts use the new PulseAudio wosname for sound by setting it to use the ESD, which I tried... and it worked. Sounds are still lagged a little (thanks to arts' buffering) but that's as good as it gets in KDE, so "W00t!"

By now I was getting annoyed at the fonts looking less than perfect, so went to turn on subpixel antialiasing with full hinting... only to find that I simply couldn't. The subpixel antialiasing tickbox was greyed out. Oh joy. So, having learnt from my sound tribulations, I gave it a go in GNOME... and whadayaknow, it worked just fine there. Shame I really don't like GNOME, huh? But I prefer KDE, seemingly in spite of Fedora's efforts to make it painful for me.

I'm well aware that subpixel AA and hinting are things that might be covered by patents, or some other such crap, but that never stopped me being able to use them in FC6... or in GNOME in F8. But in KDE, "The computer says 'no'." I checked the livna repo and there's a freetype package there, so I installed that... and now I can select subpixel AA in KDE, making me 'teh winnar!', or something.

Since I was clearly on a roll, I copied my homedir from the current box to the new one. OK, I expect some problems when keeping an old set of config files, etc. but generally it's not that big an issue and things get sorted out in short order.

And yet... and yet... My fonts still didn't look right. It wasn't the DPI - I'd already taken care of that. It wasn't the hinting/subpixel settings or any such, either. No, it was that they don't bloody exist according to anything I ask to find them. They're displayed on the screen, messily, but they're simply not in the list of fonts I can choose from. A little prodding later, I discovered that apparently "DejaVu LGC Sans Condensed" simply shows up as "DejaVu LGC Sans", exactly the same as "DejaVu LGC Sans" does. So, no "... Condensed" font, just the plain one. Which means that for all my config is specifying the font I actually want, and the system is using it, *I* can't select it. Worse still, the hinting on the font as displayed is messy. Looks like I lost my 'winnar' status.

Mr Google didn't manage to help me out here, either, BTW.

So here I am, using fonts I don't really like because that's better than the mess I get using the one I do like (and I use "DejaVu LGC Sans Condensed" *everywhere* - or, at least, I used to... sniff). My sound is working, as best I can tell, so that's a bonus... But still, it's taken me two long days & nights to get this far.

Hooray for "upgrades".

Now I've vented, I suppose I should get back to finding all the other problems and, hopefully, fixing them.

Bah.