Linux Game Publishing
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.Originally Posted by niniendowarrior
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.
Linux Game Publishing
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.
Senior Member
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.
Senior Member
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 at 05:50 PM.
Linux Game Publishing
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.
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 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.
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.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.
Linux Game Publishing
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?
Senior Member
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.
Senior Member
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.
Senior Member
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.
Posting Permissions
Reply With Quote