Wie funktioniert das normalerweise? Sagen wir ich hab ein Projekt, in dem ich Direct3D verwende. Nun dachte ich mir die Aufteilung wäre in etwa so:

GameMain.cpp
GameMain.h

In GameMain.h includiere ich die ganzen Standardheader wie <windows.h> und
<d3d9.h>, Funktionsdeklarationen und die globalen Directx pointer wie
LPDIRECT3DDEVICE9 d3ddevice usw.

In GameMain.cpp kommt WinMain() usw. und es wird GameMain.h includiert.

Und dann für alle Funktionen und Klassen wieder jeweils ne .cpp und .h.

Sagen wir nun will ich eine Funktion renderFrame() einfügen, dafür erstell ich renderFrame.cpp und .h.

Stimmt dann folgendes? :

In renderFrame.h kommt die Deklaration von renderFrame().

In renderFrame.cpp includiere ich renderFrame.h und schreibe den
Quellcode der Funktion renderFrame().

Muss ich renderFrame.h in GameMain.cpp includieren? Oder in GameMain.h?

Muss ich GameMain.h in renderFrame.h includieren? Oder in renderFrame.cpp?

Egal wie ich es versuche aufzuteilen, die renderFrame() Funktion findet dann
viele Dinge nicht (zum Beispiel die globalen Directx pointer die ich in GameMain.h deklariert habe).

Irgendwie fehlt immer irgendeiner Funktion etwas.
Ich weiß es ist schon etwas lächerlich und ich sollte eigentlich selber draufkommen, aber vielleicht kann mir doch jemand nen Tipp geben wie größere Projekte normalerweise aufgeteilt werden, und wo man was deklariert und inkludiert.

Aber prinzipiell hast du recht... in eine Headerdatei kommen nur die Deklarationen (also Deklaratinen von Klassen und Funktionen), und in der cpp Datei werden diese dann implementiert. Wenn du dann dazu noch andere externe Dateien benötigst dann solltest du die nach Möglichkeit immer erst in der cpp Datei inkludieren und nicht schon in der Headerdatei. Ausser es lässt sich natürlich nicht vermeiden.
Wenn du globale Variablen irgendwo brauchst die in einer cpp Datei erstellt wurden (Variablen erstellt man normalerweise nicht in Headerdateien), dann kannst du diese ganz oben in deinem Programmcode mit dem Schlüsselwort "extern" deklarieren und dann benutzen. Dann weiß der Compiler, dass die bereits wo anders deklariert wurden.

Aber wie gesagt, bei dir lässt das eher auf schlechtes Design schließen, wenn du sowas massenhaft brauchst. Man kommt natürlich nicht immer drum rum, aber man kann es schon weitestgehend vermeiden.

In renderFrame.h kommt die Deklaration von renderFrame().

In renderFrame.cpp includiere ich renderFrame.h und schreibe den
Quellcode der Funktion renderFrame().

Bis dahin passt es auf jeden Fall noch.

Muss ich renderFrame.h in GameMain.cpp includieren? Oder in GameMain.h?

Muss ich GameMain.h in renderFrame.h includieren? Oder in renderFrame.cpp?

Das kommt darauf an, wer welche Definitionen benötigt. Das heißt, für diese Fragen gibt es auch keine allgemeingültige Antwort.
(und im Zweifelsfall mußt du gegenseitige Includes auflösen, indem du z.B. Forward-Deklarationen verwendest oder die GameMain.h in zwei Teile aufteilst

Egal wie ich es versuche aufzuteilen, die renderFrame() Funktion findet dann viele Dinge nicht (zum Beispiel die globalen Directx pointer die ich in GameMain.h deklariert habe).

Diese Pointer mußt du dann natürlich an der Stelle eingebunden haben, wo sie benötigt werden (übrigens solltest du sie in der .h nur als 'extern' deklarieren und in der .cpp anlegen) - umgekehrt benötigst du die renderFrame() Deklaration spätestens dort, wo du sie verwenden willst.

Sollte ich vielleicht der renderFrame() Funktion einfach die Zeiger die dort gebraucht werden mit übergeben, wäre das eine gescheite Lösung?

Also lieber mit extern, oder gleich der Funktion die Zeiger mitgeben?

Sollte ich vielleicht der renderFrame() Funktion einfach die Zeiger die dort gebraucht werden mit übergeben, wäre das eine gescheite Lösung?

Ja, das wäre eine bessere Lösung (und zwar nicht nur für diese eine Funktion, sondern für das gesamte Programm - globale Variablen solltest du (wann immer möglich) vermeiden.

PS: Es gibt kein standardisiertes "übliches Vorgehen", jeder Programmierer hat so seine eigene Art, an ein größeres Projekt ranzugehen und es zu zerlegen