Games + Slackware

Yes, something frivolous... And NO - NO STEAM games here, never.
But about installing free natural-linux games in Slackware 14.1 (64bit).
SBO = (buildscripts+source=compile)
SF = (ready binaries=install)

# Battle of Wesnoth - can be easily installed from SF, Salix. There is also option to compile it from SBO, and tuning the build specifically.
deps: It might need lua (according to SBO, but not according to SF). I had lua installed previously, so I don't know.
- Wesnoth is 'turn-based tactical strategy game'. See here for more in-depth info.
Nothing more to say - I haven't played it yet.

# Tales of Maj'Eyal - Not so easy install at all. Has to be compiled from SBO, and has a bunch of deps: premake - SBO (deps: lua), OpenAL - SF binary, SDL2 + SDL2_ttf + SDL2_image - all three from SBO.
SDL2_ttf gave me error about missing/wrong libGL. Fixed it in usr/lib64/ - changed obviously wrong libdir='/usr/lib' to libdir='/usr/lib64', and compile finished without further problems. ... I have no idea why it had such a wrong address in libdir...
- Maj'Eyal is 'roguelike RPG, featuring tactical turn-based combat and advanced character building' - see here.
The game is quite enthralling, 'just one turn more' type. It's also not easy, and has various ways to die stupidly. For example: walking in sand-tunnels without digging worm ahead; lack of attention with bosses is often strightly fatal...

# Freeciv - Install is compile from SBO. No deps. Easy-peasy.
- Freeciv is 'a free turn-based multiplayer strategy game'. Has big and quite well-stocked site.
The game has several diffrent modes and mods, including civ1 and civ2. Default mode is not especially easy - certainly for those whos experience runs only in wimpy and feebleminded civ 4 and 5.
Anyway, confs are easily hackable - for example: nations' files reside in /usr/share/freeciv/nation; and in /usr/share/freeciv/default one can find all general conf files. And they all are plain txt.
At the same time, creating a new nation - by tutorial - gave somehow buggy result...
The games' gui is not especially good and easily-usable, but as a civ-game - it's very OK.

# FreeDoom - SBO, and what you get are wads only, engine has to be get separately. And it would be mightily good, if there are old Dooms', or Heretics', or Hexens' original wads available - those are also playable with zdoom or gzdoom engines.
So, pick one of them...
gzdoom seems to be newer: SBO, deps - fmodapi.
zdoom - SBO, and has more deps - TiMidity++, fmodapi, p7zip.
- Doom is a shooter - or should I say The Shooter, at least for me it was first ever game played overnights with sysadmin and some developers (right, over 20 years ago).
Take a look here.

# Lips of Suna - Well, that installation took me some 5 hours of silly wandering around. The game has to be compiled as is, no slackbuild scripts here. For guidelines see here.
Basically, by default it installs to /home/xxx/ :
cd lipsofsuna-X-X-X
./waf configure
./waf install
Here are deps. All are available in SBO, thank god. Ogre compile, though, is long as shit.
Most entertaining was that 'lips...' didn't compile - with nicy orange-bold error. Let's cut it short and reveal my winning configure line:
LDFLAGS=-lboost_system ./waf configure --ogre-plugindir=/usr/lib64/OGRE
Part before 'configure' ensures compile, part after, that ./lipsofsuna also starts.
It bloody compiled, with one orange part (but not bold)... jeez. I am sure it wasn't worth of it. But I won the struggle! :)
- No idea what the game is about, but the word 'naked' in description got me.

# Summoning wars 5.6! - SBO. Pile of deps, for me it was - after previous games: freealut SF Slacky (deps: OpenAL), physfs SBO, CEGUI SBO, poco (deps: mysql-connector-c++, unixODBC, both SBO).
Tried to compile games' new ver.058... and no luck - cegui-084 compile crapped out with windowsy (irrelevant) message ... As this games' description hasn't any word 'naked' in it - I didn't see reason to spend more than an hour with this particular problem ... And stayed with old version - 056 - and readymade SlackBuild. CEGUI compile was slow like dead AND decomposed snail, almost like shitpile firefox ... poco was as bad - like bloody half an hour... physfs compile was short and nice. What a ... letdown..., for example ginormous gcc compiled only an hour in the same box...
a..n..d..I am already compiling sumwars! Lotsa green text! It even moves! err... slowly...! OHHHHH, it erred out, unbelievably, and for your convenience, last lines were:
collect2: error: ld returned 1 exit status
make[2]: *** [sumwars] Error 1
make[1]: *** [CMakeFiles/sumwars.dir/all] Error 2
make: *** [all] Error 2
| add next day| Fix was like that, in sumwars.SlackBuild:
-DCMAKE_CXX_FLAGS="-lboost_system -ldl" \   # added here '-ldl'.
That was that, compile finished and game started...
- 'Summoning Wars is an role-playing game'.
As all time went for compile, not for play... Only thing I can say just now - games' graphics is horrible, as expected.

| ADD |
# Naev - SBO (deps: OpenAL), two source files, naev and ndata are needed. It compiled/started with no whining...
- Naev is a 2D space trading and combat game. 
Take a look, see...

# Dink Smallwood. (Flare, Baldur's Gate)
Those three are vague future plans. If they, or something else, materialize , I ADD.

All-in-all: Native Linux games mentioned here
- look like shit of various degree,
- play good IF they are out of pre-alpha (infrequent miracle!),
- and install mostly ... like shit.
I am sure that next year is Linux-Desktop Year. :)


URxvt, Slackware, Crux = problems

Or - more precisely: Those mentioned in headline WITH Nvidia binary driver AND Compton compositor (and xorgs' version is also a player here).

So the following is obviously about the same thing as in this post - Compton and Nvidia not getting along. But - it's also a slight overview of urxvt.

I installed rxvt-unicode (exec: urxvt) as fun and games and novelty to my new Crux 3.1 (Crux home, my Crux install blah: 3.0 -1, 2, 3 and 3.1) and Slackware 14.1 (and my blah). The outcome was somewhat different in those distros.

But first, what it is this urxvt?
In essence, a terminal born from xrvt, with unicode support. And do a simple search 'rxvt+unicode'. At least two pagefuls give extremely relevant tutorials and stuff. Go.
But, just to mention:
- its' conf is in .Xdefaults (or in .Xresources if going more modern)
- it has transparency in two ways. And colors up to 256.
- it's UTF-8, of course,
- tabs and perl-extensions are configurable, among other things.

- It had lag at bottom of terminal (new-line) in both Crux and Slackware. It didn't wrap lines at all in Slackware.
- Doh.

Only problem: new line at the edge of terminal bottom - a lag of 1-2 seconds.
What I have: Nvidia binary driver 331.xx and compiled compton-master 20140729.
Problem was solved with remade compton start-line in Openbox autostart:
compton --backend glx --vsync opengl-swc --glx-no-rebind --glx-no-stencil --glx-swap-method 3 --unredir-if-possible --paint-on-overlay --shadow-exclude "! name~=''" --config ~/.compton.conf &
Magical part here is '--glx-swap-method 3'. Other is fluff what I think makes my screen look better. There is also option '--backend xr_glx_hybrid' - BUT, that gave me horrible desktop flickering.

# Slackware (and Salix), Nvidia 319.xx and the same Compton as in Crux
Additionally to lag, there was no line-wrap at all (commmand doesn't brake to next line, but acguires '>' and continues from last char...And then also kinda copies whole text to line above of last command. Very bloody confusing and obviously very wrong.
- Compton conf didn't do a thing,
- Compiling everything with Crux defs - no result,
- Copying other terminal-related confs from Crux - no result.
- Means, nothing I tried worked.

So, in Slackware, I ended up installing xfce4-terminal (deps: libxfcegui4, libxfce4util), and - lag disappeared just like that.

# Ah, yes - when digging in confs - as a bonus, I cracked the mystery of 'different looking man-pages for different users' in Crux. Has to have: export PAGER="most" in all .bashrc files. :)

# General notes about urxvt:
If dealing with .Xdefaults (.Xresources)
- might stick in Xft.dpi: 96 there too, it probably makes the console look a little less hairy.
And those -

- OB autostart - urxvt in daemon mode goes like that: urxvtd -q -o -f &

- browse all possible settings:
urxvt --help 2>&1| sed -n '/:  /s/^ */! URxvt*/gp'

- Transparencies:
# True:
URxvt.depth: 32
URxvt.background: [90]#000000
# native transpency
URxvt*.transparent: true
! URxvt*.shading: 0 to 99 darkens, 101 to 200 lightens
URxvt*.shading: 110

- Scrollbar. Have to define it, have to place it etc:
# scrollbar style - rxvt (default), plain (most compact), next, or xterm
URxvt.scrollstyle: rxvt
# and so on, look it up.

- what icon you want to see in window corner:
URxvt*iconFile: /home/myname/.icons/mytheme/apps/terminal.png

- tabs. Perl-extension thing. Has to be compiled in.
URxvt.perl-ext-common: default,tabbed
URxvt.tabbed.tabbar-fg: 2
URxvt.tabbed.tabbar-bg: 0 3 0 true

# rxvt-unicode is not bad terminal. BUT, if using real Nvidia driver  + Compton + too-new-xorg, it might not be worth the hassle. There are other terminals available - with no config-wrestling.

# PS! Compton + more new Nvidia driver = more likely there are lag-problems... I just downgraded newest 340 to 331 in Crux - as 340 bloody lagged with everything.


Icon cache refresh

Sometimes I play with icons - change them or create new ones. And most excitedly, the folder they are in gets broken/unknown icon pics into it after that.
That means - icon-cache needs to be refreshed. Many distros have a script for that which runs on startup. Or something similar - on one way or another, depends on distro and desktop environment.
But if not, one needs to update cache manually.
Basic and primitive way to do this is gtk-update-icon-cache command. That same app is used also by a lot of nice frontends. The command, in terminal, looks like that, in foolproof way:
gtk-update-icon-cache -f -t /path to your icondir - dir where index.theme is
'-f' means force overwrite old cache despite of it state, '-t' means don't worry if there is no index.theme  file.
Dandy. Yeah, but quite frequently not so - and what you get is:
gtk-update-icon-cache: The generated cache was invalid.
You also see that miscreated file starts with '.' - and it's useless as cache.
I happened to have exactly that sad outcome when trying to refresh my icon-theme cache. After exceptionally frustrating googling, I found that - in my case:
- Only thing that mattered (of multiple web-hints), was spaces in icon names. Not existence of icon-size folders, or of index.theme... or something else...
That means, of course, only that I didn't have other possible problems ... if there are more.

Anyway, I got my very big collected icon-theme validated after I removed all spaces from filenames, and nothing else (well, I also checked if my index.theme was correct. It was).

The script below (Thanks to Michael, stackoverflow) looks also to subdirs so, in idea you can run it from /icons or ~/.icons and get every spacy filename switched.
I did it in slow way - as I wanted to know where problems were. I created test-folder and copy/pasted iconfolders to there one by one, and tried to make cache again. Of course, it's easier to change the script to have 'echo' to show which files were changed... in case you are fluent in bash. I'm not, I am outright moron in it. So I did it mechanically, and found that 3 of 12 folders had 'space-problems'.
And here is the script that fixed it:

#! /bin/sh
# Script what finds spaces in filenames and replaces them with _
# to get gtk-update-icon-cache to validate.

# Change this folder according to needs
cd /home/homeros/.icons/test/mimetypes

find . -depth -name '* *' \
| while IFS= read -r f ; \
do mv -i "$f" "$(dirname "$f")/$(basename "$f"|tr ' ' _)" ; \
That was that.



As it's obvious, my posting has been somewhat lacking after May.
There are quite simple reasons for that: I seem have reached the last strech of my Linux adventures.
-- I have found two Linux distros I like and keep - Slackware and Crux,
- and so I have lost motivation for more digging around.
-- Also, I do not like at all how modern Linux development turns more and more toward way-of-Windows - sensless bloat, binary blobs, forced unification, idiotic GUI-changes... etc,
- and that means: I am going to try some Bsd's in future (if some of them happen to install this time), but probably not any new Linux distros.

... Might write about some interesting problem (related to those two 'keeper' distros), though.