renderers

[Azura]

Just mentionning this because graphics are pretty choppy if the agp aperture size is low.

[BLTicklemonster]

Well, I'm down now to a 32 meg mx200 nvidia now... was on a ti4400, then fx5200, now I'm limping along...

[spykes]

Hey guys, thanks for this. I been wanting someone to get this thing compiled in Linux for ages now. I even took upon the task myself.... that is until I did not want to even attempt to screw with old GCC 2.95 ridden code as I did not even wanna bother with installing such an old compiler in the first place.

[spykes]

Another way to gain a slight boost is to compile your own SDL and replace the old stock system libSDL.so.1.2 in /usr/lib with your new one. Make sure to compile it with your proper CFLAGS that match your cpu, as well as optimization, etc.

If of course you are using gentoo then your libs are probably all optimized to begin with.

This optimization trick works regardless if you are using a proper opengl renderer or the SDL passthrough one. The game still uses SDL for most everything regarding input/output anyhow, with the exception of sound.

[DarkED]

Hey all...

I'm getting that 'OpenGLDrv not found' error that Tickle was getting.

I did a $ ls -al OpenGL* in my UT/System dir, all it pulls is OpenGLDrv.so - and I'm looking at the OpenGLDrv.ini and OpenGLDrv.int in the UT/System folder right now

What gives?

Thanks in advance!

[Rush]

btw. anybody caring to track the guy who compiled this renderer on linux ?

[DarkED]

Okay, I found one problem. The OpenGLDrv.int was named wrong, it was "OpenGlDrv" (with a lowercase L) instead of "OpenGLDrv."

So now ls -al OpenGL* finds them.

However, I still get this:

Failed to load 'OpenGLDrv': Can't find file for package 'OpenGLDrv'
Failed to load 'Class OpenGLDrv.OpenGLRenderDevice': Can't find file for package 'OpenGLDrv'
Can't find file for package 'OpenGLDrv'
Can't find file for package 'OpenGLDrv'
Signal: SIGSEGV [segmentation fault]

I can't figure it out...

[DarkED]

Okay... I've been experimenting. I tried renaming OpenGLDrv.int to just OpenGLDrv (no extension.)

UT said no:

Input system initialized for SDLViewport0
Opening SDL viewport.
Signal: SIGSEGV [segmentation fault]
Aborting.
Exiting.
Name subsystem shut down
Allocation checking disabled
Segmentation fault

Okay, fair enough. At least it recognized the existence of a 'OpenGLDrv.'

So, next I tried it with OpenGLDrv.so - this time, UT said HELL no:

Input system initialized for SDLViewport0
Opening SDL viewport.
The file 'OpenGLDrv' contains unrecognizable data
*** glibc detected *** free(): invalid pointer: 0xbfcaac38 ***
Signal: SIGIOT [iot trap]
Aborting.

This locked up my terminal

I am open to ideas right now... Someone, anyone, please help me

Oh, and Rush, does it work for you?

[MrWhite]

I have the same problem as you, but Daniel Vogel's renderer included in the UTPGPatch451 works
I wonder if the file gets corrupt when downloading?

[DarkED]

Yeah, I said forget it and I decided I would try to compile it myself. So I started looking around for things about compiling a .dll to a .so and all that, didn't find much, but found enough to get me started...

So, with little programming experience, I began working. After working all night, my brain is fried from searching for functions and variables - but I have a nonstable (but working) OpenGLDrv going. The mouse makes it unplayable but the S3TC textures look oh so good in Linux. Just gotta fix a crash thing and the mouse problem, and it'll be good to go...

More to come

Oh and BTW... I tried another OpenGLDrv before starting this, the mouse was still jerky/odd, is it my Ubuntu?

[BLTicklemonster]

Sounds like yer mouse is a Jerk, Ed. Get a new mouse.

- Abbymonster


glad you got something going on it. Sorry I couldn't help you the other night.

[BLTicklemonster]

Just PMed him a request to come over here.

[Rush]

I can install gcc-2.95 on gentoo in a no time without messing up with the system but I would need to know how to compile the utglr code and modify it in the first place, here's what the author of UTGLR wrote me in an answer for me pointing him to the Linux version of UTGLR

Originally Posted by Chris Dochnal

With version 3.2, I think I'm mostly finished with UT renderer work this time (may or may not
update the D3D one, and slight chance I might experiment with some Glide stuff, despite some
complications), and I prefer not to get too involved with any builds I can't compile or run
locally.

Even though a native build of the renderer is nice, some good comparisons between native Linux
UT and Windows UT through Wine really should be run. Even without the SSE/SSE2 code in the
renderer, I have reason to believe that some critical bits of assembly may be missing from the
Linux build based on reviewing the 432 headers and some other things. Although some of this
may be in the renderer and could be fixed with the right modifications to the headers, I think
significant parts of it could also be in other parts of the code. If the mesh lighting code is
doing reciprocal square roots with a divide and a square root instead of the optimized
approximation code, that could hurt a lot. I'm not sure how much float to int conversion there
is outside the renderer, but if using the code in the 432 headers, it's going to be very slow
(unless using a special compiler option to have it use fist instructions instead of ftol()).
The appRound() function looks broken in the 432 headers on the Linux side too (or if use
compiler option that makes these fast, and changes the rounding behavior, then the appFloor()
function becomes broken), though being off by 0.5 in the direction that doesn't do something
like turn white into black is only a minor issue. There's also the question of if whatever
MSVC6 version was used possibly generates significantly better code for UT like code compared
to whatever gcc version was used (probably something from 2.95.x series). Anyway, if certain
critical bits of assembly are missing from the Linux build, the Windows build could perform a
lot better even with extra overhead in some areas from a layer like Wine.

Chris Dohnal

and this is what I got in an answer after asking Chris about a Linux version until I known it has already been built:

Originally Posted by Chris Dochnal

I can only mostly help with things more directly related to changes I've made to the renderer.
Unfortunately, this doesn't include everything needed to build the renderer on Linux. There's a
good chance the 432 headers aren't fully compatible with the latest Linux binary, but I can't
say for sure. Even if there are some differences, it might not break the subset of things
needed to build a compatible renderer.

So, the first thing is to build a working renderer from one of the original source code releases
before I made any modifications (one set of 432 headers, but various renderer source releases
that may, or may not, work). This is the part I can't really help much with. Things like
makefiles, do the 432 headers really work (and any debug if issues or little tweaks needed
here), other libraries, etc.

You'll need to use a compatible compiler. gcc had some major C++ ABI changes in moving to
version 3. I'm fairly sure you'll need to use a later 2.x gcc version. I can't say exactly
which one, though 2.95.3 might be a good starting point unless you have more specific
information. It's best if you can extract information about which compiler version was used to
compile other parts of the engine to find this information out for sure (can't remember for sure
if I tried this or not once on some file, but have some vague recollection of 2.95.2). Anyway,
hopefully the compiler version is easily extractable from some other file, so you can find out
which version(s) can be used for a compatible build.

If you can get an original renderer build working, changes required to build my updated code
will hopefully be minor, but I can't say for sure since I haven't tested any of this. There
used to be various problems with #ifdef blocks, but I might have cleaned this up. I think it
will exclude the SSE code if not a Windows build, which isn't a huge loss (and may not be
possible to convert it to anything that could be used if have to use an older compatible gcc due
to C++ issues). There's no equivalent Linux code (in my latest source code release) for
platform specific stuff like the antialiasing init code and swap interval control code I added.
A couple large constants will need ULL suffixes added. There might be one or two remaining
member function pointer tweaks I forgot to fix (easy to miss since I usually use MSVC6 and it
won't catch these). If you're using a default install of a compatible compiler, there's a good
chance the library code that comes with it might have an out of date and incompatible sstream
implementation. If this is the case, it's probably easiest to just get rid of the
dout/ods_stream/ods_buf debug code. It's non-essential. This requires numerous, but simple,
changes to comment out all uses of this. There might be some other, hopefully minor, issues too.

Chris Dochnal

I hope that Chris doesn't mind me posting this.

[spykes]

I know why this is.

I don't know why but this new OpenGLDrv.so depends on many more libraries to be present on the system when compared to the stock version.

spike@buffy:/usr/local/games/ut/System> ldd OpenGLDrv.so
linux-gate.so.1 => (0xffffe000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb7ef6000)
libnsl.so.1 => /lib/tls/libnsl.so.1 (0xb7ee0000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7ece000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb7ddf000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb7dd1000)
libXmu.so.6 => /usr/lib/libXmu.so.6 (0xb7dbb000)
libXt.so.6 => /usr/lib/libXt.so.6 (0xb7d69000)
libXi.so.6 => /usr/lib/libXi.so.6 (0xb7d61000)
libSM.so.6 => /usr/lib/libSM.so.6 (0xb7d58000)
libICE.so.6 => /usr/lib/libICE.so.6 (0xb7d40000)
libXpm.so.4 => /usr/lib/libXpm.so.4 (0xb7d31000)
Core.so => ./Core.so (0xb7bc2000)
libstdc++-libc6.2-2.so.3 => ./libstdc++-libc6.2-2.so.3 (0xb7b7b000)
libm.so.6 => /lib/tls/libm.so.6 (0xb7b58000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7a29000)
/lib/ld-linux.so.2 (0x80000000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7a26000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb7a21000)
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb7994000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb78c6000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb78bd000)

spike@buffy:/usr/local/games/ut/System> ldd OpenGLDrv.so.bk
linux-gate.so.1 => (0xffffe000)
libdl.so.2 => /lib/tls/libdl.so.2 (0xb7ee2000)
libnsl.so.1 => /lib/tls/libnsl.so.1 (0xb7ecc000)
libpthread.so.0 => /lib/tls/libpthread.so.0 (0xb7eba000)
Core.so => ./Core.so (0xb7d4b000)
libm.so.6 => /lib/tls/libm.so.6 (0xb7d28000)
libc.so.6 => /lib/tls/libc.so.6 (0xb7bf9000)
/lib/ld-linux.so.2 (0x80000000)
libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0xb7b6c000)
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb7a9e000)
libX11.so.6 => /usr/lib/libX11.so.6 (0xb79af000)
libXext.so.6 => /usr/lib/libXext.so.6 (0xb79a1000)
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0xb7998000)
libXau.so.6 => /usr/lib/libXau.so.6 (0xb7994000)
libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xb798f000)

You need to run ldd on your version of lib and see if the dependancies are met.

[spykes]

2.95.3 appears to be the compiler version. Although there is references to egcs-2.91.66 there as well.

[spykes]

I must also add that the UTPG group has refused to release their updated versions of headers. I read about some mod writers complaining about it.

[G-Lite]

So BLTicklemonster PM'd me on BeyondUnreal.

I'm not sure I have alot to add actually. It pretty much comes down to what I said in the thread on BuF.
I did compile it with gcc 2.95.3, on Ubuntu (possibly Breezy while it was still in development, but I'm not sure about that).
It's either extremely hard or impossible to use the SSE optimizations. Besides that, I also got into problems with some debug functions, which I disabled.

The extra library dependencies shouldn't be a problem I think, they all look like standard X libraries to me, and should be present on any modern system.

I remember coming across two different sets of Unreal engine headers, and fiddling about with that, but I might've just made a mistake there.
It should be fairly straight forward to compile this with some basic C++, compiling, linking and Makefiles knowledge.

If you do need any specific help, just ask and I'll see if I can help out. I have very little knowledge of the actual engine internals the driver is touching though, or even OpenGL itself. I could try to compile it again, but I'm not sure how that'd make any difference.

[BLTicklemonster]

Bloody hell, it worked.

Thanks for dropping by with that, G-Lite.

[MrWhite]

Originally Posted by spykes

You need to run ldd on your version of lib and see if the dependancies are met.

THX spykes, it works now

[spykes]

No prob.

Yeah its the libstdc++-libc6.2-2.so.3 thats usually the kicker, thats an old compat library that most systems don't have installed by default.