Announcement

Collapse
No announcement yet.

Unreal Engine 4.1 Released With Linux/SteamOS Support

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Originally posted by GreatEmerald View Post
    What does any of that have to do with Steam? Why is its API required to begin with?
    my bad on misunderstanding, sorry. i thought that manual copy was the problem, #.#' dang, sometimes not being native english speaker really plays tricks on me, lol

    but, as far as steam goes, i'd speculate they use it to avoid distro differences by using steam as platform in order to make linux more friendly environment where steam provides dependancies, then again... who knows

    Comment


    • #22
      Originally posted by johnc View Post
      Originally posted by curaga View Post
      What the heck do they use so that Win-to-Lin cross-compiling works, but native does not.
      I have to admit that I find much of what I read in the world to be completely baffling.
      Probably they currently use a lot of Microsoft-specific extension, in the compiler (like automatic import of COM / .NET classes without even an include (*) ), in the C++ dialect (some unstandard non POSIX/non C++11 API) or in the technologies (Unreal 4 relies on .NET, hence the need of Mono on linux).

      So basically the current code was always though about only getting compiled inside Visual C++ because they never previously though about compiling it for anything else than Windows, and now that they changed their mind and need Linux executable, the only thing they could do quickly is twist VC++ into helping compile some sections instead of having to go through all the messy code and making it compiler-neutral.

      (*) - In VC++ you just say "import <name of a OLE/COM .dll>" and suddenly all the objects become automagically available, as if you had headers and glue-code libraries loaded. Meanwhile GNU tools require the necessary .h / .a to be manually generated out of a IDL which in turn might need to be rebuild out of the IDL if not provided. Now keep in mind that Microsoft's own IDL compiler barfs segfaults on some IDL and you begin to understand the pain in handling this kind of code. That's why some have gone completely "Fuck it" over this, and created dynamic dispatching libraries. It helps writing portable code, but that would require some rewriting/porting.
      I've definitely spent too much time with shitty code like this.

      Originally posted by GreatEmerald View Post
      I hope it's optional, but then why does the wiki say it's needed...
      The current Linux compile is a proof-of-concept by 3rd parties - not even EPIC themselves - (translation: 3rd paty "-there are a bunch of arcane tricks so GCC doesn't commit sepuku while trying to compile this mess") to getting to compile something that the original authors are still in preliminary support (translation: Epic "-hey, we finally got a way to compile a Linux executable... well it only works a twisted way, so don't look at it in a funny way otherwise it will go belly up").

      So don't expect too much now, beside "Hey, Linux Executable! With Unreal Engine running without Wine !".
      We're still VERY FAR from a complete and stable product. That will require quite a lot of further ironing out. And the current twisted mess "ready to fall whenever you sneeze too loudly" isn't probably that representative of the finall product and one shouldn't draw too much conclusions.

      Originally posted by kaprikawn View Post
      Yeah, this is a problem, I might have to dual boot, one with open source for general useage, and one with Catalyst for AAA games.
      Well technically, you don't need to reboot the whole machine, only restart your X session and desktop environment. Any background tasks isn't affected.
      So you CIFS or NFS file shares, any torrenting session like rtorrent in a screen teminal, ASIC bitcoin-miner, other daemons, etc. won't be interrupted.

      Originally posted by kaprikawn View Post
      I doubt the open source drivers will be able to cope with UE4 until we start seeing compliance with higher versions of OpenGL.
      Or perhaps, the whole could rise more interests and pour more ressources (like developers onto Epic's and Valve's payroll) into bringing Mesa to GL4 compliance.
      AMD is certainly open to work in that direction (they WANT the opensource drivers to have capability similar to the closed source. If only because they count on opensource drivers for long-term support of legacy hardware, like the R300 driver), is giving as much help as they can (release docs as fast as it trickles down their legal department), and have a few own devs on their own payroll.

      Comment


      • #23
        Originally posted by DrYak View Post
        Well technically, you don't need to reboot the whole machine, only restart your X session and desktop environment. Any background tasks isn't affected.
        I experimented with this a while back and unless something has changed, I'm afraid a reboot is necessary. Once the open kernel drivers have been loaded, even if you manually unload them first, subsequently starting X under fglrx hangs the machine hard. I tried all sorts including disabling the framebuffer under the running kernel, resetting the adapter's state with vbetool, and even kexec.

        Comment


        • #24
          Originally posted by Chewi View Post
          I experimented with this a while back and unless something has changed, I'm afraid a reboot is necessary.
          Well, indeed, something big IS CHANGING.

          Originally posted by Chewi View Post
          Once the open kernel drivers have been loaded, even if you manually unload them first, subsequently starting X under fglrx hangs the machine hard.
          You've probably missed the news, but AMD is considering to a new model where both Catalyst and Mesa/Gallium3D will share the same kernel drivers (instead of catalyst relying on a shim fglrx.ko like currently the case).
          So you won't have that much problems of handing the hardware in undefined state from one kernel driver to another.

          One of the main reason of not open-sourcing Catalyst (beside potential 3rd party license which by now are really minimal and non problematic, or digital restriction management, which by now on modern video subsystem can easily be isolated) is AMD needing to protect their "secret sauce". That part is mostly in the 3D part of the drivers. There aren't much trade secret that could be hidden in the simple kernel module.
          Thus, it's not impossible that, as AMD is considering, you'll have future version of Catalyst being the same open-source kernel module handling KMS and other low-level hardware management, and a closed source OpenGL and 2D accelerated rendering featuring AMD's secret leet optimisations, as an alternative to the default opensource Mesa, Glamor and Co.
          (and a much more simplified development in AMD not having to handle 2 different sets of back-ends, one open source module and one shim with the same boring functionality in Catalyst. And thus having to keep to sets of developers, etc.)

          Of course that would require development from AMD.
          In the meantime, it will also require some development from Epic to move from an early proof of concept (which currently uses openGL 3.3 anyway), to a stable production-ready OpenGL 4.4-featuring engine, and a nice library of deployed games on steam.

          Hey, who knows, maybe by then, you could even see a version of SteamOS that supports Wayland and hot-swapping of GL engines "optimus"-style. ( <- that's pure unfounded speculation )

          Comment


          • #25
            Admittedly I haven't had time to keep so up to date lately. That is indeed fantastic news. Thanks for the heads up.

            Comment

            Working...
            X