Jump to content

Milyardo

Member
  • Content Count

    30
  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by Milyardo


  1. That's not quite right, in that there are companies and middleware that allow a DirectX game to be ported to OpenGL platforms like Linux, without implementing a full OpenGL backplane. This is often what's meant when some Developers use the term 'port' -- i.e. the most economical rout.

    A full implementation of the OpenGL renderer, is much more then a port and would use OpenGL for all the 3D render calls currently done by DirectX, this will run much faster then a port that uses any translation libraries, and if done properly will typically give you a game that runs faster for the same render capability under DirectX.

    I'm not sure what you're trying to explain here, if you're refering to using middleware applications that wrap 3D renderer classes(like SDL or any commercial equivalent) instead of using OpenGL directly, using them shouldn't shouldn't pose any performance issues (though they are typically limiting in functionality since they only wrap of subset of all the 3D renders they support).

    Essentially correct, BIA is also using XAudio2, another Microsoft library for Audo which is exclusive, and while it has state-of-the-art (aka SOTA) features, it does not have SOTA performance or function, and is easily surpassed by much friendlier Sound Managers like FMOD that are completely platform agnostic.

    FMOD is far from platform agnostic, nor would I call XAudio2 SOTA. XAudio2 isn't much better than any other sound API without some 3rd party commercial support like EAX. There's nothing that would keep Dolby or anyone else supporting OpenAL if they any interest in doing so.

    I think the context of your assumption may not be complete; and I say this with some business experience in the industry. First of all in complexity of rolling an OpenGL renderer under a DirectX game is no easy chore, the more high end the DirectX features used the more complected it gets and many a Developer attempt has failed; but that's not the biggest bump in the road.

    Actually, Svartalf in a interview with Phoronix today said the exact oppsite here:

    http://www.phoronix.com/scan.php?page=article&item=linux_gaming_frank&num=1

    What generally is the biggest technical challenge you encounter in porting these games and engines to Linux?

    he Middleware that a studio chooses to use in their game. It can either make it easier or harder to make the game happen.

    It's almost never the 3D or input device support that's a problem. Most of D3D is decently handled by OpenGL and SDL's input layer does a well enough job of things that it's rare that you can't at least approximate the original games' look and input interaction on Linux fairly quickly. That's not to say there's not gotchas with the 3D support, but I'm thinking with things like MojoShader and HLSL2GLSL in hand, that you can gain purchase on most of the eye candy from the 3D side of things at this time with only some effort.

    LGP may have Brilliant Open GL Programers that find the challenge of offering a solution that surpasses DirectX exhilarating, the problem is, BI is a small company with all it's intellectual capital invested in one engine and essentially one franchise (the VBS products are an arbitrary diversification)...

    You are completely wrong on this point and it and the truth is quite the opposite. ArmA is the arbitrary diversification of the VBS, and ArmA will never amount to generating anywhere near the capital VBS does.

    The risk of handing over complete source code to another small company for a port to one platform, with a small audience inculcates enormous risk. LGP is not an industry Titan, with enormous capital that BI can sue and anticipate recovery of damages if somehow their source is lost, leaked, or IP is damaged via LGP action...

    To satisfy these objections and offer a truly compelling solution to BI, or any Developer/Publisher that holds valuable IP in a DX engine, or some successor, LGP must satisfy these criterion:

    1. That LGP can effect a full roll-put of the OpenGL render and any other middleware that's using DirectX/Microsoft API's; ergo Audio, input etc...
    2. That LGP offer an air-tight product source security guarantee, documenting methods and practices, and means of recovering loss in unforeseen circumstances or 'acts of god'.
    3. That while LGP will retain rights for Publishing a Linux product they will return full OpenGL platform agnostic source code to the Developer.

    Satisfying these criterion would be difficult even for an established company but for a small indy company like LGP would be especially challenging -- point 2 especially... There are means to satisfy a Customer like BI; though I get the impression, as may BI, that LGP may be composed of talented Programers more then experienced Business Professionals or even experienced Salesmen, with knowledge of ways and means to satisfying these sorts of objections.

    None of this is true at all and only uses stereotypes of Linux users to prop up this straw-man argument.

    Ryan Gordon is the perfect counter example to this, Ryan (a single man not an entire company who's worth is much greater than Ryan's) is routinely trusted with the task of porting many games to Linux using the Unreal and Quake engine's.

    The programmer's at LGP are all experienced individuals in Business and Management. While what happened at Loki software all those years ago was indeed shameful, and unfortunately killed the Linux gaming industry right when it had the chance for the most growth, LGP is not Loki and should not be treated as such.


  2. I don't think switching 3D renderers is at all the problem with porting BI Titles to Linux. No matter how D3D dependent ArmA, ArmA2, or OFP is, converting it over OpenGL isn't BI's problem. The developers over at LGP are the ones going to be doing all that work.

    The problem is much more likely with middleware software solutions BI may have licensed in these game. Software like SpeedTree, Kynapse, or whoever else they have contracted may require additional licensing to create Linux ports, or may even be unwilling to lisense a port, or hand over sources so that LGP may port the software.


  3. We still haven't heard from a BI representative if/how large a community movement can open the option for reconsideration. For this to work we need to know that BI will even consider us.

    So in my opinion, the first step is to open dialogue between BI and the Linux community in this thread, or some other public interface, then we can petition.


  4. Guys, do not talk about cracked exes.

    http://forums.bistudio.com/misc.php?do=showrules

    Technically, doesn't that also apply to discussion about WINE unfortunately? You can't just conditionally enforce the rule.

    ---------- Post added at 12:40 PM ---------- Previous post was at 12:35 PM ----------

    Also, even though Svartalf updated ArmA as being a dead end, it'd be nice to have BI officially make a statement about why they chose not to contract the Linux port of ArmA. Will Maruk or some one else care to comment?


  5. Hi,

    I am a dedicated BI, OFP, ArmA, and soon to be ArmA II fan. I am also a Linux user and regular visitor to Phoronix.com, a popular Linux 3D hardware and benchmarking site.

    Today, to my suprise and excitement I saw in this thread(http://www.phoronix.com/forums/showthread.php?t=17492) that Svartalf, a developer at Linux Game Publishing(LGP) listing ArmA as possibly a future canidate for a Linux Port by LGP with the quote "ARMA (Initial contact made...we'll see...)".

    I pleasently surprised that BI studios would consider a Linux port, and I would like to use this thread to give my support and thanks for giving Linux users like myself an opportunity to have a native version of any of your titles.

×