Forgot your password?
typodupeerror
This discussion has been archived. No new comments can be posted.

GLSlang Draft Approved

Comments Filter:
  • GL Slang (Score:3, Funny)

    by heldlikesound (132717) on Thursday February 27, 2003 @06:00AM (#5394466) Homepage
    Yo, I feel ya, butter up some pixies and keep da framerizates hizigh... Keep it real, an we be rollin in the rova sittin' on dubs! Damn, fool, foget dubs, Jordans!
  • by YE (23647)
    Nah, I'm waiting for glTrashTalk or at least gl13375p34k.
  • I clicked on the story thinking "I wonder if anyone has compared this to DirectX 8/9 so that I can see what the relative merits are."

    I find two comments. One of them's pretty funny, right enough, but where are the hardcore geeks??
    • DX 8 is lower level than OpenGL. It doesn't support a high level shading language. Just a low level assembly like language. This is unlikely to change, although an extra library might be designed to bolt on a higher level shader.

      A more logical comparison would be nVidia's Cg vs. GLSlang.
  • They really need to step up the pace on how they go about this stuff. The words "OpenGL 2.0" were floating around a loooonng time ago. In the time that has passed since I believe I've seen a few releases of DirectX. Now I'm all for OpenGL, but if they wish to be a decent alternative to DirectX, then they need to step up the pace, and stop squabbling over shiznit (I think NVIDIA and ATI are that the forefront of that). Honestly though, I can't wait for it to come out. It may the "push" needed to spur more Linux gaming. And that would be awesome.
    • Why? (Score:4, Informative)

      by GeckoX (259575) on Thursday February 27, 2003 @11:44AM (#5396096)
      Just because MS pumps out version after version of DirectX means that OpenGL must suck because they're only working on their second full version now?
      That argument just doesn't hold water.

      Just so you know, OpenGL 1.x has been around for a very long time now, and it still happens to be totally viable. Why? Because it was a very well designed and fully featured graphics language when it first appeared. DirectX has been playing catch-up ever since.

      It's just in the last year or so that DirectX has actually added newer features that OpenGL 1.x doesn't handle. If you look at the specs for OpenGL 2.0, you will see that once it comes out, DirectX will have probably another 5-6 releases to go before it catches up again. Oh, and it runs on just about every platform out there.

      Ever heard of a real-time medical imaging package that uses DirectX? Yeah, thought not. And you never will. DirectX is really for games only, and not only that, MS platforms only on PC and XBox.

      I could go into all the fundamental differences between OpenGL and DirectX, but is there really any point? The last one I will point out is this: DirectX is really a direct mapping to hardware, it's not really a Graphics Language per-se in that it's focus is on the actual implementation of the graphics and not on the graphics themselves. OpenGL on the other hand is ALL about the graphics, with the actual implementation totally left up to the environment it runs in.
      • Re:Why? (Score:4, Interesting)

        by drinkypoo (153816) <martin.espinoza@gmail.com> on Thursday February 27, 2003 @03:16PM (#5398751) Homepage Journal
        You're correct on all counts. The sad thing is, Microsoft had a software OpenGL implementation since the dawn of time and really the only reason Direct3D exists is because of GLIDE. If 3dfx had just done MiniGL from the beginning instead of creating their own 3D API then Microsoft would likely have stuck with OpenGL instead of creating their own (Crappy) 3D graphics API.
        • Good point, amazing how soon we forget.
          I was some ticked at 3dfx back in the day for forcing glide upon us and diluting the market at the time just because they had clout. (Fat lot of good it did them).
          But I had never really correlated that with MS's decision to create Direct3D, again, good point!
        • by juhaz (110830)
          Well, with M$:s track record of mutilating standards, it may even be a good thing.

          At least this way they didn't get their hands on OpenGL and create some half-assed noncompatible variant of it like they've done with just about every technology on the planet.
  • There is no "goto" (Score:3, Informative)

    by korpiq (8532) <.-.. .at. .korpiq.iki.fi.> on Thursday February 27, 2003 @09:53AM (#5395221) Homepage

    And wait, there's more:

    No '*' or '&' unary ops. Pointers are not supported.

    Suddenly you begin to feel enlighted. But where were these guys when all the previous derivatives of c hit us?!

    I feel soo nice reading about a language that has no strings. Literally.
    • Yeah, there are no goto's, but there is every other kind of structured branch statement: for/while/do-while/continue/break/return. Most C programmers get by with only these (although a do-while-repeat loop would be helpful), and some don't even know that C has a goto.

      Pointers aren't supported (just like in java and Fortran), and I suspect the reason for that is that pointer aliasing can only be detected at runtime, so a lot of very useful compiler optimizations can't be done. In fact, that's why a lot of super-computer applications still use fortran (besides the large existing math library base). Graphics rendering is speed-oriented, and in a special-purpose language like this, it's a good tradeoff.

      For comparison, (and for the same reasons) nvidia's cg doesn't have goto's or pointers, either. [theregister.co.uk]

      GLSlang has a lot of functions built-in (like texture lookups, vectors, and matricies) for things you may want to use pointers for. The benefit of supporting them natively is that they can be hardware-optimized extremely well. One cool thing that Cg [nvidia.com] does (and it appears that GLSlang does, too) is allow floating point indicies into texture-maps -- the inbetween position is automatically interpolated.

      Also, for the record, C doesn't have strings, either. The only string support is in libraries; not natively.
      • >> Also, for the record, C doesn't have strings, either. The only string support is in libraries; not natively.

        Almost correct.

        The C compiler knows about literal strings, that is why this:

        -- code --
        const char my_str[] = "something";
        const char my_chars[] = {'s','o','m','e','t','h','i','n','g'};
        puts(strcm p(my_str, my_chars) ? "strings supported" : "whats a string anyway");
        -- code --

        should print "strings supported", because my_str does not equal my_chars .

        For fun try this:

        -- code --
        printf("length of char array: %d", strlen(my_chars));
        -- code --

        with the above. It might not crash.

        By the way, sometimes goto can be very handy. Unless the language supports labeled break and continue statements?

        • Oops, I forgot that part! I was thinking of the built-in support of BASIC - "ab" + "cd" = "abcd" and its keywords (not library functions) like MID$ and LEN. I was thinking of how C makes no distinction between a pointer to a single character and a pointer to a null-terminated string.
      • They left out a couple of useful structured primitives: labeled break, labeled continue, switch.

        The labeled break and continue are very handy for getting out of multiply-nested loops. A goto is useful to simulate those constructs on languages that don't have them (like C).

        Switch (can be implemented with if-else-if-else...) can make things a lot more readable. Oh well, maybe someone could write a preprocessor to add the things the language designers left out.
  • by emarkp (67813)
    I'm a bit disappointed that they're reserving keywords like:
    vec2 vec3 vec4
    bvec2 bvec3 bvec4
    ivec2 ivec3 ivec4
    mat2 mat3 mat4
    without a "gl_" prefix. I have already defined classes vec2 for that purpose--using the template parameter to define the underlying type. It's unfortunate that they're gobbling up those keywords (and there's no way it appears to choose different floating point precisions for vec/mat.
    • They are reserved within vertex and fragment programs, *not* within your application. I'm pretty sure most people wouldn't define their own vec2 type within a fragment program.

      and there's no way it appears to choose different floating point precisions for vec/mat.

      They're working on it. Look at Issue#33.

    • This is in OpenGL shading language, which is probably in a string constant in your C code, so there are no conflicts.Ie the C code is something like gl_set_shader(gl_compile_shader("the source code goes here"));

      If you want to cut & paste the code so the same algorithim can be used by both your C program and shaders you can use macros. Ie "#define gl_vec2 vec2" can be inserted into the shader language fragment and then you can use gl_vec2 the way you want.

  • Did anyone else think that this was GL bindings for S-Lang? [s-lang.org]

    I was thinking to myself, What the hell good is that?

"And do you think (fop that I am) that I could be the Scarlet Pumpernickel?" -- Looney Tunes, The Scarlet Pumpernickel (1950, Chuck Jones)

Working...