i was just reading ARB meeting notes and the GL2 exts are a good thing - they will come out BEFORE GL2 is finalized, allowing us to use bits of GL2 from within openGL
1.2/1.3/1.4/1.5.
the new 3Dlabs boards will possibly implement the GL2_program_object, GL2_vertex_shader and GL2_fragment_shader exts as they already have an implementation of these up and running it seems.
i would hope the GL2 exts disappear from pure GL2. but the situation during transition might be something like how most of anything over openGL1.1 is exposed thru ARB extensions on win32, rather than a proper 1.2+ implementation.
my worry is that GL2 will be implemented on windows in practice just as a bunch of GL2 extensions - ie layered on top of the existing lame wgl stuff. the new “core” GL2 funcs may just be calling the old lame wgl stuff for anything that involves interoperation with the window system.
or how’s this - your 3d cards’ openGL2.0 drivers implement the “core” GL2 window/context creation routines with DirectX calls to allocate window-system-friendly surfaces, implement triple buffering, etc!
btw, didn’t MS once claim a win32 implementation of openGL1.2 was coming in win2k service pack 2?
I thought that drivers already used ddraw to create frame buffers. This seems to occur on all windows platforms. I suppose there is some advantage for using ddraw, maybe it has good memory management routines.
Yes, it was in 2001 when SP2 was to be released. Actually, they said the same for SP1 and the orginal release. SP3 is out now.
I thought that drivers already used ddraw to create frame buffers. This seems to occur on all windows platforms. I suppose there is some advantage for using ddraw, maybe it has good memory management routines.
i thought about it a bit after i wrote it and i’m sure you’re right. i remember reading something like that in the NV VAR spec. i wonder does this have anything to do with the warning not to mix ddraw and ogl in the same app? now that dddraw is integrated into d3d it’s just kinda funny that ogl uses it, thats all.
the real issue i’m worried about, and it’s a bit OT for this thread now, is will OGL2 work fine on win32 with no cooperation from MS? (i don’t know anything about writing gl drivers so i don’t know if it will be a problem.) or will CAD app support force MS to go along… but is there anything in OGL2 that is useful for CAD apps? (over current 1.1 + exts).
Are you sure that 3D Text, Flowerbox, Pipes, and Flying Objects are implemented using OpenGL in Windows 2000?
I just did some checking and it seems that they have been ported to Direct3D for Windows XP. I was wondering how they all seemed to have multimonitor support built into them. Maybe the Window 2000 versions are implemented using Direct3D as well. If they have a button in setup called ‘display settings’ which lets you set up each monitor then they are Direct3D.
lol, I forgot about the port to d3d. Always check with Depends or an equivalent tool.
I don’t think that CAD apps will benifit much from 1.2 and above.
The most important thing for CAD is drawing lines (preferable AA lines) and the buffer region feature can be very helpful. Perhaps ogl 2 can take over ddraw functions? Video memory management is very imporant. For the case of modeling tool, some help from the driver is essential. The window may be broken into sections (rectangles) and buffer copied in an optimized way. That is one of the tricks they use.
Other than that its all about being pretty with textures and doing tricks with vertex programs. Something that a few modelling & rendering packages need and have implemented. Those companies will jump at ogl 2
We use both Direct Draw surfaces and GL RCs in the same application and a couple of weeks ago tested it across multiple monitors. We used a GF4MX on AGP and a PCI ATI Rage XL for the second card.
Some odd things were noted (of course). Firstly, if you created the application on the GeForce everything was fine until you dragged the window onto the second monitor (the ATI card), when it stopped rendering (same with the DD surfaces). Visa-versa was true also.
I see no reason why it should opaquely allow this kind of behaviour anyway - just seems dumb to me and far too complicated to get right in every instance. The solution we will recommend to our customers is to follow simple `rules’ when creating windows in the application (and possibly helping them along with some UI code) - its a lot easier than rewriting drivers to get it to work.
I guess the new Matrox card can do this stuff ok anyway because it has 2 ramdacs - can support up to 4 monitors (I think). Even so, dual monitors is best done on a card with 2 heads.