Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

tbVideo ruckelpower :(

  • 1
  • 2

Werbeanzeige

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

11

24.05.2005, 06:38

Zitat von »"Nox"«

C-/C++-Quelltext

 
1
2

pVideo = strrev(pVideo);
memcpy(pTexture, pVideo, pSample->GetSize());

1. strrev darfst Du nicht benutzen, da die Daten kein String sind. Er würde bei der ersten auftretenden Null aufhören, weil er denkt, der "String" wäre zu Ende.
2. Warum überhaupt die Daten umkehren? Damit wäre es noch langsamer als es ohnehin schon ist. Eine Spiegelung kann man mit veränderten Texturkoordinaten besser erzielen, außerdem sind die Bilder nicht vertikal, sondern horizontal gespiegelt. Mit dem Umkehren aller Daten würdest Du nur aus einem horizontal gespiegelten Bild ein vertikal gespiegeltes Bild machen, was einem nichts bringt.
3. Du darfst nicht die kompletten Daten einfach auf einmal in die Textur schreiben. Man sollte immer nur eine Zeile auf einmal schreiben, weil man nicht weiß, wie viel Speicher "zwischen" zwei Texturzeilen liegt. Dafür gibt es ja das Member D3DLOCKED_RECT::Pitch. Es kann also durchaus sein, dass die Grafikkarte z.B. bei 640x480 intern(!) eine 1024x512-Textur nimmt und 384 Pixel in jeder Zeile einfach ignoriert werden. Würdest Du da rein schreiben, bekämst Du die geschriebenen Daten nie zu Gesicht.

Hier nochmal der entsprechende Ausschnitt aus tbVideo. Da man sowieso jede Zeile einzeln kopieren muss, kann man sie auch gleich in die richtige Reihenfolge bringen, ohne dass es zusätzliche Performance kostet (naja, ein bisschen vielleicht wegen Cache, aber nicht entscheidend).

C-/C++-Quelltext

 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

    // 24-Bit-Format

    else if(m_TexDesc.Format == D3DFMT_R8G8B8)
    {
        BYTE* pVideo;
        pSample->GetPointer(&pVideo);
        pVideo += dwVideoWidth * (dwVideoHeight - 1) * 3;
        BYTE* pTexture = (BYTE*)(LockedRect.pBits);
        DWORD dwPitch = LockedRect.Pitch;

        for(DWORD y = 0; y < dwVideoHeight; y++)
        {
            memcpy(pTexture, pVideo, dwVideoWidth * 3);
            pTexture += dwPitch * 3;
            pVideo -= dwVideoWidth * 3;
        }
    }


Jedenfalls kann es an diesem Stückchen Code nicht liegen, dass es bei einigen Leuten so langsam läuft. Vor allem nicht, dass es im Vollbildmodus ruckelt und im Fenstermodus nicht.

Allerdings habe ich festgestellt, dass es im Vollbildmodus nicht so stark ruckelt, wenn man V-Sync abschaltet.
David Scherfgens Website | Konzentrationstest Polizei

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

  • Private Nachricht senden

12

24.05.2005, 14:07

Hmm an die Nullen habe ich nicht gedacht, aber die Ursprungsidee war alles umzudrehen um sich die perpixel Konvertierung zu sparen.
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

13

24.05.2005, 14:33

Zitat von »"Nox"«

Hmm an die Nullen habe ich nicht gedacht, aber die Ursprungsidee war alles umzudrehen um sich die perpixel Konvertierung zu sparen.

Es wird ja gar nichts konvertiert, zumindest nicht in tbVideo.
Wenn irgendwo was konvertiert wird, dann innerhalb von DirectShow (also außerhalb unseres Einflusses).
David Scherfgens Website | Konzentrationstest Polizei

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

  • Private Nachricht senden

14

24.05.2005, 15:30

Konvertierung war das falsche Wort; meinte von BGR auf RGB
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

Anonymous

unregistriert

15

25.05.2005, 12:03

Geht leider immer noch nicht :(

Ich glaube ich nehme für die Zwischensequenzen DirectDraw. Wird mir langsam zu blöde. Wechsel ich halt im Spiel zwischen den beiden APIs, kein Bock mehr.

Nox

Supermoderator

Beiträge: 5 272

Beruf: Student

  • Private Nachricht senden

16

25.05.2005, 14:19

Schau dir doch einfach mal das DirectDraw to surface Beispiel der doku an.
PRO Lernkurs "Wie benutze ich eine Doku richtig"!
CONTRA lasst mal die anderen machen!
networklibbenc - Netzwerklibs im Vergleich | syncsys - Netzwerk lib (MMO-ready) | Schleichfahrt Remake | Firegalaxy | Sammelsurium rund um FPGA&Co.

Anonymous

unregistriert

17

12.06.2005, 03:01

Hat jemand schon herausgefunden wo der Fehler liegt?

Ich habe alles was hier gepostet wurde für Veränderungen ausprobiert, jedoch es ruckelt bei mir auch im Vollbild :(

Werbeanzeige

  • 1
  • 2