Question about gluLookAt()

[Sylus101]

Thanks again to DiscoStew for the longer explanation on the glClear() question before. Hope he's around again for this one.

I understand how this function works due to running quite a few tests with it, but where I'm confused is in regards to it's being reset when glLoadIdentity() is called. I would have thought since it has to do with the camera position that calling glLoadIdentity() during GL_MODELMATRIX mode that it wouldn't have affected it's position but it obviously does from the tests I've run.

I guess the question is... why?

Side question... I think the total poly count allowed is 1024 (seems like a rather small number). Is that correct?

[Discostew]

With gluLookAt(),

This link should help with your question - http://www.opengl.org/resources/faq/tec ... iewing.htm - but to answer it directly....(copied straight from that link)

The GL_PROJECTION matrix should contain only the projection transformation calls it needs to transform eye space coordinates into clip coordinates.

The GL_MODELVIEW matrix, as its name implies, should contain modeling and viewing transformations, which transform object space coordinates into eye space coordinates. Remember to place the camera transformations on the GL_MODELVIEW matrix and never on the GL_PROJECTION matrix.

gluLookAt() is tied in to whatever matrix mode is currently in use, though as the above states, it should always be in the ModelView mode because that is how it is designed. With the DS, it is actually implemented to switch to the ModelView mode anyways, should one forget to set it beforehand (though it doesn't call glLoadIdentity within the function). glLoadIdentity() will revert the matrix to it's identity, and anything done prior to it, including gluLookAt(), will be lost. That is how it is with OpenGL too. In most cases, you should load the identity prior to anything else. If you must retain the transformation that gluLookAt makes, then be sure to use glPushMatrix/glPopMatrix appropriately.

--------------------------------------------

With total poly count,

The DS hardware is capable of rendering up to 2048 tris or 1536 quads per frame, or a mixture of both. Because they share the same internal buffer space (it is double-buffered), using one will reduce then number allowed for the other, and vice versa, until you flush it (with glFlush), of which then it swaps the buffers at the next VBlank, and resets the current loadable buffer so you can load the next frame.

[Sylus101]

Thank you again, that explains it very well! On the poly count, I did end up searching around a bit and there's a post on maxforums (haven't been there before) saying that if you use strips it lowers the number of vertices and you could get away with more than 2048 triangles. Is this possible or does another part of the hardware possibly limit this?

EDIT - I'm ending up with another question as well...

I'm getting too used to using the float functions and want to go ahead and make the change to using fixed point. There seems something a little odd though in comparison to setting up your own 2D movement system with fixed point.

With 2D If I wanted to move an object at 1/4 a pixel per frame, I might setup a .12 fixed point system and set it's velocity to 1024, shifting the it's x/y position down (bit shifting right) when actually set to OAM.

So here, I'm finding that the using 1.0 in the float type functions is the same as 1 << 12 in the fixed types putting fractional values between 0 and 4096. What I'm having trouble wrapping my head around is the fact that I'm shifting up (left) when passing it to the glVertex3v16... so working with some kind of logical unit system is beginning to trouble me. My instinct is telling me that I could decide that I need to decide on how many steps I want to be taking between 0 and 4096 (say I want 1 of my units to equal 1/16) then I could pass 1 into a wrapper function for glVertex3v16() that shifts it up 8 times instead of 12... does that sound about right?

[Discostew]

Thank you again, that explains it very well! On the poly count, I did end up searching around a bit and there's a post on maxforums (haven't been there before) saying that if you use strips it lowers the number of vertices and you could get away with more than 2048 triangles. Is this possible or does another part of the hardware possibly limit this?

I don't think that is true. While it may be true for OpenGL, as far as we have been able to tell when using tri/quad strips, the NDS hardware just takes the last 2 vertices from the buffer, and copies them with the new vertex (or 2 with quads) at the tail-end of the buffer, making it as if you added a completely new tri/quad, as well as sets the polygon info that it is a tri/quad, rather than a tri/quad strip. The benefits I see from using strips even with this circumstance is that it is takes up less RAM storage, as well as takes less time to load, either manually or by FIFO DMAing.


I'm pretty rusty in explaining how fixed-point works (maybe someone here can explain it), but a good start in the transition to it is by using the pre-made macros supplied in the videoGL.h file, allowing you to use floats, but are converted to ints for use as fixed-point values, like as follows...

Code: Select all

int aVal = floattof32( 1.5f );  // 1.5 -  float -> 6144 - .12 fixed-point

Adding and subtracting are done normally as long as the fixed-point size is the same. For multiplying/dividing, I suggest you use functions supplied in the math.h file until you get a bit more acquainted with how fixed-point arithmetic works.

[Sylus101]

Actually, I'm pretty familiar with the concept of fixed point, I use it for 2D movement quite often and know to use mulf32(), divf32(), the Lerp versions of sin, cos etc...

The initial confusion... was that say if I were using a .12 fixed point system for 2D, when I was ready to pass a sprite's x coordinate (for example) to OAM, it'd be passed shifted down, oamMain.oamMemory[0].x = sprite.x >> 12;

With the vertex coordinates, I'm shifting whatever unit I'm working with up (bitwise left) 12... so my trouble was if I wanted values less than 1 (which seemed highly likely) what I would do.

After testing different ideas I think I'm pretty well set, at least until the next question pops up. Still, I think I'm pretty clear on setting the camera (more or less), drawing polys, trasformations on the Model Matrix, and using Push and Pop to affect different polygon sets or models in different ways. Not bad for a weeks time, eh?