   GL newbie...
  Hi,I have been looking at NeHe''s tuts, and being a directx coder since starting 3D programming, have found some things odd that would be nice to find a solution too.GL has no concept of batching? except VBO''s and vertex lists. It just has a simple loop and you set each vertex, normal etc...is this normal? i cant belive this doesnt make OGL cpu dependant?i guess it has its benifits, like being able to sort polys  but sorting polys is also CPU intensive.so im guessing i would put most data into VBO''s? when did video cards support this? ie. geforce 3 and above?matrices... all the NeHe tuts just set rotation and translation, then render, is it possible to use matrices? no point letting ogl recreate these matrices each frame if there is no need?multitexturing seems failry complex having to set function callbacks? unless i read the tut in to much of a hurry ;pthanks in advance... 
  1.  Display lists might be somewhat helpful.  There''s also vertex arrays.  Both are supported on all cards as far as I know.2.  Matrices... when you use the rotation and translation functions, you''re really just multiplying the modelview matrix (the DX equivalent escapes me right now) by a rotation/translation.  There''s a glMultMatrix, and other "low-level" matrix functions.3.  Yes, a lot of people don''t like extensions at first.  You could always use the GLEE library (written by Benjamin Bunny of this forum, in fact) to do that for you.   ;quote:Original post by supagu  GL has no concept of batching? except VBO''s and vertex lists. It just has a simple loop and you set each vertex, normal etc...is this normal? i cant belive this doesnt make OGL cpu dependant?thats by far not the only and especially not the common method. its the easiest but most inefficient. storing data in video memory came up with gf1, at first via vendor extensions like var and vao and much later via vbo (you might thank ms for slowing down any progress as much as possible while they were in the arb)quote:matrices... all the NeHe tuts just set rotation and translation, then render, is it possible to use matrices? no point letting ogl recreate these matrices each frame if there is no need?opengl has no math libraries, as its really just a graphics lib. you can load matrices to the stack and read matrices from the stack, which is less work than in d3d but should be avoided doing a lot (especially in the middle of a frame).. like everything thats reading back data from the card.quote:multitexturing seems failry complex having to set function callbacks? unless i read the tut in to much of a hurry ;pagain, thank ms for not supporting anything higher than opengl 1.1 in windows. its quite simple, if you want people to use YOUR api, make sure using the other api is as much a pain in the ass as possible. luckily there are still quite a few that prefer not tying themself to a single platform if they dont have to ,-);  Before VBOs came along, a common practice was to store Vertex Arrays in Display Lists. Depending on the driver, the gfx card would store the data in video memory. As far as i know, most of the new drivers from both nVidia and ATI claim that they now store geometry in Display Lists in Video memory. From my tests, it shows that with the new drivers, display lists give the same performance as VBOs.Also, vertex arrays are still widely used for dynamic data. 