OpenGL port

[BreathesFire]

I would like to explain my current work on my opengl angband port to get some feedback.


My current file list:
MakeFile.opengl
main-opengl.c (probably should be called main-opengl-win.c)
openGLFunctions.c/h
openGLRendering.c/h
openGLShaders.c/h
openGLVertexBufferObject.c/h
openGLBindingManager.c/h
fontConverter.c/h
transcript.c/h
glext.h
wglext.h
glxext.h
min.frag
min.vert

I am not using GLEW or GLUT (typical libraries used with opengl) to reduce the dependencies as well as give myself the opportunity to learn how to do things from the ground up.

Originally I started building in the version 1 environment of openGL, but later learned that the old methods of glBegin glEnd and everything between was deprecated. The new method in version 3+ sends the vertex data to the video ram once, instead of sending the data for each frame. I decided that the purpose of building an openGL port is to use accelerated graphics, so I switched to the newer, efficient method and scrapped the old. My only worry is that older computers won't have the driver support for these newer functions.

File specific comments

MakeFile.opengl
This is a direct copy of the windows makefile, but it adds the opengl32 library and includes a new "opengl" directory to house the related code. MakeFile.src also includes the new opengl files, which needs a opengl-specific restriction on loading.

main-opengl.c
The main-opengl.c file is pretty much designed to make a window, build an openGL context, handle OS events, build and set function hooks, build the virtual terminal, and start the game. This file is a mashup between the sdl, win, and xxx files. Similar to the main-win.c, this file bypasses main.c for the sole purpose of calling WinMain() instead of main(). main() produces a console window, whereas WinMain() does not -- that's pretty much it. I am wondering if some preprocessor macro magic could change the function name and arguments of main() in main.c.
My main issue is that window context and OS events should have no direct relation to the terminal, updating hooks, and game model. I think this is important because building an openGL linux/OSX port shouldn't have to re-implement the virtual terminal and game model. I'm not quite sure of the boundary, so I'm not deviating from the original format.

openGLFunctions.c/h
This is the code that enables the opengl functions. With an exception to Windows, all functions must retrieve their procedure address via system specific glGetProcAddress(). Windows already defines version 1.1 opengl functions in <gl/gl.h>. For the remaining functions, Windows uses wglGetProcAddress(), Linux uses glXGetProcAddress(), and OSX uses aglGetProcAddress(). Windows also must have an (any) opengl context open before retrieving functions, whereas Linux and OSX apparently don't have this restriction.

openGLRendering.c/h
I made this Rendering object to handle the entire opengl process of initializing shaders, setting vertices, building glyphs, drawing frames, and properly freeing memory when finished. Currently, my idea is that the rendering handles one window, and it renders all the terminals inside this one window. I was reading that the SDL port does this, and it was not a popular design. So I want to ask what are people's opinions on terminal windows -- One master ternimal, or a bunch of individual windows? Multiple windows may be expensive on processing. Terminals themselves are probably going to be represented by individual VertexBufferObjects anyways.

openGLShaders.c/h
Shaders are the custom code that you insert into the GPU. From what I've read, you need a minimal fragment shader and vertex shader, attach them to a "program", and feed it into your graphics card via the opengl functions. The examples I have found had a generic shader object, but I decided it would be unnecessary if I was only building two static shaders, so this file compounds the program creation/deletion with the shaders.

openGLVertexBufferObject.c/h
This is where I am currently working. VertexBufferObjects are things stored in the video RAM. This code handles the process of sending the vertex data into the ram, drawing it when requested, and releasing when finished. VBOs seem to have multiple formats, which confuses me. The simple part is the vertex coordinates and their respective colors. Currently I am looking at Vertex Array Objects, Indexed Arrays, Interleaved Arrays, all of which seem to build the same 3D objects in different ways. Then there are also normal maps, UV maps, and texture maps. I only care for reaching the texture maps, which would allow me to display character glyphs.

openGLBindingManager.c/h
After getting through shaders, VBOs, and rendering, I realized that the "Bind" function is a resource heavy function since it handles video ram. To reduce the number of binds, this code prevents rebinding content that is already "open"

fontConverter.c/h
This is the current shell that reads in window FON files and converts them into a texture format. Since the opengl version change, I need to figure out what this new format should be.

transcript.c/h
A small file writing log. I made this to track code flow without using GDB.

glext.h
wglext.h
glxext.h
Distributed by The Khronos Group Inc., these files provide the necessary definitions of the opengl functions.

min.frag
text file containing the fragment shader program

min.vert
text file containing the vertex shader program


Ack, so many files already and I'm not done =(
I am not sure how to publish my work or if I even should, since it is incomplete. I'm a GIT-newbe. There something about forking angband and uploading code, but I am afraid of messing up and obliterating everything.


Anyways, any and all comments or help are welcomed.

[d_m]

I think creating a git fork is the right thing to do.

First, make a backup copy of all your work (especially if you're worried).

Next, create an account at github.com.

Next, fork the angband/angband repo.

Now, you'll have a repo called something like BreathesFire/angband.

You should clone that repo (e.g. git clone git@github.com:Breathes/angband.git)

Now you should start copying files into that directory until it seems to work. After you get it working as well as your current copy is working, you'd want to run git commit -a to commit all your changes.

After that, keep working in this folder. When you get things to a "save point" (e.g. a place you might want to go back to if you mess things up) do another commit. Once you get things to the point where you want other people to see your work (or when you're ready to request that your work be pulled back into V) you're ready to worry about merging your work.

Does this help? Ping me on IRC (or here) if you need more detailed instructions.

[BreathesFire]

That was helpful. Let me try to get to a "working" build and I'll try committing to my fork.