3. [gelöst:] LNK 2001 Error nach "Umzug" von Variablen von .cpp nach Header - mittlerweile OffTopic (DirectX Frag

[gelöst:] LNK 2001 Error nach "Umzug" von Variablen von .cpp nach Header - mittlerweile OffTopic (DirectX Frag

  • D

    dong schrieb:

    Nur ein Problem habe ich noch:
    Wie definiere ich das Array? Ne for Schleife funktionierte jedenfalls nicht ...

    Ich hab's, so:
    LPDIRECT3DVERTEXBUFFER9 C3DFenster::mprivatestat_pVBar[2000] = {0};

    Gruß,
    Dong

    0
  • A

    Solche konstruktionen um das ganze code in jedem header erspart dir immer die mehrfachdeklarationen und mehrfachdefinitionen:

    #ifndef C3DFENSTER_HPP
#define C3DFENSTER_HPP

//dein code

#endif

    das klappt 100% immer. ich bau das sicherheitshalber bereits in jede datei ein, schaden kann's nicht...

    Jetzt ma ne ganz andere geschichte...
    zu den 2000 vertex buffern...

    IDirect3DVertexBuffer9 Objekte sind schnittstellen, die von IDirect3D9 erzeugt werden. Die werden gebraucht, um vertex-daten direkt im RAM der grafikkarte zu speichern, weil von dort der zugriff viel schneller erfolgen kann. Beim sperren eines vertexbuffers bekommst du ein Array zu verfügung, in den du deine vertices reinkopieren kannst. Die länge dieses arrays kannst du vorher angeben: ob du da hundert oder tausend vertices reinkopieren willst, ist egal, du brauchst nur eine einzige IDirect3DVertexBuffer9 schnittstelle.

    Ausser natürlich, du willst da mehr als 2^32 Vertices reinkopieren, weil dann der IndexBuffer nicht mehr "hochauflösend" genug ist.
    dann hättest du aber ein echtes hardcoreproblem... 2^32 sind 4294967296 vertices, für jedes brauchst du sagen wir mal 28Byte, dann brauchst du schon für einen einzigen vertexbuffer 2^32*28byte=114688 MByte, multipliziert mit 2000 sind es 224000 GB! 😮

    Und das kommt mir ein klitzekleines bisschen verdächtig vor^^ (*rofl*)

    Also jetzt mal raus mit der sprache: WO HAST DU EINE GRAFIKKARTE MIT 250000 GB RAM AUFGETRIEBEN????? 😃 😃 😃 😃 😃 😃 😃 😃

    0
  • L

    Andrey schrieb:

    Solche konstruktionen um das ganze code in jedem header erspart dir immer die mehrfachdeklarationen und mehrfachdefinitionen:

    Falsch, die schützen genausowenig wie #pragma once for Mehrfachdefinitionen in mehreren Objektdateien.

    0
  • A

    warum klappts dann in meinen programmen?
    Obwohl... hm... seltsam... muss ich noch nachschauen, evtl möglich, dass es dann doch nichts bringt 🙄

    0
  • L

    Versteh mich nicht falsch. Include-Guards (alternativ #pragma once) sind wichtig, um beim compilieren einer Datei rekursive und/oder mehrfache Includes derselben Datei zu vermeiden. Über mehrere Compilierungseinheiten hinweg bringen sie allerdings relativ wenig 😉

    0
  • C

    dong schrieb:

    LordJaxom schrieb:

    Die Definitionen gehören auch in eine Implementierungsdatei, wenn die im Header stehen sind sie in jeder Compilierungs-Einheit, die den Header inkludiert vorhanden.

    Ah ja! (Ich dachte, #pragma once) würde mehrfache Header-Einbindung verhindern.

    "#pragma once" verhindert (genau wie Andrey's Konstruktion) nur davor, den Header mehrfach in EINER Übersetzungseinheit einzubinden. Der Linker sieht davon überhaupt nichts mehr (genau genommen sieht noch nicht einmal der Compiler etwas von diesen Konstruktionen, da die vom Präprozessor verarbeitet werden).

    0
  • D

    @LordJaxom & CStoll:

    Danke, ich habe es glaube ich hoffentlich verstanden... 🙂

    Dazu:

    Andrey schrieb:

    Jetzt ma ne ganz andere geschichte...
    zu den 2000 vertex buffern...

    IDirect3DVertexBuffer9 Objekte sind schnittstellen, die von IDirect3D9 erzeugt werden. Die werden gebraucht, um vertex-daten direkt im RAM der grafikkarte zu speichern, weil von dort der zugriff viel schneller erfolgen kann. Beim sperren eines vertexbuffers bekommst du ein Array zu verfügung, in den du deine vertices reinkopieren kannst. Die länge dieses arrays kannst du vorher angeben: ob du da hundert oder tausend vertices reinkopieren willst, ist egal, du brauchst nur eine einzige IDirect3DVertexBuffer9 schnittstelle.

    Ausser natürlich, du willst da mehr als 2^32 Vertices reinkopieren, weil dann der IndexBuffer nicht mehr "hochauflösend" genug ist.
    dann hättest du aber ein echtes hardcoreproblem... 2^32 sind 4294967296 vertices, für jedes brauchst du sagen wir mal 28Byte, dann brauchst du schon für einen einzigen vertexbuffer 2^32*28byte=114688 MByte, multipliziert mit 2000 sind es 224000 GB! 😮

    Und das kommt mir ein klitzekleines bisschen verdächtig vor^^ (*rofl*)

    Also jetzt mal raus mit der sprache: WO HAST DU EINE GRAFIKKARTE MIT 250000 GB RAM AUFGETRIEBEN????? 😃 😃 😃 😃 😃 😃 😃 😃

    Ich hatte anfnags tatsächlich Probleme mit nur einem Puffer, siehe in diesem Thread. Dort wurde mir auch dazu geraten, mehrere Puffer anzulegen.

    Erscheint wohl wirklich etwas oversized, aber ich wählte diese große Größe aus praktischen Gründen:
    Ein ganzes Koordinatengittersystem paßt nicht in einen Puffer, die Zuordnung zu Puffern soll möglichst systematisch sein
    --> Ein Puffer für jede Zeile.

    Genaugenommen so:

    HRESULT C3DFenster::fuellePuffer()
{
	CUSTOMVERTEX groessenmasstab[1]; // wird nur für den sizeof Operator weiter unten benötigt, der mit den Zeigern nicht funktioniert.
	VOID* pVertices;

	//schreibe aktuelle Position und Zoom in den Zwischenspeicher:
	g_xstart_buffered = m_xstart;
	g_ystart_buffered = m_ystart;
	g_fzoom_buffered = m_fzoom;
	g_fzskal_buffered = *g_fzskal;

	// Erzeuge den Vertex Puffer, falls noch nicht vorhanden
	if (b_bereit == false) this->bereiteVariablenVor();

for (int j = 0; j < this->yBloe3D; j++)
{
	punkte[0].x =  xOffset; 
	punkte[0].y =  yStep * j + yOffset + yStep;
	punkte[0].z =  zskal(m_fwert[xpos(0)][ypos(j)]); 
	punkte[0].color = farbeSand(m_fwert[xpos(0)][ypos(j)]);
	for (int i = 0; i < this->xBloe3D; i++)
    {
		punkte[2* i + 1].x =  xStep * i + xOffset; 
		punkte[2* i + 1].y =  yStep * j + yOffset; 
		punkte[2* i + 1].z =  zskal(m_fwert[xpos(i)][ypos(j)]); 
		punkte[2* i + 1].color = farbeSand(m_fwert[xpos(i)][ypos(j)]);
		punkte[2* i + 2].x =  xStep * i + xOffset + xStep; 
		punkte[2* i + 2].y =  yStep * j + yOffset + yStep;
		punkte[2* i + 2].z =  zskal(m_fwert[xpos(i+1)][ypos(j+1)]); 
		punkte[2* i + 2].color = farbeSand(m_fwert[xpos(i+1)][ypos(j+1)]);
   }
	punkte[2* this->xBloe3D + 1].x =  xStep * (this->xBloe3D - 1) + xOffset + xStep; 
	punkte[2* this->xBloe3D + 1].y =  yStep * j + yOffset; 
	punkte[2* this->xBloe3D + 1].z =  zskal(m_fwert[xpos(this->xBloe3D)][ypos(j)]); 
	punkte[2* this->xBloe3D + 1].color = farbeSand(m_fwert[xpos(this->xBloe3D)][ypos(j)]);

	// Fill the vertex buffer # j
    if( FAILED( g_pVBar[j]->Lock( 0, (2* this->xBloe3D + 2) * sizeof(groessenmasstab), (void**)&pVertices, 0 ) ) )
        return E_FAIL;
    memcpy( pVertices, punkte, (2* this->xBloe3D + 2) * sizeof(groessenmasstab) );
    g_pVBar[j]->Unlock();
}

	return S_OK;
}

    mit

    HRESULT C3DFenster::bereiteVariablenVor(void)
{
	b_bereit = true; // An dieser Stelle, da ja noch etwas schiefgehen kann.
	//MessageBox(NULL,L"Puffererzeugung",NULL,NULL);

	//Anlegen der Variablen für die Punktmenge:
	punkte = new CUSTOMVERTEX[(2* this->xBloe3D + 2)];

	//Erzeugen der Graphikpuffer:
	for (int j = 0; j < this->yBloe3D; j++)
	{
		// Create the vertex buffer # j
		if( FAILED( g_pd3dDevice->CreateVertexBuffer( (2* this->xBloe3D + 2) *sizeof(CUSTOMVERTEX),
				                                      0, D3DFVF_CUSTOMVERTEX,
						                              D3DPOOL_DEFAULT, &g_pVBar[j], NULL ) ) )
		{
			b_bereit = false;
			return E_FAIL;
		}
	}
	return S_OK;
}

    Die Anwendung braucht dabei nie mehr als 16MB RAM, ich denke, das ist akzeptabel.

    Gruß,
    Dong

    0
  • A

    hmmm.... hab ma ganz kurz in den anderen thread reingeschaut, und eigentlich wundert mcih schon, dass in einen buffer nicht mehr als ca. 20000 vertices reinpassen, denn wozu braucht man dann in dem fall 32bit Indexbuffer, mit dem man über 4000000000 vertices adressieren kann? und überhaupt... was zum henker heisst denn jetzt " f'`8k " ???

    0
  • G

    Nichts. TGGC's Tastatur ist einfach nur kaputt.

    0
  • ?

    Das bleibt wohl für immer ein geheimnis, für alle ausser TGGC^^ :p

    0
  • D

    Andrey schrieb:

    hmmm.... hab ma ganz kurz in den anderen thread reingeschaut, und eigentlich wundert mcih schon, dass in einen buffer nicht mehr als ca. 20000 vertices reinpassen, denn wozu braucht man dann in dem fall 32bit Indexbuffer, mit dem man über 4000000000 vertices adressieren kann?

    Ja, das mit der Umstellung auf 32bit habe ich auch mal gelesen, allerdings nur für meshes, nicht für vertices.
    Ich weiß aber leider nicht mehr, wo man das einstellen konnte, war glaube ich eine Device Eigenschft.

    Gruß,
    Dong

    0
  • ?

    Andrey schrieb:

    was zum henker heisst denn jetzt " f'`8k " ???

    www.games-net.de/hosted/tggc/trash/serious.gif f'`8k

    Gruß, TGGC (\-/ returns)[/quote]

    0
Anmelden zum Antworten