Announcement

Collapse
No announcement yet.

CrossOver Games Coming Out Tuesday

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

  • CrossOver Games Coming Out Tuesday

    I forgot to mention this earlier, but CodeWeavers is releasing CrossOver Games this coming Tuesday. March 25, 2008.
    Michael Larabel
    http://www.michaellarabel.com/

  • #2
    Good it's about time someone put cedega out of it's misery.

    Comment


    • #3
      Hmm... Codeweavers is drawing up battle lines. I wish both of them focused more on porting than this crap.

      Comment


      • #4
        Though I would rather have efforts focusing on ports, the fact that there is a third line for getting games that already have been released for Windows and have them working on Linux and other i386 Unix systems, is actually a good thing. However, just like ninendowarrior it would be much better to have actual ports.

        I, however, understand the many impediments in the way of ports, and for starters if the parent company of a given product doesn't see a profit or potential market, they won't enable any other potential porter company to do it. In the mean time "compatibility layers and API wrapper code" will have to do.

        Comment


        • #5
          I do wonder at the development cost of building a devel library package that would accept the Windows game code as is and compile it under Linux. Perhaps the reality of it still has some port coding overhead, but I'd like to see something like this under GPL and have any game company just pick up the library and recompile.

          Comment


          • #6
            It'd be cool to have a program or plugin of sorts for "translating" code. Specifically it would be most useful if such a tool could translate DirectX code into SDL code. Problem is that automating such a task induces a lot of problems in itself, and the tool would have to deal with a lot of different coding styles, mistakes, and hacks, that alone makes such a tool almost impossible to write, because even if the DirectX functions, classes, objects and other API features are standard, it is the particular context in which these are used within an application's code that render automated translation almost useless. The best approach would be to actually write from scratch the applications with portability in mind, which thanks in part to the success made from some Linux distros and (some may say mostly) Apple's inroads into the market share, portable code may actually have become a priority for companies.

            I for one would love to see more companies use platform agnostic tools and libraries such as SDL, many commercial Linux games use it, and some don't, and SDL can even be used with DirectX and OpenAL (I'd almost say that's an ideal solution to deal with DirectX and OpenAL in Vista, in the absence of DirectSound), and could make things much easier for porters to focus on areas that don't have a native counterpart, like graphics with Direct3D and OpenGL, where translation from DirectX through SDL could be easier to do to OpenGL through SDL. I don't know of any commercial application or game that uses SDL on Windows or Mac. I'm not saying there aren't. Not even Blizzard (for which the founder and headmaster of SDL works for) uses it for their projects (that I know of, at least). I'd sure like to see more support for SDL from game developers.

            Comment


            • #7
              Originally posted by niniendowarrior View Post
              I do wonder at the development cost of building a devel library package that would accept the Windows game code as is and compile it under Linux. Perhaps the reality of it still has some port coding overhead, but I'd like to see something like this under GPL and have any game company just pick up the library and recompile.
              You mean like winelib?

              http://www.winehq.org/site/winelib

              Comment


              • #8
                Originally posted by deanjo View Post
                You mean like winelib?

                http://www.winehq.org/site/winelib
                Heh... If it were just that simple, we'd be using it for pretty much everything and have a lot more titles out than we do out of LGP, RuneSoft, etc.

                You have to replicate ALL the bugs for that to work that way- and even with 1.0, we really don't have that yet. May never have it. It's also worth noting that some of those bugs aren't in the ABI for Windows, but in VC++ which they use. It allows very, very attrocious things to be compiled and mostly work. Doing a winelib wrapper doesn't fix that or fix that you're binding against a Windows-centric view of everything. It's why WordPerfect for Linux isn't still selling. They used Winelib for the later on version of the product- and it sucked bigtime, as much for the bad code as the clunky result from using Winelib.

                Comment


                • #9
                  Originally posted by deanjo View Post
                  You mean like winelib?

                  http://www.winehq.org/site/winelib
                  Sort of. But I'm not happy with winelib. I just don't see it ever being anything substantial. Those guys are too busy trying to emulate Windows.

                  I just think the focal point should be on the api that developers use, not reimplementing Win32 API. It was just an idea anyway.

                  Comment


                  • #10
                    Originally posted by Svartalf View Post
                    Heh... If it were just that simple, we'd be using it for pretty much everything and have a lot more titles out than we do out of LGP, RuneSoft, etc.

                    You have to replicate ALL the bugs for that to work that way- and even with 1.0, we really don't have that yet. May never have it. It's also worth noting that some of those bugs aren't in the ABI for Windows, but in VC++ which they use. It allows very, very attrocious things to be compiled and mostly work. Doing a winelib wrapper doesn't fix that or fix that you're binding against a Windows-centric view of everything. It's why WordPerfect for Linux isn't still selling. They used Winelib for the later on version of the product- and it sucked bigtime, as much for the bad code as the clunky result from using Winelib.
                    Good point. I don't necessarily think about entirely reimplementing things. It's more like a wrapper api for something else. Perhaps reroute to QT/GTK and some to SDL and so on and so forth. But anyhow, it's never straight forward. Benefit-wise, I don't know how useful it would be, but it did sound like a good idea.

                    Comment


                    • #11
                      Originally posted by niniendowarrior View Post
                      Sort of. But I'm not happy with winelib. I just don't see it ever being anything substantial. Those guys are too busy trying to emulate Windows.

                      I just think the focal point should be on the api that developers use, not reimplementing Win32 API. It was just an idea anyway.
                      The big problem is, you're talking about an API that they've just barely gotten a handle on- and it's not something that people haven't done already (RealtechVR implemented a DirectX 8.1 wrapper that supported pretty much everything on the Direct3D side. The big problem is: when you're talking 9.X, etc. you're talking about HLSL and a host of other things that you need to support, bug for bug, for it to be useful to a developer in that way.) Far easier, I think, to move the code to a more cross-platform state than do that. It's as herculean an effort as doing WINE in and of itself.

                      Nice idea- but in all the years of people trying, we're only talking about WINE being 1.0 after all this time. And there've been attempts that have been shelved because they weren't worth the pain.

                      Comment


                      • #12
                        Originally posted by niniendowarrior View Post
                        Sort of. But I'm not happy with winelib. I just don't see it ever being anything substantial. Those guys are too busy trying to emulate Windows.

                        I just think the focal point should be on the api that developers use, not reimplementing Win32 API. It was just an idea anyway.
                        WINE is simply a DLL loader to allow you to force-load Windows binaries in a Unix world against Winelib.

                        WINE pretty much IS Winelib. WINE is pretty much a "lightweight" abstraction layer against the Windows ABI. It's that Windows is just that byzantine and screwed up.

                        Comment


                        • #13
                          Originally posted by niniendowarrior View Post
                          Good point. I don't necessarily think about entirely reimplementing things. It's more like a wrapper api for something else. Perhaps reroute to QT/GTK and some to SDL and so on and so forth. But anyhow, it's never straight forward. Benefit-wise, I don't know how useful it would be, but it did sound like a good idea.
                          The real problem starts at the coding of the original application, and not having portability in mind. That is what hinders all ulterior efforts for porting.

                          Comment


                          • #14
                            Originally posted by Svartalf View Post
                            WINE is simply a DLL loader to allow you to force-load Windows binaries in a Unix world against Winelib.

                            WINE pretty much IS Winelib. WINE is pretty much a "lightweight" abstraction layer against the Windows ABI. It's that Windows is just that byzantine and screwed up.
                            I don't believe that Wine is an abstraction layer in the sense that it simply remaps the Windows ABI into Unix. I think that Wine does a step further and tries to be a Windows ABI substitute on a whole different complex level, because they really attempt to reimplement the entire api and make an otherworldly binary think it's running on Windows.

                            I think that with Direct X SDK openly available and header files entirely readable, it might be possible to build a library that takes all that and rechannels them into something like SDL.

                            Of course, as you say, every DX version is an entirely different beast with even more complexities to work on. I just see it as part of a bumpy roadmap.

                            I hate to talk in percentages when dealing with code because it's barely quantifiable, but what I do hope happens is that at the very least a good 60 to 70 percent of the code works okay and that the the rest of the legwork is fixing up the code to work based on the porting library.
                            Last edited by niniendowarrior; 03-22-2008, 06:50 PM.

                            Comment


                            • #15
                              Originally posted by niniendowarrior View Post
                              I don't believe that Wine is an abstraction layer in the sense that it simply remaps the Windows ABI into Unix. I think that Wine does a step further and tries to be a Windows ABI substitute on a whole different complex level, because they really attempt to reimplement the entire api and make an otherworldly binary think it's running on Windows.
                              Unfortunately, with the way Windows binaries are written, you HAVE to make the code think it's running on Windows, even if you're "purely native". That's the problem. It's like a tarbaby.

                              I think that with Direct X SDK openly available and header files entirely readable, it might be possible to build a library that takes all that and rechannels them into something like SDL.
                              No offense... It's not that simple. We HAVE a Direct3D to OpenGL wrapper library for version 8.1- but 9 changed EVERYTHING. So did 10. You have to have a solid translator for shader based operations because everything uses HLSL, etc. and not basic vertex operations past DX8.1. It's five times more complex than you think it is.


                              I hate to talk in percentages when dealing with code because it's barely quantifiable, but what I do hope happens is that at the very least a good 60 to 70 percent of the code works okay and that the the rest of the legwork is fixing up the code to work based on the porting library.
                              Heh... THen you're talking the same thing as what I do after hours for LGP. And it doesn't get any easier if you have DirectX. Like I said...the thing happens to have nasty sharp edges that won't go away any easier than re-implementing the rendering layer. It just wouldn't help you any. Honest. It's why you don't see it all that often- and why some people keep trying to run winelib up the flagpole, because it'd be closer even though it's a lot more heavyweight than a port effort would be. What you're proposing isn't a magic bullet that'll get you 60-70% there- it's only something that'll get you 40% or so there, if that.

                              Comment

                              Working...
                              X