Announcement

Collapse
No announcement yet.

There Exists A Native Linux Port Of CryEngine 3

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

  • #16
    Originally posted by entropy View Post
    I wonder why they don't provide an Linux client for Crysis 2?
    Maybe they don't want to provide support.
    EA publish game, not CryTek.
    So EA make decisions about supported platforms, and they decide to not support even OS X in Crysis 2.

    Comment


    • #17
      Portable code?

      A game engine(not game) must be portable and modular. I heard in some developer discussion forum that a good way to achieve portable code is develop it concurrently on 2 platform. In this way any fully platform specific code won't go to the main logic part and the code is easier to port other architecture(I once heard WinXP was developed on non x86 machines). If they have a linux port thats most likely they're making code portable. Also may be(just may be) they were using Linux shell and other tools for development. That seriously does not means it will used for any Linux title or even if its Linux performance is even production level(I think this are totally different thing that a engine compile and run under linux and its giving a decent FPS on Linux).

      Comment


      • #18
        Originally posted by russofris View Post
        In other 5-year-old news... Any title that is available on PS3 has an openGL (EGL) renderer and an ELF binary available.
        No it doesn't. Yes, the PS3 supports a form of GL ES. No, no serious game on the PS3 actually uses it. It's a bit like how Windows supports GL but most games using D3D, except even worse.

        A very large part of this is because GL (and GL ES) are horrifically crappy APIs that have a lot of limitations in regards to contemporary PC graphics hardware, much less the very non-PC-like architecture of the PS3 (or XBox 360 or Wii, for that matter). No general-purpose graphics API is going to match the hardware of the consoles well, hence nobody uses general-purpose graphics APIs on the consoles.

        A lot of games on the consoles partially eschew any API and make use of directly writing opcodes to the GPUs. This works only because the hardware is completely locked to a specific architecture, unlike the PC. This also allows a level of efficiency that is impossible on the PC. One might remember the idiotic statements by a mid-level AMD executive about how DX12 might do away with an API in favor of direct machine-code GPU programming; the recent complete architecture overhaul of AMD's GPUs shows why that's retarded on the PC, even though it's entirely feasible on a console.


        In related news, it doesn't surprise me that Crytek has a Linux port. A lot of game engines that you dont' even know about have Linux ports. Some companies port to Linux because it's a cheap "proving ground" to porting to consoles, which often use a GCC-based compiler (albeit, an ancient shitty horrible disgusting pre-4.3/GPL3 version of GCC) which has a lot of incompatibilities with the PC game mainstay, Visual C++. Some engines have internal ports because an employee or two are Linux nerds. Some because Linux adds another cheap-and-easy bullet point to the feature list page which they use to sell to the executives at production companies. I've worked on two games using Linux on my primary dev machine (before I gave up on Linux ever being a real desktop and switched to Win7 on all my non-server machines), and no Linux binaries ever have been (or probably ever will be) released for those games. I know of at least one commercial engine which supports Linux _solely_ because the tech lead wanted to be able to use Valgrind every now and again; that same tech lead has been quoted as saying "Linux will never be a platform worth supporting commercially." (Granted, the same tech lead has said some rather silly things, so take that as opinion, not fact.)


        In unrelated topic land: can you guess why Unreal (and almost every other big commercial engine) is so popular in the industry? Hint: it has a lot less to do with the developers/engineers who make games and a lot more to do with marketing than you probably suspected. I've yet to meet an engineer who's worked with the Unreal technology and hasn't hated it. Basically, executives see the Epic demos and hear "buy in bulk now and get a huge discount," then go and buy a ton of licenses, and then tell their development houses to use the engine licenses they already paid for in bulk. This feeds a vicious cycle, where consumers buy more games based on some hyped-up engine, or where so-called "schools" like Full Sail or Devry or SMU "educate" a new crop of half-assed one-tool developers, or where more devs are conditioned into the crappy codebases, resulting in more industry adoption of crappy game engines that costs tons of money and require boatloads of time and effort to build a unique game on top of while flexible engines like Unity3D or in-house engine devs struggle to gain mindshare.

        Comment


        • #19
          Originally posted by elanthis View Post
          I've yet to meet an engineer who's worked with the Unreal technology and hasn't hated it.
          @Eleanthis, sometimes your comments annoy me, but on the technical side I am reading them with great interest.
          This time I don't want to be a dick,... just of curiosity - What is wrong with UEngine, and how you compare it to Source or IDTech4 for example?

          Comment


          • #20
            I agree with Drago. I have been working with the Unreal Engine (mostly the first two iterations), and while it is true that the demos do increase their popularity, but the reason for using the engines is definitely not that. It's pretty simple, really. When you are creating a game, why should you reinvent the wheel? UE is a complete game suite with excellent support for scripting, materials, meshes, renderers, audio and everything else a game needs. Plus, it has great tools for that. The UDK is another thing that makes it so popular - anyone can try out the tools that game developers themselves used, in a free (as in beer) manner, without any limitations, with the exception of selling your game and revealing proprietary code.

            Comment


            • #21
              I've also heard almost no one liking to work with Unreal in the past, but it may not be true anymore with UDK. Unreal Tournament 2004 is a little unstable on Linux, but does look nice and some of its mods like UnWheel also made it to Linux, which isn't always the true for mods.

              Edit: What GreatEmerald said.
              Last edited by downer; 04-05-2012, 11:58 AM.

              Comment


              • #22
                Originally posted by GreatEmerald View Post
                The UDK is another thing that makes it so popular - anyone can try out the tools that game developers themselves used, in a free (as in beer) manner, without any limitations, with the exception of selling your game and revealing proprietary code.
                The Cryengine seems to be available as well for free under a non-commercial license: http://mycryengine.com
                At least there are some header files present hinting some kind of Linux support, taken from this thread (aug. 2011).



                Of course, this does not necessarily mean that the Linux port is included in the SDK.
                Last edited by entropy; 04-05-2012, 12:18 PM.

                Comment


                • #23
                  Originally posted by elanthis View Post
                  No it doesn't. Yes, the PS3 supports a form of GL ES. No, no serious game on the PS3 actually uses it. It's a bit like how Windows supports GL but most games using D3D, except even worse.

                  A very large part of this is because GL (and GL ES) are horrifically crappy APIs that have a lot of limitations in regards to contemporary PC graphics hardware, much less the very non-PC-like architecture of the PS3 (or XBox 360 or Wii, for that matter). No general-purpose graphics API is going to match the hardware of the consoles well, hence nobody uses general-purpose graphics APIs on the consoles.

                  A lot of games on the consoles partially eschew any API and make use of directly writing opcodes to the GPUs. This works only because the hardware is completely locked to a specific architecture, unlike the PC.
                  While I understand that much of the OGLES API is often bypassed during the optimization phase, I do not believe that this disqualifies the the game from being an OGL game. The example of windows OGL/D3D is confusing to me, as I am unaware of any other API available on the PS3 (aside from the direct-to-hardware optimizations and cuda).

                  Ultimately, I agree with what you've said, but do not feel that optimized-for-PS3 titles no longer qualify as being "OpenGL Games". Perhaps my knowledge of the topic is simply dated and no longer accurate (It's been approximately 4 years), and there is some new fancy pants-to-the-metal API for PS3.

                  Comment


                  • #24
                    Originally posted by entropy View Post
                    The Cryengine seems to be available as well for free under a non-commercial license: http://mycryengine.com
                    At least there are some header files present hinting some kind of Linux support, taken from this thread (aug. 2011).
                    AFAIR linux headers were already a part of the CryEngine SDK when it was the Far Cry Mod SDK. These files are needed to build game binaries for Linux-based servers.

                    Comment


                    • #25
                      Linux may be used simply because it shares semantics with OS X, so developers that are distributed over the team, can use Linux as a surrogate in testing phase. At the end, OS X I think may be the target.

                      Comment


                      • #26
                        Originally posted by ciplogic View Post
                        Linux may be used simply because it shares semantics with OS X, so developers that are distributed over the team, can use Linux as a surrogate in testing phase. At the end, OS X I think may be the target.
                        You may be partially right. Mac shares the x86 architecture and OpenGL API. I'm not certain that mac games would use SDL and OpenAL though.

                        From a software-platform standpoint, I believe Mac has more in common with a PS3 than a Linux86 PC, including the Mach-O binary format (not ELF like linux). A couple days ago I took a look at my PS3, and it appears to be running a Mach kernel with some components taken from BSD (networking). Think of it as a powerPC mac with Mach-kernel+sony-gui and a funky memory layout, which is divided into two areas. I do not imagine that the thing is easy to develop for.

                        On the plus side, I have heard rumors that Microsoft, Nintendo, and Sony will all use ATI's tech in their next offerings. If they all use SI tech, then PC SI users may start to see titles ported over more easily.

                        F

                        Comment


                        • #27
                          Originally posted by ciplogic View Post
                          Linux may be used simply because it shares semantics with OS X, so developers that are distributed over the team, can use Linux as a surrogate in testing phase. At the end, OS X I think may be the target.
                          That doesn't really make any sense to me as the monthly cost of a programmer is about the same as the price of three high class Macintosh computers. I personally think it's dangerous to use Linux as a surrogate for OS X while testing (and vice versa), as XNU and Linux may handle some things differently.

                          Comment


                          • #28
                            Originally posted by russofris
                            Ultimately, I agree with what you've said, but do not feel that optimized-for-PS3 titles no longer qualify as being "OpenGL Games".
                            They're not programmed with OpenGL. Simple.

                            Even if you want to focus on PSGL (the GL-derived API Sony offers on the PS3), understand that it has a ton of completely non-standard, non-portable extensions that must be used to actually do anything interesting with the PS3 GPU. The games written with it are NOT GL games, because they aren't using any remotely standardized, portable, usable version of the API's managed by Khronos. The API looks like GL ES 1.x at first glance. That's where the similarly ends.

                            You might as well claim that XBox360 titles qualify as OpenGL games. Hell, it's actually _easier_ to port XBox360 titles to GL, since at least the modified D3D9-based API is closer to desktop D3D/GL than the crazy PS3-specific APIs used on Sony's console.

                            Originally posted by Drago
                            @Eleanthis, sometimes your comments annoy me,
                            You're such a sweetheart.

                            but on the technical side I am reading them with great interest.
                            This time I don't want to be a dick,... just of curiosity - What is wrong with UEngine, and how you compare it to Source or IDTech4 for example?
                            I haven't seen Unreal4's internals, so they may have finally gotten their act together, but I can't say. Also keep in mind that my "niche" is an engine lead, so I'm particularly critical of unsexy internal architecture things that certain other classes of developers don't notice, understand, or care about (graphics programmers in particular; yet to meet a graphics dev who doesn't write code that makes me want to gouge my eyes out with a rusty spoon, even if that code does produce ridiculously amazing results I could never replicate; graphics is all hacks).


                            Regarding Unreal, the problem largely stems from Unreal being over a decade old and originally built back in the bad-old-days. The engine's code is messy. The engine's structure is inflexible and at times incomprehensible. Like most old, monolithic, feature-packed codebases, it's just a nightmare to work with unless you've already been knee-deep in for years. It's also not designed for making things besides shooters, and doesn't have flexibility in the places you want it if you're trying to make anything that's not a shooter.

                            One of the more depressing aspects of the engine -- which I presume has been curbed somewhat given its ports to mobile platforms -- is how its object model works. (Aside: That's a long discussion in itself; I'll point you to http://www.objectmentor.com/resource...offeeMaker.pdf and http://cowboyprogramming.com/2007/01...your-heirachy/, and then just note that Unreal, Source, and idTech all do the complete opposite of what those links suggest. CryTek is a hybrid.) In Unreal, the base game object class used to take up around 2 kilobytes of memory. Every character, dynamic object, hell even every single bullet. Why? Well, those bullets had code to support a shitload of features that never ever would make any sense to have on a bullet, but because inheritance was used and abused to implement design-side hierarchies of object types, the base game engine had to have the features that any game object might want to use. Like camera bobbing, for instance. Every bullet had data members (and methods) to support camera bob, among a billion other features that couldn't be slapped onto a specific game object subclass because you never know where or when someone might want to use it. The end result is that most serious large games you saw developed with Unreal spent the first 3-9 months literally just rewriting, hacking, slashing, and fixing a giant mess of a codebase that was really only ever meant to be used for Unreal Tournment.


                            Source is actually related to idTech, being forked from the Quake 2 engine iirc. I have never used it myself, but a number of developers I know -- including a few Valve employees -- have quite unflattering things to say about it. Valve, however, has a rather interesting coporate culture, one which does not prize or seek out people that could be considered "tech leads" in the traditional sense. The engine is very organic; if someone needs something, it gets hacked in, and then they move on. The pile of hacks and hardcoded game-logic gets left in, which is why you can find bits and piecesof Valve's past game's game logic in their newer games. The engine has a huge technical debt. If you want to build a new game on it, you had better get ready to dive into the guts and hack it together with duct-tape and prayers.


                            The idTech engines are made for simplistic shooters. They are also inflexible. They are old. They are built like early 1990's game engines. Also, nobody actually licenses them anymore. idTech4 was only used in about 8 games. 6 of those were id's own titles. Of the other two, one flopped commercially ("bad graphics and repetitive gameplay" being one of the bigger complaints) and the other got cancelled before release. idTech5 also currently has no announced licensees, I believe. The old engines are now FOSS and so seem "cheap" to use, but even a small skilled team of game programmers can (and should!) spend a few months rebuilding the base tech and give themselves more flexibility and efficiency further along in the development process.

                            It's very cool and all that id Open Sources their old engines. I love it. All games should do that, IMO. The tech is old, but still valuable for those who want to see gaming art and culture live on for ages to come, and id should keep doing it.


                            All that said, keep in mind that these engines obviously still all work. That any of them is a pain in the ass to work with is not the same as saying that they're unusable, though I do know I tend to speak in absolutes and I've probably come close to outright saying that a few times. Unreal gets the job done. Source obviously can be used for some awesome games. CryTek has things going on. idTech has been used for great games like Doom3^WPrey^WRAGE^WQuake3.


                            One of the things that really irritates me when a lot of non-developers talk about engines is how everyone fawns over graphical tech demos, like Unreal or Unigine or idTech. You can slap amazing graphics into _any_ game engine. You don't even need a game engine at all to do amazing graphics, which is why projects like OGRE can even exist in the first place (don't take that as a recommendation for OGRE; never used it myself, so I have no opinion on it, could be great or it could be horrible). Graphics is 80% art assets, 15% smoke and mirrors, and 5% insane math code that has nothing to do with anything else in the game engine. Don't judge an engine based on how good its content people are; judge an engine on how easy it was for those content people to make that amazing-looking game/demo.

                            When you ask, "what is a good game engine," the answer _should_ be something that makes it very easy for developers, artists, and designers to quickly build new and interesting games with a minimal of bullshit. That means that the engine should not require months of heavy tweaking to get slight variations of functionality in. That means that designers should not need to ask programmers to write new C++ code for new uses of behavior that already exists in the engine. That means that artists should not be forced to learn new misdesigned/incomplete tools built-in to the engine that sounded good on paper; it also means that if external tools are used, artists should not be required to go through a 10-minute export/import process to get asset tweaks into the engine. The really good game engines allow designers and game logic programmers to build large, highly diverse, innovative games with lots of content while requiring no changes at all to the core engine code for each project.

                            Comment


                            • #29
                              Great post, thanks!

                              Originally posted by elanthis View Post
                              When you ask, "what is a good game engine," the answer _should_ be something that makes it very easy for developers, artists, and designers to quickly build new and interesting games with a minimal of bullshit. That means that the engine should not require months of heavy tweaking to get slight variations of functionality in. That means that designers should not need to ask programmers to write new C++ code for new uses of behavior that already exists in the engine. That means that artists should not be forced to learn new misdesigned/incomplete tools built-in to the engine that sounded good on paper; it also means that if external tools are used, artists should not be required to go through a 10-minute export/import process to get asset tweaks into the engine. The really good game engines allow designers and game logic programmers to build large, highly diverse, innovative games with lots of content while requiring no changes at all to the core engine code for each project.
                              So in the end, if I got you right on the rest of your post, this engine doesn't exist yet by far?

                              Comment


                              • #30
                                Originally posted by elanthis View Post
                                Game engine summary snipped
                                Thanks elanthis; that was informative.

                                Comment

                                Working...
                                X