logo
Main

Forums

Downloads

Unreal-Netiquette

Donate for Oldunreal:
Donate

borderline

Links to our wiki:
Wiki

Walkthrough

Links

Tutorials

Unreal Reference

Usermaps

borderline

Contact us:
Submit News
Page Index Toggle Pages: 1 Send TopicPrint
Hot Topic (More than 10 Replies) [227i] UnrealLinux.bin, various odd problems. (Read 3314 times)
スマイル・ドラゴン
Betatester
Offline


『smile。。。』

Posts: 1236
Location: Independence, KS
Joined: Feb 10th, 2008
Gender: Male
[227i] UnrealLinux.bin, various odd problems.
Dec 13th, 2014 at 5:16pm
Print Post  
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
Back to top
IP Logged
 
Smirftsch
Forum Administrator
*****
Offline



Posts: 7935
Location: at home
Joined: Apr 30th, 1998
Gender: Male
Re: [227i] UnrealLinux.bin, various odd problems.
Reply #1 - Dec 14th, 2014 at 7:22am
Print Post  
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 Cheesy

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).
  

Sometimes you have to lose a fight to win the war.
Back to top
WWWICQ  
IP Logged
 
スマイル・ドラゴン
Betatester
Offline


『smile。。。』

Posts: 1236
Location: Independence, KS
Joined: Feb 10th, 2008
Gender: Male
Re: [227i] UnrealLinux.bin, various odd problems.
Reply #2 - Dec 14th, 2014 at 8:21am
Print Post  
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
Back to top
IP Logged
 
Smirftsch
Forum Administrator
*****
Offline



Posts: 7935
Location: at home
Joined: Apr 30th, 1998
Gender: Male
Re: [227i] UnrealLinux.bin, various odd problems.
Reply #3 - Dec 14th, 2014 at 8:44am
Print Post  
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 Smiley
  

Sometimes you have to lose a fight to win the war.
Back to top
WWWICQ  
IP Logged
 
スマイル・ドラゴン
Betatester
Offline


『smile。。。』

Posts: 1236
Location: Independence, KS
Joined: Feb 10th, 2008
Gender: Male
Re: [227i] UnrealLinux.bin, various odd problems.
Reply #4 - Dec 14th, 2014 at 9:48am
Print Post  
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
Back to top
IP Logged
 
Smirftsch
Forum Administrator
*****
Offline



Posts: 7935
Location: at home
Joined: Apr 30th, 1998
Gender: Male
Re: [227i] UnrealLinux.bin, various odd problems.
Reply #5 - Dec 14th, 2014 at 6:01pm
Print Post  
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
Quote:
optirun -b primus ./UnrealLinux.bin -log


without "-b primus" it does only
Quote:
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 Smiley (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.
  

Sometimes you have to lose a fight to win the war.
Back to top
WWWICQ  
IP Logged
 
スマイル・ドラゴン
Betatester
Offline


『smile。。。』

Posts: 1236
Location: Independence, KS
Joined: Feb 10th, 2008
Gender: Male
Re: [227i] UnrealLinux.bin, various odd problems.
Reply #6 - Dec 14th, 2014 at 6:23pm
Print Post  
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
Back to top
IP Logged
 
Smirftsch
Forum Administrator
*****
Offline



Posts: 7935
Location: at home
Joined: Apr 30th, 1998
Gender: Male
Re: [227i] UnrealLinux.bin, various odd problems.
Reply #7 - Dec 14th, 2014 at 6:35pm
Print Post  
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.
Back to top
WWWICQ  
IP Logged
 
スマイル・ドラゴン
Betatester
Offline


『smile。。。』

Posts: 1236
Location: Independence, KS
Joined: Feb 10th, 2008
Gender: Male
Re: [227i] UnrealLinux.bin, various odd problems.
Reply #8 - Dec 14th, 2014 at 11:53pm
Print Post  
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
Back to top
IP Logged
 
Smirftsch
Forum Administrator
*****
Offline



Posts: 7935
Location: at home
Joined: Apr 30th, 1998
Gender: Male
Re: [227i] UnrealLinux.bin, various odd problems.
Reply #9 - Dec 15th, 2014 at 7:40am
Print Post  
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.
  

Sometimes you have to lose a fight to win the war.
Back to top
WWWICQ  
IP Logged
 
スマイル・ドラゴン
Betatester
Offline


『smile。。。』

Posts: 1236
Location: Independence, KS
Joined: Feb 10th, 2008
Gender: Male
Re: [227i] UnrealLinux.bin, various odd problems.
Reply #10 - Dec 15th, 2014 at 8:01pm
Print Post  
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
Back to top
IP Logged
 
Smirftsch
Forum Administrator
*****
Offline



Posts: 7935
Location: at home
Joined: Apr 30th, 1998
Gender: Male
Re: [227i] UnrealLinux.bin, various odd problems.
Reply #11 - Dec 16th, 2014 at 11:23am
Print Post  
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.
Back to top
WWWICQ  
IP Logged
 
Page Index Toggle Pages: 1
Send TopicPrint
Bookmarks: del.icio.us Digg Facebook Google Google+ Linked in reddit StumbleUpon Twitter Yahoo