Slashdot Mirror


An Open Source Direct3D 8.0 Wrapper for Open GL

Jason writes: "RealTech-VR, creators of the V3X 3D engine, also developed a Direct3D-to-OpenGL wrapper and they have now open sourced their work. They are seeking for more hackers to help porting the wrapper to Linux and MacOS. A lot of the functionality of Direct3D is already ported but it still needs quite some work. Get the scoop at OSNews."

88 of 246 comments (clear)

  1. Interview with RealTech-VR by Anonymous Coward · · Score: 3, Informative

    Actually, OSNews has an interview with the guy behind the wrapper, and they even have some screenshots! I hope this wrapper comes to Linux soon!

    1. Re:Interview with RealTech-VR by sydb · · Score: 2, Insightful

      Moderators are becoming increasingly brain dead. Yeah, and I'm using my +1 bonus to make this point.

      --
      Yours Sincerely, Michael.
  2. Nice... by Anonymous Coward · · Score: 2, Insightful

    While this may validate the DirectX API as a standard (like it wasn't already) it may be a useful tool for gaming companies to do an easier port to Linux and OSX...This is good, really good.

    1. Re:Nice... by smagoun · · Score: 2, Interesting

      While it's been awhile since I've done anything in the 3D world, it seems to me that the slow parts were the drawing itself, not the API calls. As I understand it, what they've created is essentially an adaptor that passes calls from one API (D3D) to another (OpenGL). There will be some places that require a bunch of work, but I'm willing to bet that most of the translation is pretty simple. There might be a 1-5% performance hit with the D3D->OpenGL translation layer, but I wouldn't expect a huge performance gap.

      This is similar to what VMWare does for the Win32 API, isn't it? Performance there is a bit slower, but it's perfectly acceptable. As a mac guy, this is absolutely fantastic.

    2. Re:Nice... by GregWebb · · Score: 2

      I disagree. Well, sort of :-)

      Another poster has already commented on the speed issue (this meaning that Win32 remains the gaming platform of choice, and giving people erroneous reasons to believe why), but y'know what? This really solidifies the standard. No point pushing for that nasty OpenGL just to get the cross-platform stuff, use D3D. Which MS can control and push around however they want, to the detriment of this.

      I know that the ship has pretty much sailed on D3D as the standard, I know that cross-platform development at the moment essentially means making sure that the PC stuff can be ported to the X-Box. So I know my objections are essentially irrelevant, but it still makes me sad to see a development that can only help entrench a proprietary standard at the expense of an (apparently adequate and earlier, I'm not a 3D coder) open standard. This is a cool development and a useful development, but so much of what it signifies and what it has the power to create blows.

      (Why oh why oh why did the computing world let themselves become enslaved to the morons from Redmond? Oh well, back to trying to pull down their mountain with a toothpick...)

      --

      Greg

      (Inside a nuclear plant)
      Aaaarrrggh! Run! The canary has mutated!

    3. Re:Nice... by Wildcat+J · · Score: 2, Informative
      I haven't really done much with Direct3D, but as I recall it has both an immediate and a retained mode. OpenGL is basically an immediate mode graphics library. Of course, I'm not writing any graphics code these days, so take this all with a grain of salt ;) I welcome the any corrections from experts in the field.

      I believe that immediate mode is mostly a rasterizer for your polys. You (the programmer) are responsible for maintaining all of your model information, view parameters, and so forth. Whereas retained mode maintains more persistant scene information, making for a more general library.

      Anyway, the relevance is that, if retained mode functionality is required, it may take more of a performance hit because there is not a 1:1 correspondance of D3D to OpenGL calls. Keeping in mind, of course, that D3D Retained mode does this in software also, so I would imagine that a well-implemented wrapper could actually improve performance.

      I guess the question is, does anyone use retained mode?

    4. Re:Nice... by Com2Kid · · Score: 2, Insightful

      Sorry man, I hate to admit it (and trust me, I REALLY hate to admit it) but DirectX _HAS_ become a worthwhile standard.

      It just. . . . rocks.

      For the end user at least.

      It is uber-sweet to have everything working together.

      The ZSNES team went over to DirectX just because it made so much of their life easier. The controllers for starters. . . .

      A game that does a -good- job implementing DirectX control does not care how many buttons your joystick has, or how many joysticks you are using at once to control things.

      I have seen games where I can switch over dynamically from one controller to another with no problems. Sheeps is nice in this regard.

      But that is not what DirectX is all about.

      It is about having a -standardized- set of APIs that people can latch on to.

      Linux currently has the problem that there are a gazzilion different ways to access damn nearly everything. Sound cards, monitors, and so forth. Sure on the system level they (tend) to have the same way of doing things, but the game programmers cannot just say "heya, latch on to monitor 1 if that is all that is available, but if the person has two monitors latch on to monitor one for the primary view and pop up a dialog box asking the player if they want to have monitor two used for their rearview mirror."

      Nor is there just -one- way for a game to ask

      "Heya, I notice you have two separate sound cards installed, which one would you like to use for playing this game?"

      Of course there ARE game programing APIs to be had, and in fact there are plenty of them.

      Which makes it an absolute bitch for game developers to make requests for new features.

      Nvidia and ATI were recently able to strong arm Microsoft into including each companies choosen features into DirectX8. (ah, there are also now four pixel shaders versions, ugh. ATI's 1.4 card came out before Nvidia's faster 1.3 card, ::groans:: )

      still though, all in all having one central target to direct feature requests to is nice. This means that over time ALL of the necessary features will hopefully be added.

      But if you have multitudes of API standards, you can either get one that just fits you right with no extra baggage (yah for you) or more likely you will find that some of them have some of the features that you want but none of them have all of the features that you want. (yes sure you can add those features on, open source and all, but shit, then your company is learning a new API, adding to that API, and programming a game for that API, ouch.)

      DirectX streamlines stuff. Or at least the complaint and request part of 'stuff'.

      It may not be profound, and hell it may be full of bugs (heh, Nvidia cards have had some rather. . . odd. . . issues with DirectX from time to time. :) ) and misusing it may be far to easy for the game developers to do (THANKFULLY /most/ of them have learned that disabling alt-tab will just piss off most of your customers, and that it is also a big Plus is a person can alt-tab in and out of the application/game. I said most of them. . . . few damn stragglers left, grrr.)

    5. Re:Nice... by Com2Kid · · Score: 2

      DirectX is more then just a 3d standard now. Heck games on windows that use OpenGL for the graphics still often times (the majority of them) use DirectX for EVERYTHING else.

      In the interview it was said that hopefully somebody will port over other stuff besides Direct3d. I certainly hope so. DirectX makes everything so nice and seamless for the end user. :) (for one, joystick button 1 is joystick button 1 across all applications, heh. And joystick button 9 is joystick button 9, and so forth. Sound is also nice and nifty, it just /works/ damnit. To whatever level your sound card supports it works.)

    6. Re:Nice... by Stiletto · · Score: 2

      It is about having a -standardized- set of APIs that people can latch on to.

      One API to bind them all...?

      One of Linux's strengths is that there is always more than one way to do something. What if you (as a developer) don't like the way DirectX does something? Tough luck--wait for the next version.

      Having only one way to do something is not an advantage, if that way sucks.

    7. Re:Nice... by glassware · · Score: 2
      Having only one way to do something is not an advantage, if that way sucks.

      Having more than one proper way to do something leads to code bloat.

      The part I really like about having multiple interfaces is that one of them gets upgraded faster and becomes more robust, and I've usually chosen the other one because it was simpler. So my code gets out of date fast.

      One of the worst things Microsoft ever did to Windows was to have multiple, redundant APIs that each did roughly the same thing. You can accomplish the same task with WIN32, MFC, ATL, .NET, and so on down the line. The part that really bothered me was the scatterbrained implementation of multimedia. There were WINMM libraries, media player interfaces, text parsing launchers, direct function calls, and eventually COM wrappers.

      If you have one interface, and it's obnoxious and complicated, at least everyone knows what function they have to call.

    8. Re:Nice... by johnjones · · Score: 2

      people only use retained mode when you have to (alot of the time in a real game when you look at a spefic feature thats done in retain mode but the rest not)

      the point is that the nice thing about D3D is that it is supported by most vendors now look on a box that a game came in you will find that they require Direct X version 99.8 (-;

      the point is that although the API changes it can do the old api's in emulation

      much like OpenGL 2.0 will do

      all I hope is that ATI's String based extensions to OpenGL get in 2.0 rather than NVidia's so we aren't tied to their hardware

      D3D is crap(ish) what make Direct X so good is all the other API's like sound and input (OpenIL and OpenAL be damned as they just dont have the people leading them)

      so I have high hopes for the OpenGL ARB to produce something nice that IBM/SONY/APPLE/SUN/HP/3Dlabs can rock Microsoft's little world

      try haveing a look at
      http://www.3dlabs.com/support/developer/ogl2/index .htm

      regards

      john jones

    9. Re:Nice... by Com2Kid · · Score: 2

      MSI installers beat the royal crude outa Wise now days. :)

      Wise installers shove everything under ALL users (uh, BAD) and if any one user tries to remove it from their start menu, it is removed from everybodies start menu. . . .

      Suffice to say, leads to clutter.

    10. Re:Nice... by drzhivago · · Score: 2, Informative

      As a Mac guy, you should know the main problem with ports and the Mac. It is not Direct3D. Mac porters know how to go from Direct3D to OpenGL or RAVE, etc. The problem lies with DirectPlay instead, and has caused many Mac ports to be network incompatible with their Windows counterparts. DirectPlay isn't very difficult to use on Windows, which is why it is widely used. And annoying for Mac gamers.

      And as to your question about it being comparable to Wine (you mean Wine, and not VMWare right?), the answer is no, it isn't. It is source-code compatibility rather than binary compatibility. The code will need to be natively compiled to run on that platform. The only benefit is that you don't have to rewrite the 3D code because doesn't support Direct3D (only version 8). Wine uses the native Windows application.

      Greg

    11. Re:Nice... by JabberWokky · · Score: 2
      Linux currently has the problem that there are a gazzilion different ways to access damn nearly everything. Sound cards, monitors, and so forth.

      Okay, I'm just tossing this one out to chew on for a second. Other than soundcards, there is a standardized system in Unix to handle input and graphical output. It's called X. X also has incredible extendablity built into it - the most common API people use right now was intended to be a reference implementation. Right now, the RENDER extension is bringing nice 2D effects in.

      Well, why not just build DirectX into X? (Yeah, yeah, I know - "Well, get started then", "It's not easy", "MS controls the API"). But I am serious - if DirectX *has* become a working standard, then it should be supported on *nix. And the logical place to support it would be the system that handles all I/O, including graphics and pointing devices, etc. In otherwords, X.

      Even add sound to X - sound and video network transparancy is being built into many apps now (KDE's aRts and mcop, VideoLAN, etc), but it really should be at a lower level so all X apps get it.

      --
      Evan

      --
      "$30 for the One True Ring. $10 each additional ring!" -- JRR "Bob" Tolkien
    12. Re:Nice... by GiMP · · Score: 2

      Wouldn't that be:

      because Direct3D doesn't support the platform of your choice? :)

    13. Re:Nice... by spitzak · · Score: 2
      I agree with this.

      Also X seriously blows when even new input devices are considered, and these are things that were well known even when X was being designed (back then most graphics workstations had a bunch of dials and toggle switches and joysticks). The XDevice interface is a typical "extension" with enormously complex controls that NOBODY uses (this should be apparent as we were forced to make the mouse wheel pretend to click buttons 4 & 5 on the mouse, this interface was better and easier to program for than XDevice and without it I doubt you would see any mousewheel support on Linux).

      GL (not OpenGL) had it pretty much right. There should be a call that is "tell me what all the devices are". Each device can produce a single value that is either a number or 0-1 true/false (ie a typical mouse is 5 devices: x, y, and three on/off buttons). Each device has a string name, and it is up to the program to figure out if a device is interesting (ending horizontal things with x and vertical things with y and other pseudo-standards would make this almost transparent to the user). The program can then say "I am interested in this device" and it now gets an X event every time that device changes value. SIMPLE!

    14. Re:Nice... by sg_oneill · · Score: 2

      Actually GL is indeed a proprietry "standard", but it's generally treated , and to a degree allowed to behave as a standard. Of course DirectX is not a standard if only one platform supports it.

      --
      Excuse the Unicode crap in my posts. That's an apostrophe, and slashdot is busted.
    15. Re:Nice... by Com2Kid · · Score: 2

      "Other than soundcards, there is a standardized system in Unix to handle input and graphical output. It's called X. X also has incredible extendibility built into it - the most common API people use right now was intended to be a reference implementation. Right now, the RENDER extension is bringing nice 2D effects in."

      X is complicated. Hell we all know X is complicated. What is needed is a BeOS like system, or whatever else you may choose.

      X is nice, but, uh, isn't it time for Y? Or Z? Or something? I mean standards have to be updated sooner or latter. There is a reason why nobody is using B any more, it was supplanted (rather quickly :) ) by C. Of course C is far superior to B, which had many shortcomings, while X is a good system the fact is that it can indeed be improved.

      Ah, what the computing world REALLY needs though is some sort of cross platform driver set though. :( Give each device a 512K, 1024K, or 2048K ROM chip (Flashable or not, whatever) that can store a base driver that all platforms can then interpret.

      Of course getting ANYBODY to agree to this would be a MAJOR pain.

      Microsoft benefits from devices only working on their platform, and a good part of the rest of the computer community is highly unwilling to subscribe to any standard that The Beast Of Redmond also agrees to.

      But still, it would make like SO much simplier, and FINALLY allow for TRUE plug and play. (drivers? What drivers? Your video card, sound card, modem, NIC, etc, would all work once plugged in with no fuss what so ever.)

      The way such a driver system would most likely work is that it would provide an abstraction layer for the drivers to work on (thus allowing for the platform independency)and then interpret (yes I used a bad bad word. :) ) those drivesr for that platform. The drivers would only have to be interpreted the first time the device was plugged in (and you mine as well spend some time doing it, heh) and then they would Just Work Damnit.

      (basically I am saying write drivers in Java, C#, whatever. ^_^ Not likely Java, can Java even DO things like that??? I mean one device all platform type of a thing, heh. Obviously a custom language would need to be developed, since compatibility would come first.)

      Now each platform would THEN be dependent upon providing the driver interface panel and such.

      The driver would say

      "Give them a Gamma Adjustment option with Settings Such And Such, This and That, and So on And So On." and the individual OS, err, GUI, would be responsible for providing the controls.

      Hell even a text based console interface would work, it would just pop up a message saying "heya, buddy, edit this text file here, when your done run this script file and your setting will be loaded".

      The idea would be that I could plug in ANY device to ANY computer and have it work, just so long as the connectors matched up. :)

      No more printer issues, no more scanner issues, no more d*mn friggin driver CDs (heh).

      Anyways, just an idea, it would be hard to implement and performance would likely take a significant drop (serious limits would be put on hardware based optimizations, since even just putting in flags saying that such and such section of the code is for the Windows plateform and what not would in itself start to cause driver developers to once again start writing for that one platform. . . .), but darnit the pay off would ROCK.

      (and the desire to keep the additional cost of the ROM chips down would also hopefully encourage companies to stop writing TWENTY FRIGGIN MEGABYTE driver files! What the HELL is up with that????? SHIT. That sucks. A lot. Nobody should not have to wait an hour to download drivers. . . ever. . . . Grrr. ::starts swearing in Creative's general direction:: )

  3. Big Step by Renraku · · Score: 2

    Not sure if other parts of DirectX work under Linux/MacOS, but this is certainly a big step for them. If they can get some DirectSound wrapper up and running, Linux/MacOS users would almost be home free to play Windows games. Only a few more things would have to be done.

    --
    Job? I don't have time to get a job! Who will sit around and bitch about being broke and unemployed then?
  4. Implementation into Wine? by XRayX · · Score: 2

    I'm not very much into Wine Development, but it should be possible to integrate parts of this into Wine. If it's possible, then Linux DirectX Gaming Heaven isn't too far away, even without WineX...

    --
    Boycot? Blackout? Subscriptions?
    I don't care!
  5. DirectX wrapping of OpenGL -- too slow? by slithytove · · Score: 4, Informative

    I'm a game developer working on the Nel platform. I've only dealt with app level code so far, but from my few perusals of the lower levels of the library and my browsings of simple directx code, it seems as if the complexity would make for pretty slow and buggy engines.
    Extra layers obviously have that property in general, but I see it as the wrong place to create that cross compatability. The nevrax team has said in the past that they have designed the system to be able to replace the OpenGL bindings with DirectX or gamecube api (what is gc api like?)
    I hope that more developers will build games based on Opensource engines as our company is (in-orbit.net)- it has saved us a lot of money and allowed us to focus on gameplay and uniqueness.

    1. Re:DirectX wrapping of OpenGL -- too slow? by dair · · Score: 5, Informative
      I've only dealt with app level code so far, but from my few perusals of the lower levels of the library and my browsings of simple directx code, it seems as if the complexity would make for pretty slow and buggy engines.
      Probably not - my day job for the last 6 months was the Mac port of Black & White, and we wrote a similar D3D->GL shim for that. Mapping from one API to the other is fairly straightforward, and the most expensive part of both is simply shoving the geometry/texture data down from the app to the API (assuming you cache out redundant state changes).

      It doesn't really matter if that goes down through DrawPrimitive (D3D) or glDrawElements (GL): if that's your bottleneck, the cost is pretty much the same either way.

      -dair
    2. Re:DirectX wrapping of OpenGL -- too slow? by MrResistor · · Score: 2
      I suspect that, at least in the Linux case, any performance hit could be made up for by killing the GUI when/before starting the game, thus giving the game access to resources it wouldn't have under Windows. Not really sure how much of a difference it would really make, though.

      --
      Under capitalism man exploits man. Under communism it's the other way around.
  6. SDL integration by moebius_4d · · Score: 5, Interesting

    It would be useful to (re)build this on SDL so that they don't have to re-invent the wheel for audio, 2D, etc. (all the non D3D parts). Already SDL allows (hell, requires) you to call OGL directly when you need 3d accel. So by implementing their calls as an SDL layer they would lose nothing and gain a very nice cross-platform layer.

    1. Re:SDL integration by Cuthalion · · Score: 4, Informative

      SDL provides kind of a minimal interface, which makes it really easy to pick up and learn. If you want to expose / accelerate all the features that DirectX does, you'd need a significant rewrite or extension of the SDL API.

      Just to provide one example (there are many others): In DirectDraw when you're blitting a sprite, you have the option of flipping it horizontally. There's no way to do that with SDL - you have to store two copies of your sprites if you think you'll want to blit it facing the other way. Or do it by hand each blit, but then you're not geting HW accel.

      Now this may be a concious design decision. A complaint I have about DirectX IS that it's interface is sort of boroque. For the most simple of blits, there's a lot of unused parameters, which is kind of irritating, and makes the code harder to read and the interface harder to learn. My initial reaction to SDL was "This is great - it's so easy!" until I started noticing not-so-advanced features that are missing. I've basically concluded that if I want any kind of powerful 2d support I might as well just use OpenGL directly rather than fuck around with SDL's hamstrung (but admittedly very easy to use) interface.

      So the upshot: DirectX is a proper superset of the SDL functionality, so writing an SDL plugin for directx would be a losing proposition at best (never minding the issues of adding a second, or on some platforms, third, layer of abstraction in what is already a time-critical interface)

      ps: don't even get me started on SDL_mixer

      --
      Trees can't go dancing
      So do them a big favor
      Pretend dancing stinks!
    2. Re:SDL integration by CoughDropAddict · · Score: 3, Insightful

      SDL provides kind of a minimal interface, which makes it really easy to pick up and learn. If you want to expose / accelerate all the features that DirectX does, you'd need a significant rewrite or extension of the SDL API.

      SDL has had the ability to create OpenGL contexts for a long time. And we're talking about Direct3D, not DirectX, so the DirectDraw example doesn't apply.

    3. Re:SDL integration by CoughDropAddict · · Score: 2

      Actually if you bothered to read the parent of the post you're responding to, they mean all of DirectX... These people may only be working on a Direct3D wrapper, but that was a criticsm the parent of the post you replied to was making; that it was just Direct3D...

      Re-reading the original message, I can see how you interpreted it that way, and perhaps that's what the poster meant. It was ambiguously written, however, and this was my reading:

      "Wow, using this Direct3D wrapper would be great for writing games! But it only provides 3d functionality, I'd like to be able to use SDL for the rest. I hope they integrate these wrappers into SDL so that I can use Direct3D calls for 3D and regular SDL calls for the rest."

      In the future you should use that +1 more conservatively, since your response is off topic at best, or just another troll with a +1...

      Your implied belief that /. comment ratings have some kind of sanctity that needs to be protected is quite amusing (a quick sample of the god-awful "jokes" rated +5 funny is more than enough to purge me of any "guilt" for using a +1 by default). Being called off-topic for directly replying to a parent's subject matter is even better. But the very best is being called a troll by someone whose comments default to Score:0. Thanks, you've made my day.

      See sig. Consider #3 dedicated to you.

  7. good news.. by Suppafly · · Score: 2

    This seems like good news for those of still stuck with 3dfx brand chipsets..

    1. Re:good news.. by BrookHarty · · Score: 2

      not reslly, the cards do ok in directx already, its opengl that they have a hard time on.

      Most 3dfx users (I have a voodoo5) use WickedGL drivers for opengl games.

  8. Direct3D and the Mac by feldsteins · · Score: 4, Insightful

    I have always viewed Direct3D as a Really Bad Idea for the Macintosh platform. I mean, that's all we need is to hitch our 3D waggon to Microsoft. We'd always be a version behind, some features would never be implimented, etc. And then when all game manufacturers were using D3D, whoops! Microsoft isn't supporting D3D on the Mac anymore.

    Even some game developers I have spoken to seemed pretty positive about the idea. "if only we could do D3D," they said. I think otherwise for the reasons stated above.

    And what does this new "wrapper" mean to us? I hope it doesn't mean that Game developers or porting companies don't bother with the OpenGL conversion (when necessary). For if this turns out to be the case I fear the sceneario above may come to pass in the long run. Bottom line is, this scheme seems to still leave 3D on the Macintosh platform vulnerable to the whims of MS.

    --
    You like your Macintosh better than me, don't you Dave? Dave? Can you hear me Dave?
    1. Re:Direct3D and the Mac by imac.usr · · Score: 2
      Bottom line is, this scheme seems to still leave 3D on the Macintosh platform vulnerable to the whims of MS.

      It may already be too late to prevent that, I'm afraid.

      --
      I use Macs for work, Linux for education, and Windows for cardplaying.
  9. What about WINE? by Anonymous Coward · · Score: 3, Informative
    It appears that this project,
    ("Direct X 8 port only support DirectX Graphics. The DirectX Graphics for BeOS is an OpenGL wrapper for the Microsoft® Direct3D API. Application written in Direct3D 8 will be able to compile on BeOS platform. At execution, the Direct3D 8 functions will be converted into the OpenGL ones with a minimal performance loss.

    is a subset of WINE.
    After all, The Sims uses DirectX and works over WINE. (I'm sorry, I can't find a link.)

    1. Re:What about WINE? by MikeTheYak · · Score: 2

      Actually, Transgaming had to create a custom version of The Sims to get it to work. Unfortunately, it's not straight emulation.

      http://www.transgaming.com/gamefaq.php?gameid=9 (see the question about running the Windows version of The Sims and the one about expansion packs)

  10. A good idea? by tempest303 · · Score: 3, Insightful

    Is this really such a hot idea? Compatability is cool, but wouldn't developers' time be better spent improving or coding for OpenGL?

    1. Re:A good idea? by Mr.+Sharumpe · · Score: 2, Insightful

      Is this really such a hot idea? Compatability is cool, but wouldn't developers' time be better spent improving or coding for OpenGL?

      It doesn't really matter - games are already coded with DirectX, and OpenGL already exists. If it is not the best thing (or, rather, the MS thing) the majority will code to DirectX. If you want their games, you have to use the API they use. I don't they will switch to OpenGL even if there are some improvements, because DirectX will always be tied in to Windows more closely than any third-party API.

      Mr. Sharumpe

      --
      -- The above comments are just my opinion. If you are going to flame me, save your time. I am fireproof.
  11. SDL/OpenGL vs DirectX OR the end of open standards by XRayX · · Score: 4, Insightful

    I'm not sure if this is a good thing. Of course it might be great to have something like this integrated to Wine to play DirectX Games under Linux, but if the other wrappers (DirectSound/Input/Play etc.) are implemented and run something stable, me as a game developer would think twice about porting this to truly open standards like OpenGL and SDL ("Why don't use the DirectX wrapper?").
    So if you see things on the long run, this might be more a damage than a boost to native Linux/OpenSource game-development.

    --
    Boycot? Blackout? Subscriptions?
    I don't care!
  12. Allways nice.... by Otis_INF · · Score: 5, Interesting

    It's allways nice to see a v0.0.2 version of a project that tries to port COM to Unix.

    Because _THERE_ is the real challenge. Not the polypusher-code to transfer d3d calls to opengl calls. Besides the lefthand-righthand difference between OGL and D3D ofcourse.

    D3D is COM based, OpenGL is plain C. Of course, COM is just a pile of C interfaces, but still, coding D3D is using binary objects with methods and properties. OpenGL is just a global canvas with global functions. I sincerely doubt this will ever succeed for 100%.

    --
    Never underestimate the relief of true separation of Religion and State.
  13. Amen to that! by pb · · Score: 3, Interesting

    DirectX support in Wine is pretty bad, and could definitely use something like this. Of course, OpenGL support in Wine has it's own problems, but this can only be a good thing for porting to non-Windows platforms.

    I don't know if it's a good thing for Wine or not, though, because I couldn't find any details of the license. Wine is released under an artistic style license, so if this thing is GPL (or similar) it couldn't get merged directly into Wine.

    However, they seem like nice enough people, so hopefully the Wine folks will check into it... Otherwise, we'll end up with a forked, GPL-compatible version of Wine for gaming, which wouldn't be so bad, but would be less than ideal.

    --
    pb Reply or e-mail; don't vaguely moderate.
    1. Re:Amen to that! by the_2nd_coming · · Score: 2

      the License is BDSL

      --



      I am the Alpha and the Omega-3
  14. Re:SDL/OpenGL vs DirectX OR the end of open standa by Nerds · · Score: 5, Interesting

    If I could get DirectX games to play on a linux machine I guarantee there are at least 15 people I could have running Debian by the end of the week. It's a good thing.

    Let's just be crazy and say this happens and everyone starts throwing their Windows CDs in the trash. One of two things might happen:

    1. Developers say "Let's just keep writing for DirectX, the wrappers work." So what? A Microsoft technology sticks around, but if so many people are leaving Windows, MS won't really have the power to enforce changes to DirectX 9 that would make it incompatible, because the devs will ignore them.

    2. Developers decide that since everyone has a linux box anyway, why not write in OpenGL since it would probably be more efficient?

    Either way, who cares? A working DirectX wrapper would win users over, and that's a good thing.

    --
    My other .sig is 'The Art of Computer Programming'
  15. Wouldn't it be quicker... by volpe · · Score: 4, Funny

    ...to just walk around Redmond with a big "Sue Me" sign on their backs?

  16. Too bad . . . by Anonynnous+Coward · · Score: 2, Funny

    . . . this came too late for Loki.

  17. Re:what license by spt · · Score: 3, Funny

    Picking a file at random (dsetup.h) shows


    *
    * Copyright (C) 1995-1997 Microsoft Corporation. All Rights Reserved.
    *
    * File: dsetup.h
    * Content: DirectXSetup, error codes and flags


    so, whatever license the DirectX SDK comes under I guess.

  18. Make it a non issue by DeadBugs · · Score: 4, Insightful

    STOP buying D3D games
    KEEP buying OpenGL games

    --
    http://www.kubuntu.org/
    1. Re:Make it a non issue by Cryptnotic · · Score: 3, Insightful
      That's not really practical for the large majority of game buyers. It would be like telling Americans to stop speaking English. And since Microsoft has gotten DirectX into game consoles (Dreamcast, X-Box), developers have a strong incentive to develop using only DirectX (Easy ports of DirectX games).


      Cryptnotic

      --
      My other first post is car post.
    2. Re:Make it a non issue by Ryan+Amos · · Score: 2

      Well, that, and the fact that OGL is a generation behind D3D. This is a non-issue right now, but in the 6 months it won't be. OpenGL development is much slower as it has to be done on many platforms at once, while MS and NVidia pretty much design the D3D spec to run on Windows and NVidia hardware, and then they let ATI and Matrox catch up later. Pretty soon we'll start to see games that don't support OpenGL, or where OpenGL is more or less unusable.

    3. Re:Make it a non issue by Steveftoth · · Score: 2

      WinCE in the DC was a proof of concept implementation. Only about 5 games actually used it. Almost all of them used the SEGA OS. The only game I know of for the DC that used it was the Sega Smash Pack. All the realy good games (Shenmue, Soul Calibur, Jet Grind) used the sega os because it was better/faster/etc. They just made Sega put the logo on the machine.

      DirectX isn't a bad technology, actually the only real difference inbetween DirectX and OpenGL is that DirectX is not easily expandable by the HWmaker. In OpenGL, Nvidia can add whatever crazy feature they want to their card and provide a function in their OpenGL driver to use it. However, with Direct3D you cann't use that feature until MS updates their API. Advantage OpenGL. However, In Direct3D, all functions that the API specifies work, since they are all emulated with software if the HW doesn't support them.
      Really, you have to think of DirectX as a platform, in the same way that the PS2 or the GameCube is a platform.

    4. Re:Make it a non issue by Cryptnotic · · Score: 2
      They just made Sega put the logo on the machine.

      Actually, Microsoft probably paid them to put it on the machine. Unfortunately, that didn't save them from unprofitability.

      Cryptnotic

      --
      My other first post is car post.
    5. Re:Make it a non issue by nihilogos · · Score: 2

      and then they let ATI and Matrox catch up later

      My ATI Radeon 8500 get better results than my brother's gf3 does on benchmarks and when playing tribes 2. I don't care that it was released a few months later.

      And read this

      And 3D API's don't provide functionality. 3D Card manufacturers do. D3D can invent any sort of wonderful function they like but if there aren't cards to support it then it is useless. AFAIK nvidia and other card manufacturers are still committed to providing opengl support. Go to nvidia.com and you can read The NVIDIA DetonatorTM XP Unified Driver Architecture (UDA) delivers new performance optimizations and features in both DirectX® and OpenGL®

      --
      :wq
    6. Re:Make it a non issue by Dwonis · · Score: 2
      a few diehard holdouts, notwithstanding

      You write as if id is insignificant, which is clearly not the case.

    7. Re:Make it a non issue by Steveftoth · · Score: 2

      If you knew that, then why did you say that MS made the OS for the DC?

    8. Re:Make it a non issue by Cryptnotic · · Score: 2
      I didn't. I said they've "gotten DirectX into consoles (Dreamcast, X-Box)", which they did. In the Dreamcast case, as I am sure you know, they ported WinCE w/ DirectX to the Dreamcast platform. I think Sega thought this was going to be a good idea since they'd get ports of PC games on Dreamcast, where they'd get licencing fees. That didn't really happen. If their contract with Microsoft stipulated that they had to pay a per Dreamcast licence fee for WinCE, that cost could have contributed to the failure of the Dreamcast.


      By the way, I love the Dreamcast. I own 3 of them (2 U.S. and 1 Japanese) and something like 30 games.


      Cryptnotic

      --
      My other first post is car post.
  19. Re:SDL/OpenGL vs DirectX OR the end of open standa by XRayX · · Score: 2

    good point. It overall reminds of the .NET/Mono situation: It is good to have supported as much as possible under Linux, because that will make the people use it or develop for it (hopefully).

    --
    Boycot? Blackout? Subscriptions?
    I don't care!
  20. useful? not really by mysticbob · · Score: 3
    so, this is useful why?


    will it help people port to other platforms? doubtful, as they're probably using other ms stuff if they're using DirectX.


    will it help people use more advanced features on other platforms? no, since they're just using underlying opengl (and extensions) anyway, which they could do in the first place.


    is it more performant? no way - it's another layer of indirection, so it's at least an additional pointer dereference, and extra stuff on the stack.


    so i'm left thinking this is a solution in search of a problem. if you want portability, you write to opengl. if you want extensions, you use the _portable_ extension mechanism that opengl already provides. check out nvidia's directx vs opengl extension comparison some time - guess which one has better & more support? hint, it doesn't start with direct..


    so, again, why would any sane developer write to this?


    (and yes, i read the faq.)

    1. Re:useful? not really by josepha48 · · Score: 2
      It may help the wine project. They would not have to implement teh Direct X stuff they could require this instead. This may give games a little more speed when running under wine on Linux/UNIX.

      I think at some point Linux will have added enought window's ness and windows will have added enought BSDisms that at some point they will be not that far from each other. Of course that will be the end of the 'OS wars'.

      --

      Only 'flamers' flame!

  21. mod up by Bastian · · Score: 2, Redundant

    I doubt this project is going to succeed, and, if it does, I doubt even more that it will be able to keep up.

    If you REALLY want games for your system of choice, try voting w/ your money

  22. Re:Useful... by praedor · · Score: 2

    This is the only game left in town. Loki is tits up. Virtually no one is willing to entertain linux ports of games. Recall that idSoftware tried it and it failed. Few bought the linux versions - they couldn't wait and bought the windoze version instead.


    Fortunately, idSoftware still releases linux ports of their game binaries for free but they require you to buy the windoze version to work. With the paucity of linux users willing to actually buy software or their unwillingness to wait a month or 3 for a linux port (ala idSoftware), there is ZERO reason or incentive for anyone to support linux games.


    We are left with such things as WineX who are focusing wine development specifically on games (checkout their site, there are quite a few games that run well using WineX. Many do not require windoze at all, even for the install).


    If you want linux-native games, it's too late but you COULD try to NICELY encourage companies to do what idSoftware now does and release (unsupported) linux binaries for download. That is more likely to work than trying to get anyone to actually release boxed linux games. WineX and perhaps this DX8 translater are the only game in town (pun intended).

    --
    In Bushworld, they struggle to keep church and state separate in Iraq as they increasingly merge the two in America.
  23. Wow... by mfos.org · · Score: 2, Funny

    Now we can use a $5,000 OpenGL card to play any DirectX games

  24. OpenGL does not handle the following: by yerricde · · Score: 2

    OpenGL is what we call source-portable...anything that's legal openGL will work any openGL environment. So what's platform-specific in this code?

    OpenGL does not handle windowing, that is, actually creating a surface on which to draw. OpenGL also does not handle input (DirectInput), audio (DirectSound/DirectMusic), or video (DirectShow). GLUT handles windowing and video to an extent, but AFAIK, standard GLUT can't go full-screen, read joysticks, or read more than one keyboard key at a time.

    --
    Will I retire or break 10K?
    1. Re:OpenGL does not handle the following: by spitzak · · Score: 2
      Old GL (from SGI before OpenGL) did have calls that created windows and read input devices. There was a design problem so that programs pretty much had to run busy loops and read variable devices, but the idea was there. Vastly simpler than X or Win32GDI. It is really too bad SGI did not think that these calls should be part of OpenGL.

      On those old machines, which ran at maybe 5Mhz, the entire interface (buttons, menus, text editing, etc) was done in GL, and as far as I can tell it works as well as modern X does on 1000Mhz machines. And if you wanted 3D you did not have to learn anything new!

      Oh well...

  25. Re:Open Source Direct 3D Wrapper Means by praedor · · Score: 2

    Sheesh. Has NO ONE heard of WineX? Mandrake Gaming Edition (incorporating WineX from Transgaming?). Take a look at the list of games that work with WineX. It is impressively long - and it already incorporates a lot of DX8 support in it. There is more wine than that bottled at winehq.


    Winehq DOES benefit from Transgaming's work, by the way.

    --
    In Bushworld, they struggle to keep church and state separate in Iraq as they increasingly merge the two in America.
  26. What license? by Have+Blue · · Score: 2

    If it is GPLed or any similarly viral license, the game industry won't touch it with a ten-foot pole.

    1. Re:What license? by LinuxGeek8 · · Score: 2

      It sounds to me like a BSD license

      Taken from dxglwp-src-0.04.zip
      /projects/src/d3d.cpp

      File: d3d.cpp
      Description: Direct3D 8 Wrapper
      Copyright: Realtech VR 2001

      Permission to use, copy, modify, distribute and sell this software and its documentation for any purpose is hereby granted without fee, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation. Realtech makes no representations
      about the suitability of this software for any purpose.
      It is provided "as is" without express or implied warranty.

      --
      Well, don't worry about that. We can get you back before you leave. (Dr. Who)
  27. WINE integration? by IGnatius+T+Foobar · · Score: 2

    This could be super useful for the mainline version of WINE ... Direct3D support can be in the main tree now.

    If nothing else, this could pressure TransGaming into putting their Direct3D code into the main WINE tree.

    Either way, WINE gets Direct3D support. Check off one more box on the list of things needed for full Windows compatibility. (And then buy native Linux apps anyway because it's a good idea.)

    --
    Tired of FB/Google censorship? Visit UNCENSORED!
  28. why would by Ender+Ryan · · Score: 2
    Why would any sane developer even touch D3D in the first place? I can understand direct input and direct draw. Windows had absolutely horrible 2D graphics and input performance, but why even touch D3D when OpenGL has always been better.

    After 7 YEARS (or is it 8, or only 6?) D3D is finally at the performance level of OpenGL(arguably not, seeing as how Q3A STILL outperforms games with similar graphics today).

    When D3D was first created by MS, it was an extremely unstable, lousy performing, moving target! And don't even think about upgrading D3D, your current set of games probably won't work! And on top of everything else already wrong with it, it is completely non-portable! Why the fuck did anyone adopt it in the first place?

    --
    Sticking feathers up your butt does not make you a chicken - Tyler Durden
  29. Good, bad, or ugly? by prototype · · Score: 3, Interesting

    This is not some kind of holy grail that everyone is looking for so stop it right now. OpenGL, which is a far better API IMO (and John Carmack thinks so too!) is and has always been the defacto standard portable API to code against. I will admit that recently with DX8, things got more in line with OpenGL and the D3D API is better than it was, but it's still COM based and completely not portable (among other problems). This product is just a wrapper to make COM look like C++ objects and underneath, make OpenGL calls.

    So what does this give us? It does NOT give us a WINE implementation of being able to run DirectX apps. Yes, you could integrate the code into WINE but it's meant to wrap functions at the source level, not the executable level. It does give us a wrapper that DirectX code can, for the most part, compile against and product a working Linux/BeOS/Mac exectuable. So for the game developers it might mean their DirectX code will compile on other platforms, but any good game company would have abstracted out their graphics code so it would be API independant. That's what most of them do already and some do offer OpenGL/DirectX selection for rendering. Why they don't produce Linux versions of their apps if they can simply call OpenGL instead isn't clear, but that's their decision.

    So are developers going to take DirectX code and compile against this to produce Linux OpenGL executables? I doubt it. Anyone who has coded their graphics sub-system directly against DirectX has probably coded other parts directly against the Windows API and if they haven't ported it to Linux already, they probably won't. Those that already have a clear decoupling of the graphics and the API don't need to and again, if they haven't ported they still won't for whatever reason (most likely support/business cases/etc)

    On the flipside, I do applaud what these guys did as it is a big undertaking to wrap a system as big and complex as Direct3D so congrats and perhaps for the garage developer, it might be useful but to those people I say just code in OpenGL in the first place.

    liB

    1. Re:Good, bad, or ugly? by be-fan · · Score: 2

      Umm, these days OpenGL 1.3 isn't really better than DirectX 8.0+. In fact, its probably worse because so many important features are implemented as extensions rather than parts of the standard proper. One the reasons why 3D Labs is proposing OpenGL 2.0, is because modern graphics accelerators are moving away from the traditional pipeline. DirectX has followed these changes while OpenGL really has not.

      --
      A deep unwavering belief is a sure sign you're missing something...
  30. Re:Just what we DON'T need, MS API's in Linux by Ryan+Amos · · Score: 3, Insightful

    What sort of crack are you smoking? Extra compatability is always a good thing. Get the notion that Microsoft has nothing to offer out of your fucking head. At some point, Linux has to grow up beyond the "fight-the-power" angst-filled culture that is quickly alienating it from the corporate market (wonder why you don't see quite so many people pushing Linux anymore? It has a bad rep in corporate America.) If you're in favor of a less functional operating system just because "Microsoft is evil! Fight the man!" you need to grab a bottle of Clue (tm) and take twice daily. Sure, I don't approve of everything Microsoft does, but you don't see me running around like a spoiled 6 year old who is mad because a girl wants to play with his friends.

    Karma to burn, baby.

  31. I send you this api to have your advice... by Mongoose · · Score: 4, Informative

    Listen kids this is an early alpha of a D3D wrapper for WinGL, with minor ports of MacGL and others. This isn't DirectX, which handles the input, sound, and even ( directplay is horrible ) networking.

    Things to note:

    1. D3D is a huge moving target itself
    2. This project doesn't support full D3D ( ATI/NV )
    3. D3D isn't a 'standard', it's rewritten every release

    Keeping these things in mind you won't get your windows games on linux, you won't get a wrapper for D3D for all GL cards, and you won't even get a finished release of this. I don't mean to sound negative, but by the time they have all the NV/ATI extentions supported DX 9.0 and maybe even OpenGL 2.0 will be out with an all new shader systems.

    Too bad vertex and pixel shaders won't be used much until another few generations. You have to wait for the target (mainstream) consumers to get at least something like a GF3 or similar first generation consumer card shader support. However, I will say that doesn't mean you won't have some games and applications just requiring you to get a card with support or offer it as a runtime enabled option.

  32. bullstuff! by Ender+Ryan · · Score: 2
    As I said, it's only now, 7 or 8 years later, that D3D is up to the performance of OpenGL. If that effort had been put into OpenGL, it'd be even better.

    --
    Sticking feathers up your butt does not make you a chicken - Tyler Durden
    1. Re:bullstuff! by ethereal · · Score: 2, Insightful

      If Microsoft had put the effort into the open standard, then they wouldn't be Microsoft, now would they? The whole point of having your own proprietary API is developer lock-in. The sad thing is that developers seem to fall for it pretty frequently.

      --

      Your right to not believe: Americans United for Separation of Church and

  33. Not much there by gavriels · · Score: 5, Informative

    While it sounds all nice and all, there is very very little that is actually supported in this library. Most of the Direct3D functions are simply stubs, and this library would be absolutely incapable of running anything more complex than the rotating-cube demo they have a screenshot for. They are about where we were 18-20 months ago, and this is certainly not keeping me up at nights.

    -Gav

    --
    Gavriel State
    CEO & CTO
    TransGaming Technologies Inc.
    gav@transgaming.com

    1. Re:Not much there by IGnatius+T+Foobar · · Score: 4, Insightful
      They are about where we were 18-20 months ago, and this is certainly not keeping me up at nights.
      True enough -- but there was a time when Linux wasn't keeping the SCO people up at nights either. Fear commoditization.
      --
      Tired of FB/Google censorship? Visit UNCENSORED!
    2. Re:Not much there by furiousgeorge · · Score: 2

      >>Whatever else Loki might've done wrong, native
      >>porting was one thing they did right

      What color is the sky in your world?

      It may have been 'right' in your eyes, but it was a colossal failure. Remember the total lack of sales, and death of Loki. You may have agreed with their approach, but the fact remains they had to fire all their developers and go bankrupt.

      >>None of which will wind up in TransGaming's
      >>coffers.

      Lets see...... to vote with your gaming dollars you can buy Tux Racer, or........ Tux Racer. Good show old man.

      I know it's hard, but try to see past the end of your nose. So instead of having games in emulation (support Transgaming and the work they're doing), you'd rather have them fail because they're not doing it the way you would. So you end up with nothing.

      And lets recap.... the way you would do it was the Loki way. Yup - good business plan there.

    3. Re:Not much there by furiousgeorge · · Score: 2

      ID only ports to Linux out of good will. Yes, it's nice and appreciated. But the odds of you getting lots of ports from 'good will' are about as likely as me getting my gas tank filled up with 'good will' at Texaco.

      Games are big business. Didn't we just hear that they outdid hollywood last year?

  34. Re:Just what we DON'T need, MS API's in Linux by prototype · · Score: 2

    Learn to read what the post is about and what the product is. This is not from Microsoft not will it screw up Linux in any way. It's a bunch of C++ objects that look like Direct3D, but really OpenGL underneath. It's not MS APIs in the least since there is not COM component there and MS doesn't control anything. Get a life.

    liB

  35. Re:Just what we DON'T need, MS API's in Linux by jejones · · Score: 2

    Locutus has a point. If Linux ever gets to the point of depending on MS for anything, MS has a means of control. If graphics card makers decide not to provide X drivers or provide the information needed for someone else to do so, with the rationalization "Why bother--they can just use the OpenGL/DirectX compatibility layer," MS can start munging the API to put Linux in a game of perpetual catchup--much the way they did with win32s.dll to screw over OS/2. Linux doesn't need that kind of grief.

  36. Re:Just what we DON'T need, MS API's in Linux by Dirtside · · Score: 2, Flamebait
    At some point, Linux has to grow up beyond the "fight-the-power" angst-filled culture that is quickly alienating it from the corporate market (wonder why you don't see quite so many people pushing Linux anymore? It has a bad rep in corporate America.)
    Good. Corporate American can go fuck itself. They're responsible for 90% of the problems we have now. Fuck their greed and fuck their pride.
    --
    "Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
  37. yup! by Ender+Ryan · · Score: 2
    Yes, that is exactly my point. There was nothing ever good about D3D, it's all about stealing a market. It is incredible that anyone fell for D3D in the first place...

    --
    Sticking feathers up your butt does not make you a chicken - Tyler Durden
  38. Re:SDL/OpenGL vs DirectX OR the end of open standa by Nerds · · Score: 2

    In that hypothetical situation (let me stress hypothetical, because the other people who replied to me seemed to miss that part), you'd probably see one of two things:

    1) Microsoft gives up and decides to go cross platform, at which point they continue maintaining DirectX. This still causes problems for free/open software types, because they'd still have to play catch up, but at least it gives people a choice of OS.

    2) Devs realize that there are plenty of people who aren't on Windows so they start using an already established cross platform kid (like SDL), or they just do what Id does and roll their own.

    Again, it's not that I actually think this is going to happen tomorrow, or at all. All I'm really saying is that a DirectX wrapper is a good thing.

    --
    My other .sig is 'The Art of Computer Programming'
  39. Re:usefulness? by praedor · · Score: 2

    Give me a break! This is NOT a troll. I am dead-ass serious. It is also a FACT, inescapable, that NO linux game company (an now porting company) has suceeded. It is disheartening but it is VERY true nontheless.


    You can beg, call, petition all you want for companies to write native linux games but it wont work and cannot work (for the near future certainly). There is NO money in it. Ask Loki and John Carmack, fer Cthulhu's sake! You MIGHT get lucky with a couple vendors if you ask nicely for free, unsupported linux binaries for some games ala idSoftware, but anything else? Yeah right, been there, tried that, failed IN EVERY CASE.


    Troll my ass, just the ugly facts (AND I WANT/BOUGHT LINUX GAMES IDIOT MODERATOR!).

    --
    In Bushworld, they struggle to keep church and state separate in Iraq as they increasingly merge the two in America.
  40. Re:Just what we DON'T need, MS API's in Linux by Locutus · · Score: 2

    wow, I thought that Direct3D(tm) was a bunch of API's for programming on the Microsoft Windows platform. If it "looks" like Direct3D then it's just following Microsofts published API's.

    I agree that in the short term this might look like a good thing but look at history. They push/change/break their own API's to keep the competition one step behind.

    If you start "talking" the Microsoft Windows language (API's) on Linux then your just stepping in line and following the piper. And he's leading you over the cliff.

    By the way, I NEVER said this was FROM MICROSOFT. They do control the API's this is being built to.

    Do some research and see what Microsoft does.

    LoB

    --
    "Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
  41. Re:Just what we DON'T need, MS API's in Linux by Locutus · · Score: 2

    Great, ONE person sees what I'm getting at. Yeah, JeJones.

    Those other YAHOO's must be young punks who have no recollection of the phrase, "DOS ain't done til Lotus don't run". Isn't that flying on a flag in Redmond somewhere(joke). ;)

    LoB

    --
    "Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
  42. Re:Just what we DON'T need, MS API's in Linux by I_redwolf · · Score: 2

    Yes, extra compatability is nice.. Microsoft has some pretty cool things to offer. However they don't want others using those cool things. As for Linux being "alienated" from the corporate market that has nothing to do with compability. It has everything to do with service and support, if a Linux Company (ie: RedHat) offered the quality and support of say another Unix (ie: Sun Microsystems) you'd see alot more Linux deployed. RedHat should be looking into offering kickass support, maybe they should of even bailed or helped VA keep it's hardware business afloat. However the head honchos don't see it this way and thats why even though RedHat is staying afloat now it needs to make a decisive move into a market, while still concentrating on things like embedded support. Without a decisive move Redhat won't exist in it's current form for long. If VA could of cut a deal with Redhat and offered the support for hardware while Redhat offered support for software, VA Linux would still be around and Redhat + VA would be cutting into Sun Microsystems. Instead VA chose to create their own Linux distribution instead of buddying up with a "brand" (In advertising BRAND is everything) This is easier said than done however and unfortunately for VA it's too late, and soon to will Redhat go the way of the dinosaur without a decisive and substansial move to support one of the many things they currently DO support. In other words, i'm an admin and I have alot of machines to look over, I want to use Linux in the corporate enviroment but can't because there is no vendor to truly support my hardware and then Redhat might not support my machine based on what I buy if I piece it together.. So Linux stays out except for some tiny machines. Sun Microsystems supports my hardware and if I have a problem with Solaris they will support that as well.. We pay a lumpsum of cash for the support even if we don't need any. When we do need it, it's prompt and efficient; Infact it's damn near immediate. The above is what keeps Linux out of the corporate enviroment.

  43. Re:Open Source Direct 3D Wrapper Means by praedor · · Score: 2

    Which version(s) of WineX have you tried? There has recently been the 1.0-2 (which shipped with Gaming Mandrake, and now there is 1.0-3 beta-ish/tester.

    --
    In Bushworld, they struggle to keep church and state separate in Iraq as they increasingly merge the two in America.
  44. Re:Actually... by Dwonis · · Score: 2
    Get the Linux implementation to be better than the Windows "reference" implementation, and Microsoft will lose control of the standards.

    It doesn't even have to be better. It just has to be close enough that the benefits of using Linux will outweigh the benefits of using Windows.

  45. Re:usefulness? by johnnyb · · Score: 2

    There hasn't been a Linux game company. There have only been Linux game porters. If you already have a Windows machine to run your games, why on earth would you buy Linux ports after you already bought the windows versions?

    If there was a true Linux gaming company, I think we'd see different results. We'll see what happens when TuxRacer comes out.

  46. Re:usefulness? by praedor · · Score: 2

    Heh...TuxRacer?! Yes, lets have tuxracer vs Unreal II, Call of Cthulhu, Doom III (ok, Doom III being an idSoftware child will end up with an unsupprted linux binary for download), WarCraft III, and the like.


    TuxRacer may be cute but it is simply not comparable to the likes of games coming or available for doze. I understand that a subpop actually likes senseless arcade games ala centipede, etc, but come on. I can only hope that TuxRacer acts as merely a springboard for real cool, technically complex games like those mentioned above.


    I would argue that id was not just a porting operation when they dipped into the linux game market. They were developing both versions, but the linux version, by necessity, having a lower priority due to the market size, took a few months longer. This was precisely the reason it (linux games) came stillborn! Linux users were NOT willing to wait a measly 2 months for a native version. They just HAD to have it NOW and, of course, once you have the game for doze, why the hell would you pay again to get the native linux version? Linux gamers are too impatient and/or unwilling to pay for games. I love linux and the whole opensource thing but it is NOT the answer to everything and you MUST be willing to pay for good games if you want them to continue coming. Too often the overall linux crowd seems to get indignant that they can't just download a cool game for free (as if the Constitution or Bill of Rights - or equivalent - assures this should be so).


    IF linux can gain on the desktop to an appreciable extent (and it must be able to AT LEAST match the Apple market share) THEN commercial games will start to trickle in. Look at Apple! They do only have a small piece of the desktop pie and naturally, games are fewer. You expect equal to windoze treatment for linux even though it's desktop share is a fraction of Apple's? Pure wishful thinking...and not logical or reasonable.


    Gain more of a hold on the desktop and ask companies to provide linux binaries ala idSoftware. If they try to release linux boxed games, they will fail financially (see idSoftware and ask Carmack). It, of course, would be GREAT to get boxed games with Mac, Doze, and Linux binaries in the same package, on the same CD but even that is asking a lot given the desktop linux penetration to date and the examples of Loki, id, and a couple other noble attempts. I cannot hold out hope for a simplistic arcade game (TuxRacer) to somehow be the savior of linux gaming.

    --
    In Bushworld, they struggle to keep church and state separate in Iraq as they increasingly merge the two in America.