Sorry that had nothing to do with the speed, I was just letting you know.Originally Posted by Shamino
Sorry that had nothing to do with the speed, I was just letting you know.Originally Posted by Shamino
The loops are most certainly killing your code. Let's look at this loop:
Ok each loop goes from 0 to n so each loop is considered n.Code:for (int i=0;i<100;i++) { //Statement A for (int j=0;j<100;j++) { //Statement B for (int k=0;k<100;k++) { //statement C } } }
With two loops you get n*n or n^2. With three loops you get n*n*n or n^3. This is horrible. The inner most loop (the k loop) takes more time than any of the other loops to execute, because it executes not 100 times, not 1000 times, but 100*100*100 times. The j loop executes 100*100 times and the i loop executes 100 times.
All those loops are not necessary to draw a grid like that. One quad is two triangles and one quad is created by creating two triangles. But forget the triangles. How would you draw this assuming we have our own C library function called DrawSquare() and a function called DrawLine().
Ok this draws the same thing you have but with a whole lot less code. You can also eliminate the inner J loop if you test the current X position of the grid cell against the (left+right) position of the right side of the grid.Code:void Square(int left,int top,int right,int bottom) { DrawLine(left,top,right,top); DrawLine(left,top,left,bottom); DrawLine(right,top,right,bottom); DrawLine(left,bottom,right,bottom); } void DrawGrid(int left,int top,int right,int bottom,int cellw,int cellh) { for (int i=left;i<right;i+=cellw) { for (int j=top;j<bottom;j+=cellh) { DrawSquare(i,j,i+cellw,j+cellh); } } }
Now for OpenGL. All you have to do is essentially what I've done in plain C code. Draw the grid the same and the vertices for each quad in the grid are:
Vertex 0 - Upper left - (i,j)
Vertex 1 - Upper right - (i+cellw,j)
Vertex 2 - Lower left - (i,j+cellh)
Vertex 3 - Lower right - (i+cellw,j+cellh)
And for the indexes to create the triangles - Assuming counter clockwise culling - face vertices are ordered in clockwise fashion when looking at the front of the face
Triangle 1 = 0,1,2
Triangle 2 = 1,3,2
Look at my DirectX code and you will see I created a completely flat grid using the same method I just explained to you.
The problem with your code is you are using 2 for loops for the grid, and 1 for loop for each row in the grid, and it looks like maybe even 1 for loop for each column in the grid. Take all that stuff out and start over.
Your problem: Too many loops and incorrect use of the API. You create the vertex list, save it, and display it later. Don't create it on the fly....ever, unless you have an optimized renderer - like one based on BSPs or quad trees.
There is a recursive way to create your grid as well.
And don't take your beast of a CPU for granted. Sloppy code can still bring it to its knees.Code:void CreateGrid(int left,int top,int right,int bottom,int size) { if (right-left>=size) return; midx=(right-left)>>1; midy=(bottom-top)>>1; DrawSquare(left,top,right,bottom,size); DrawSquare(left,top,left+midx,top+midy); DrawSquare(left+midx,top,right,top+midy); DrawSquare(left,top+midy,left+midx,bottom); DrawSquare(left+midx,top+midy,right,bottom); }
try this:
See how long that takes to execute - even on your super CPU.Code:float BI(float v1,float v2,float v3,float v4,float f1,float f2) { float val1=v1+f1*(v2-v1); float val2=v3+f1*(v4-v3); return (val1+f2*(val2-val1)); } void CrappoAlgo(int v1,int v2,int v3,int v4,float f1,float f2) { for (int i=0;i<v1;i++) { for (int j=0;j<v2;j++) { for (int k=0;k<v3;k++) { for (int l=0;l<v4;l++) { float value=BI((float)i,(float)j,(float)k,(float)l,f1,f2); printf("%f\n",value); } } } } }
All that power means nothing if you use it incorrectly.
Last edited by VirtualAce; 10-07-2005 at 08:22 PM.
the loops are functioning as I intend them to...
we need 3 sections of 392
which is 14x28
then we need 3 nights
so its doing 3(3*18*28)
Note that it only renders 392 at a time, its not showing them all...
, but it is rendering them on the fly, which i believe is the pinpoint of my problem...
I only use that giant loop to do save functions, and to give information to the parts of the array, and then I use it to create 392 boxes at a time
Last edited by Shamino; 10-07-2005 at 11:06 PM.
But that is why it is slowing down. I was doing a similar thing on a project of mine until Bubba showed me otherwise.I only use that giant loop to do save functions, and to give information to the parts of the array, and then I use it to create 392 boxes at a time
Hmm let me reallly think this through
for 3
for 14
for 28....
so it does the 28 14 times..
and then that 3 times... 1176, exactly correct... what i need it to be....... and then i have 3 instances of this class, so 3*1176, = 3528, enough seats to go for 3 nights, 3 sections in each night, 392 in each section
otherwise, if it was going over, wouldnt i get errors for adding to my array on the fly? since int i, j, k, are all inside the body of the loop in general, inside the array, if i went over what the array was set for s[3][14][28].... wouldn't i get an error?
so you mean, avoid loops of 3000+?????
because they lag?
urgh.... that blows!
Hmm, well its not looping near 4000 times that is slowing me down, i made a tiny program with my same loops just adding += 1 to a variable each time... its done in less than 3 seconds....
soo, i'll be assuming, its the fact that i'm also drawing a square, giving it a boolean value, and a seatnum, all at the same time, 3528 times, in a row, in rapid succession.... not just the fact that i loop 3528 times...
right?
Last edited by Shamino; 10-08-2005 at 12:16 AM.
No, its only the printf.Originally Posted by Shamino
Warning: Have doubt in anything I post.
GCC 4.5, Boost 1.40, Code::Blocks 8.02, Ubuntu 9.10 010001000110000101100101
I guess i can see the printf function being a bit slow... seeing as how it has to go through every single letter to find out which one i need etc etc....
Are there any suggestions, simply put, to help my program out?
Argue with me all you want but you are approaching this render completely wrong. There is a better way. You don't need 3 loops of anything.
The loops are your problem. Period. Too many damn loops. Kill em.
That terrain I created is fifty times more complex than that screenshot you provided. I'm getting well over 100 fps with a pure-brute force algorithm. During the render there are NO loops. None nada zilch. Don't stick a bunch of for loops inside of a render function. It ain't gonna work man.
So....in essence you don't need all that crap. When you really feel like fixing the problem instead of arguing about your crappy slow-ass algo....come back and post. Till then enjoy your lag.
If the loops are working just as you intended...and just by looking at your code....what you intended is not what you need.
Last edited by VirtualAce; 10-08-2005 at 07:07 PM.
Shamino,
If an algorithm works but has too high of a "cost" then you need to rethink the algorithm. Yes your function might be what you intended, but due to the cost you need to rethink it.
Jee bubba be nice, i was just saying those loops are functioning the way I want them, whether it was what was slowing me down all this much was my problem....
Soooo, turn those loops into a square with "cells" that determine how big the lines are, instead of looping... looping a renderer = bad... k... got it... What if i were to single handedly write out those 3528 quads? would it still be slow? (i know this isnt the way to do it either, but im just curious)
Can i still do click detection with a loop?
Isnt, um, that thing you posted bubba, with the 2 for loops, isnt that basically a render loop? only smaller?
teehee, don't mind me, i agree that that is my problem, but its going to cause me to rewrite my entire program to some extent
Is this a render loop?Code:glLoadIdentity(); // Reset The Current Modelview Matrix for (loop1=0; loop1<11; loop1++) // Loop From Left To Right { for (loop2=0; loop2<11; loop2++) // Loop From Top To Bottom { glColor3f(0.0f,0.5f,1.0f); // Set Line Color To Blue if (hline[loop1][loop2]) // Has The Horizontal Line Been Traced { glColor3f(1.0f,1.0f,1.0f); // If So, Set Line Color To White } if (loop1<10) // Dont Draw To Far Right { if (!hline[loop1][loop2]) // If A Horizontal Line Isn't Filled { filled=FALSE; // filled Becomes False } glBegin(GL_LINES); // Start Drawing Horizontal Cell Borders glVertex2d(20+(loop1*60),70+(loop2*40));// Left Side Of Horizontal Line glVertex2d(80+(loop1*60),70+(loop2*40));// Right Side Of Horizontal Line glEnd(); // Done Drawing Horizontal Cell Borders } glColor3f(0.0f,0.5f,1.0f); // Set Line Color To Blue if (vline[loop1][loop2]) // Has The Horizontal Line Been Traced { glColor3f(1.0f,1.0f,1.0f); // If So, Set Line Color To White } if (loop2<10) // Dont Draw To Far Down { if (!vline[loop1][loop2]) // If A Verticle Line Isn't Filled { filled=FALSE; // filled Becomes False } glBegin(GL_LINES); // Start Drawing Verticle Cell Borders glVertex2d(20+(loop1*60),70+(loop2*40));// Left Side Of Horizontal Line glVertex2d(20+(loop1*60),110+(loop2*40));// Right Side Of Horizontal Line glEnd(); // Done Drawing Verticle Cell Borders }
Last edited by Shamino; 10-13-2005 at 09:16 AM.
omg Yes, that is a render loop, i think, because...
omg, all I gotta do is create a display list for 1 quad, and then loop it 14x28 times to throw it on the screen, it doesnt have to create a new quad every time, just translate it so I have my grid.....
Display lists 4tw, nehe 4tw!
hmm, okay.... it's still slow.... definately not a stroke of genius here..... hummm....
Question, If I were to write out 392 quads, the long way, no loops, no nothing, would it still be lagging?
Last edited by Shamino; 10-13-2005 at 09:47 AM.