Choosing a compiler

This is a discussion on Choosing a compiler within the Game Programming forums, part of the General Programming Boards category; OpenGL is a collection of the core and two levels of extensions, the ARB extensions and the vendor extensions. Every ...

  1. #16
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    OpenGL is a collection of the core and two levels of extensions, the ARB extensions and the vendor extensions. Every new version of OpenGL typically takes some tried and proven ARB extensions and makes them part of the core. In turn, ARB extensions are created by taking vendor extensions that have become popular and making a uniform interface for them. This way, functionality slowly wanders from the outside, the vendor extensions on which you simply cannot rely, towards the inside, the core, which you can rely on. In other words, an OpenGL driver claiming support for a specific OpenGL version MUST implement all core functionality of that version, can additionally support any number of ARB extensions and of course have whatever vendor extension it likes.
    Programs work with this by dynamically detecting the availability of such extensions. They can then provide the new, shiny features only if support is available, and fall back on less shiny methods of achieving their goal otherwise.
    Or they fail to start. Or they foolishly don't do proper detection and crash when trying to use the unavailable functionality. That's most likely the back-compatibility issues you're experiencing, Mario. Programs that simply don't bother to support drivers that do not offer the features they need.

    DirectX follows a different philosophy. There are no extensions. There is just DX. You either support it or you don't. To gain access to the brand new features, you cannot splice your program to three code paths for three incompatible vendor-specific implementations of the feature as you might do in OpenGL. Instead you don't use the features until Microsoft has released the next DirectX version which supports the feature in a uniform way. (Of course you could wait in OpenGL until it becomes an ARB extensions, but who wants to wait that long? ) It's definitely easier and more portable this way. And if MS decides to release the new DX version only for their new OS, you're screwed. I'm not making any judgement here, just saying it as it is.
    Now the thing is that MS always supplies software emulation for all features of DirectX. There is no such thing as an unsupported feature, there's just a feature not supported by the hardware. Which to me, recalling the frame rates I got when pixel shaders where the shiny new feature my TNT2 (I think) didn't support, is pretty much the same as unsupported, except that it doesn't crash your app. It only makes it run like a slug with asthma.

    OpenGL gives the choice about feature support to the program. The program can support older cards by emulating new techniques or falling back to old techniques. The program can also not support the driver/card. The card/driver, in turn, can support whatever it wants through the extension rules, at the risk of having some programs not run. If driver development stops, the card is dead to new OpenGL apps that have no fallback.
    DirectX can somehow query the hardware capabilities, although I can't remember how. But in principle, it imposes requirements on the card/driver. This interface is the stuff you have to support, or be non-compliant and software-emulated. The program is, mostly, supposed not to notice. Which I consider misguided, but that's just me.

    It should be pointed out that the Mesa project offers something similar to what DirectX does. Mesa is a software implementation of OpenGL for the X system, but it's also the gateway to the DRI, the hardware rendering support. Set X to use Mesa (instead of the vendor OpenGL implementations such as ATI's or NVidia's) and at your disposal are the asthmatic slug versions of all the features Mesa supports, whether your card supports them or not. Then you plug in a 3d driver like the open-source radeon driver and Mesa will automatically use the hardware as much as possible.
    The downside? Open-source 3d drivers are always many years behind the times, because they mostly have to guess at how the 3d cards work. Only very recently has support for the ATI r300 chips (that would be Radeon 9800 and friends) entered the Mesa source, and it's far from stable.

    Edit: I just realized I made a mistake about the extension levels. There are actually three levels of extensions: ARB, EXT and vendor.
    Vendor is vendor-specific. Only the inventor is ever expected to support the extension.
    When several vendors implement similar functionality, they are encouraged to work together and create an EXT version of the functionality, which is a uniform interface.
    EXT extensions can be officially accepted by the review board, making them ARB extensions. These are scheduled for inclusion in the core and very reliable in terms of availability.
    Last edited by CornedBee; 12-13-2006 at 03:42 PM.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  2. #17
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,383
    > Or they foolishly don't do proper detection and crash when trying to use the unavailable functionality. That's most likely the back-compatibility issues you're experiencing, Mario. Programs that simply don't bother to support drivers that do not offer the features they need.

    Ah! That makes a lot of sense, CornedBee. Thanks
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  3. #18
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,584
    This is a thread about compilers, not graphics APIs.

  4. #19
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,383
    Yes. The discussion kinda of evolved. I'm sorry. But I'm sure you have something to say about compilers.

    Do say it.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  5. #20
    Registered User
    Join Date
    Dec 2006
    Posts
    17
    haha, it certainly did evolve

    I appreciate the information about the differences between the APIs. I won't use DirectX because it's so bound up with Microsoft... I want to be able to port this game!

    Am I correct in understanding that the fundamental difference is that DX implements software driven versions of functionality where hardware capabilities to perform the same do not exist? If this is the case, I think I'd rather stick with OpenGL anyway

  6. #21
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,383
    > I think I'd rather stick with OpenGL anyway

    And that you should, if that's what you want.
    Just be sorry of the poor lil' people like me out there, and when coding for ARB extensions make sure you check for their availability and fall back to core functionality if they aren't available
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  7. #22
    Registered User
    Join Date
    Dec 2006
    Posts
    17
    I will, I promise

  8. #23
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,584
    I'm a DirectX guy by preference because it offers the most complete gaming solution for the x86 platform. OpenGL is a graphics API whereas DirectX is the whole shebang to include input devices, multimedia streaming/playback/recording, 2D/3D graphics, an extremely useful library with common 3D functions/objects/structures/classes and COM objects. The D3DX library alone should be enough for anyone in OpenGL to run like hell to DirectX. It's extremely useful.

    Another point is that you see most games out there are coded for x86 platforms and usually support both GL and DX. So the issue of cross-platform is a moot point and if we are talking consoles, MS is already developing technology to port from PC to console (XBOX) and back. Their new XAct technology will greatly aid in porting code.

    With DirectX you can create an entire game start to finish (from a pure code standpoint) without touching a third party library although you may wish to. The only other library I might even suggest using is the Miles sound library developed by RAD game tools. It is NOT cheap by any stretch of the imagination but it simply kicks ass. The only audio engine that surpasses it is the proprietary Bungie audio system that drives the Halo games. No one does audio like Bungie.

    Also when it comes to things like shaders and effects Microsoft has an excellent effect framework that integrates seamlessly into existing engines and it is easy to develop an engine that works with it. I'm not a Microsoftie by any means but I must give credit to them for DirectX. It is sheer brilliance.


    Core assembly and C/C++ code
    Compiler/IDE: MSVS (most recent version of Visual Studio is .NET 2005)
    Assembler: MASM or NASM

    Core shader code
    Shader code language: HLSL (High Level Shading Language)
    Shader compiler: fxc - MS's HLSL compiler


    As an example of the D3DX library take this code which sets up a world transformation matrix:

    Code:
    D3DXMATRIX matScale;
    D3DXMATRIX matTrans;
    D3DXMATRIX matRot;
    D3DXMATRIX matWorld;
    
    D3DXMatrixScaling(&matScale,m_vecScale.x,m_vecScale.y,m_vecScale.z);
    D3DXMatrixTranslation(&matTrans,m_vecPos.x,m_vecPos.y,m_vecPos.z);
    D3DXMatrixRotationYawPitchRoll(&matRot,m_vecRot.x,m_vecRot.y,m_vecRot.z);
    D3DXMatrixIdentity(&matWorld);
    
    matWorld*=matScale*matRot*matTrans;
    
    m_pDevice->SetTransform(D3DTS_WORLD,&matTrans);
    ...
    Now this can be done in OpenGL but you would need the following:

    • A 3D vector class with operator overloading for common operations
    • A matrix class to handle matrices
    • A matrix math library to handle matrix mathematics and common matrix/matirx and matrix/vector operations



    Now imagine writing code in OGL to set values in your shaders. You would need something to identify the vector, matrix, or value and then code to set the value. This is actually quite a bit of code.

    In Direct3D once you have an effect created you can simply do this to set a matrix:

    Code:
    D3DXMATRIX matWorldViewProj;
    D3DXMATRIX matView;
    D3DXMATRIX matProj;
    D3DXMATRIX matWorld;
    
    m_pDevice->GetTransform(D3DTS_PROJECTION,&matProj);
    
    //Camera would be a user class....no native camera support in D3D
    m_pCamera->GetViewMatrix(&matView);
    
    //Get world matrix from the object
    m_pObject->GetWorldMatrix(&matWorld);
    
    //Do the multiply once and transfer to shader
    matWorld*=matView*matProj;
    
    //Assumes m_pEffect is a valid ID3DXEffect interface pointer
    //Created by calling D3DXCreateEffectFromFile() and passing in needed params
    m_pEffect->SetMatrix("matWorldViewProj",&matWorldViewProj);
    
    ....
    Done. Now your matrix matWorldViewProj in your effect file has been set and is ready for use.
    So in essence the core code is already there and all you have to do is wrap these nice interfaces in classes which really speeds things up. An engine is really 3 levels or I like to think of it that way. First level is the core code that does the math, sets up the basic functions, etc, etc. The second level is the C++ code that wraps all of this into nice neat tight little classes/objects. The third level of code is the C++ code that uses the second level, or simply put, uses and expands on the wrappers and objects that wrap the core code. For instance in my engine I have the following:

    • Level 1 - DirectX functions - the core set of DirectX functions/interfaces available to the application
    • Level 1A- The D3DX library of functions that are available to all applications - wraps a lot of level 1 interfaces/functions
    • Level 2 - CD3DXApp - wraps the core startup code, DirectX/D3DX functions/interfaces, etc, into a core application object
    • Level 3 - CStarXApp - the 'game specific' derivative of the core application object that handles game-specific initialization, rendering, etc.
    • Level 4 - User derived classes - CStarXApp has pointers to many more manager classes which then have pointers to vectors of base objects, user-defined objects, etc, etc.


    When you begin to look at the code requirements to gain the functionality of D3DX and the effect framework you can see why people choose Direct3D. Do not let COM programming influence your decision concerning Direct3D - it has been made so simple a child could do it. Personally I think Direct3D is a cakewalk. Now getting your algorithms and all to work and your resource management system to function flawlessly and efficiently is a completely different story. Graphics are easy...but a game is 10% graphics and 90% management of resources.

    If you want compatibility you can never go wrong with Microsoft. Everyone else struggles to match the compatibility of MS products. To be fair it is because they designed the OS on which their apps run. Whether or not that is fair is up to someone else to decide...but that's how it is.

    But in the end its up to you. We could sit here and hash out differences but the end result will still be you must make the final decision. My recommendations based on my experience:
    Last edited by VirtualAce; 12-14-2006 at 06:24 AM.

  9. #24
    Registered User
    Join Date
    Dec 2006
    Posts
    17
    Yep, programmers are lazy

    I'm willing to put the effort in to do this right though. I don't want to spend countless hours putting together an engine which is intrinsically reliant on Microsoft products

    I really do appreciate your input though. Thanks!

  10. #25
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,584
    I'm willing to put the effort in to do this right though. I don't want to spend countless hours putting together an engine which is intrinsically reliant on Microsoft products
    And why not? Nearly every PC out there in some form or another relies on Microsoft products. It's high time for the cross-platform myth to be shattered. It's just not plausible that Microsoft is going to lay down and die while Linux or some other system takes over. Don't choose OpenGL based on MS or non-MS, choose it based on what it offers or does not offer.

    If my product relies on Microsoft then I can pretty much be guaranteed that my product can be sold to about every PC user out there. I don't see this as a problem. Now if you are coding for mainframe or something else, then yes, I can see the need for cross-platform. But not for this.

  11. #26
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    Now where did the compiler discussion go, Bubba?

    Another point is that you see most games out there are coded for x86 platforms and usually support both GL and DX.
    Haven't seen a game in a long time that does that, except those based on the Irrlicht engine and not using any system-specific calls. In terms of commercial games, that means zero.
    Begin coded for the x86 is a different matter. Assembly aside, I think many programs would, for example, be mostly compatible with amd64 architectures.

    So the issue of cross-platform is a moot point
    Huh? There's more to being cross-platform than offering code paths for both GL and DX.

    if we are talking consoles, MS is already developing technology to port from PC to console (XBOX) and back.
    Given that the XBox uses DirectX and runs an embedded Windows, programs should have been largely portable from the get-go. I wonder why not.

    Also when it comes to things like shaders and effects Microsoft has an excellent effect framework that integrates seamlessly into existing engines and it is easy to develop an engine that works with it.
    I must admit that the last time I looked seriously into 3d programming was when shaders were programmed in assembly-like languages, so I don't know how excellent this framework is or if any GL-based library offers the same.

    Now this can be done in OpenGL but you would need the following:

    * A 3D vector class with operator overloading for common operations
    * A matrix class to handle matrices
    * A matrix math library to handle matrix mathematics and common matrix/matirx and matrix/vector operations
    None of which are particularly hard to find, but that aside ...
    Code:
    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
    glScalef(m_vecScale.x,m_vecScale.y,m_vecScale.z);
    glTranslatef(m_vecPos.x,m_vecPos.y,m_vecPos.z);
    glRotate(angle, axis.x, axis.y, axis.z); // Not sure what the D3DX call does exactly.
    If I want to save the matrix for later reuse, I can use the matrix stack.


    I don't know about effects, so I can't comment on the next snippet.

    Graphics are easy...but a game is 10% graphics and 90% management of resources.
    And physics and AI and game idea and level design and ...
    Meh. Personally I find the physics to be the hardest part. I like good physics.

    If you want compatibility you can never go wrong with Microsoft.
    Depends on your definition of compatibility. I run Linux. Microsoft to me is the antithesis to compatibility: something touched by MS is most unlikely to run properly on my system.
    By the way, when will you be switching to DirectX 10?

    Everyone else struggles to match the compatibility of MS products.
    Everyone struggles to be compatible to MS producs - because they're the market leader. It's easy to be compatible if things are measured against your product.

    Nearly every PC out there in some form or another relies on Microsoft products.
    Mine doesn't. The Windows installation (for games *sigh*) aside, my computer doesn't use a single Microsoft product. So there

    It's high time for the cross-platform myth to be shattered. It's just not plausible that Microsoft is going to lay down and die while Linux or some other system takes over.
    I agree that this is not plausible, but what is this cross-platform "myth" you're talking about?
    Cross-platform compatibility is about reaching the largest audience possible, now and in the future. Linux market share is going to rise, even if it won't come anywhere near threatening Microsoft. Macintosh might also be nipping more at the Windows user base. And there are personal considerations: for a hobby game programmer who has Linux on his own system, being able to run the games on Linux is a pretty overriding argument.
    Besides, platform moves are always a chicken-egg problem. If nobody writes programs for a platform because nobody uses it, then nobody will use the platform because nobody writes programs for it.
    If someone, however, writes applications for many platforms at little additional cost (I still maintain that OpenGL and DirectX differ mostly in syntax details, D3DX aside), then the new platform suddenly has applications and gain users.
    I consider that a good thing.

    Don't choose OpenGL based on MS or non-MS, choose it based on what it offers or does not offer.
    For me, OpenGL offers programs that work on the platform I use. I think that's a good criterium.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  12. #27
    The Right Honourable psychopath's Avatar
    Join Date
    Mar 2004
    Location
    Where circles begin.
    Posts
    1,070
    Quote Originally Posted by CornedBee
    I must admit that the last time I looked seriously into 3d programming was when shaders were programmed in assembly-like languages, so I don't know how excellent this framework is or if any GL-based library offers the same.
    There's GLSL, if that counts. Although it's not a library, it's part of OpenGL 2.x
    Memorial University of Newfoundland
    Computer Science

    Mac and OpenGL evangelist.

  13. #28
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,892
    The high-level shaders are only a part of what the effects framework is about. From what I understand, it contains quite a few more things.

    It's actually quite a brilliant idea, I have to admit. An effects file basically encodes the textures, shaders and other rendering options to use to achieve an effect. So far, so good - that would be the work of one, maybe two weeks to copy.
    Now the great thing is that the effects files also automatically know what capabilities the effects need - and each effect file can contain several alternative methods of achieving an effect, with different requirements. The framework automatically chooses the best version that is supported by the hardware. This leads to a very easy way to degrade on older hardware - all you have to do is code the method; the framework chooses the best method for you.
    Last edited by CornedBee; 12-14-2006 at 09:38 AM.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. C Compiler and stuff
    By pal1ndr0me in forum C Programming
    Replies: 10
    Last Post: 07-21-2006, 11:07 AM
  2. I can't get this new compiler to work.
    By Loduwijk in forum C++ Programming
    Replies: 7
    Last Post: 03-29-2006, 05:42 AM
  3. how to call a compiler?
    By castlelight in forum C Programming
    Replies: 3
    Last Post: 11-22-2005, 10:28 AM
  4. Help With finding a compiler
    By macman in forum A Brief History of Cprogramming.com
    Replies: 4
    Last Post: 04-15-2005, 08:15 AM
  5. choosing a compiler
    By almost_here in forum Game Programming
    Replies: 4
    Last Post: 11-29-2001, 06:20 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21