Hey guys, cut it out… There is no need to argue. I think the situation of tranders is clear: you don’t have to move to LP. I assure you that open-source wrappers for legacy GL will appear, so all applications written against OpenGL 2.1 and earlier should run just fine. It is not like new LP will break your application. As to glfreak, I am yet to hear some arguments. All I heard were assumptions. And please, don’t go comparing LP and C# - your ignorance in this matter is just amusing. C# is one of the best C clones ever made, if some language earns the name of “ugly monster” that it is without doubt C++. And to you information, Java runs almost as fast as C++, what do you mean by “hardware-accelerated java” anyway?
C++ is beautiful.
tranders, on this occasion your naive use of a rendering API will be ok, the ARB will produce an abstraction of LP for you, in the form of layered mode.
Originally posted by knackered:
C++ is beautiful.
I used to be a pascal fan
don’t want to bother you, but i never liked pascal 
we learned it in school (about 1990) on some computers running ms dos. that’s why pascal will always remind me of sitting in front of a black 14" screen with 80x40 white characters on it. very depressing compared to what we have today. no windows, no opengl, no mp3, no internet…brrrrr!
same for modula 2
no windows, no opengl, no mp3, no internet…brrrrr!
We had Netwars!
We had porn mags too. Anyone remember them?
i think you can still buy them. at gas stations along the highways.
How quaint.
Originally posted by V-man:
CAD is simple. No scene support. No lightmaps. No special lighting features. No culling (Octree or whatever), no character animation, no stencil shadows, no shadow maps, no bump maps, no glow, no lens flares, no HDR.
When you are designing an engine, a solar car or PCB, you don’t need those things.
I’m not saying that some CAD packages don’t have simple rendering requirements – most consumer products do – but most professional CAD packages are anything but simple. The packages I’m familiar with all use scene graphs for display management, culling for large model visualizations, animation and motion for simulation and analysis, some form of shadowing technique (my product has used stencil shadows since around 1994), and various multi-texture (or multi-pass) displays for specific visualization requirements. Most of these products have been in production and development for over ten years (some for over thirty) and retaining support for an existing customer base is an absolute requirement. Fixed function pipelines will simply inherit layering when LP drivers hit the streets and will address the use or benefit of shaders as time allows.
The OP basically suggested that the LP release be named such that it is easily distinguished from classical OpenGL and personally I agree with that recommendation. Feel free to disagree.
Originally posted by tranders:
The OP basically suggested that the LP release be named such that it is easily distinguished from classical OpenGL and personally I agree with that recommendation. Feel free to disagree. [/QB]
The OP wanted GL be updated and mentions 2.5 and 3.0
It may seem like a valid suggestion but doesn’t make a whole lot of sense.
Typically it is games that need the latest extensions, features, best performance.
The OP said GL LM sucks because it will be very different while ignoring the benifits of GL LM.
I don’t know what he is working on, but in your case, do you need those Geforce 8 series extensions to become core?
Or GL could be left in it’s current state.
Originally posted by V-man:
[b]The OP wanted GL be updated and mentions 2.5 and 3.0
It may seem like a valid suggestion but doesn’t make a whole lot of sense.
Typically it is games that need the latest extensions, features, best performance.
The OP said GL LM sucks because it will be very different while ignoring the benifits of GL LM.
I don’t know what he is working on, but in your case, do you need those Geforce 8 series extensions to become core?
Or GL could be left in it’s current state. [/b]
I interpret his post to mean that LP is so radically different from the traditional OpenGL API that incrementing the version is misleading. LP is nothing like the traditional/classical OpenGL API and should be named (renamed?) accordingly. I agree that games tend to drive the latest advances but games do not have a lock on requiring performance. If the graphics card vendors can deliver layering on LP drivers without impacting the performance and quality of legacy applications I’ll be happy.
they already are, in effect.
Originally posted by knackered:
they already are, in effect.
With the exception of fixed function attributes which are currently implemented internally in the hardware between stages and have no shader based equivalency (e.g., wide/stippled wireframe).
With the exception of fixed function attributes which are currently implemented internally in the hardware between stages and have no shader based equivalency (e.g., wide/stippled wireframe).
What makes you say that these are supported in hardware? How do you know that the driver isn’t doing a texture/shader thing behind your back?
Furthermore, how do you know that, if such things are implemented in hardware, they will not be exposed through shaders or through a different kind of object?
Stipple in particular is annoying to emulate because each segment of a line strip is defined to continue the stipple pattern where the previous segment left off. Proper emulation requires calculating the screen-space length of each segment, and that seriously impacts performance.
I am aware of implementations which support this natively in hardware, and others which do not. If the driver guys do their jobs, you should not be able to tell the difference (modulo performance).
I’ve always assumed the quadros have some kind of line drawing circuitry, as they’re considerably faster at drawing lines than a chipset equivalent geforce. I suppose that would be emulated if any kind of shader is active.
Programmable hardware covers the vertex, (geometry) and fragment stages. Rasterization (i.e. generating the fragments for the current primitive) remains fixed function at this time.
Originally posted by Michael Gold:
Rasterization (i.e. generating the fragments for the current primitive) remains fixed function at this time.
And no matter how cool that would be to program, i hope it never reaches that stage, before we get programmable rasteration i think we need at least a Blend shader and maybe an object shader(that sits before the vertex shader).
Besides, what could you do with programmable rasterisation that you can’t do with the fragment shader or the geo shader.
more efficient 2D particle systems.