CrossOver Games Coming Out Tuesday

[Michael]

I forgot to mention this earlier, but CodeWeavers is releasing CrossOver Games this coming Tuesday. March 25, 2008.

[deanjo]

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

[niniendowarrior]

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

[Thetargos]

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.

[niniendowarrior]

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.

[Thetargos]

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.

[deanjo]

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

[Svartalf]

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.

[niniendowarrior]

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.

[niniendowarrior]

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.

[Svartalf]

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.

[Svartalf]

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.

[Thetargos]

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.

[niniendowarrior]

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.

[Svartalf]

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.

[Svartalf]

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.

Got it in one.

Unless you duplicate the Windows environment, with most of the issues with it- you have an increasing effort with each step away from something like WINE or Winelib that you go from that.

And it's the bulk of the work- not the tail end of it. It may comprise only 20-30% of the code- but it typically consumes 80% of your time doing it because the conversion from Direct3D to OpenGL is typically straightforward to those familiar with both APIs, but the stuff that you end up with from Visual C++'s encouragement of some very, very bad coding practices and design methodologies ends up consuming most of the time doing. It's easier to write BAD code that mostly works than it is to write solid code that works cleanly all the time. It's not much harder, mind, but many of the developers are seriously pressed for time because of unrealistic deadlines all the time. If it takes 10% longer to write it the right way instead of the half-assed, should work most of the time way- the half-assed way will get done every time. Heh...it'll get fixed on the next patch set anyhow, right? ;)

[Thetargos]

That's what happens when you have to deal with a half-baked compiler and development suite like Visual Studio. Sure, it will allow you to produce nice, clean, well thought through code, but it will also allow for aberrational code to be built, and worst, run. The time constraints are a very real impediment to get good code done, but in that even Microsoft's tools have caused many developers to shoot themselves in the foot, as allowing for slacker code to be built, has also been one of the reasons why there aren't many DirectX 10 games out. AFAIK, DirectX 10 based applications have to be much more cleanly coded and built in order for them to work reasonably well on a another half-backed platform like Vista.

At any rate, the point is the same, it poses quite a problem on porters to work with bad code and get it right (from what I also understand, some people also complain that even with full source access to the original code for the port work, more often than not it is very badly documented if at all, not to mention not very well commented). That is a problem in itself, as has the porter developers trying to find out what a certain part of the code is there to begin with, which more often than not, leads to building the original code with debug symbols, run it through a debugger to try and understand [i]what{/i] that code actually does.

[xav1r]

Really, is visual studio that lousy of a product? I thought that MSVC was microsoft's only good product line. Which other IDE/compiler would you consider to be good.

[Thetargos]

Is not that it is bad as such. But it does allow for aberrant code to be built, and won't even attempt to warn you. It also has a tendency to "do a lot of stuff" for you, in such a way that is not exactly the best, but many developers have become used to its templates. Obviously, these templates are Windows-centric only (what would you expect from Microsoft product?), which in turn gets in the way of portable code. Not to mention that even if it fully supports ISO and ANSI C/C++ notation, it doesn't encourage it.