"Which way is faster?" pre-supposes:
1. It matters (i.e. there is a significant difference)
2. Runtime performance is the most important thing to you
Personally, I'd say, developer performance is *FAR* more important than runtime performance. Developer performance can be optimised by doing things in the simplest way that works, and not wasting time posting on gamdev.net
"Which is faster? x = x +1 or x ++ or ++x ????"
Mark
Which way is faster?
Quote:Original post by fooman_69Optimization is the key, but optimization is more about finding the best algorthm and less about finding the fastest implementation of an algorthm.
Thnaks for the replies.
I only asked because it was beat into my throughout college that optimization is key.
Quote:I figured 10 calls to a class method was more costly than creating two temp variables once.True, in unoptimizing compiler land, the latter would be faster than the former. However, most likely your compiler is doing automatically what you're forcing it to do by hand.
Also, pointers would probably be slight faster in unoptimzed compiler land as well, since you're making a copy of the data to simply reference it.
Quote:I will do my best to optimize the gl calls however.I haven't seen your Render method nor how you're texturing these quads, so I cannot say with any certiany.
If I am drawing quads throughout the Render method, I should only ever need one glBegin/glEnd call right?
You are only allowed to call:
glVertex*, glColor*, glIndex*, glNormal*, glTexCoord*, glEvalCoord, glEvalPoint, glArrayElement, glMatrial
within a glBegin/glEnd statement. If you need to use glBindTexture, for example, you'll have to step outside of the glBegin/glEnd.
However, if you're worried about speed, you shouldn't be using glBegin/glEnd anyways. VARs(glDrawElements/glDrawArrays) are your friend.(VARs calls a pseduo-glBegin/glEnd for you.)
~~
Premature Optimization is the worse thing you can do.
Optimization is great, but at the algorthmic level.
Carmack doesn't sit around all day saying, "I should switch this while() loop for a do...while() loop, it'll make my code 20 bytes longer, but it should remove 2 clock cycles. Sure it's in the Menu, but every optimization counts".
Instead...he sits around all day saying, "My profiler says I spend a lot of time in this code. If I simplify this part of my algorthm, the users bullets would be more inaccurate, but not enough to notice, and I'll decrease the steps in my algorthm, speeding up my engine."
Followed by, "Let's shoot things into Outer Space!"
The code is in the "wrong place" anyway (as well as much of the data probably):
// Player class aggregates the whatever ent1/ent2 is, along with the p1/p2 x/y// i.e. it represents the player's position and "entity"void Player::draw() { // You might instead choose to wrap draw() in a glBegin/End block, to make // sure that the state is correct before drawing (i.e. quads). That would // indeed be a valid optimization issue - doing things that way makes sure // that you won't have weird things happen if you try to draw the Player in // other contexts, but will result in redundant calls to the (considered-slow) // GL state transition functions. // bottom-left glTexCoord2f(image.left, image.bottom); glVertex2f((float)(x * TILE_SIZE), (float)(y * TILE_SIZE)); // within the object for player1, p1_x and p1_y are stored; similarly player2 // similarly the other three corners}// The whole point with the "encapsulation vs optimization problem" is that the// code belongs next to the data it operates on. If you are worrying about the// performance of a direct member access vs. the "OO-ness" of a raw accessor -// then you have failed to understand OO.// And then in the drawing:glLoadIdentity();glBegin(GL_QUADS); // unless encapsulated in draw()player1.draw();player2.draw();glEnd(); // unless encapsulated in draw()
Just to clarify the above, what the posts mean is to optimize BIG things, not little things. Compilers usually optimize many of the little things anyway. For example, take the quads and put them into a display list or vertex array instead of using immediate mode. That gets you a big boost in speed because it is a BIG thing. As said above, with OpenGL, a big optimization is trying to avoid state changes when possible. As in, not going to the extreme, rather when you can batch tris of the same texture, do so, but don't write an extremely long code block to batch them, unless it runs at initialization, not at run time. Try to keep things simple. Then when done, profile the application/game to see where the time is being taken up, look for the bottleneck. Optimize it, (IF NEEDED), then go on with your day. Don't waste time optimizing to see if i++ or ++i is faster. The difference is so liitle that the end user won't notice. And remember, the end user is the one who really cares.
Author
Seriously, thanks but I was just curious. I'm not sitting here thinking about optimization in terms of 0++ or ++0. I just felt I would ask to see if any of this mattered. Apparently it does not.
btw, I really appreciate the condescending tones of many of the above posts.
btw, I really appreciate the condescending tones of many of the above posts.
Ignoring optimisation, from a style point of view, I'd say:
I suspect that none of the implementations is likely to differ vastly in runtime performance, and even if they do, you probably don't care.
Mark
//Draw players const Sprite & ent1Spr = ent1->GetImage(); glLoadIdentity(); glBegin(GL_QUADS); //player 1 glTexCoord2f(ent1Spr.left, ent1Spr.bottom // etcI suspect that none of the implementations is likely to differ vastly in runtime performance, and even if they do, you probably don't care.
Mark
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
