Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 9 of 9

Thread: 2 suggestions

  1. #1
    Junior Member Newbie
    Join Date
    Feb 2002
    Location
    Joliette, Quebec, CANADA
    Posts
    3

    2 suggestions

    the first would be majorly based on the fact that it is frustrating that a "graphical" libray contains native support only for bitmap, i suggest you could provide functions for loading and maintaining more image types like TGA, TIFF, JPEG and JPG, and also handle things like image compression transparently.

    Secondly i would suggest a clearer way of switching from 3D to 2D, as calls to Glortho can be lenghty and boring to write, of course you can call me lazy but its that sort of functionality that make things better when you dont have time to make reusable code.
    Christian Roy

  2. #2
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    3,576

    Re: 2 suggestions

    First, I'll address the second point. Calls to glOrtho aren't any slower than calls to gluPerspective or glFustrum. All they do is set various hardware registers. There is no 3D or 2D mode; there are simply various transforms of the perspective matrix.

    Secondly, OpenGL doesn't support bitmaps. It supports giving it the most basic, fundamental information required for use as a texture. This information can also be used for functions like glBitmap. But, OpenGL is primarily a 3D library, so I would say that functions like glBitmap should probably be done away with.

    In any case, no current hardware deals natively with decompression of various common file formats (like TGA, JPEG, etc). OpenGL should not deal with loading things from files; after all, what would those functions do on a device that has no files? In any event, driver writters would have to waste a lot of time writing code that is freely avaliable on the net to load various formats and transform them into suitable texture formats.

    As for texture compression, the hardware already does that pretty transparently. The texture compression extension simply allows you to specify a particular compressed format, and the driver will do the compression for you. The user doesn't have to do anything more than ask.

  3. #3
    Member Regular Contributor
    Join Date
    Jun 2000
    Location
    Karlsruhe, Germany
    Posts
    360

    Re: 2 suggestions

    Nonsense.

    OpenGL should not contain any file loading capabilities, there are enough image loading libs out there, and it would be stupid to put this functionality into OpenGL (platform dependency (little endian - big endian issues usw.))

    And as far as 3D or 2D does: there is no 2D in OpenGL. OpenGL has a pipeline which handles 3D data, and in one in the final steps those 3D "data" is projected onto a 2D place(to be displayed on the monitor). perspective and orthogonal projections are 2 common types, so OpenGL has a function to auto setup such projections instead of calculating the projection matrix by hand.

    OpenGL is not supposed to be "all things a programmer even needs" but a 3D graphics library.

    -Lev

  4. #4
    Member Regular Contributor
    Join Date
    Jun 2000
    Location
    Karlsruhe, Germany
    Posts
    360

    Re: 2 suggestions

    Korval: that was pretty syncronous

    Of couse my posting is a reply to the original post, not to yours

    -Lev

  5. #5
    Junior Member Newbie
    Join Date
    Feb 2002
    Location
    Joliette, Quebec, CANADA
    Posts
    3

    Re: 2 suggestions

    In fact, all i am asking is API functionality not hardware accelerated file loading, you may have missed my point here. I am perplex as to see that kind of reaction, because if you look into directx those features are supported, just take the native model importer *.x", maybe it would make sense for people that dont give a.... about model optimization and the likes, i only want objectivity here. What i sense from your posts is old timer paranoia that your art is beginning to be more open to the grand public. because everything comes down to functionality over optimisation 70% of the time.
    Christian Roy

  6. #6
    Senior Member OpenGL Guru Humus's Avatar
    Join Date
    Mar 2000
    Location
    Stockholm, Sweden
    Posts
    2,345

    Re: 2 suggestions

    Well, I don't think moving file loading stuff into OpenGL is the right thing to do. However, there could of course be file loading utils in something like glu/glaux, but I don't think it has any place in the core API.

  7. #7
    Advanced Member Frequent Contributor
    Join Date
    Feb 2000
    Location
    London
    Posts
    503

    Re: 2 suggestions

    If that offer is still open... you're lazy.

    The OpenGL community has always been very supportive of hobbyists, but at the end of the day it's driven by the needs of professionals, and "I couldn't be bothered to link with more than one library" isn't going to persuade anybody. (I'm just a hobbyist myself, btw.)

    OpenGL implementations are (mostly) built by IHVs; therefore, it makes sense to restrict the interface to stuff that only they can do, or that they can do better than anybody else. Once you start piling "convenient" features on top of this, you just get bloat, loss of focus, wasted time for the IHV's engineers, and wheels being reinvented over and over and over again. Loading an image file has nothing to do with your graphics subsystem, so there's no reason whatsoever to shovel it in there.

    As for "if you look into directx"... DirectX is, essentially, a game operating system. OpenGL is an immediate-mode rendering API. Comparing the two is a bit daft.

  8. #8
    Junior Member Newbie
    Join Date
    Feb 2002
    Location
    Joliette, Quebec, CANADA
    Posts
    3

    Re: 2 suggestions

    ok, sorry i surrender i am just a programmer, i am going to wrap everything in an engine just like everybody does.
    Christian Roy

  9. #9
    Senior Member OpenGL Guru zed's Avatar
    Join Date
    Jul 2000
    Location
    S41.16.25 E173.16.21
    Posts
    2,407

    Re: 2 suggestions

    >>because if you look into directx those features are supported, just take the native model importer *.x"<<

    no, d3d doesnt support the .x file format natively
    d3dx does but thats just a libray eg like glut/sdl/devil etc

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •