Tips for the SL Linux Client

Since we are all expert in using the SL linux alpha client, I thought we oldbies could give some tips for newbies in a separate thread.

Tips I have had so far:

Getting the Video Memory used;

the full list is in /263/05/85822/1.html

quote :

Also the variable for the option above are (settings.ini)

GraphicsCardMemorySetting 0 for 16Mb
GraphicsCardMemorySetting 1 for 32Mb
GraphicsCardMemorySetting 2 for 64Mb
GraphicsCardMemorySetting 3 for 128Mb
GraphicsCardMemorySetting 4 for 256Mb
GraphicsCardMemorySetting 5 for 512Mb

Getting the resolution from 800 x 600 to something usable;

a) switch the client to Full Screen Mode in the normal preferences;
b) choose your resolution

(not from me; I read it here but can't find it)


EDIT: added 30th August 2006 since it seems to be so useful:

OLD and broken: url from browser: http://forums.secondlife.com/showpo...382&postcount=6

NEW: url from browser: /263/f4/88482/1.html - whole thread, the old URL ist broken.

Exact Post for Mozilla: /263/f4/88482/1.html#post896382

Thanks to Signore Iredell for pointing this out Instructions for Mozilla and Opera are included.

settings.ini for graphics memory, debug, etc: /263/05/85822/1.html, first few posts

wiki for lots of wine stuff: http://stux.wikiinfo.org - seems to be down right now

Secondlife command line options:

http://secondlife.com/badgeo/wakka.php?wakka=newview

EDIT end

Anyone else got any?

For debug menu add following to settings.ini

UseDebugMenus TRUE

More settings.ini changes

For AGP acceleration (only try on nvidia)

RenderUseAGP TRUE

For Ripplewater (only try on ati 9500+ or nvidia 5200+)

RenderRippleWater TRUE

For local lighting

RenderLocalLighting TRUE

For anistropic filtering

RenderAnistropic TRUE

For shadows

RenderShadows TRUE


Some of these may just not work, i can verify, local light and shadows as working, anistropic and agp dont for me, and my card isnt capable of ripple

There's a tip note from the folks running the Furnation realms:

Preferences: General tab
Show Names: Show temporarily

Network Tab
Maximum Bandwidth: Max it out.
Disk Cache Size: Ditto

Graphics Tab
Performance Options:
OFF: Ansiotropic Filtering, Local Lighting, Shadows.
ON: Disable Far Clip, Shiny Objects*
(*turn this one off if there's too much lag)

Avatar Rendering: Normal
Terrain Detail: Full

Adv. Graphics Tab
AGP Acceleration: ON
Texture Cache Size: Max it out
Video Card Memory: What you have (Edit settings.ini)
Object/Tree/Avatar detail: Futz around to what you're comfortable with
Avatar Vertex Program: ON
Draw Distance: 128 or less
Fog Distance: 4.0
Drop Draw Distance: DISABLED
Bumpiness Draw Distance: 10 or lower
Max Particle count: 1024 or lower
Outfit Composite Limit: 10 or Lower


DEBUG SETTINGS -- SEE ABOVE TO ACTIVATE DEBUG MENU
Turn off:
Rendering > Types > Clouds
Rendering > Features > Fog
They say these effects are composed of particles and lag the client badly.

Not a tip but more of a suggesgion, the following tests are usually used on the preview grid, you may like to do a few and see if you encounter some new bugs, remember to check to see if you get the bug in main client too if so report it via pc/mac bug reporter

http://secondlife.com/tiki/tiki-index.php?page=QA+Test+Scripts

Custom Window sizes in settings.ini

WindowHeight 640
WindowMaximized FALSE
WindowWidth 1592

In KDE setup, replace the "alt" key with the "meta" key, so that Alt still works in SL.

Control Center, Desktop, Window Behaviour, Actions rider, Inner Window, Titlebar and Frame, Modifier Key -> choose Meta instead of Alt.

Turning on AGP accelleration is one of the things I tried here (nVidia card user), and it didn't appear to do squat.

Frankly I think the client might behave a little better if it allowed the external GL library to be used instead of bringing in it's own (so that things like nVidia's native acceleration and fglrx could be used), but that's something I'm sure Icculus has well under control.

(BTW, don't try to shoehorn the supplied libGL.so out of the way. The client will just implode.)

I have yet to get the thing to actually use fullscreen mode tho... Is there something I should be turning on in X that I've apparently not done that would allow it to change the screen modes. (Knowing my usual luck, by morning I'll actually remember what that configuration item is on my own)

Wow you love your Xinerama, don't you?

No, but I do love my 1600x1200 CRT

I just wish that SL would let me have all it's windows as completely separate windows, then I would be happy with an 800x600 3D view and use the space either side to drop the chat, map and inventory windows in, which would save a lot of rendering time

I have a feeling the option isn't used at all yet. Sometimes it doesn't even get written out to settings.ini for me, so the next time you start it defaults back to FALSE anyway.


The client doesn't come with its own libGL.so (if it did, you'd get next to no acceleration, and/or it'd be very picky card support). It does, though, come with its own libGLU.so.1 (a libGL-helper), which you can't seem to be able to remove without SDL croaking when setting a video mode:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1228359968 (LWP 7687)]
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0x08493182 in glXGetProcAddressARB ()
#2  0x446f417c in X11_GL_GetProcAddress () from /usr/lib/libSDL-1.2.so.0
#3  0x446e86bd in SDL_GL_GetProcAddress () from /usr/lib/libSDL-1.2.so.0
#4  0x446eac38 in SDL_SetVideoMode () from /usr/lib/libSDL-1.2.so.0
#5  0x0849400f in LLWindowSDL::createContext ()
#6  0x08493a2c in LLWindowSDL::LLWindowSDL ()
#7  0x0848d0bf in LLWindowManager::createWindow ()
#8  0x09aafd85 in LLViewerWindow::LLViewerWindow ()
#9  0x09d914c7 in main ()

Yes, I removed SL's libSDL-1.2.so.0 and am using my system's.. which otherwise works fine, as long as I use SL's libGLU.so.1.

In fact, these seems to be the only libs I needed to keep for SL to run on my system:
libapr-1.so.0
libCgGL.so
libCg.so
libGLU.so.1
libkdu_v42R.so
libxmlrpc.so.0
And it does run noticeably better than if I left everything else.

Removing LibSDL caused me problems with texture loading. Many things ended up with the default texture, including the land surface, which was odd.

I wouldnt mess around too much with the libraries, basically because this being alpha, quite a few of the componets may be included with the download package but are not implemented yet or have only partial implementation, obviously if the included files dont work and you can find a work around then thats something that should be reported

Same here. I just moved it all out. The only difference is that the fonts are different -- I probably need to install the ones in the SL directory as system ones.

I agree. I want to test the SL linux client as supplied by LL. To make sure that it works, and to be able to say the problems are in the package, not in my "optimizing".

I am not sure I would move the supplied libraries anywhere else, though, and certainly not replace system libraries This IS an alpha version, and the libraries ARE set up for SL ...

I got this tip from David Sleesak, and since I don't know how to quote from one thread to the next, I have cut & pasted it here.

##############################################

David Sleestak
Registered User


Join Date: Jan 2006
Posts: 3
I have this exact same problem, as have everyone else I know running SL on Linux.

This only seems to happen when editing my avatar's appearance. If I leave it alone, it doesn't happen.

The one fix I've found for this after trying just about everything and not getting any real response from support, is to fire up SL on my Windows partition and log in. Once in, I then edit my appearance. Saving should restore the correct color to your skin. You may need to do something like increase your height by 1 point just to be able to save, but this will fix the issue. You can then log back in under Linux and all will be well. Just remember that if you need to edit your appearance, you'll need to do so running windows instead of wine on Linux.

Sucks, doesn't it?

################################################


Thanks, David!

I think it's fairly safe to assume that anyone messing about with libraries has probably tried to get the client to work as-supplied first.

They may be trying to make it run faster or they may be trying to make it run at all, it varies.

I think we need to know if LL are intending to always ship it with their own libs or if the intention is to depend on the system libs more with later releases. If the latter then this line of testing may be useful.

And, of course, some of us just want to play the bloody game we're paying for.

I am slightly disappointed in some ways, not because of problems with the linux client, but because it still performs equaly crap on my system. I thought 1.7 broke wine(x) compatability, now I just have to assume that the CPU requirements have increased and that my XP2000+ is finally too old for running modern games (even if Doom 3 is playable!)

Eh? You'll notice I'm playing on an XP1700+; a 2000+ is definitely not too old.

1.7 seemed to introduce some more aggressive threading that WineX 3.3.2 (or whatever the version was) couldn't handle... I don't think the CPU requirements went up. WineCVS handles it fine, except for the audio (or am I the only one that gets horrible stutter with it?)

~Orenj~

I concur. I have a 1.1GHz AMD, with a memory-starved KDE system. Plays fine (barring the known issues), even with other programs running.


Nope, I do too. Though I assumed it was due to the horrible swap access that practically locks my system up (which doesn't seem to happen in the linux client, btw).

Sound??? Someone has SOUND??? Wow!

I have sound neither with wine nor with the native client.

KDE itself does have sound though.

I am impressed that someone has gotten sound working Any chance of posting a "how to" as a tip?

I run SL ok with my 1800 Duron, with 1 GB of memory. I could run on 512 MB in Linux, but not in windows (I always have opera etc open as well). I get between 4 and 15 fps, depending on where I am etc, and I can live with that for now.

I am not sure that I would classify SL as a "modern game". It is more a window to the ever changing world Second Life. There are way too few "fixed" components to compare the performance with a basically static game, so SL in my mind will always need a LOT more from the client than just about anything I can think of.

I think (read: hope) he meant with the Windows client in Wine. With winecfg, I have both alsa and oss selected as audio output drivers (I also have arts on, but I don't have that selected). No problems with sound on other Wine apps either.

Aha! I will try that I only activated sound in KDE after I switched to the linux client. (The volume was turned down).

If I can get it working in wine, I have hopes that it is not a linux issue (locked sound device, for example).

Well, I'm running an XP2000+ with 2 512mb sticks of PC2100 DDR on an nForce 1 motherboard, GeForce 6600GT, Gentoo, kernel 2.6.15-ck3, not many services running, and I've even tried it without KDE by calling SL directly as a parameter to xinit. I suppose the only thing that could be bringing me down is Software RAID5.

SL chews up 97% of my CPU and struggles to beat 3fps once everything has rezzed. It often drops below 1fps in the WA.

Check glxinfo to make sure you're using the nVidia OpenGL drivers (and make sure it says 'direct rendering: yes'). Also check SL's startup log for anything suspicious.

use winecfg to change the audio settings to Emulated in both places and u will get no clicks or stutters.