ich bin gerade dabei mich in C++/DirectX einzuarbeiten und schreibe mir eine Klasse, mit der ich mit möglichst wenig Zeilen Code möglichst resourcenschonend viele 2D Texturen zeichnen kann. Sie soll ungefähr so aufgebaut sein, wie die SpriteBatch Klasse von XNA, evtl. kennt die ja einer. Dabei benutze ich dynamische VertexBuffer mit COUNT * 4 Vertices, wobei COUNT im Moment mit 1024 definiert ist. Ein Vertex ist so definiert:

struct Vertex
{
    D3DXVECTOR3 position;
    D3DXCOLOR color;
    D3DXVECTOR2 texture;
};

Er hat also eine Größe von 36Bytes.
Bis vor kurzem wurde noch in jedem Frame für jede Texture2D ein Vertex* erstellt, in dem dann die Vertices gespeichert wurden. Am Ende wurden dann alle vorhandenen Vertex* in den Speicher des VertexBuffers kopiert und gerendert. So hat das auch alles wunderbar funktioniert.
Nun dachte ich mir aber, dass es doch ziemlich unperformant sein muss, in jedem Frame COUNT*4*sizeof(Vertex) Bytes zu reservieren, um sie danach wieder freizugeben. Also wollte ich mir einen Pool mit Vertex* anlegen. Somit würden alte Vertex* wiederverwendet werden und müssten nur einmal reserviert und einmal freigegeben werden. Und damit währen wir direkt beim Problem:
So lange ich "nur" 1024 mal eine Textur zeichne, funktioniert alles, sobald ich aber mehr als 1024 Texturen zeichne, bekomme ich bei Vertex* vertices = new Vertex[COUNT * 4] eine std::bad_alloc exception. Die Exception tritt hier bei return... auf (in malloc.c):

__forceinline void * __cdecl _heap_alloc (size_t size)

{

    if (_crtheap == 0) {
        _FF_MSGBANNER();    /* write run-time error banner */

        _NMSG_WRITE(_RT_CRT_NOTINIT);  /* write message */
        __crtExitProcess(255);  /* normally _exit(255) */
    }

    return HeapAlloc(_crtheap, 0, size ? size : 1);
}

Die exakte Fehlermeldung, die VisualStudio 2012 mir gibt, lautet:
Unhandled exception at at 0x7698C41F in UnblockMeNative.exe: Microsoft C++ exception: std::bad_alloc at memory location 0x0031F3C0.

Ausgelöst wird sie von diesem Code bei new...:

if(_vertices.size() <= _vcount)
	_vertices.push_back(new Vertex[COUNT * 4]);

_vcount enthält dabei die Anzahl an aktuell verwendeten Vertex* und _vertices ist ein vector<Vertex*>.
Das erste mal läuft das noch ohne Probleme durch, beim zweiten Mal kommt dann die oben genannte Fehlermeldung.

Seltsam dabei ist allerdings, wenn ich COUNT einfach auf 2048 festlege, läuft alles wie geschmiert, obwohl ja im Endeffekt genauso viel Speicher reserviert wird. Selbst wenn ich COUNT auf 4096 festlege und 4096 mal eine Textur zeichne, läuft das Programm. Zwar nur mit 33FPS (im Debug Mode), aber es läuft...
Ich blick da leider nicht mehr so ganz durch, deswegen hab ich mich ja auch hier registriert

Wäre super, wenn ihr mir helfen könntet
Wenn ihr mehr Code braucht, liefere ich den natürlich gerne nach, allerdings wüsste ich nicht, welcher Teil noch für diese Fehlermeldung relevant sein könnte.

Vielen Dank im Voraus!

Geheimnisvolle Fehler sind oft auf Bereichsüberschreitungsfehler oder ähnliches zurück zu führen, also Fehler die aus Pointergefrickel entstehen und die sich mit obigem Tipp ganz toll vermeiden lassen. Daher setz das erst einmal um. Und falls die Fehler trotzdem noch auftreten, dann kann man die Debugmöglichkeiten des vectors nutzen.

P.S.: Wobei ein vector mit fester Größe auch komisch wäre, du willst vermutlich eher std::array für die innere Datenstruktur. Dafür gilt das gleiche wie für den vector, aber es ist in einer verschachtelten Struktur wesentlich schneller als der vector (und schneller als dein new, da dieses gleich schnell ist wie der vector).

wenn ich COUNT einfach auf 2048 festlege, läuft alles wie geschmiert, obwohl ja im Endeffekt genauso viel Speicher reserviert wird.

Im Vergleich zu wenn COUNT auf 1024 festgelegt ist, wie du ja zuvor gesagt hattest? Zweifelhaft
Wenn das keine Konstante ist, dass wird COUNT u.U. einfach nicht [mehr] das enthalten, was du eigentlich glaubst.

Und sonst klingt das alles etwas wirr. Man zeichnet keine Texturen, es ist unklar was deine ganzen Vertexarrays überhaupt sollen (enthalten die irgendwelche sinnvollen Daten oder legst du die rein nach dem Prinzip "mehr ist besser" an?).

_vcount enthält dabei die Anzahl an aktuell verwendeten Vertex*

...?

Die ganzen Vertex Arrays haben aber trotzdem einen Grund. Ich versuche bei dem Zeichnen der Texturen mit möglichst wenig Draw Calls auszukommen. Dazu erstelle ich mir Vertex Arrays der Größe 4 * COUNT (4 weil eine Textur nun mal 4 Ecken hat) und wenn eins davon voll ist, wird ein neues erstellt. Es kann ja auch mal vorkommen, dass eine Textur mehr als 1024 mal gezeichnet werden soll (Particle Engine, große TileMap etc.).

Am Ende werden dann alle Vertices, die sich angesammelt haben, gezeichnet. Ich könnte natürlich auch nur ein Vertex* verwenden und per realloc vergrößern, oder einen vector verwenden, aber dann müsste ich den VertexBuffer jedes mal neuerstellen, wenn mehr Vertices dazugekommen sind.

Ich hab mir eben noch einmal den SpriteBatch von ANX (sozusagen das OpenSource XNA) angeschaut, und dort werden die Vertices erst ganz am Ende erstellt, wenn sie gezeichnet werden. Davor werden nur Texturen, Positionen und Farben gespeichert. Vielleicht werde ich mal versuchen das so rum zu implementieren.

So lange ich "nur" 1024 mal eine Textur zeichne, funktioniert alles, sobald ich aber mehr als 1024 Texturen zeichne

Wie machst du das, wenn deine Vertexarrays nur Platz für jeweils 1024 Quads bieten?

oder einen vector verwenden, aber dann müsste ich den VertexBuffer jedes mal neuerstellen, wenn mehr Vertices dazugekommen sind.

Wie kommst du zu der Aussage? Es zwingt dich niemand, die Größe eines vectors zu verändern, aber im Gegensatz zu C-Arrays sind std::vector und std::array in der Lage out-of-bounds-Zugriffe im Debug-Modus zu erkennen, wie SeppJ ja schon gesagt hat.

Nur noch eine klitzekleine Frage:
wenn ich per
for each(pair<ID3D11ShaderResourceView*, vector<Vertex>> p in _textures)
durch eine map<ID3D11ShaderResourceView*, vector<Vertex> durchiteriere, wirft IntelliSense einen Fehler, dass for each den Ausdruck nicht verarbeiten könnte, kompilieren tut es aber wunderbar. Sollte ich trotzdem lieber etwas (meiner Meinung nach unübersichtliches) wie
for(map<ID3D11ShaderResourceView*, vector<Vertex>>::iterator i = _textures.begin(); i != _textures.end(); i++)
verwenden, gibt es da noch eine viel bessere Variante, oder soll ich den Fehler einfach ignorieren?

Er hat also eine Größe von 36Bytes.

Das kann man einfach so sagen? Ist das nicht total maschinenabhängig?

Nur noch eine klitzekleine Frage:
wenn ich per
for each(pair<ID3D11ShaderResourceView*, vector<Vertex>> p in _textures)
durch eine map<ID3D11ShaderResourceView*, vector<Vertex> durchiteriere, wirft IntelliSense einen Fehler, dass for each den Ausdruck nicht verarbeiten könnte, kompilieren tut es aber wunderbar. Sollte ich trotzdem lieber etwas (meiner Meinung nach unübersichtliches) wie
for(map<ID3D11ShaderResourceView*, vector<Vertex>>::iterator i = _textures.begin(); i != _textures.end(); i++)
verwenden, gibt es da noch eine viel bessere Variante, oder soll ich den Fehler einfach ignorieren?

for each ist eine nicht standardgemäße Compilererweiterung von MSVC++. Nutz lieber die standardkonforme zweite Variante, std::for_each oder am besten, falls MSVC++ dies inzwischen kann, ein range-based for.

<:xmas2:>

Edit: Also entweder hat MS bei der Implementierung von Ranged Based For ziemlich geschlampt, oder das ist, warum auch immer, immer so unperformant. Denn mit for(auto i : _textures) hab ich bei 4096 * mal eine Textur zeichnen 18FPS, wenn ich for(auto i = _textures.begin(); i != _textures.end(); i++) verwende, bekomme ich 23FPS. Oder kann es sein, dass dadurch, dass _textures im Moment nur eine Länge von 1 hat (ich zeichne ja bisher nur eine Textur) ranged base for noch einen sehr großen OverHead hat, der sich bei größeren Größen von _textures auszahlt?

ohne das & iteriert er by value, bzw erstellt eine Kopie und arbeitet damit.