#low@irc.freenode.net logs for 1 Nov 2003 (GMT)

Archive Today Yesterday Tomorrow
LoW homepage


[01:49:55] <Coren_> Crud. Turns out qbsp3 creates /concave/ visgroups.
[01:51:05] <Coren_> Yukness. Means I /have/ to write a world editor after all.
[01:51:42] * Coren_ isn't looking forward to this.
[01:52:42] <servus> Heh
[01:52:53] <servus> I hate extensions... I want GL 2
[01:53:07] <Coren_> Why?
[01:53:29] <Coren_> GL2 is also going to do extensions. That's what sets GL above and beyond Dirape 3d.
[01:53:33] <servus> The worst part is, of course, trying to find relevant information and technical documentation... I can't believe that most of these extensions only have a light abstract for them in the registry, and no demos elsewhere.
[01:53:57] <Coren_> "light" abstract? There are complete specs.
[01:54:06] <Coren_> No sample code, though.
[01:54:52] <servus> They don't give enough information to get you going
[01:54:58] <Coren_> The only problem is that the specs are sorts of diffs against Base GL + prerequisite. Sorta CVS.
[01:55:03] <servus> I'm referring to the information that I have to add to my glext
[01:55:49] <servus> They don't give any sort of standard export names...
[01:56:17] * Coren_ doesn't get you.
[01:56:31] <Coren_> Every extension defines, in detail, every single symbol that is used.
[01:57:39] <servus> They don't tend to give function extern tokens.
[01:58:07] <Coren_> What is a "function extern token"? And what extension do you feel something is missing?
[01:58:07] <servus> At least not for the extensions I'm interested in...
[01:58:41] <servus> Here's an example: PFNGLSECONDARYCOLOR3FEXTPROC glSecondaryColor3fEXT = (PFNGLSECONDARYCOLOR3FEXTPROC)SDL_GL_GetProcAddress("glSecondaryColor3fEXT");
[01:59:17] <Coren_> Aaaaah! That has *nothing* to do with OpenGL! That's WGL garbage!
[01:59:37] <servus> Implementation details are important!
[02:00:12] <Coren_> Yes. "glSecondaryColor3fEXT" is properly defined. The fact that your platform is severely broken isn't GL's problem.
[02:00:38] <servus> Likewise, typedef void (__cdecl * PFNGLSECONDARYCOLOR3FEXTPROC) (GLfloat red, GLfloat green, GLfloat blue); <- the spec gives no information on how I'd figure that out, if it were not done for me
[02:00:48] <Coren_> Should GL also define API details for GL on Commodore 64? LOL
[02:01:23] <servus> It should define function return types, tokens and parameters
[02:01:58] <Coren_> It does. For the *real* function. Those ugly macros are WGL garbage caused by Microsoft's completely assinine implementation of dynamic binding. :-)
[02:02:07] <servus> That's SDL, actually.
[02:02:35] <servus> Regardless of anything, I need a function prototype and they hold out on me.
[02:02:50] <Coren_> No, SDL just gives you a polite wrapper around everything else; in your case, WGL.
[02:03:30] <Coren_> Why do you even bother with GetProcAddress anyways?
[02:03:38] <servus> It needs to be done, does it not?
[02:03:47] <Coren_> Not with SDL it doesn't.
[02:03:52] <servus> How am I to call an extended [extern] function without resolving the function address?
[02:04:08] <Coren_> Because that's what a dynamic linker is for! :-)
[02:04:23] <servus> It doesn't work that way over here. ;-)
[02:04:29] <Coren_> Just call the real function directly and let the dynamic linker worry about resolving it. :-)
[02:04:32] <servus> extern'd functions need to be resolved in the code.
[02:05:23] <Coren_> Ah, true, the Windows dynamic linker is broken.
[02:05:50] <servus> Regardless of *anything*, a function prototype is necessary.
[02:06:54] <servus> Besides, my card doesn't support GL_ARB_POINT_SPRITE...
[02:06:57] <servus> :D
[02:07:34] <servus> Oh well, I have some diagrams to sketch out...
[02:10:58] <Coren_> You get all your /real/ prototypes when you include the proper includes.
[02:11:22] <Coren_> Indeed, declaring a function you do not define yourself is *very* bad coding.
[02:11:43] <servus> I don't have the proper includes
[02:12:06] <servus> Likewise, they are not provided, which takes me to my original point.
[02:12:09] <Coren_> Go get the correct gl.h
[02:12:16] <servus> I have the newest of all of those.
[02:12:17] <Coren_> It *is* part of the standard.
[02:12:33] <Coren_> Then it has all registered extensions' prototypes and symbols in it.
[02:12:35] <servus> I don't declare any prototypes myself.
[02:12:40] <servus> No, it does not.
[02:12:52] <Coren_> Then you have broken gl.h
[02:12:58] <Coren_> Go get a correct one.
[02:13:26] <Coren_> Want mine?
[02:13:33] <servus> What's your version?
[02:13:58] <servus> Eeek, 1.1 here! I didn't update that one >.<
[02:14:04] <Coren_> Dunno. Doesn't appear marked, but it defined GL_VERSION_1_4
[02:14:29] <servus> Ah, I see, the registry only includes gl*ext files
[02:15:31] <Coren_> .. and ARB supposedly.
[02:15:46] <servus> They only post glext.h, glxext.h, and wglext.h on that page... *Searches*
[02:16:22] <Coren_> You want a vendor gl.h for vendor extensions (obviously). Though most include most-- nVidia's include many SGI, APPLE, HP, etc.
[02:17:01] <Coren_> Hm. Forgot. Broken dcc. Hang on.
[02:17:38] <Coren_> http://tab.ctrl-alt-del.ca/~marc/gl.h
[02:17:38] <servus> I have a firewall up... I'll check dev.nvidia
[02:17:49] <servus> 404
[02:18:02] <Coren_> Try that again. My bad.
[02:19:52] <servus> Thanks, let's see if it breaks my program :)
[02:21:10] <servus> It did. :P
[02:21:22] <Coren_> Then, technically, your program is broken.
[02:21:58] <Coren_> Erg. I *so* do not want to have to write a world editor.
[02:22:22] <servus> I'm taking out my externs.
[02:22:28] <servus> Use 3dMax *grin*
[02:22:41] <Coren_> Ah, yes, like I said, those declarations should never have been there to begin with. :-)
[02:23:31] <servus> I can help you write a 3DMax exporter at least. *grin*
[02:24:35] <servus> Yay, linking errors, my favourite thing in the world.
[02:24:55] <Coren_> Heh. The problem to solve with an exporter is NP-complete: find the minimal set of convex enclosed spaces. Not much to do except write an editor from scratch that undertands sectors, really.
[02:26:12] <servus> Well.... not really.
[02:26:28] <Coren_> Silly qbsp3 cheats and doesn't bother with convex sectors. Which also means that because of this flaw, the q2 engine is severely suboptimal.
[02:26:36] <servus> Worldcraft will convert DXF files into proper Quake Maps, for instance. DXF files are just vertex-based data.
[02:27:22] <servus> I believe they just originate from the info_player_start entity and search for leaks to the outside world. Once the world has been guaranteed as 'watertight', they know that all the polygon-to-plane conversions will be correct.
[02:27:47] <Coren_> Yes, but it breaks the visgroups into rough approximations, not convex hulls.
[02:28:37] <Coren_> iD just punted on the problem and decided they didn't mind overdraw. But my system requires true convexness (which makes it very fast because of the large number of presumptions I can make.
[02:28:41] <servus> Now that's just not right... it can't resolve glRotatef?
[02:29:04] <Coren_> *shrug* WGL might need evil voodoo to do things right.
[02:29:23] <Coren_> I wouldn't know. I compile my windows executables under Linux so I don't have to mess with that garbage.
[02:29:35] <servus> But... of course I never extern'd glRotatef et al so it shouldn't be broken now!
[02:30:10] * servus bonks his head
[02:30:19] <Coren_> And I use a real compiler, too. :-)
[02:30:57] <servus> CL is mediocre, but VC++ IDE is fantastic!
[02:31:23] <Coren_> Yes, I see the bonks on your head proving how fantastic it is. :-)
[02:32:01] <Coren_> ./configure --target=win32-mingw && make
[02:32:53] <servus> It's just something stupid that could occur with any compiler or platform
[02:33:31] <servus> I bet there's vicious anti-Windows code in your gl.h :D
[02:33:48] <servus> It's simply not linking to opengl32.lib though I tell it to
[02:33:59] <Coren_> Yes. Right. Funny, though, that those things that could occur to any compiler or platform always occur on windows. :-)
[02:35:00] <Coren_> Windows is sorta semi-adequate for end users, but as a development platform it sucks so greatly that even a VAX running VMS is friendly in comparision.
[02:35:04] <servus> That's a shifted representation of the issue!
[02:36:21] <Coren_> Hey; I have programmed professionally for nearly 18 years, now, and on more platforms than you have likely ever seen. I can tell you for a fact that Windows is the most broken of all.
[02:36:48] <servus> Maybe I'll create my own lib from the opengl32.dll
[02:37:06] <Coren_> Some give you very little to work with, some are a charm, but Win32 is the only one I have ever seen where the API is an actual hinderance.
[02:38:11] <servus> It's a link error, that's all!
[02:38:17] <servus> I'll figure it out after dinner, 'ta.
[02:38:33] <Coren_> The Win32 APIs are a confusing hodgepodge of simple to use complex interfaces that never do /quite/ what you want, and needlesly compilcated low-level stuff that takes pages of code to do the simplest of things. :-)
[02:38:35] <Coren_> Bye!
[02:38:36] <Coren_> :-)
[02:38:48] <servus> I program Linux in MSVC++ without much trouble at all!
[02:39:34] <-- Coren_ has left IRC ("BBL")
[06:26:53] <servus> I was right -- your Nixon gl.h was killing it, I simply awk'd gl.h back to Windows-Speak
[08:09:56] <servus> Straight from the horse's mouth: The problem is
[08:09:57] <servus> that because of the way Microsoft chose to support OpenGL extension functions, an OpenGL
[08:09:57] <servus> application cannot simply link with these functions. The application must first use the
[08:09:57] <servus> wglGetProcAddress1 routine to query the function address and then call through the returned
[08:09:57] <servus> address to call the extension function.
[08:10:09] <servus> Oh, I hate how mIRC does multiple posts per newline >.<
[10:09:14] <servus> Haha, I got it to work in VC++ with minimal hackage!
[22:12:54] --> Coren_ has joined #low
[22:12:54] --- ChanServ gives channel operator status to Coren_