After successfully writing solutions for 1-10 of NeHe’s OpenGL tutorials I decided it was time to venture into newer technology. OpenGL 3+ is a bit harder to use compared to the older versions. The main issue is creating a render context. This was already a hard task in assembler and 3+ does not make the task any easier. First you create a context just like in NeHe’s tutorial but then you need to get function pointers for all of the OpenGL functions you plan on calling. After achieving this you destroy your context and remake it using the functions you have just found. It is a bit of tedious task I think I’m confident I could achieve it but I have decided I don’t want to focus on that for my latest endeavor.

What I plan to do instead is use GLFW and GLEW to help with OpenGL. GLFW is an OpenGL library that helps with creating windows and such. GLEW is an OpenGL extensions library that gets all of the function pointers I mentioned earlier and gets them ready for use. Again I plan to follow someone else’s tutorial as I do not have much knowledge of OpenGL at this point. The tutorials I plan to rewrite are fromĀ Their tutorials are using out of date versions of GLFW and GLEW and I plan to modify the solutions to use the latest versions.

At the same time I have decided that I will use Microsofts Incremental Linker (link.exe) instead of ALINK. My only reason for doing this is to try a different way of linking my executables. One of the changes with using the link.exe instead of alink is that NASM has to compile win32 obj files instead of borland compatible obj files. This change means that you can’t use the import directive to specify which dll you are linking with. When not using the import directive lib files are passed into the linker at link time. In the grand scheme of things it means you don’t have to specify anything in the import part. One disadvantage of this is that you have to use the correct names as specified in the lib file and these are not always the same as the names specified in documentation. For example from kernel32.dll:

_ExitProcess@4 instead of ExitProcess

The @4 informs you that the function is a std call and would like 4 bytes of information on the stack and you should clean up the stack after the call. ExitProcess( DWORD var ). If there is no @X then it is probably a cdecl call and you do not need to clean up the stack. It just so happens that the WinAPI and GLEW uses std calls and GLFW uses cdecl calls. This is important and there will probably be many bugs in my programs in the future due to me forgetting this.

All code for this can be found on my github.