First off, I have to say Thank You Homer -- for not spoon feeding me, but feel free to jump in and teach me good habbits while I have a fighting chance.  I've learned a lot from all the stupid error messages and such.  ;)  At any rate, I would like to put out a basic structure for first timers attempting to use OpenGL and GLUT, it gets really messy because so many links are broken and there really isn't a good guide (that I could find) for me (the MASM user).  I'll try to give credit to where I copied/pasted others code.

Ok you will want to get the VC++ style ArgC and ArgV pointers, so link to MSVCRT.inc and .lib and use this code.  While you are at it also link to gl.inc glu32.inc glut32.inc glu32.lib glut32.lib and opengl32.lib  I can't tell you how long I searched for GL.lib, it was really opengl32.lib :S

;;http://www.masm32.com/board/index.php?topic=1286.0
bWildCard DD 0
pEnv DD 0 ; environment variables
pArgv DD 0 ; arguement vectors
nArgc DD 0 ; arguement count
stinfo STARTUPINFO <?>
;;



mov bWildCard, FALSE
Push Offset stinfo
Push bWildCard
Push Offset pEnv
Push Offset pArgv
Push Offset nArgc
Call getmainargs

From here you can now satisfy glutInit and set up some basic operations

GLUT_SINGLE Equ 0
Invoke glutInit, Addr nArgc, Addr pArgv
Invoke glutInitDisplayMode, GLUT_SINGLE
Invoke glutInitWindowSize, 500, 500
Invoke glutInitWindowPosition, 100, 100
Invoke glutCreateWindow, CTEXT("First GLUT try")
Invoke glutDisplayFunc, Addr Redraw

And the code in your Redraw proc might start off similar to

R8Zero Real8 0.0
R8Half Real8 0.5
R8One Real8 1.0
Redraw Proc
Invoke glClearColor, 00, 00, 00, 1
;glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
Invoke glClear, GL_COLOR_BUFFER_BIT + GL_DEPTH_BUFFER_BIT
Invoke glLoadIdentity
Invoke gluLookAt, , , , , , , , ,
Invoke glFlush
Ret
Redraw EndP

Another thing about using this code, as I go I am changing my include files to use REAL8 instead of Dword, Dword so my glu32.inc has these two lines changed

;gluPerspective PROTO :DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD
gluPerspective PROTO :REAL8, :REAL8, :REAL8, :REAL8
;gluLookAt PROTO :DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD,:DWORD
gluLookAt PROTO :REAL8,:REAL8,:REAL8,:REAL8,:REAL8,:REAL8,:REAL8,:REAL8,:REAL8


Even after all of this, it seems that all I can get is a black box even if I do a glBegin ... glEnd.  I even tried setting the camera and line color but nothing appears
Posted on 2009-09-18 23:02:36 by GoldStar611
That is correct, because you did not draw anything :)

You have written an empty 'shell application' for opengl apps, and its rendering *blackness*, so we know its working, however we did not tell it to draw anything.
And theres no need to call LookAt from the 'onDraw' callback function UNLESS the camera view has changed.
Since you don't (yet) have any camera code, theres no need. Call it once, from the main code.
Posted on 2009-09-18 23:41:10 by Homer
I'd quickly graduate from GLUT and simply write my own windowing and input code. Simply because once your game HAS a main-loop, instead of callbacks, it's a thousand times easier to make the game. Then, I'd put all GL commands together, instead of having glViewport/gluPerspective/gluLookAt being called in random callbacks. Just a matter of taste and keeping things coherent.
For a quick-start, if you like my approach, you can extract+port code from: http://dl.getdropbox.com/u/1969613/OpenIL.7z  (ILX_Main.cpp) . Ignore the shader/stuff initialization and the use of custom maths (those things are required only in strict OpenGL3.2 environment).
The camera-code inside could be a bit tricky to port, as I work in left-hand coord-sys. (GL transforms stuff in right-hand sys, but presents them in left-hand, which is a major pain). You just need to negate a few signs for the movement-vectors, you'll notice which.

Here's a quick preview of what the posted main.cpp does: http://dl.getdropbox.com/u/1969613/mot2.avi


When you don't see a thing onscreen, chances are the camera is not looking at it :) . That's why once you manage to draw a single flat triangle with z=0, it's probably best to make some gluLookAt-based camera. (it's quite easy, just make the camera look at (0,0,0), position it at (0,0,-1) and vary the position x/y/z with keys).
Posted on 2009-09-19 00:22:45 by Ultrano
Wow, that is amazing Ultrano.  And I'll be damned if I didn't see that level on Counter Strike ;)  You were both right, I had a few line segments drawn but my perspective wasn't right.  As far as the LookAt function being called, it was just a direct translation of a c++ tutorial I was reading online. 

I see now that it is going to be increasingly hard to get things right with GLUT (namely the callbacks dont allow for much freedom).  I've ordered a book on OpenGL as well, to give me some time to study and reference away from the keyboard.  I can only sit down for so long figuring things out on my own.  One quick question though, is MASM able to push Real4 and Real8 onto the stack like regular numbers?  Would be nice not to use the macros at the moment.
Posted on 2009-09-19 00:46:24 by GoldStar611
Unfortunately MASM doesn't support pushing of real4/real8 out of the box. Fortunately, there is an invoke2 (I don't recall its exact name) that does that, with param-checking. Also, there's this little snippet:


pushf macro value ; I don't remember right now where the "org $-4" was priceless
   push 011223344h
   org $-4
   real4 value
endm

pushf2 macro value
  db 68h
  real4 value
endm


P.S. Thanks, though the demo is extremely simplistic actually, except for the included code to research some advanced skinmeshing (I'm aiming to make Uncharted: Drake's Fortune style animation). Once you get the basic keyboard-input, a simple camera, have the maths-funcs ready, texture-loading and binary file-formats ready, it's just a few lines to draw such a demo.
Posted on 2009-09-19 00:53:23 by Ultrano
Huh, OpenGL and GLUT develop in Assembly, that's cool! :shock:

I only used they in my C++ game projects! ;)
Posted on 2009-09-19 09:49:11 by nathanpc
I'm having a hard time understanding the camera view in OpenGL.  I'm trying to zoom out on these points at the current moment it draws a square on the whole "screen" right now


Invoke gluLookAt, R8(0.0), R8(0.0), R8(1.0), R8(0.0), R8(0.0), R8(0.0), R8(0.0), R8(1.0), R8(0.0)
Invoke glBegin, GL_QUADS
Invoke glVertex3f, R4(-1.5), R4(-1.5), R4(0.0)
Invoke glVertex3f, R4(-1.5), R4(1.5), R4(0.0)
Invoke glVertex3f, R4(1.5), R4(1.5), R4(0.0)
Invoke glVertex3f, R4(1.5), R4(-1.5), R4(0.0)
Invoke glEnd

I realize that this square is drawn on the XY-plane and my camera is viewing it from the Z-axis, looking at the origin with the "up" vector being <0,1,0>  I just don't understand why if I change my camera eye point to 0,0,2 it shows nothing
If interested I am using savages macros with my own equates.

;#################################################
;#                Macros
;#################################################
R4 Equ $fConst
R8 Equ $dConst
Posted on 2009-09-22 23:06:03 by GoldStar611
It's because you don't use gluPerspective(), I bet. You need to have setup the near and far clipping planes, at least. An identity-matrix as a projection-matrix means that whatever coords you give, they'll be unchanged in clip-space. And clipspace discards anything outside the [-1;1] range.
Posted on 2009-09-22 23:45:35 by Ultrano
That's definitely it.  Are there any limits on this function? Seems like at a certain point everything gets drawn weird.  This is the max that I've gotten it to work with.  My points are only from -20 to + 20 on each axis right now..

Invoke gluPerspective, R8(170.0), R8(1.0), R8(0.1), R8(10.0)
Posted on 2009-09-22 23:56:32 by GoldStar611
Replace 170.0 with 45.0, and you can also safely increase the 10.0 to i.e 1000.0-10000.0 at any time.
Posted on 2009-09-23 00:02:25 by Ultrano
I have just found Japheths include files.  This has a lot of includes missing in my original masm32 install as well as OpenGL includes defined with the right types.  Just wanted to post this for anyone who hasn't already found this set of includes
Win32INC
http://www.japheth.de/
Posted on 2009-09-29 18:13:14 by GoldStar611
I'm back on the trail again with some simple OpenGL programming this time from a list.  Following sample c++ code from Luke Benstead's book I've come up with this, but it seems to have errors:

.DATA
vertices Real8 - 2.0, -2.0, 0.0, 2.0, -2.0, 0.0, 2.0, 2.0, 0.0, -2.0, 2.0, 0.0
indicies DB 0, 1, 3, 1, 2, 3

.CODE
Invoke glEnableClientState, GL_VERTEX_ARRAY
Invoke glVertexPointer, 3, GL_FLOAT, 0, Addr vertices
Invoke glDrawElements, GL_LINES, SizeOf indicies, GL_UNSIGNED_INT, Addr indicies
Invoke glDisableClientState, GL_VERTEX_ARRAY


This is just a sniplet of code I have working when I used hard coded values and was able to get a wireframe made from GL_lines.  I'm just trying to expand it.  I've followed it in olly and it seems to be breaking right at DrawElements function.
Posted on 2010-01-16 20:45:14 by GoldStar611
change to this:
indicies DD 0, 1, 3, 1, 2, 3

(and thus "sizeof indices" needs /4 )
Posted on 2010-01-16 23:42:47 by Ultrano
Ok got it, it was expecting dword indicies because I told it unsigned integer which is 4 bytes.  So if each index was 2 bytes I would call glDrawElements with gl_short type.  I am closer to my goal.  I now I have floating point units.

Now instead of using Real8s I would be loading verticies in Real4 format (IEEE 754).  I can't call glVertexPointer with gl_short because that would tell it they are unsigned integers.  What measures up to single precision floats for open gl?

Ah, I see GL_Float is single precision and GL_Double is double precision.  The file I am loading in didn't save them in intel architecture so I'll have to either BSWAP the bytes or find out if open GL supports big endian
Posted on 2010-01-17 18:09:34 by GoldStar611
So if each index was 2 bytes I would call glDrawElements with gl_short type

More specifically, gl_unsigned_short as index format.
Posted on 2010-01-17 18:40:00 by Ultrano
So if each index was 2 bytes I would call glDrawElements with gl_short type.


Yes, this is recommended. Some older hardware doesn't have actual support for 32-bit indices anyway, so the driver needs to do translation... And even for newer hardware there's the obvious size-advantage in videomemory. So don't use 32-bit indices unless you really have to (which is hardly ever, as usually it's more interesting to split up larger objects into subsets that can be encoded with 16-bit integers. There's usually a high rate of locality between the indices, because if there isn't, you'll be getting poor memory access performance anyway).

Likewise for vertices and other stuff, you should always use real4, as no hardware supports real8 anyway. Again, obvious advantages for size and the driver not requiring any translation 'under the hood'.
Posted on 2010-01-22 06:32:56 by Scali
He's spot on.

If you need 32 bit indices, you should be looking at partitioning schemes that divide your 3D space into 16 bit chunks.
This is a very active field of research, you should never need to use 32 bit indices. Forget they exist for the next 20 years, and you should be fine.

Examples are BSP and QuadTree to get you started but theres lots, and variations too.
Posted on 2010-01-22 08:19:29 by Homer