提高執行該代碼的速度

我有兩種方法用於渲染網格。第一招：提高執行該代碼的速度

二

void Grid::openglRender(){ 
    glPolygonMode(GL_FRONT_AND_BACK, GL_LINE); 
    glBegin(GL_TRIANGLES); 
    glColor3f(1.0f, 1.0f, 0.0f); 
    Node* A, * B, * C, * D; 
    for(size_t X=0 ; X<sizeX-1 ; X++)for(size_t Z=0 ; Z<sizeZ-1; Z++){ 
    A = &nodes[X*sizeZ+Z]; 
    B = &nodes[(X+1)*sizeZ+Z]; 
    C = &nodes[X*sizeZ+(Z+1)]; 
    D = &nodes[(X+1)*sizeZ+(Z+1)]; 
    glVertex3f(A->x, A->y, A->z); 
    glVertex3f(B->x, B->y, B->z); 
    glVertex3f(C->x, C->y, C->z); 

    glVertex3f(B->x, B->y, B->z); 
    glVertex3f(D->x, D->y, D->z); 
    glVertex3f(C->x, C->y, C->z); 
    } 
    glEnd(); 
};

之一：

void Grid::openglRender(){ 
    glPolygonMode(GL_FRONT_AND_BACK, GL_LINE); 
    glBegin(GL_TRIANGLES); 
    glColor3f(1.0f, 1.0f, 0.0f); 
    for(size_t X=0 ; X<sizeX-1 ; X++)for(size_t Z=0 ; Z<sizeZ-1; Z++){ 
    glVertex3f(nodes[X*sizeZ+Z].x, nodes[X*sizeZ+Z].y, nodes[X*sizeZ+Z].z); 
    glVertex3f(nodes[(X+1)*sizeZ+Z].x, nodes[(X+1)*sizeZ+Z].y, nodes[(X+1)*sizeZ+Z].z); 
    glVertex3f(nodes[X*sizeZ+(Z+1)].x, nodes[X*sizeZ+(Z+1)].y, nodes[X*sizeZ+(Z+1)].z); 

    glVertex3f(nodes[(X+1)*sizeZ+Z].x, nodes[(X+1)*sizeZ+Z].y, nodes[(X+1)*sizeZ+Z].z); 
    glVertex3f(nodes[(X+1)*sizeZ+(Z+1)].x, nodes[(X+1)*sizeZ+(Z+1)].y, nodes[(X+1)*sizeZ+(Z+1)].z); 
    glVertex3f(nodes[X*sizeZ+(Z+1)].x, nodes[X*sizeZ+(Z+1)].y, nodes[X*sizeZ+(Z+1)].z); 
    } 
    glEnd(); 
};

我的第一個看起來操作次數的期限較好，glVertex3f我只是用指針來獲得的值。在第二種方法中，每次我必須乘法和添加一些東西。

但在運行的時候，我並不真的覺得有區別。所以我說得對，當我說第一個更好？也許無論我選擇了編譯器知道的比我，怎樣做才能獲得最佳的好...

也許這將是一個好一點，如果我宣佈for循環之前X和Z避免特別聲明和銷燬的Z sizeX倍

而且我想，最好是創建一個列表（同一時間，RO存儲可以每幀重複使用）的所有節點的順序來遍歷使用兩個for

來創建網格而不是

來源

2013-11-29 The Unholy Metal Machine

'glVertex3f（...）'*** far ***的通話開銷超過了任何你可以拋出這個問題的花式褲子指針算術黑客的機會。像這樣微觀優化即時模式幾乎沒有意義，你應該切換到索引頂點數組，並把它花費更多的時間。但是如果你堅持的話，如果你把'glVertex3fv（... ）'放到混合中再進行一次微型優化，你可以讓這個噩夢持續更長的時間。 –

@ AndonM.Coleman聽起來不錯，我很高興我從來沒有使用過頂點數組，所以當我編寫代碼時我甚至沒有想到它。我在一些書中讀到了關於他們的一些。我將在圖書館明天閱讀更多有關 –

A = &nodes[X*sizeZ+Z]; 
B = &nodes[(X+1)*sizeZ+Z]; 
C = &nodes[X*sizeZ+(Z+1)]; 
D = &nodes[(X+1)*sizeZ+(Z+1)];

可能是

A = &nodes[X * sizeZ + Z]; 
B = A + sizeZ; 
C = A + 1; 
D = B + 1;

這不僅應該減少操作的數量相當多，但也會使節點之間的關係更加明顯。我不知道你的編譯器有多聰明，它是否能夠自己做這種優化。但是，爲什麼要做到這一點，何時更清晰？

（約這裏過早優化強制性的警告。如果你沒有，甚至注意到兩者之間的區別，那麼它的太早擔心微觀優化。）

來源

2013-11-29 04:18:39 cHao

我喜歡這樣我會重複使用 –

僅僅因爲你優化的代碼沒有按並不總是意味着你會看到更好的運行時性能。你如何衡量運行時性能？取決於兩個for循環內的迭代次數，除非迭代次數足夠高，否則您可能看不到差異。 sizeX和sizeZ的實際值是多少？

來源

2013-11-29 04:19:43 Andrew

Actualy我的目標是獲得一些提示，以便更有效地編寫代碼。我不測量運行時間。 –

儘管確保編寫乾淨而高效的代碼總是一件好事，但要小心不要陷入「過早優化」的陷阱 - 這意味着要進行各種代碼優化，甚至不需要這樣做。在某些情況下，實際上可能會使代碼變得不太清晰，具體取決於您所做的優化。 – Andrew

是的，我已經浪費了一些時間試圖讓事情變得更好。我總是試圖提醒一位老師在我年輕時告訴我的是什麼：「最好的就是好的歸屬感」（譯自法文） –

這些調用已被棄用，這是您的程序運行緩慢的原因之一。您應該考慮VBO和着色器！

來源

2013-11-29 13:03:53 thetheodor

我正在閱讀橙皮書（着色器），但我不太瞭解應該用着色器編寫，應該用C++編寫，我知道着色器使用GPU，所以我問自己是否所有與圖形相關的東西都應該用着色器編寫。 –

@bobthemightyspellcaster：不，只有用於動態計算的東西屬於着色器。有很多操作在加載時只需要完成一次。我強烈建議你在跳入着色器之前研究OpenGL流水線的各個階段 - 着色器實際上是在GPU上運行的微型程序，並計算管線某些階段的輸出（例如頂點變換階段=頂點着色器，原始組裝階段=幾何着色器，光柵化階段=片段着色器）。一旦你瞭解了流水線的流程，着色器就更有意義了。 –

@bobthemightyspellcaster：查看[本文]（http://www.opengl.org/wiki/Rendering_Pipeline_Overview）瞭解更多詳情。 –

提高執行該代碼的速度

回答

相關問題