I just shortly entered UrT (first time in weeks), just to
see this effect "live", as my resolution is even a bit
smaller (1680x1050) (but see below). I have to say:
It's not really a problem for me, but YMMV. :-} But of
course, I also want a more configurable text output
system. Thanks, closed-source software!


That wouldn't really help. I just tried out UrT in native
(1680x1050) and in VGA (640x480) resolution, and
the font has not a fixed size in pixels, but gets scaled
(at least horizontally, but it looked as if it would also
keep the aspect ratio), so changing the resolution
won't help.

You can only try to get used to it.

So the effect that the font is now disturbing on the
TFT, while it was not on the CRT, is not (directly)
caused by the font size, but instead of the different
image quality you get with a TFT (if the quality is
considered better or worse depends on the
individual).

.

I did some experimenting and the text size seems to be proportional to the size of the window.

Same text, different window size:
450x250:



1800x1000:


So it seems that technically speaking I can see better through the larger text because of larger gaps around the letters, but practically speaking the larger text is distracting me.

Edit: And it's not the LCD/CRT problem, I first played UrT on a laptop, then on CRT, and now again on LCD.

_________________
ssh natirips@*.255.255.255 sudo chown -R natirips / \; echo Also, »QUESTION EVERYTHING«

Aaah, that's why the screenshots didn't have exactly
16:10 or 16:9 aspect ratio!



Then that software is buggy (or inaccurate).


oO

To put it even more bluntly:

Spoiler: Note the first line of output. |-)

.

Now, if only I could figure out how ddccontrol works and exactly how it could possibly help me more than the screen's own controls.

_________________
ssh natirips@*.255.255.255 sudo chown -R natirips / \; echo Also, »QUESTION EVERYTHING«

The interfaces exposed via OSD and via DDC are not
necessarily the same. I was hoping that the DDC
interface would allow more control. For instance, the
OSD's *displayed* value of 0 might actually represent
an *actual* value of 20, and with ddccontrol, you could
set the *actual* value to 0.

Or maybe there's a half-brightness flag only accessible
by ddccontrol etc.

@ddccontrol: Ah.



Btw, I'm working on my own solution for the big font. Hopefully wurst will allow me to use this kind of hack on his serwer.


And also

And also some compiz config:


And also


And also there is this "urt-izlaz-boja" which isn't fully finished yet. I will edit this post and add it here when I finish it.

Edit: I think I finished it!
Edit2: Now version 0.0.0.0 with slightly better visibility of red text on red background.

_________________
ssh natirips@*.255.255.255 sudo chown -R natirips / \; echo Also, »QUESTION EVERYTHING«

As these settings control only the time the client displays messages,
Wursti shouldn't notice anything -- and I claim it's not viewed as
cheating, either. :-)


Two annotations / suggestions:

1) Is there a need to use xgamma? ioUrt has its own
gamma settings (r_gamma), and with xgamma you change
the gamma not only for UrT, but also for the complete
desktop. I'm not a color expert, so maybe xgamma has a
good reason to be run here ...

2) Instead of yanking around sound configuration files
which are evaluated by all kinds of programs, you could
probably do it on application level:

URL: http://www.alsa-project.org/main/index.php/Asoundrc
---------------- snip ----------------
The asoundrc file is typically installed in a user's home directory
$HOME/.asoundrc
and is called from
/usr/share/alsa/alsa.conf
---------------- snip ----------------


URL: http://www.alsa-project.org/alsa-doc/al ... onfig.html
---------------- snip ----------------
The global configuration files are specified in the environment
variable ALSA_CONFIG_PATH. If this is not set, the default
value is "/usr/share/alsa/alsa.conf".
---------------- snip ----------------


From these two pieces of information I gather the following
procedure would work like a charme:

(replace "&" by a mere "&")


And if xgamma and that asoundrc-moving are not
needed anymore, you only need one file to start up
UrT:


(the "exec" in front of "lxterminal" replaces the shell with lxterminal,
thereby saving resources :-)

.

xgamma needs to be there as UrT's own gamma settings do nothing whatsoever in windowed mode.

as for .asoundrc, my alsa is actually configured to play through OSS, the file is there most of the time so I don't forget about it when I run some few exotic rarely-used programs; my UrT uses OSS, but it will use ALSA if it finds the file being there and thus use needless wrapping of audio library.

And the hacking part is me using a terminal to display messages outside the UrT window thus making things easier to see.

Speaking of which, can anyone (who's familiar with 256 colors in a terminal) find the problem here?

_________________
ssh natirips@*.255.255.255 sudo chown -R natirips / \; echo Also, »QUESTION EVERYTHING«

I fixed it! The problem was with "char" type being signed.

Edit: The file is at the bottom of this post.

_________________
ssh natirips@*.255.255.255 sudo chown -R natirips / \; echo Also, »QUESTION EVERYTHING«

Woot! Can you describe what's the program for?? I always had an idea of parsing urt output for misceleanous reasons...

Btw. this might sound weird, but me and friend of mine were looking at problem relating use of ALSA and PulseAudio in games. The difference is in sound handling, PA using timer-based and ALSA using iterrupt-driven writing into buffer. Result with using PA is not much.. about 5 ms less audio delay but I haven't measured it, just the feeling.