Optimierung von Pixel

[Medium]

Zitat von EWeiss:

Fehler "Bereichsüberschreitung bei ZeilenIndex" wenn mein Buffer 256 groß ist.

Dann ist dein Buffer größer als das Bitmap hoch ist. (Oder du übergibst aus irgend welchen anderen Gründen eine Y-Koordinate ausserhalb des Bitmaps. Ohne konkreten Code schwer zu sagen.) Was diese Meldung sagt: "Du forderst eine Zeile im Bitmap an, die das Bitmap gar nicht besitzt." Also entweder eine Zeile < 0 oder >= Bitmap.Height.

Letztlich ist aber die Variante, die die Scanlines puffert, sicherlich schneller. Mich würde aber dennoch interessieren, wo das Problem mit meinem Vorschlag war, wo ein 1-zeiliges Bitmap gedreht ge-PlgBlt-ed wurde. Mangels Delphi kann ich das gerade nicht weiter testen, aber noch sehe ich mildes Potenzial darin.

[EWeiss]

Zitat:

Dann ist dein Buffer größer als das Bitmap hoch ist. (Oder du übergibst aus irgend welchen anderen Gründen eine Y-Koordinate ausserhalb des Bitmaps. Ohne konkreten Code schwer zu sagen.) Was diese Meldung sagt: "Du forderst eine Zeile im Bitmap an, die das Bitmap gar nicht besitzt." Also entweder eine Zeile < 0 oder >= Bitmap.Height.

Ok dann muss ich da nochmal durch und debuggen.
EDIT:
Ok es liegt daran weil die Schleife bei 0 anfängt und
ScanLines[BUFFER_SIZE - i] nun mal 256 sind das hat zur folge das P dann nicht initialisiert wird und NIL ist.

muss halt auf NIL prüfen

Wie gesagt schade das der Channel bei dir 0 ist.

Zitat:

aber noch sehe ich mildes Potenzial darin.

Glaube ich dir gern..
Ich hatte Probleme bei der Grafik Darstellung kann natürlich auch daran liegen
das ich deinen Code falsch interpretiert habe und deshalb die Implementierung fehlgeschlagen ist.
Versucht habe ich es auf jeden fall

Zitat:

Die Bitmap muss gar nicht größer werden, nur der Buffer. Allerdings musst du dann die Schleife anders aufbauen

Verstehe ich nicht warum den Buffer vergrößern sind doch genug Daten enthalten die ich Rendern will also wenn das Bitmap 160 hoch ist.


gruss

[Medium]

Zitat von EWeiss:

Verstehe ich nicht warum den Buffer vergrößern sind doch genug Daten enthalten die ich Rendern will also wenn das Bitmap 160 hoch ist.

Nochmal: Nur weil du genau passend aus dem Buffer liest, heisst das nicht, dass die DLL auch passend rein schreibt. Stell dir die Funktion in der DLL grob so vor:

Delphi-Quellcode:

function GetData(aChannel, aMaxData, aPosition: Integer): Single;
begin
  ...
end;

procedure BASS_ChannelGetData(aChannel: Integer; buf: Pointer, aDataType: TBassDataType);
var
  i: Integer;
begin
  case aDataType of
    BASS_DATA_FFT256:
      for i := 0 to 127 do
        Single((buf+(i*4))^) := GetData(aChannel, 127, i);
    BASS_DATA_FFT512:
      for i := 0 to 255 do
        Single((buf+(i*4))^) := GetData(aChannel, 255, i);
    BASS_DATA_FFT1024:
      for i := 0 to 511 do
        Single((buf+(i*4))^) := GetData(aChannel, 511, i);
    ...
  end;
end;

Wenn du diese Funktion mit dem Parameter BASS_DATA_FFT512 aufrufst, werden immer zwingend 256 Single-Werte ab der Speicherposition des ersten Elementes deines Arrays geschrieben. Selbst wenn dein Array nur 1 Element lang wäre. Die Prozedur weiss nicht wie lang das Array ist, und geht - weil du mit BASS_DATA_FFT512 aufgerufen hast - davon aus, dass du dafür gesorgt hast, dass der Speicher lang genug reserviert ist.
Wenn dies nicht der Fall ist, liegen im Speicher hinter dem zu kurzen Array potenziell andere Variablen, möglicherweise sogar welche, die überhaupt nichts mit dem Programmteil zu tun haben, sondern vielleicht irgendwas in der VCL oder weiss der Geier. Die DLL würde diese dann ohne Gnade überschreiben, und wenn sie dann später mal gebraucht würden, knallt es. Auch wieder möglicherweise an komplett anderen Stellen, die keinen Rückschluss darauf zulassen, dass der eigentliche Fehler hier an dieser Stelle passiert ist.
Wenn man sich solche Schnitzer eingefangen hat, kann man in größeren Programmen Tage bis Wochen damit verbringen sie zu finden.

Anderes Thema:
----------------------------------
Ich habe erst jetzt realisiert, dass du ja gar nicht beim Abspielen "live" das FFT Bild malst, sondern vorab! Das eröffnet eine interessante Möglichkeit: Man könnte das Bild zunächst um 90° gedreht auf ein Puffer-Bitmap zeichnen, weil du damit dann nämlich schön alle Zeilen (lies: Scanlines) nacheinander durchgehen kannst, und nicht wie jetzt diese puffern und umherspringen musst. Das fertige Puffer-Bitmap zum Schluss dann mit PlgBlt() gedreht in das Image malen, und fertig. Das sollte ruck zuck gehen.
Leider hast du alle Anhänge gelöscht (wieso!?!?), so dass ich das nicht testweise bauen kann. Schade.

[EWeiss]

Ich werde deine Ausführung nochmal genau durchgehen.
So das ich genau verstehe warum und wieso.. Danke!

Zitat:

Wenn man sich solche Schnitzer eingefangen hat, kann man in größeren Programmen Tage bis Wochen damit verbringen sie zu finden.

Was muss ich denn nun genau machen damit hier kein Fehler auftritt?
Den Buffer auf 256 einstellen und anschließend nur 160 Pixel daraus lesen also abhängig von der höhe der Bitmap?
Dann ist der Speicher mit 256 Bytes gefüllt verwende dann aber nur 160 davon.
Wenn es das ist was ihr meint.
Dann wird aber genau wie vorher nicht der gesamte Bereich des Spectrums gezeichnet weil das Bitmap halt kleiner ist.
Der Speicher hingegen ist dann aber korrekt gefüllt.

Zitat:

Leider hast du alle Anhänge gelöscht (wieso!?!?), so dass ich das nicht testweise bauen kann. Schade.

Kein Problem hänge es nochmal an.
Habe noch etwas geändert bzg. dem Fehler mit ScanLine prüfe jetzt auf <> NIL.
Damit bei der Rückgabe der Farben kein ZeilenFehler auftritt.

Hoffe nur du bekommst jetzt einen Channel

gruss

[Medium]

Zitat von EWeiss:

Den Buffer auf 256 einstellen und anschließend nur 160 Pixel daraus lesen also abhängig von der höhe der Bitmap?
Dann ist der Speicher mit 256 Bytes gefüllt verwende dann aber nur 160 davon. Wenn es das ist was ihr meint.

Exakt das, ja.

Zitat:

Dann wird aber genau wie vorher nicht der gesamte Bereich des Spectrums gezeichnet weil das Bitmap halt kleiner ist.

Ist ja erstmal nicht schlimm, das ist ja gewollt, wenn ich das richtig verstanden habe.

Zitat:

Der Speicher hingegen ist dann aber korrekt gefüllt.

Und das ist wichtig! Was du bisher hattest, war einer der klassischsten Bugs überhaupt, und ganz klar ein echter Fehler im Code. Solche Dinger sind keine Kleinigkeiten, weil die potenziellen Effekte von gar nichts bis Bluescreen reichen, und sowohl zeitlich als auch örtlich (lies: Codestelle) augenscheinlich völlig unabhängig von dem eigentlichen Fehler auftreten können. Richtig eklig.

Zitat:

Kein Problem hänge es nochmal an.

Danke. Leider jetzt zu spät, das Abendprogramm geht gleich los. (Informatiker mit Sozialleben, wo gibs denn sowas?) Mal schauen dass ich morgen noch Mal dran gehe. Interessant isses ja

Zitat:

Hoffe nur du bekommst jetzt einen Channel

Das war im Büro in einer VM. Ich hoffe, dass es zu Hause direkt auf dem PC besser geht. Aber leider nur Lazarus, wo es kein TBitmap.Scanline gibt. Mal gucken wie ich das deichsel.

Schönes sonniges Wochenende!

[EWeiss]

Zitat:

Exakt das, ja.

Ok habe die Korrekturen vorgenommen.
In dem Beispiel funktioniert jetzt auch das weiterschalten der Seiten.

Zitat:

Schönes sonniges Wochenende!

Dir auch

gruss

[BUG]

Um das mit dem Buffer nochmal zu veranschaulichen: Stell dir vor, du hast einen Kaffeeautomaten (die BASS-Funktion), der dir immer genau eine Tasse Kaffee ausspuckt, wenn du auf den Knopf drückst. Wenn du jetzt Lust auf wenig Kaffee hast und nur eine Espresso-Tasse (zu kleiner Puffer) drunterstellst, dann gibt es eine Sauerei