Autor Beitrag
OlafSt
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 459
Erhaltene Danke: 90

Win7, Win81, Win10
Tokyo, VS2017
BeitragVerfasst: Mo 17.09.12 11:00 
IMHO gehört diese "Idiotensicherheit" zum guten Ton, wenn man professionell programmiert. Ich habs auch so gelernt und lege meine Programme darauf aus (sogar die TAB-Reihenfolge und ALT-Hotkeys ;) ). Ich weiß, ist inzwischen völlig aus der Mode gekommen, so zu arbeiten. Bis man sein Programm mal an den richtigen gibt :D

_________________
Lies, was da steht. Denk dann drüber nach. Dann erst fragen.
Mathematiker Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Quizmaster
Beiträge: 2615
Erhaltene Danke: 1421

Win 7, 8.1, 10
Delphi 5, 7, 10.1
BeitragVerfasst: Mo 17.09.12 11:02 
Hallo Delphi-Laie,
user profile iconDelphi-Laie hat folgendes geschrieben Zum zitierten Posting springen:
Traurig finde ich nur, daß man mit Delphi nicht für niedrige Versionen speichern kann (wie es viele Programme können), so daß ich Mathematikers Delphi-5-Datendateien (konkret natürlich die Formulardateien) nicht mit Delphi 4 lesen kann.

Warum hast Du denn noch nichts gesagt? :bawling:
Wenn ich gewusst hätte, dass es unterschiedliche Formate gibt, hätte ich schon lange reagiert. Unter Delphi 5 muss ich nur mit einem Rechtsklick auf das Formular zwischen Text- und Binary-Format umschalten. Das habe ich jetzt getan.
Die Revision 14 müsste damit Dein Delphi 4 lesen. Hoffe ich.

Und noch einmal. Ich bin in keiner Weise beleidigt, wenn jemand einen Fehler in irgendeinem meiner Programme findet. Im Gegenteil. Das zeigt mir doch, dass das Programm benutzt wird.
Außerdem gibt es mir die Möglichkeit, die Fehler zu entfernen und vor allem aus diesen zu lernen.
Deshalb kann ich nur alle bitten, fleißig zu testen und mir Probleme mitzuteilen.

Beste Grüße
Mathematiker

_________________
Töten im Krieg ist nach meiner Auffassung um nichts besser als gewöhnlicher Mord. Albert Einstein


Zuletzt bearbeitet von Mathematiker am Mo 17.09.12 20:25, insgesamt 1-mal bearbeitet
Delphi-Laie
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 1586
Erhaltene Danke: 231


Delphi 2 - RAD-Studio 10.1 Berlin
BeitragVerfasst: Mo 17.09.12 13:20 
"Lässig", damit ist es lesbar, danke.

Das trifft aber für alle Deine Projektquelltexte und auch so ziemlich für alle Projektquelltexte anderer Forumsteilnehmer zu, die mit neueren Delphis erstellt wurde. Anscheinend wurde es es mit Delphi 5 möglich, die Formular-/VCL-Informationen als Text abzuspeichern, und daß das umschaltbar ist und dann sogar von Delphi 4 gelesen werden kann, erstaunt mich sehr. Zur Not kann man ja auch mit Rechtsklick auf Formular eine Formulardatei komplett als Quelltext mit VCL-Elementen versorgen.

Sooo schlimm war es nun aber auch wieder nicht, denn das Geheimnis steckt ja fast ausschließlich in den eigentlichen Quelltexten.

Na gut, wenn Du Dich nicht auf den Schlips getreten fühlst, gleich noch eins: Das Neuzeichnen funktioniert auch noch nicht sauber. Schiebt oder zoomt man ein anderes Fenster "stufig" über die Graphik hinweg, und zwar so, daß nur ein Teil neugezeichnet wird (werden muß), und danach ist wieder ein Stückchen mehr der Graphik zu zeichnen, ist diese nicht mehr homogen.


Zuletzt bearbeitet von Delphi-Laie am Mo 17.09.12 17:23, insgesamt 1-mal bearbeitet
Mathematiker Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Quizmaster
Beiträge: 2615
Erhaltene Danke: 1421

Win 7, 8.1, 10
Delphi 5, 7, 10.1
BeitragVerfasst: Mo 17.09.12 17:03 
Hallo Delphi-Laie,
user profile iconDelphi-Laie hat folgendes geschrieben Zum zitierten Posting springen:
Schiebt oder zoomt man ein anderes Fenster "stufig" über die Graphik hinweg, und zwar so, daß nur ein Teil neugezeichnet wird (werden muß), und danach ist wieder ein Stückchen mehr der Graphik zu zeichnen, ist diese nicht mehr homogen.

Ich vermute Du nutzt Windows XP, denn unter Vista und 7 gibt's das eigentlich nicht mehr.
Aber auch das Problem glaube ich gelöst zu haben. Allerdings muss ich morgen erst einmal auf einem XP-Computer prüfen, ob der Fehler noch auftritt. Wenn nicht, nun ja, dann wird es vielleicht Revision 15 sein.
Ich hätte nie gedacht, dass es so viele geänderte Programmversionen werden. :wink:

Beste Grüße
Mathematiker

_________________
Töten im Krieg ist nach meiner Auffassung um nichts besser als gewöhnlicher Mord. Albert Einstein
Delphi-Laie
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 1586
Erhaltene Danke: 231


Delphi 2 - RAD-Studio 10.1 Berlin
BeitragVerfasst: Mo 17.09.12 17:26 
2000.

Sollte m.E sogar auf jedem Windows fehlerfrei funktionieren, auf dem es lauffähig ist. Bin in der Beziehung akribisch. Nur, wenn der Aufwand gar zu groß wäre, kann man natürlich die alten Betriebsprogramme ignorieren. Muß eben jeder für sich entscheiden. XP erfreut sich aber immer noch großer Beliebheit und Verbreitung.
Mathematiker Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Quizmaster
Beiträge: 2615
Erhaltene Danke: 1421

Win 7, 8.1, 10
Delphi 5, 7, 10.1
BeitragVerfasst: Mo 17.09.12 22:00 
Hallo Delphi-Laie,
user profile iconDelphi-Laie hat folgendes geschrieben Zum zitierten Posting springen:
Nur, wenn der Aufwand gar zu groß wäre, kann man natürlich die alten Betriebsprogramme ignorieren.

Warum sollte ich? Es war keine große Mühe und ich hoffe, dass es jetzt funktioniert, d.h. unter Windows XP und 2000 das Bild sauber aufgebaut wird.

Eine weitere Ablaufbremse habe ich die ganze Zeit übersehen, das round beim Einrechnen des Faktors. Dabei genügt ein
ausblenden Quelltext
1:
shr ecx, 1					

am Anfang der Prozedur farbmitte und man kann eine integer-Variable faktor, statt real, nutzen und zwei mal round sparen. Außerdem ist die Variable anzahl überflüssig und auch shr 1 ist etwas günstiger als div 2.
Da die Bilderzeugung mittlerweile schon ziemlich schnell ist, sind 6 ms Zeitgewinn je Bild (Anfangsgröße) auf meinem PC scheinbar nicht viel. Es sind aber immerhin knapp 10 %.
Übrigens kostet das Zählen der Berechnungen auch noch 1 ms. Dennoch muss es erst einmal enthalten bleiben, bis eine Lösung gefunden ist, die mitunter überflüssigen Berechnungen auf Null zu bringen.

Ich werde jetzt unverschämt und setze das (unrealistische?) Ziel, weniger als 50 ms auf meinem langsamen Rechner zu erreichen. Im Moment sind es 56 ms. Nebenbei würde mich interessieren, ob die Berechnung und Darstellung eigentlich mit C# schneller wäre. Ich habe davon keine Ahnung.
Da es doch wieder ein deutliche Änderung ist, bedeutet das Revision 15. Ich verspreche keine weitere Revision 16, sagen wir, vor Mittwoch. :lol:

Beste Grüße
Mathematiker

_________________
Töten im Krieg ist nach meiner Auffassung um nichts besser als gewöhnlicher Mord. Albert Einstein
Horst_H
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 1647
Erhaltene Danke: 237

WIN10,PuppyLinux
FreePascal,Lazarus
BeitragVerfasst: Di 18.09.12 07:43 
Hallo,

ein paar kleine Bemerkungen:
Wie ich weiter oben erwähnte sind, kann die Logik, um unnötige Berechnungen aus zu schließen, mehr Zeit kosten, als die Berechnung selbst.
Eine Bitmap ist eine Null Basiertes Feld also von 0..Höhe-1/0..Breite-1.
Also muss das farbFeld entsprechend groß sein und nicht 1 breiter und höher.
Das geht auch wenn man die Startwerte richtig setzt.
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
      //Startwerte
      farbfeld[0,0]:=random(255)+1;
      farbfeld[hoehe-1,0]:=random(255)+1;
      farbfeld[0,breite-1]:=random(255)+1;
      farbfeld[hoehe-1,breite-1]:=random(255)+1;


Mich hat schon "früher" gestört, das bei der crt -Routine GotoXY ( Spalte,Zeile) war, aber im Bildschirmspeicher (MemW[B8000:Zeile*Spaltenbreite+Spalte] es genau andersherum ist.Eben passend zur zeilenweise Ausgabe des Bildes auf dem Fersehbildschirm=CRT mit dem Elektronenstrahl .
Bitmaps sind auch so gespeichert, vielleicht erkennbar an scanline.
Das GotoXY hast Du unwissentlich beibehalten bei Farbfeld.
Das bedeutet aber , dass Punkte, die horizontal nebeneinanderliegen, im Speicher immer um Breite versetzt sind und bei Verwendung eines zweidimensionalen dynamischen Feldes auch sonstwo liegen können, aber mindestens um Breite+Konstant versetzt.
Dadurch wird die Zuweisung des FarbFeld-> Bitmap gebremst, weil die Daten nicht schön nebeneinander mit maximaler Geschwindigkeit aus dem Cache gelesen werden, sondern ständig aus dem Hauptspeicher oder Level2/3 Cache nachgeladen werden müssen.Deshalb ist das auf dem Notebook bei mir wesentlich langsamer.

Lange Rede keinen Sinn:
Ich würde alle farbFeld Änderung auf Hoehe/Breite umstellen.
ausblenden Delphi-Quelltext
1:
setlength(farbfeld,paintbox1.height,paintbox1.Width);					

und dazu den Aufruf von Fenster ändern, y bleibt ja Höhe.
procedure fenster(ya,ye,xa,xe:integer);
Innerhalb von fenster müssen dann alle x und y bei Farbfeld getauscht werden.Z.B.:
ausblenden Delphi-Quelltext
1:
2:
3:
4:
farbe1:=farbmitte(pixel1,pixel3,dy);
             farbfeld[xa,ym]:=farbe1;
in
             farbfeld[ym,xa]:=farbe1;

Ob das wesentlich schneller ist kann ich jetzt nicht testen, da ich noch mit Lazarus hadere, um scanline hin zu bekommen.Dort kann man auch direkt auf die BitMap zugreifen mit Bitmap.RawImage.Data;
ausblenden volle Höhe Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
procedure TForm1.InsBildKopieren(Sender: TObject);
var
  i,j,index:integer;
  pfF,pPix:pByte;
begin

{$IFDEF FPC}
  pPix:= Bitmap.RawImage.Data;
  for i:=0 to paintbox1.height-1 do
    begin
    pfF := @farbfeld[i,0];
    for j:=0 to paintbox1.width-1 do
      begin
      index := pfF^;
      IF index <> 0 then
        begin
        index := (index + cyclestart);
        IF Index > 255 then
          dec(Index,254);
        end;
      inc(pfF);
      with pal[index] do
        begin
        pPix^:= r;inc(pPix);
        pPix^:= g;inc(pPix);
        pPix^:= b;inc(pPix);
        // bitmap.canvas.pixels[i,j]:=rgb(r,b,g);
        end;
      end;
    end;

{$ELSE}

Irgendwie schreibt das Programm nur Daten, wenn die Form verändert wird, sehr kurios.Mal schauen, wo ich den Fehler mache.

Meine Version von Fenster, kannst Du getrost entfernen, die ist nicht schneller.

Hier ein Link, der etwas wesentlich beschleunigen könnte:
www.pjh2.de/delphi/a...s/graphic/bitmap.php
wenn man die Bitmap als 8Bit- Paletten Bitmap anlegt, braucht man nur deren Palette ändern/ um eine Position verschieben und nicht jeden einzelnen Punkt.( Bei FullHd fast 2 Mio )
Siehe dort
www.pjh2.de/delphi/a.../bitmap.php#Methode1

Ich versuche das mit der Palette mal das umzusetzen.

Mein Versuch mittels Getmem(pFarbFeld,Breite*Hoehe) mir dynamische 2-dimensionale Feld zu sparen, ist kläglich gescheitert.
In Freepascal, bekomme ich eine Adresse in pFarbfeld und es funktioniert und mit Lazarus zeigt pFarbfeld auf $1 und das sofort einen Zugriffsfehler.
Wahrscheinlich hat die Unit Windows ( nur wegen queryperformancecounter ) auch ein getmem. Ärgerlicher Kram das...

Gruß Horst

Für diesen Beitrag haben gedankt: Mathematiker
OlafSt
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Beiträge: 459
Erhaltene Danke: 90

Win7, Win81, Win10
Tokyo, VS2017
BeitragVerfasst: Di 18.09.12 12:37 
user profile iconMathematiker hat folgendes geschrieben Zum zitierten Posting springen:
Nebenbei würde mich interessieren, ob die Berechnung und Darstellung eigentlich mit C# schneller wäre. Ich habe davon keine Ahnung.


Auf keinen Fall. C# wird in einen Zwischencode übersetzt (IL genannt). Anschließend wird dieser IL-Code vom JIT-Compiler interpretiert und ausgeführt. Zweifellos ist der JITC, den Microsoft da gebaut hat, schnell wie die Sünde, ändert aber nichts daran.

Ergo: Es kann, genauso wie Java, unmöglich so schnell sein wie direkter Binärcode.

_________________
Lies, was da steht. Denk dann drüber nach. Dann erst fragen.
Horst_H
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 1647
Erhaltene Danke: 237

WIN10,PuppyLinux
FreePascal,Lazarus
BeitragVerfasst: Di 18.09.12 13:05 
Hallo,

bezüglich C#.
Bei softgames/developia gab in einem Forum mal eine Diskussion, 4 gewinnt möglichst schnell auf Gewinn zu testen.
Es lief dann darauf hinaus, das 6x7 Feld als als 3 Int64 ( einmal Rot/gelb und Vereinigungsmenge) aufzufassen und einfach alle Möglichenkeiten mittels einer Maske zu testen.
Mit Java dauerte ein Test im Schnitt 10 Takte. In der Art
For i := 0 to 52 do
IF SpielfeldRot AND Maske[i]= Maske[i] ...

Das fand ich sehr schnell, weiß aber nicht mehr, ob es auf einem 64-Bit Betriebssystem lief

Gruß Horst
Delphi-Laie
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 1586
Erhaltene Danke: 231


Delphi 2 - RAD-Studio 10.1 Berlin
BeitragVerfasst: Di 18.09.12 13:42 
user profile iconOlafSt hat folgendes geschrieben Zum zitierten Posting springen:
user profile iconMathematiker hat folgendes geschrieben Zum zitierten Posting springen:
Nebenbei würde mich interessieren, ob die Berechnung und Darstellung eigentlich mit C# schneller wäre. Ich habe davon keine Ahnung.


Auf keinen Fall. C# wird in einen Zwischencode übersetzt (IL genannt). Anschließend wird dieser IL-Code vom JIT-Compiler interpretiert und ausgeführt. Zweifellos ist der JITC, den Microsoft da gebaut hat, schnell wie die Sünde


Ist das jetzt Ironie? Ich vermute, eher nicht.

Ich weiß nicht genau, ob dier IL-Code schon bei der Programmerstellung oder erst beim Programmstart erzeugt wird, nach meiner Kenntnis ersteres. Wird das Programm gestartet, muß natürlich erst einmal dieser Zwischencode compiliert werden. Klar, das dauert ein wenig, aber danach liegt doch ein vollwertiges Compilat vor, an dem man dann nach Herzenslust die Sündengeschwindigkeit genießen kann.


Zuletzt bearbeitet von Delphi-Laie am Di 18.09.12 18:43, insgesamt 1-mal bearbeitet
Mathematiker Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Quizmaster
Beiträge: 2615
Erhaltene Danke: 1421

Win 7, 8.1, 10
Delphi 5, 7, 10.1
BeitragVerfasst: Di 18.09.12 18:24 
Hallo Horst_H,
user profile iconHorst_H hat folgendes geschrieben Zum zitierten Posting springen:
Ich würde alle farbFeld Änderung auf Hoehe/Breite umstellen.

Wie immer eine tolle Idee. Obwohl ich skeptisch war, habe ich es ausprobiert und es ist tatsächlich wieder 2 ms schneller.
Du hast zwar ausführlich erklärt, warum es schneller sein muss, ich verstehe es auch, bin aber doch verwundert.
Für die Zukunft heißt das also auch bei anderen Projekten genau zu überlegen, welche Koordinate usw. bei einem zweidimensionalen Feld zuerst steht. Irgendwie verrückt. :eyecrazy:

Deinen zweiten Hinweis mit der Palette habe ich schon einmal gesehen. Ich werde es ausprobieren. Vielleicht ergibt sich damit ein Vorteil bei der abchließenden Erzeugung des Bildes.
Bezugnehmend auf Deinen Hinweis bei den 2 Matherätseln: Ja es sind einige "Baustellen". Meine Erfahrung ist aber, dass man das eine oder andere Problem, z.B. p196, erst einmal einige Zeit ruhen lässt, bis man wieder eine neue Idee hat. :zwinker:
Beim Plasma nähern wir uns ja auch dem Optimum, d.h. bald ist es eine Baustelle weniger.

Beste Grüße
Mathematiker

_________________
Töten im Krieg ist nach meiner Auffassung um nichts besser als gewöhnlicher Mord. Albert Einstein
Mathematiker Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Quizmaster
Beiträge: 2615
Erhaltene Danke: 1421

Win 7, 8.1, 10
Delphi 5, 7, 10.1
BeitragVerfasst: Di 18.09.12 20:45 
Hallo an alle Mitstreiter,

:beer: Geschafft! Weniger als 50 ms je Bild! :beer:

Durch die kleine Änderung am Ende der Fenster-Methode
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
        if uy then begin
          farbe5:=(farbe1+farbe2+farbe3+farbe4) shr 2;
          farbfeld[ym,xm]:=farbe5;
          //rekursive Konstruktion
          fenster(xa,xm,ya,ym);
          fenster(xm,xe,ya,ym);
        end;
        fenster(xa,xm,ym,ye);
        fenster(xm,xe,ym,ye);

und das Entfernen der Berechnungszählung bekomme ich jetzt Zeiten von etwas mehr als 48 ms bei der Startfenstergröße. Die Berechnung allein erfolgt in etwa 29 ms, der Rest wird für die Bitmapkonstruktion gebraucht. Zu Beginn dieses Programms waren es insgesamt etwa 8400 ms für ein Bild!
Außerdem werden bei einem Bild mit Breite>Höhe keine Punktberechnungen mehr zu viel durchgeführt; für Höhe>Breite ein paar, die aber kaum bremsen. Untersucht man unterschiedliche Bildgrößen zeigt sich, dass die Berechnungszeit proportional zur Pixelzahl wächst, wie es auch sein soll.
Das Ergebnis stelle ich als Revision 16 ein, obwohl ich keine neue Variante vor Mittwoch versprochen hatte. :P

Ich danke allen, die hier fleißig mitgeholfen haben. :wave:
Zwar soll man nie sagen, dass es nicht mehr besser geht, dennoch glaube ich, wir haben vorerst das Optimum erreicht.
Eure Ideen sind weiterhin sehr willkommen. Vielleicht geht's ja noch schneller: 40 ms, 30 ms, 20 ms, 10 ms, ...

Beste Grüße
Mathematiker

_________________
Töten im Krieg ist nach meiner Auffassung um nichts besser als gewöhnlicher Mord. Albert Einstein
Horst_H
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 1647
Erhaltene Danke: 237

WIN10,PuppyLinux
FreePascal,Lazarus
BeitragVerfasst: Mi 19.09.12 08:32 
Hallo,

endlich habe ich in Lazarus/FPC den Scanline Ersatz gefunden, die auch wirklich neuzeichnet.
BeginUpdate und EndUpdate war die Lösung.

ausblenden volle Höhe Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
procedure TForm1.InsBildKopieren;
var
  i,j,index:integer;
  pfF,pPix:pByte;
  rowrgb : pbytearray;
  BitmapRawData :ptrUint;
  delta : ptrUint;//DWord;
begin
  Bitmap.BeginUpdate();
  // Abstand Zeile n bis Zeile n+1 bei pf24Bit= 3 Byte aufgerundet auf 32Bit-Teilbarkeit
  // So sind Bitmap definiert.
  {$IFDEF FPC}
  delta := ((Bitmap.Width*3-1)DIV 4+1)*4;
  BitmapRawData:= ptrUint(Bitmap.RawImage.Data);
  {$ENDIF}
  for j:=0 to bitmap.height-1 do
    begin
    {$IFDEF FPC}
    pPix := pbyte(BitmapRawData+j*delta);
    {$ELSE}
    pPix:= pbyte(bitmap.scanline[j]);
    {$ENDIF}
    pfF := @FarbFeld[j,0];
    for i:=0 to bitmap.width-1 do
      begin
      index := pfF^;

      IF index <> 0 then
        begin
        index := (index + cyclestart);
        IF Index > 255 then
          dec(Index,254);
        end;
      inc(pfF);
      with pal[index] do
        begin
        pPix^:= r;inc(pPix);
        pPix^:= g;inc(pPix);
        pPix^:= b;inc(pPix);
        end;
      end;
    end;
  Bitmap.EndUpdate();
  paintbox1.canvas.draw(0,0,bitmap);
end;

Diese Konstrukt sieht etwas seltsam aus, aber in früheren Versionen sollte 0 immer 0 bleiben sollte und die anderen Werte sich von 1..255 ändern können.
Aber 0 kommt bei der Erzeugung garnicht vor, Farbmite ist ja immer >= 1.
Das kostet also wenig Zeit, da die Sprungvorhersage funktioniert.
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
      index := pfF^;

      IF index <> 0 then
        begin
        index := (index + cyclestart);
        IF Index > 255 then
          dec(Index,254);
        end;


Eine kleine Abwandlung:
Ich berechne den Rand zuerst und spare ein paar IF/ Sprünge, ein falscher Sprung kostet mich ja 20 Takte.
ausblenden volle Höhe Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
45:
46:
47:
48:
49:
50:
51:
52:
53:
54:
55:
56:
57:
58:
59:
60:
61:
62:
63:
64:
65:
66:
67:
68:
69:
70:
71:
72:
73:
74:
75:
76:
77:
78:
79:
80:
81:
82:
83:
84:
85:
86:
87:
88:
    {$ELSE}
    //Mittelwert der Farben berechnen
    function farbmitte(f1,f2,abweich: integer): integer;
    begin
      result := (f1+f2) shr 1;
      IF abweich > 0 then
        result:=max(1,(result + random(abweich) - abweich shr 1AND 255)
    end;
    {$ENDIF}

    procedure fensterX0(ya,ye:integer);
    var
      ym,dy:integer;
    begin
      IF ye-ya > 1 then
        begin
        dy := (ye-ya)*faktor;
        ym := (ya+ye) shr 1;
        farbfeld[ym,0] :=farbmitte(farbfeld[ye,0],farbfeld[ya,0],0);
        fensterX0(ya,ym);
        fensterX0(ym,ye);
        end;
    end;

    procedure fensterY0(xa,xe:integer);
    var
      xm,dx:integer;
    begin
      IF xe-xa > 1 then
        begin
        dx := (xe-xa)*Faktor;
        xm := (xa+xe) shr 1;
        farbfeld[0,xm] :=farbmitte(farbfeld[0,xe],farbfeld[0,xa],0);
        fensterY0(xa,xm);
        fensterY0(xm,xe);
        end;
    end;


    procedure fenster(xa,xe,ya,ye:integer);
    var
        xm,ym,dx,dy:integer;
        sum:word;
        ux,uy:boolean;
        pixel2,pixel3,pixel4,farbe:byte;

    begin
        if (xe-xa<2and (ye-ya<2then
           EXIT;

        //Diamond-Square-Algorithmus
        xm:=(xa+xe) shr 1;
        ym:=(ya+ye) shr 1;

        pixel2:=farbfeld[ya,xe];
        pixel3:=farbfeld[ye,xa];
        pixel4:=farbfeld[ye,xe];

        dy:=(ye-ya)*faktor;
        dx:=(xe-xa)*faktor;
        if waagerecht then ux:=xm<xe
                      else ux:=xm>xa;
        uy:=ym>ya;

        sum :=farbfeld[ya,xm]+farbfeld[ym,xa];

        if uy then begin
          farbe:=farbmitte(pixel2,pixel4,dy);
          farbfeld[ym,xe]:=farbe;
          inc(sum,farbe);
        end;

        if ux then begin
          farbe:=farbmitte(pixel3,pixel4,dx);
          farbfeld[ye,xm]:=farbe;
          inc(sum,farbe);
        end else exit;

        if uy then begin
          farbfeld[ym,xm]:=sum shr 2;;

          fenster(xa,xm,ya,ym);
          fenster(xm,xe,ya,ym);
        end;

        fenster(xa,xm,ym,ye);
        fenster(xm,xe,ym,ye);
     end;

Ich brauche mit Lazarus auf meinem Rechner jetzt 84,5 ms für 1,808e6 Bildpunkte.
Sind immer noch 150 Takte/pro Pixel.Wow , ganze 6 Takte schneller ;-)
Das Kopieren in die Bitmap und anschliessende Ausgabe kosten 32 ms.Das liegt aber auch daran, das meine Grafikkarte; wie wohl bei den meisten, auf pf32Bit eingestellt ist.
Man kann seinen Rechner auch ärgern ;-) , indem man alle 3 Byte was abholt statt 1,2,4,8,16-byte mäßig.
Mein Vorschlag: pal wieder in vfarben umwandeln und dann mit pf32bit arbeiten.
Dann wird pPix ein Zeiger auf ein integer und vFarben in eins kopiert.

Mal schauen, was das bringt.

Gruß Horst
EDIT1:
Das war ja ein Reinfall.Nichts, niente, nada .
paintbox1.canvas.draw(0,0,bitmap); braucht alleine 17 der 32 ms, auch bei pf32bit.
Mathematiker Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Quizmaster
Beiträge: 2615
Erhaltene Danke: 1421

Win 7, 8.1, 10
Delphi 5, 7, 10.1
BeitragVerfasst: Mi 19.09.12 16:15 
Hallo Horst_H,
user profile iconHorst_H hat folgendes geschrieben Zum zitierten Posting springen:
Ich berechne den Rand zuerst und spare ein paar IF/ Sprünge, ein falscher Sprung kostet mich ja 20 Takte.

Die Idee ist nicht schlecht. Ich habe das ausprobiert und es bringt bei mir etwa eine halbe Millisekunde.

Übrigens habe ich heute einmal, probeweise, Lazarus installiert. Sieht gut aus!
Allerdings habe ich den Eindruck, dass es noch komplizierter ist als mein Delphi 5, und vor allem das Compilieren dauert ziemlich lange. Interessant ist es aber. Im Moment habe ich noch keine Möglichkeit gefunden, ein Delphi-Projekt zu laden, das finde ich aber noch.

Beste Grüße
Mathematiker

_________________
Töten im Krieg ist nach meiner Auffassung um nichts besser als gewöhnlicher Mord. Albert Einstein
Horst_H
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 1647
Erhaltene Danke: 237

WIN10,PuppyLinux
FreePascal,Lazarus
BeitragVerfasst: Mi 19.09.12 17:14 
Hallo,

Projekt -> schliessen und dann erscheint schon in der Auswahl, Delphi-Projekt umwandeln.
Ja, Lazarus ist beim starten/komplieren sehr lahm, da werden zig units durchgeorgelt..
Keine Sorge, das Kompilat ist meist langsamer, aber hoffentlich sind die Zeiten vorbei, wo die äussere von drei Schleifen ein Register belegt und die Daten ständig aus dem Speicher/in den Speicher und so weiter geschoben werden, weil die Register knapp sind.Da hilft es enorm, die innere Schleife in eine extra Prozedur zu packen.

Gruß Horst
Delphi-Laie
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 1586
Erhaltene Danke: 231


Delphi 2 - RAD-Studio 10.1 Berlin
BeitragVerfasst: Mi 19.09.12 20:58 
user profile iconHorst_H hat folgendes geschrieben Zum zitierten Posting springen:
Projekt -> schliessen und dann erscheint schon in der Auswahl, Delphi-Projekt umwandeln.


Eine mögliche und bequeme, aber leider in einer Beziehung ziemlich schlechte Variante, weil es die berüchtigten Riesencompilate erzeugt.

Besser ist ein compilatsgrößenminimiertes (mit den entsprechenden Einstellungen) Projekt zu laden und diesem die benötigten Projektinformationen "manuell" beizubringen. Oder man kennt sich wirklich mit allen relevanten Projekteinstellungen aus (ich gehöre nicht zu diesem elitären Kreise):


Zuletzt bearbeitet von Delphi-Laie am Mi 19.09.12 21:51, insgesamt 1-mal bearbeitet
Mathematiker Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Quizmaster
Beiträge: 2615
Erhaltene Danke: 1421

Win 7, 8.1, 10
Delphi 5, 7, 10.1
BeitragVerfasst: Mi 19.09.12 21:37 
Hallo Horst_H,
ich muss noch einmal auf
user profile iconHorst_H hat folgendes geschrieben Zum zitierten Posting springen:
Ich berechne den Rand zuerst und spare ein paar IF/ Sprünge, ein falscher Sprung kostet mich ja 20 Takte.

zurückkommen.
Ich habe jetzt jeweils 1000 Bilder, einmal mit besonderer Berechnung der Randpunkte und einmal ohne, erzeugen lassen. Ich war etwas vorschnell, mit der Aussage, dass die externe Berechnung des linken und oberen Randes beschleunigt, zumindest nicht unter meinem Delphi 5 auf meinem PC.
Deine neue Idee finde ich immer noch überzeugend, aber aus einem mir noch nicht ganz klaren Grund, wird es sogar etwas, nicht viel, langsamer. Ich vermute, dass die Erhöhung der Zahl der rekursiven Aufrufe bremst. Bisher wurden zwar für jeden Nichtrandpunkt zwei überflüssige Tests durchgeführt, aber insgesamt weniger oft die fenster-Routine aufgerufen.
Irgendwie finde ich es trotzdem seltsam.

Beste Grüße
Mathematiker

PS: Meine ersten Versuche mit Lazarus sind nicht so gut gelaufen, wie erhofft. Vor allem "nervt" mich die lange Compilierzeit. Da der erste Eindruck angeblich der beste ist, bin ich ziemlich frustriert.

_________________
Töten im Krieg ist nach meiner Auffassung um nichts besser als gewöhnlicher Mord. Albert Einstein
Delphi-Laie
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 1586
Erhaltene Danke: 231


Delphi 2 - RAD-Studio 10.1 Berlin
BeitragVerfasst: Mi 19.09.12 21:57 
user profile iconMathematiker hat folgendes geschrieben Zum zitierten Posting springen:
PS: Meine ersten Versuche mit Lazarus sind nicht so gut gelaufen, wie erhofft. Vor allem "nervt" mich die lange Compilierzeit. Da der erste Eindruck angeblich der beste ist, bin ich ziemlich frustriert.


Dann bist Du also ein ähnlicher Umweltfreund wie ich und benutzt einen älteren Computer, anstatt Dir den neuesten und schnellsten zu kaufen. Ich lasse Lazarus compilieren und tue während der Zeit etwas anderes (z.B. in der Entwickerecke zu surfen ;-) ). Ist fast wie in der Computerfrühzeit.

Mit der Compilatsgröße läßt sich die Compilierzeit auch marginal beeinflussen, weil kleinere Compilate nun einmal schneller geschrieben werden (können). Vieles weitere kann man bei Lazarus einstellen, jedoch kann man, wenn man sich alles mögliche beim Compilieren anzeigen läßt, die Compilierzeit bis fast unendlich steigern, bei Abschalten der wichtigen Dinge, was nicht ratsam ist, wird es natürlich marginal schneller. Auch sonst muß man sich an einiges gewöhnen. Weil der Compiler aber empfindlicher gegenüber Quelltextunsauberkeiten ist (Delphi ist in der Beziehung toleranter), zwingt er auch zu größerer Sorgfalt. Letztlich ergänzen sich beide (Delphi und Lazarus/FPC), und es kann generell nicht schaden, den Quelltext für den einen dem jeweils anderen vorzusetzen (sich sozusagen eine zweite Expertenmeinung einzuholen).

Für diesen Beitrag haben gedankt: Mathematiker
Mathematiker Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starhalf ontopic starofftopic star
Quizmaster
Beiträge: 2615
Erhaltene Danke: 1421

Win 7, 8.1, 10
Delphi 5, 7, 10.1
BeitragVerfasst: So 28.08.16 16:09 
Hallo,
bei den ersten Versuchen mit Delphi 10.1 habe ich auch die Plasmadarstellung testen wollen. Unter D5 und D7 läuft alles problemlos, bei Delphi 10.1 kommt aber eine Exception
fehler
in der Assemblerroutine
ausblenden Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
 //Mittelwert der Farben berechnen
    function farbmitte(f1,f2,abweich: integer): integer;
    asm
         shr ecx, 1
         add eax, edx       //(f1+f2) div 2
         shr eax, 1
         cmp ecx, 1
         jbe @ohnea         //abweich < 2
         push eax           //(f1+f2) div 2 speichern
         xor edx, edx       //Zufallsgenerator
         mov eax, ecx       //Initialisierung auf 0 bis abweich
         imul edx, [randseed], $08088405
         inc edx
         mov [randseed], edx
         mul edx
         mov eax, edx       //in eax steht zufallswert [0,abweich-1]
         pop edx            //(f1+f2) div 2 zurückholen
         add eax, edx       //Addition (f1+f2) div 2
         shr ecx, 1         //abweich div 2
         sub eax, ecx       //subtraktion abweich div 2
         jc @null
         @ohnea: and eax, 255       //mod 256
         cmp eax, 0         //Test auf Null
         jz @null
         ret               //HIER KOMMT DIE EKCEPTION            
         @null: mov eax, 1
       end;

Da ich nur rudimentäre Kenntnisse von ASM habe, bin ich etwas ratlos.
Sieht jemand den Fehler?

Danke für jeden Hinweis
Mathematiker
Einloggen, um Attachments anzusehen!
_________________
Töten im Krieg ist nach meiner Auffassung um nichts besser als gewöhnlicher Mord. Albert Einstein


Zuletzt bearbeitet von Mathematiker am So 28.08.16 18:59, insgesamt 1-mal bearbeitet
Delphi-Laie
ontopic starontopic starontopic starontopic starontopic starontopic starofftopic starofftopic star
Beiträge: 1586
Erhaltene Danke: 231


Delphi 2 - RAD-Studio 10.1 Berlin
BeitragVerfasst: So 28.08.16 16:41 
In bezug auf Assembler bin ich ein mindestens ebensolcher Analphabet wie Du, vermutlich noch heftiger.

Aber zwei Fragen fallen mir spontan ein:

1. 32- oder 64-Bit-Compilat?
2. Schon mit Debuggen versucht?