User talk:V-man

Hello. I was noticing some of your recent work, and I wanted to bring something to your attention. Wikipedia defines a minor edit as fixing typos, formatting, and various other small things that do not alter the functional content of a page. I believe that some of your edits that you mark as being "minor" do not qualify.

For example, this edit. It has added content to the page, in the form of GL 3.0 versions of function calls. It may not have added a new section or made radical changes to the page's contents, but it is far from typo corrections or formatting changes. Alfonse 15:03, 27 April 2011 (CDT)

I see. That also answers what should be done in the case of spelling corrections. I was wondering if there was a way to not record it in the history. V-man 16:02, 27 April 2011 (CDT)

---

First, I'd like to thank you for your input on the OpenGL Wiki. However, there is a subject matter I would like to bring to your attention.

The <br> elements that you put at the end of your lines. These are poor MediaWiki formatting. Instead, simply separate your lines by a blank space. Alfonse 18:20, 24 August 2009 (UTC)

I saw the page you posted, OSX.6 Geforce 9400 features, and you seem to still be using <br> tags. Alfonse 23:34, 30 August 2009 (UTC)

It seems that you're not very well versed on MediaWiki editing conventions. For example, conversations like this are appropriate for user's talk pages, not that user's main pages. The user's main page is for that user to talk about themselves as it relates to the Wiki. Indeed, modifying someone else's talk page for them is generally a big no-no.

Also, when having a conversation like this, it is customary to reply on the talk page where the conversation started, not to ping-pong back and forth between two users' talk pages. Lastly, always use ~~~~ to sign posts on discussion pages: it makes it easy to see who is responsible for which statements.

As to the subject of this discussion, if you want a list of things, you should use list formatting. MediaWiki has a lot of good formatting tags. You should not try to use <br> as a way of replicating some exact look that you're interested in. On the page in question, for example, you put a line break after the inline-list of extensions; that simply makes the paragraph hard to read.

Remember: this is a web-page. Everyone has a different monitor resolution and so forth. Let HTML and MediaWiki formatting do their jobs. It is better for an article to seem to have too much line spacing than for it to have too little. Alfonse 20:47, 31 August 2009 (UTC)

---

Hello. I noticed one of your recent edits, and I was wondering if you could start using some of the formatting templates I've developed and distributed to various pages. Of particularly utility is the Template:apifunc apifunc template, which links directly to documentation about the function. Alfonse 09:15, 7 April 2012 (PDT)

Will do! V-man 04:58, 16 April 2012 (PDT)

Oh, and BTW: I saw your changes on the "Texturing a Sphere" page. The <source lang=""> stuff includes GLSL. So you can use <source lang="glsl"> for shader code. I noticed that you used lang="c". A full list of supported languages is available. Alfonse 23:05, 21 April 2012 (PDT)

Changes to OpenGL Loading Library

I reverted your change to the OpenGL Loading Library page. You stated that "Extension loading libraries don't fetch the function pointers for GL 1.1 because these are already available from a library (ex: opengl32.lib on MS Visual C++)" That's not true at all. GLEW and the GL SDK (at the very least. I haven't looked at GLee or GL3W) both provide their own function pointers for core 1.1 stuff. You don't #include gl.h with them at all; indeed, you can't include gl.h before including their headers, or they will fail to work.

This is done for the sake of consistency. They don't technically "load" those function pointers with wglGetProcAddress, but they do get those function pointers and store them in variables and #defines just like other OpenGL stuff. It also makes the non-Windows ports easier, since glXGetProcAddress will return function pointers for 1.1 stuff. Alfonse (talk) 23:56, 14 July 2012 (PDT)

I looked into it and it doesn't look like it loads function pointers for GL 1.1 stuff. glew_head.h just duplicates gl.h, therefore you don't need gl.h. You still need to link with opengl32.lib. On *nix system, I imagine it is the same situation : you feed -lGL to your linker even if you are linking with -Lglew32. Go ahead and try it. Make a simple project and link with glew32 only and your linker can't find any of the GL 1.1 functions. V-man (talk) 04:21, 15 July 2012 (PDT)

There is a difference between what library you link to and where you get your function pointers from. You have to link with those libraries to be able to get the function pointers either way (since OpenGL32.lib is an import library for OpenGL32.dll). But I see your point on how GLEW links statically to 1.1. That doesn't change the fact that a loading library doesn't have to link statically to them. GL Load in the GL SDK doesn't; for the sake of consistency (and ease of implementation), it loads 1.1 functions them dynamically by getting the OpenGL32.dll module and pulling function pointers from it where appropriate.

So the statement is still false in general. You can put that notation in the GLEW section if you like, but it is most certainly not true of all OpenGL loading libraries. Alfonse (talk) 10:21, 15 July 2012 (PDT)