Jump to content
  • Advertisement
Sign in to follow this  
Tesserex

Should I use display lists?

This topic is 4250 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've just learned what display lists are but from what I've read I don't know if I can implement them. I'm writing an engine for a free-roam 3D space flying game. I've got a working quaternion camera and a system for putting objects anywhere and controlling their position and orientation with a reference to game-space (not camera-space). I feel that will make it much easier to keep track of other independent objects down the road, since the camera follows the player's ship. Now the thing is, with this system, if I create display lists to hold things like the swarms of enemy ships or laser blasts, how can I make sure they're drawn in the right place? Keep in mind that any algorithm for drawing a display list object shouldn't require more computing than just redrawing the object the old way. Here's same relevant code:
// from the drawing function
testplayer.GetView(camup, camfor, campos); // read camera location

	gluLookAt(campos.x, campos.y, campos.z, campos.x+camfor.x, campos.y+camfor.y, campos.z+camfor.z, camup.x, camup.y, camup.z);

	// draw skybox - demonstrates my current method for display list drawing, namely, translate-draw-translate back
	glTranslatef(campos.x,campos.y,campos.z);
	glCallList(skybox);
	glTranslatef(-campos.x,-campos.y,-campos.z);

	testplayer.Draw();
	
	// these objects have game-space locations hard-written into the display lists - they can't be moved or rotated at all like this.
	glCallList(blocklist);
	glCallList(olist);
Would any other code segments be useful?

Share this post


Link to post
Share on other sites
Advertisement
You need to change your matrix operations order. So basically, when making your display lists, draw them all at 0,0,0 world space with 0,0,0 rotation. Then, when you want to draw them, translate/rotate the matrix to where you want to have the model, then call the list.

Share this post


Link to post
Share on other sites
As you show with your skybox, transforms (in this case a translation) still operate on display lists.

Thus you could create, for instance, an enemy fighter model as per usual, as if it were at the origin and with some basic orientation (looking down the negative z-axis, for instance), compiling the model in a display list. You could then call it in your draw code and place the relevant tranformations (translation for position, rotation for orientation, etc.) before it as if the model were specified between glBegin and glEnd statements in that draw code.

Thus, if you wanted an object to appear at x, y, z and be rotated r degrees about the y-axis (for example), you could simply have something like this:


//Some initialisation function
void initialise()
{
//miscellaneous initialisations

//compile an enemy starship's display list
glNewList(evil_ship_list, GL_COMPILE);
//glBegins and ends, material specifications, etc, but no translations
// or rotations that shouldn't be present in all cases
glEndList();
}

//draw code
void draw()
{
//various drawing functions for other things, if called for
// - for example your skybox

//we now come to draw our enemy ship...
//The trnasforms should apply to the called list,
// and thus move and rotate the enemy ship.
glTranslatef(x, y, z);
glRotatef(r, 0.0, 1.0, 0.0);
glCallList(evil_ship_list);

//various other drawing functions for other things, if called for
}



[edit]More or less as Damocles said, I believe.

Share this post


Link to post
Share on other sites
edit: this entire post was written stupidly and was wrong. Even after gluLookAt, the origin is still the origin, as it always was, right? The rule of thumb is: You move the camera around and draw things where you want, but once its drawn, its pasted on the screen as is and nothing further will change that. We use that feature as an advantage.

So...

I look at some location and draw my ship. Then, I want to draw an object at (X,Y). Since the display list is at (0,0), I move the camera away from the origin by (X,Y), then draw at (0,0), giving the illusion (because its stuck where its drawn) that its at (X,Y), correct?

One thing I don't get: Why is it, that in my skybox code, the first translation is by a POSITIVE campos, and not negative? If the ship is at a location of +campos, shouldn't it be that I move by -campos to return to 0, draw the skybox, then move the camera back? That way it would always be that the skybox is drawn at the same place every frame. I tried that and its not the case. Also note I can't just draw the skybox as the first thing, because then it wouldn't even rotate with the ship, which it should. I also tried two gluLookAt's, the first with no translation and then drawing the skybox - that failed miserably.

Another concern - about translation - once my camera is moved around, I have a very strong feeling that just doing a glRotate isn't going to cut it for rotating a distant object around. Maybe its just because I had such a hard time with the quaternion camera. I suppose... since the display list is at (0,0) the object will rotate just fine, and then I take my snapshot (draw it) from the new angle, then carry that drawn image back when I un-rotate and un-translate. Another plus is that since object orientations are in game-space, I don't have to worry about my ship or camera angle affecting how I should rotate for the ship, it's one less set of transformations to do. The game-space axes don't change, just the camera's location and orientation do.

[Edited by - Tesserex on April 21, 2007 5:32:38 PM]

Share this post


Link to post
Share on other sites
Sorry for the delay. ^^;

Quote:
I look at some location and draw my ship. Then, I want to draw an object at (X,Y). Since the display list is at (0,0), I move the camera away from the origin by (X,Y), then draw at (0,0), giving the illusion (because its stuck where its drawn) that its at (X,Y), correct?


That sounds right, yes, give or take a negation. ^_^

I think that you'd move the camera by -X, -Y, since that would put the object at X,Y relative to the camera.

Alternatively, you could look at it as moving the world and leaving the camera alone. One nice thing about programming 3D graphics is that, unless I'm forgetting something, you can move the world around you as easily as you can move yourself in it. ;)

In that case yes, you'd transform by X,Y.

Quote:
One thing I don't get: Why is it, that in my skybox code, the first translation is by a POSITIVE campos, and not negative? If the ship is at a location of +campos, shouldn't it be that I move by -campos to return to 0, draw the skybox, then move the camera back?


I think that I'm correct in saying that this is because gluLookAt should modify the modelview matrix with a translation of negative campos. If you move the camera by, say, 1 unit along the positive z-axis, everything else should appear as if it had moved by 1 unit along the negative z-axis, as mentioned earlier. Thus to return to the origin after a gluLookAt that moves the camera to campos, the modelview matrix (i.e. the world) has moved to negative campos, and so to zero it again you move by positive campos.

Of course, if you use your own rotations and translations for your camera you could perhaps avoid this by putting the skybox drawing code between the rotation and translation calls for your camera. Whether converting to this is worth the trouble is up to you; my guess is that it isn't.

Quote:
Another concern - about translation - once my camera is moved around, I have a very strong feeling that just doing a glRotate isn't going to cut it for rotating a distant object around.


I don't think that it should be an issue, unless I'm missing or forgetting something, or you're doing something that I'm not thinking of. You should be able to perform the relevant operations for each object, as long as those transformations are not allowed to affect subsequent objects. The camera, of course, is exempt from this in most cases, since most of the time the camera's position and orientation should affect the apparent position of the rendered objects. The exceptions, of course, are those objects that should always be in a particular place or position relative to the camera, such as your skybox (in terms of position in that case, at least).

To that end, instead of performing negative rotations and translations to clear those performed for a previous object, as it seems that you are suggesting that you do, simply put a glPushMatrix() before and a glPopMatrix() after each object's specific transformations - the former function stores the current transformation matrix on a stack, while the latter removes the top matrix from that stack and instates it as the current matrix. You can thus use these functions to isolate objects from other objects' transformations. Since they operate on a stack, you can also nest them within each other should you desire - for a hierarchical model, perhaps.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!