For direct access use https://forums.oldunreal.com
It's been quite a while since oldunreal had an overhaul, but we are moving to another server which require some updates and changes. The biggest change is the migration of our old reliable YaBB forum to phpBB. This system expects you to login with your username and old password known from YaBB.
If you experience any problems there is also the usual "password forgotten" function. Don't forget to clear your browser cache!
If you have any further concerns feel free to contact me: Smirftsch@oldunreal.com

[227i] UnrealLinux.bin, various odd problems.

for Unreal & UnrealTournament
Post Reply
User avatar
スマイル・ドラゴン
OldUnreal Member
Posts: 1263
Joined: Sun Feb 10, 2008 9:07 pm

[227i] UnrealLinux.bin, various odd problems.

Post by スマイル・ドラゴン »

UMenu\UWindow seems to act like wanting to use the in-game mouse cursor rather than respond to the window manager's cursor when running in a window, as a result the mouse cannot be used with the menu system if you're running UnrealLinux.bin in a window.

IgnoreUngrabbedMouse set to True only barely makes the cursor usable, it still uses the in-game cursor and the mouse escapes from the window VERY frequently and does not match at all where I'm pointing in the game itself.

A only solution I can think to this is if there's no way to make UMenu\UWindow respond to the window managers cursor is to make a hotkey (like CTRL+F12 in DosBOX) to capture\uncapture the mouse to window. Other SDL based games use this feature even under Windows.


And now onto OpenGL: I can't use AntiAliasing at all under UnrealLinux.bin, UseAA=true and NumAASamples=8. Works fine under Windows and under Wine, but not under UnrealLinux.bin as it seems to ignore the option. Anisotropy works at 16 samples though. This *might* be a SDLDrv problem, since I remember from experience you have to enable AA through SDL's interface when creating the OpenGL context...

I'm running xorg-radeon as my video driver, on a Radeon HD 6870. AA support works fine in other linux based games, like Valve's GoldSrc and Source engine ports.

Here's GLXINFO just in case:

Code: Select all

name of display: :0.0
display: :0  screen: 0
direct rendering: Yes
server glx vendor string: SGI
server glx version string: 1.4
server glx extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, GLX_ARB_multisample, 
    GLX_EXT_create_context_es2_profile, GLX_EXT_framebuffer_sRGB, 
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
    GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
    GLX_OML_swap_method, GLX_SGIS_multisample, GLX_SGIX_fbconfig, 
    GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, GLX_SGI_swap_control
client glx vendor string: Mesa Project and SGI
client glx version string: 1.4
client glx extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_ARB_create_context_robustness, GLX_ARB_fbconfig_float, 
    GLX_ARB_framebuffer_sRGB, GLX_ARB_get_proc_address, GLX_ARB_multisample, 
    GLX_EXT_create_context_es2_profile, GLX_EXT_fbconfig_packed_float, 
    GLX_EXT_framebuffer_sRGB, GLX_EXT_import_context, 
    GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, GLX_EXT_visual_rating, 
    GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
    GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
    GLX_MESA_swap_control, GLX_OML_swap_method, GLX_OML_sync_control, 
    GLX_SGIS_multisample, GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, 
    GLX_SGIX_visual_select_group, GLX_SGI_make_current_read, 
    GLX_SGI_swap_control, GLX_SGI_video_sync
GLX version: 1.4
GLX extensions:
    GLX_ARB_create_context, GLX_ARB_create_context_profile, 
    GLX_ARB_fbconfig_float, GLX_ARB_framebuffer_sRGB, 
    GLX_ARB_get_proc_address, GLX_ARB_multisample, 
    GLX_EXT_create_context_es2_profile, GLX_EXT_framebuffer_sRGB, 
    GLX_EXT_import_context, GLX_EXT_texture_from_pixmap, GLX_EXT_visual_info, 
    GLX_EXT_visual_rating, GLX_INTEL_swap_event, GLX_MESA_copy_sub_buffer, 
    GLX_MESA_multithread_makecurrent, GLX_MESA_swap_control, 
    GLX_OML_swap_method, GLX_OML_sync_control, GLX_SGIS_multisample, 
    GLX_SGIX_fbconfig, GLX_SGIX_pbuffer, GLX_SGIX_visual_select_group, 
    GLX_SGI_make_current_read, GLX_SGI_swap_control, GLX_SGI_video_sync
OpenGL vendor string: X.Org
OpenGL renderer string: Gallium 0.4 on AMD BARTS
OpenGL core profile version string: 3.3 (Core Profile) Mesa 10.1.3
OpenGL core profile shading language version string: 3.30
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile
OpenGL core profile extensions:
    GL_AMD_conservative_depth, GL_AMD_draw_buffers_blend, 
    GL_AMD_seamless_cubemap_per_texture, GL_AMD_shader_stencil_export, 
    GL_AMD_shader_trinary_minmax, GL_AMD_vertex_shader_layer, 
    GL_ANGLE_texture_compression_dxt3, GL_ANGLE_texture_compression_dxt5, 
    GL_ARB_ES2_compatibility, GL_ARB_base_instance, 
    GL_ARB_blend_func_extended, GL_ARB_clear_buffer_object, 
    GL_ARB_conservative_depth, GL_ARB_copy_buffer, GL_ARB_debug_output, 
    GL_ARB_depth_buffer_float, GL_ARB_depth_clamp, GL_ARB_draw_buffers, 
    GL_ARB_draw_buffers_blend, GL_ARB_draw_elements_base_vertex, 
    GL_ARB_draw_instanced, GL_ARB_explicit_attrib_location, 
    GL_ARB_fragment_coord_conventions, GL_ARB_fragment_shader, 
    GL_ARB_framebuffer_object, GL_ARB_framebuffer_sRGB, 
    GL_ARB_get_program_binary, GL_ARB_half_float_pixel, 
    GL_ARB_half_float_vertex, GL_ARB_instanced_arrays, 
    GL_ARB_internalformat_query, GL_ARB_invalidate_subdata, 
    GL_ARB_map_buffer_alignment, GL_ARB_map_buffer_range, 
    GL_ARB_occlusion_query2, GL_ARB_pixel_buffer_object, GL_ARB_point_sprite, 
    GL_ARB_provoking_vertex, GL_ARB_robustness, GL_ARB_sampler_objects, 
    GL_ARB_seamless_cube_map, GL_ARB_shader_bit_encoding, 
    GL_ARB_shader_objects, GL_ARB_shader_stencil_export, 
    GL_ARB_shader_texture_lod, GL_ARB_shading_language_420pack, 
    GL_ARB_shading_language_packing, GL_ARB_sync, 
    GL_ARB_texture_buffer_object, GL_ARB_texture_buffer_object_rgb32, 
    GL_ARB_texture_buffer_range, GL_ARB_texture_compression_rgtc, 
    GL_ARB_texture_cube_map_array, GL_ARB_texture_float, 
    GL_ARB_texture_mirror_clamp_to_edge, GL_ARB_texture_multisample, 
    GL_ARB_texture_non_power_of_two, GL_ARB_texture_rectangle, 
    GL_ARB_texture_rg, GL_ARB_texture_rgb10_a2ui, GL_ARB_texture_storage, 
    GL_ARB_texture_storage_multisample, GL_ARB_texture_swizzle, 
    GL_ARB_timer_query, GL_ARB_transform_feedback2, 
    GL_ARB_transform_feedback3, GL_ARB_transform_feedback_instanced, 
    GL_ARB_uniform_buffer_object, GL_ARB_vertex_array_bgra, 
    GL_ARB_vertex_array_object, GL_ARB_vertex_attrib_binding, 
    GL_ARB_vertex_shader, GL_ARB_vertex_type_10f_11f_11f_rev, 
    GL_ARB_vertex_type_2_10_10_10_rev, GL_ATI_blend_equation_separate, 
    GL_ATI_texture_compression_3dc, GL_ATI_texture_float, 
    GL_ATI_texture_mirror_once, GL_EXT_abgr, GL_EXT_blend_equation_separate, 
    GL_EXT_draw_buffers2, GL_EXT_draw_instanced, GL_EXT_framebuffer_blit, 
    GL_EXT_framebuffer_multisample, GL_EXT_framebuffer_multisample_blit_scaled, 
    GL_EXT_framebuffer_sRGB, GL_EXT_packed_depth_stencil, GL_EXT_packed_float, 
    GL_EXT_pixel_buffer_object, GL_EXT_provoking_vertex, GL_EXT_texture_array, 
    GL_EXT_texture_compression_dxt1, GL_EXT_texture_compression_latc, 
    GL_EXT_texture_compression_rgtc, GL_EXT_texture_compression_s3tc, 
    GL_EXT_texture_filter_anisotropic, GL_EXT_texture_integer, 
    GL_EXT_texture_mirror_clamp, GL_EXT_texture_sRGB, 
    GL_EXT_texture_sRGB_decode, GL_EXT_texture_shared_exponent, 
    GL_EXT_texture_snorm, GL_EXT_texture_swizzle, GL_EXT_timer_query, 
    GL_EXT_transform_feedback, GL_EXT_vertex_array_bgra, 
    GL_IBM_multimode_draw_arrays, GL_KHR_debug, GL_MESA_pack_invert, 
    GL_MESA_texture_signed_rgba, GL_NV_conditional_render, GL_NV_depth_clamp, 
    GL_NV_packed_depth_stencil, GL_NV_texture_barrier, GL_NV_vdpau_interop, 
    GL_OES_EGL_image, GL_OES_read_format, GL_S3_s3tc
Another strange issue is that the log is improperly closed on exit, almost as if Unreal is crashing but I get no Segmentation Fault message in terminal... so I'm not sure what's going on there.
“I am the dragon without a name.”
Ðàrk-_¦_-Ñïght.: / κυνικός Δράκων / スマイル・ドラゴン / Draco Nihil
User avatar
Smirftsch
Administrator
Posts: 8999
Joined: Wed Apr 29, 1998 10:00 pm
Location: NaPali
Contact:

Re: [227i] UnrealLinux.bin, various odd problems.

Post by Smirftsch »

The SDL stuff definitely could need some overhaul, I was thinking about moving on to new 2.x, also due to the fact that it could allow things like a "preferences" window and such. I wouldn't be surprised to find some mouse improvements there as well. It's just that currently I plain don't find the time.
The idea with the shortcut however is nice, I think I am going to see whats needed to do that.

As for OpenGL, I am pretty sure it at least WAS working at some point and I can't remember any change which could affect this specific option. How did you check AA is working?
Guess I need make bumblebee running here and check it again, as I am only having crappy intel graphics chip currently in Linux and that's really not usable for reference :D

The log usually does fine for me here, but you could also use commandline with -log parameter or if you want to have it in a file "./UnrealLinux.bin -log > bla.log" (which will also avoid having trouble with UTF32 in regular logfile some texteditors have).
Last edited by Smirftsch on Sun Dec 14, 2014 7:28 am, edited 1 time in total.
Sometimes you have to lose a fight to win the war.
User avatar
スマイル・ドラゴン
OldUnreal Member
Posts: 1263
Joined: Sun Feb 10, 2008 9:07 pm

Re: [227i] UnrealLinux.bin, various odd problems.

Post by スマイル・ドラゴン »

I ran 227i and 226b under Wine, and I get 8x MSAA which is the maximum the 6870 can support. I also ran Linux Native Source engine games like Half-Life 2 and Counter Strike Source and they both accept the 8x MSAA setting Unreal can take.

I'd recommend caution with the new 2.x SDL as it seems to be drastically different than 1.2, but it could be beneficial to 227 since the deprecated features don't seem much use to Unreal. Maybe SDL 2.x will fix the antialiasing issue, it is heavily dependent on the initial context creation for some reason yet none of the other OpenGL options are dependent.

The -log workaround works just fine, why exactly does 227 use UTF-32? Is there a localization that requires something more than UTF-8?
“I am the dragon without a name.”
Ðàrk-_¦_-Ñïght.: / κυνικός Δράκων / スマイル・ドラゴン / Draco Nihil
User avatar
Smirftsch
Administrator
Posts: 8999
Joined: Wed Apr 29, 1998 10:00 pm
Location: NaPali
Contact:

Re: [227i] UnrealLinux.bin, various odd problems.

Post by Smirftsch »

yes, I switched to UTF32 to support russian properly, also it offers the chance for any other possible translation, even if it is chinese or japanese or whatever else comes in mind :)
Sometimes you have to lose a fight to win the war.
User avatar
スマイル・ドラゴン
OldUnreal Member
Posts: 1263
Joined: Sun Feb 10, 2008 9:07 pm

Re: [227i] UnrealLinux.bin, various odd problems.

Post by スマイル・ドラゴン »

Ah okay then. UTF-32 isn't much of a problem, though it's not added to text encodings default list in gedit, that's easily fixed.

I also had another question, would it be better to have UnrealLinux actually make use of X and GLX directly rather than SDL? darkplaces engine is built towards both X and SDL on Linux, the same way the windows one is built towards windows API and SDL.
“I am the dragon without a name.”
Ðàrk-_¦_-Ñïght.: / κυνικός Δράκων / スマイル・ドラゴン / Draco Nihil
User avatar
Smirftsch
Administrator
Posts: 8999
Joined: Wed Apr 29, 1998 10:00 pm
Location: NaPali
Contact:

Re: [227i] UnrealLinux.bin, various odd problems.

Post by Smirftsch »

indeed was asking myself a few times already, but never came around to really test it out. Also not sure in what stage the input system in XDrv was left and iirc the output window had certain issues with some windowmanagers as well. And I know parts of the code are using deprecated functions. Overall probably nothing serious, but again quite some work and testing required.

I had a quick peek into SDL migration 1.2 to 2.0 guide and it seems its really doable, but they made a couple of changes in the input systems as well which would be probably the most work, also I think it would kill SDLSoftDrv entirely (although any crappy Linux distro is having Mesa, so I am not sure if this is of any importance at all).

Oh, and made bumblebee running on my Laptop now, was a bit trouble since I am using a custom kernel and I had to make sure to install also all 32bit libs, but finally I made it running with
optirun -b primus ./UnrealLinux.bin -log
without "-b primus" it does only
Failed to load 'Class Render.Render': Failed to find object 'Class Render.Render'
which is not really helpful, so maybe this trick will help others with the same problem :) (guess I should write it into some own topic or the wiki...)


So I can test now with Intel/Mesa and Nvidia if AA is working or not.
Last edited by Smirftsch on Sun Dec 14, 2014 6:14 pm, edited 1 time in total.
Sometimes you have to lose a fight to win the war.
User avatar
スマイル・ドラゴン
OldUnreal Member
Posts: 1263
Joined: Sun Feb 10, 2008 9:07 pm

Re: [227i] UnrealLinux.bin, various odd problems.

Post by スマイル・ドラゴン »

It's pretty amazing how far xorg-radeon has gotten development-wise. I've yet to run into any major problems running any "modern" game engine under Linux without the use of fglrx. My framerate is a consistent 60 FPS, no jittering and shader stages work pretty much perfectly for me.

To be honest I rather not even touch fglrx because everytime the kernel get's updated the binary blob is obviously broken. 227 runs really great with this driver as does every other native game I tried.
“I am the dragon without a name.”
Ðàrk-_¦_-Ñïght.: / κυνικός Δράκων / スマイル・ドラゴン / Draco Nihil
User avatar
Smirftsch
Administrator
Posts: 8999
Joined: Wed Apr 29, 1998 10:00 pm
Location: NaPali
Contact:

Re: [227i] UnrealLinux.bin, various odd problems.

Post by Smirftsch »

oh well, after checking the logs and looking again into the code I had to realize that AA isn't implemented in Linux version of the UTGLR renderer. Never noticed before although I made quite a few changes to it over the years. Guess this means I need to check now why it wasn't implemented.
Sometimes you have to lose a fight to win the war.
User avatar
スマイル・ドラゴン
OldUnreal Member
Posts: 1263
Joined: Sun Feb 10, 2008 9:07 pm

Re: [227i] UnrealLinux.bin, various odd problems.

Post by スマイル・ドラゴン »

Probably because you have to assign AA to the SDL window before it's created.
“I am the dragon without a name.”
Ðàrk-_¦_-Ñïght.: / κυνικός Δράκων / スマイル・ドラゴン / Draco Nihil
User avatar
Smirftsch
Administrator
Posts: 8999
Joined: Wed Apr 29, 1998 10:00 pm
Location: NaPali
Contact:

Re: [227i] UnrealLinux.bin, various odd problems.

Post by Smirftsch »

that alone wouldn't be reason enough I think. I mean, maybe Chris was just a bit lazy, but if it needs to be set up at before the window was created the max required would be a restart.
It seems SDL offers easy ways to set the buffers and pixelformat, maybe in the end its easier than expected.

Edit: I added the required code and it seems to work, requires some testing yet.
Also noticed that "MinDepthBits" should be added in [OpenGLDrv.OpenGLRenderDevice] so that it is possible to run it in Linux with 24bit depth buffer (z-buffer) instead of 16bit- not sure though if it makes any visual difference, but windows usually runs it at 24bit.
Last edited by Smirftsch on Mon Dec 15, 2014 8:29 am, edited 1 time in total.
Sometimes you have to lose a fight to win the war.
User avatar
スマイル・ドラゴン
OldUnreal Member
Posts: 1263
Joined: Sun Feb 10, 2008 9:07 pm

Re: [227i] UnrealLinux.bin, various odd problems.

Post by スマイル・ドラゴン »

Chris's OpenGL seems to struggle with z-fighting regardless of the depth buffer size. I don't know what kentie's d3d10drv renderer does differently but his manages to counteract the effects of z-fighting even in Epic's maps for UT99.

Do GPU's only support 24-bit Z? In some older games I see a selection for a 32-bit Z but never heard of any hardware that supports that...
“I am the dragon without a name.”
Ðàrk-_¦_-Ñïght.: / κυνικός Δράκων / スマイル・ドラゴン / Draco Nihil
User avatar
Smirftsch
Administrator
Posts: 8999
Joined: Wed Apr 29, 1998 10:00 pm
Location: NaPali
Contact:

Re: [227i] UnrealLinux.bin, various odd problems.

Post by Smirftsch »

maybe other zFar zNear config, would have to compare.

No idea about 32bpp depth for GPU, it seems that 24bit is commonly used. I think there have been at least some ATI cards with it, but it seems that they are maybe better methods nowadays if really wanted.
Sometimes you have to lose a fight to win the war.
Post Reply

Return to “Linux-Board”