有点无聊，于是打开了之前收藏的关于opengl tutorials的链接。既然是tutorial嘛，当然很多都是初步介绍怎么使用api等一些基础，于是有点烦。
就想，为什么要学OpenGL呢？
1. 通过学OpenGL来了解Graphics/Rendering Pipeline.
例如在看Essential Mathematics for Grames and Interactive Application时候，那些Transformation, lighting, framebufffer等概念以及计算方式，
要是结合OpenGL的Api，那些原理对应什么api，能达到什么效果，这感觉多好啊。
例如在3D Game Engine Design, second edition时候，那个software render engine，要是结合原理一起看，那估计就深刻了。
2. OpenGL是基础招式，例如C/C++的语法掌握，在此基础上可以去学习很多更复杂的算法、框架和系统等。
例如http://www.paulsprojects.net/opengl/projects1.html这上面就很多特效算法，当然不是为了某几个特别的例子啦，
我估计从它们中可以了解到一类的特效，甚至做一个特效系统，然后特效算法估计也涉及其它更广阔的知识面。
2009年7月10日星期五
glext; glew, glee这些library的原理
下面就是glext为我们做的事：
(1), 根据显卡厂商对某个extension的具体说明来定义一些宏.
#define GL_ARRAY_BUFFER_ARB 0x8892 //具体的地址是在各个specification中定义的.
#define GL_STATIC_DRAW_ARB 0x88E4
(2), 声明一些函数指针的类型.
typedef void (APIENTRY * PFNGLBINDBUFFERARBPROC) (GLenum target, GLuint buffer);
typedef void (APIENTRY * PFNGLDELETEBUFFERSARBPROC) (GLsizei n, const GLuint *buffers);
typedef void (APIENTRY * PFNGLGENBUFFERSARBPROC) (GLsizei n, GLuint *buffers);
typedef void (APIENTRY * PFNGLBUFFERDATAARBPROC) (GLenum target, int size, const GLvoid *data, GLenum usage);
然后在我自己的实现中就需要做以下的事:
(3). 声明定义一些函数指针:
PFNGLGENBUFFERSARBPROC glGenBuffersARB = NULL;
PFNGLBINDBUFFERARBPROC glBindBufferARB = NULL;
PFNGLBUFFERDATAARBPROC glBufferDataARB = NULL;
PFNGLDELETEBUFFERSARBPROC glDeleteBuffersARB = NULL;
(4). 利用wglGetProcAddress函数取得各个函数的地址指针.
glBindBufferARB = (PFNGLBINDBUFFERARBPROC)wglGetProcAddress("glBindBufferARB");
glGenBuffersARB = (PFNGLGENBUFFERSARBPROC)wglGetProcAddress("glGenBuffersARB");
glBufferDataARB = (PFNGLBUFFERDATAARBPROC)wglGetProcAddress("glBufferDataARB");
而其实在glATI.h, wglATI.h, ATIExtensions.h, and ATIExtensions.c中也是这么做的.
那些glew, glee就将上面4步都给我们做了.
所以当使用extensions时候，
要么是下载glext回来，自己提供源代码实现(3, 4)两步.
要么是直接用glew or glee.
(1), 根据显卡厂商对某个extension的具体说明来定义一些宏.
#define GL_ARRAY_BUFFER_ARB 0x8892 //具体的地址是在各个specification中定义的.
#define GL_STATIC_DRAW_ARB 0x88E4
(2), 声明一些函数指针的类型.
typedef void (APIENTRY * PFNGLBINDBUFFERARBPROC) (GLenum target, GLuint buffer);
typedef void (APIENTRY * PFNGLDELETEBUFFERSARBPROC) (GLsizei n, const GLuint *buffers);
typedef void (APIENTRY * PFNGLGENBUFFERSARBPROC) (GLsizei n, GLuint *buffers);
typedef void (APIENTRY * PFNGLBUFFERDATAARBPROC) (GLenum target, int size, const GLvoid *data, GLenum usage);
然后在我自己的实现中就需要做以下的事:
(3). 声明定义一些函数指针:
PFNGLGENBUFFERSARBPROC glGenBuffersARB = NULL;
PFNGLBINDBUFFERARBPROC glBindBufferARB = NULL;
PFNGLBUFFERDATAARBPROC glBufferDataARB = NULL;
PFNGLDELETEBUFFERSARBPROC glDeleteBuffersARB = NULL;
(4). 利用wglGetProcAddress函数取得各个函数的地址指针.
glBindBufferARB = (PFNGLBINDBUFFERARBPROC)wglGetProcAddress("glBindBufferARB");
glGenBuffersARB = (PFNGLGENBUFFERSARBPROC)wglGetProcAddress("glGenBuffersARB");
glBufferDataARB = (PFNGLBUFFERDATAARBPROC)wglGetProcAddress("glBufferDataARB");
而其实在glATI.h, wglATI.h, ATIExtensions.h, and ATIExtensions.c中也是这么做的.
那些glew, glee就将上面4步都给我们做了.
所以当使用extensions时候，
要么是下载glext回来，自己提供源代码实现(3, 4)两步.
要么是直接用glew or glee.
2009年7月9日星期四
opengl32.dll--Windows系统下OpenGL的实现和扩展
Windows, OpenGL Versions, and Extensions
这是在http://www.gamedev.net/ 上看到的文章, 这里转帖一下:
Something I've noticed any number of times is that many people are quite vague on how OpenGL works on Windows. This causes a lot of confusion about exactly what the limitations on Windows are with respect to versions, and people tend to say things that don't make sense. The most common misunderstanding is that Windows is limited to OpenGL 1.1. It's time to clear things up.
First, let's start by dissecting the basic OpenGL architecture on Windows. When you build your OpenGL based program, you link to opengl32.lib. This file from the Platform SDK is a companion to the opengl32.dll that ships with Windows. The GL/gl.h header you use matches these two files. When your code runs, some behind the scenes work happens that loads up the functions out of opengl32.dll. However, opengl32.dll is a purely software implementation of OpenGL 1.1, and it's probably not what you want to be using. What you want to be using is the real OpenGL DLL, for example nvoglnt.dll. This file is installed with your video driver.
This is where magic starts to happen. Your calls to opengl32.dll will be redirected to the actual driver specific DLL, which exports at least all the functions in opengl32.dll. The trick is, it also exports a lot more than that. The entire OpenGL API for the version that it supports will be exported, along with all the extensions. Calls to wglGetProcAddress become GetProcAddress calls on the OpenGL DLL that came from the driver. This isn't limited to extensions; you can use it on regular non-extension functions as long as the video driver supports a version of OpenGL that includes them.
The problem here is that, depending on the manufacturer of your video driver and the version, the real DLL that implements OpenGL could be anywhere. Windows provides opengl32.dll as a common place to go to, instead of having to figure out what DLL you need at runtime. That DLL also servves the dual purpose of providing the basic software implementation. That's why it's nearly never been updated; adding new OpenGL functions would mean writing code to implement all of that in software. In Vista they decided to provide a new version built on D3D instead of software, so applications using the Vista headers and libraries can get a baseline of OpenGL 1.4 statically.
All that an extension loader does, then, is to automate the tedious process of making the dozens or hundreds of GetProcAddress calls to retrieve the functions that aren't statically linked and forwarded. Again, these functions don't have to be extensions. You can wglGetProcAddress for glMapBuffer, not just glMapBufferARB. There's no question of what Windows supports. It doesn't matter. The only function you actually need from Windows is wglGetProcAddress, which is your key to accessing the real OpenGL DLL. The rest of the interface is just a convenience in that you don't have to go out and get the addresses for the OpenGL 1.1 functions, since they're already being redirected for you. And since modern extension loaders are machine generated systems that automatically look up everything, it's less relevant than ever before.
这是在http://www.gamedev.net/ 上看到的文章, 这里转帖一下:
Something I've noticed any number of times is that many people are quite vague on how OpenGL works on Windows. This causes a lot of confusion about exactly what the limitations on Windows are with respect to versions, and people tend to say things that don't make sense. The most common misunderstanding is that Windows is limited to OpenGL 1.1. It's time to clear things up.
First, let's start by dissecting the basic OpenGL architecture on Windows. When you build your OpenGL based program, you link to opengl32.lib. This file from the Platform SDK is a companion to the opengl32.dll that ships with Windows. The GL/gl.h header you use matches these two files. When your code runs, some behind the scenes work happens that loads up the functions out of opengl32.dll. However, opengl32.dll is a purely software implementation of OpenGL 1.1, and it's probably not what you want to be using. What you want to be using is the real OpenGL DLL, for example nvoglnt.dll. This file is installed with your video driver.
This is where magic starts to happen. Your calls to opengl32.dll will be redirected to the actual driver specific DLL, which exports at least all the functions in opengl32.dll. The trick is, it also exports a lot more than that. The entire OpenGL API for the version that it supports will be exported, along with all the extensions. Calls to wglGetProcAddress become GetProcAddress calls on the OpenGL DLL that came from the driver. This isn't limited to extensions; you can use it on regular non-extension functions as long as the video driver supports a version of OpenGL that includes them.
The problem here is that, depending on the manufacturer of your video driver and the version, the real DLL that implements OpenGL could be anywhere. Windows provides opengl32.dll as a common place to go to, instead of having to figure out what DLL you need at runtime. That DLL also servves the dual purpose of providing the basic software implementation. That's why it's nearly never been updated; adding new OpenGL functions would mean writing code to implement all of that in software. In Vista they decided to provide a new version built on D3D instead of software, so applications using the Vista headers and libraries can get a baseline of OpenGL 1.4 statically.
All that an extension loader does, then, is to automate the tedious process of making the dozens or hundreds of GetProcAddress calls to retrieve the functions that aren't statically linked and forwarded. Again, these functions don't have to be extensions. You can wglGetProcAddress for glMapBuffer, not just glMapBufferARB. There's no question of what Windows supports. It doesn't matter. The only function you actually need from Windows is wglGetProcAddress, which is your key to accessing the real OpenGL DLL. The rest of the interface is just a convenience in that you don't have to go out and get the addresses for the OpenGL 1.1 functions, since they're already being redirected for you. And since modern extension loaders are machine generated systems that automatically look up everything, it's less relevant than ever before.
2009年7月8日星期三
Reading note - memory management
book1: Memory as a Programming concept in c and c++ 已经打印了.
book2: c++ pointers and dynamic menory management. Michael C. Daconta.
Memory location: a container that can store a binary number.
Address: a unique binary number assigned to every memory location. 特别的二进制数。
Pointer: a memory location that stores an address
Variable:a named memory location that can store a value of certain data type..[book2 chapter2]
There is absolutely no difference in functionality between pointers and references. The difference is that with references, the compiler handles the details of passing pointers and dereferencing them instead of you doing it yourself.
1. A reference is an alias for a variable, is not an object, while a pointer is an object. An object has two main attributes: its storage class and its type. The storage class determines the lifetime of this chunk of storage, while the type determines the meaning of values found in the object.
2. References exist only in the compiler and not after compilation. They have symbol table entries only.
3. 初始化时候要给出初值，除了在class中是在初始化列表中的，不能做数学操作.
Array name, is a label, the label of the first address, is not the same as a pointer.
Three memory spaces: [book1,2]
1. global: for global variables(函数之外没有被static关键字的, 函数之内有static关键字的，类声明中static的variables), allocated at compile.
2. stack: activation frame when a function is called, the local automatic variables.
3. free store: binary heap(system heap or free store) at os level keeped by os memory management, dynamic list of free segments at process level keeped by process memory manager.[book1 chapter4].
malloc/new.
malloc 自己用sizeof觉得分配的字节数，返回的是void*，分配得到的空间之内是垃圾数据；
而new在这三方面都有所不同。
Pass by value: cope the variable's content to the activation frame(function stack).
Pass by reference: cope the variable's address to the activation frame.
在datastructure中找linklist的笔记, 也涉及pointer的使用, 学会画图来表示, 32bit里面是variable的地址呢，还是pointer的地址呢?这就是一级pointer和二级pointer的区别。
特别是那个push(struct node *head, int data)的为什么错了, 而需要改成push(struct node **head, int data)?
一定要学着画图, 并且结合以下的概念，
函数传递struct node，那么是将整个structure copy一份到被调用函数的activation frame;
如果函数传递的是struct node*，那么是将structure的地址，也就是指针本身的context copy一份到被调用函数的activation frame;
如果函数传递的是struct node**，那么是将指针本身的address copy一份到被调用函数的activation frame, 这样就修改到指针本身了.
book2: c++ pointers and dynamic menory management. Michael C. Daconta.
Memory location: a container that can store a binary number.
Address: a unique binary number assigned to every memory location. 特别的二进制数。
Pointer: a memory location that stores an address
Variable:a named memory location that can store a value of certain data type..[book2 chapter2]
There is absolutely no difference in functionality between pointers and references. The difference is that with references, the compiler handles the details of passing pointers and dereferencing them instead of you doing it yourself.
1. A reference is an alias for a variable, is not an object, while a pointer is an object. An object has two main attributes: its storage class and its type. The storage class determines the lifetime of this chunk of storage, while the type determines the meaning of values found in the object.
2. References exist only in the compiler and not after compilation. They have symbol table entries only.
3. 初始化时候要给出初值，除了在class中是在初始化列表中的，不能做数学操作.
Array name, is a label, the label of the first address, is not the same as a pointer.
Three memory spaces: [book1,2]
1. global: for global variables(函数之外没有被static关键字的, 函数之内有static关键字的，类声明中static的variables), allocated at compile.
2. stack: activation frame when a function is called, the local automatic variables.
3. free store: binary heap(system heap or free store) at os level keeped by os memory management, dynamic list of free segments at process level keeped by process memory manager.[book1 chapter4].
malloc/new.
malloc 自己用sizeof觉得分配的字节数，返回的是void*，分配得到的空间之内是垃圾数据；
而new在这三方面都有所不同。
Pass by value: cope the variable's content to the activation frame(function stack).
Pass by reference: cope the variable's address to the activation frame.
在datastructure中找linklist的笔记, 也涉及pointer的使用, 学会画图来表示, 32bit里面是variable的地址呢，还是pointer的地址呢?这就是一级pointer和二级pointer的区别。
特别是那个push(struct node *head, int data)的为什么错了, 而需要改成push(struct node **head, int data)?
一定要学着画图, 并且结合以下的概念，
函数传递struct node，那么是将整个structure copy一份到被调用函数的activation frame;
如果函数传递的是struct node*，那么是将structure的地址，也就是指针本身的context copy一份到被调用函数的activation frame;
如果函数传递的是struct node**，那么是将指针本身的address copy一份到被调用函数的activation frame, 这样就修改到指针本身了.
订阅：
博文 (Atom)