| 
| Autor | Beitrag |  
| OlafSt 
          Beiträge: 486
 Erhaltene Danke: 99
 
 Win7, Win81, Win10
 Tokyo, VS2017
 
 | 
Verfasst: 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  _________________ Lies, was da steht. Denk dann drüber nach. Dann erst fragen.
 |  |  |  
| Mathematiker  
          Beiträge: 2622
 Erhaltene Danke: 1448
 
 Win 7, 8.1, 10
 Delphi 5, 7, 10.1
 
 | 
Verfasst: Mo 17.09.12 11:02 
 
Hallo Delphi-Laie,
 	  |  Delphi-Laie hat folgendes geschrieben  : |  	  | 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?    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 
          Beiträge: 1600
 Erhaltene Danke: 232
 
 
 Delphi 2 - RAD-Studio 10.1 Berlin
 
 | 
Verfasst: 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  
          Beiträge: 2622
 Erhaltene Danke: 1448
 
 Win 7, 8.1, 10
 Delphi 5, 7, 10.1
 
 | 
Verfasst: Mo 17.09.12 17:03 
 
Hallo Delphi-Laie,
 	  |  Delphi-Laie hat folgendes geschrieben  : |  	  | 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.    Beste Grüße
 Mathematiker_________________ Töten im Krieg ist nach meiner Auffassung um nichts besser als gewöhnlicher Mord. Albert Einstein
 |  |  |  
| Delphi-Laie 
          Beiträge: 1600
 Erhaltene Danke: 232
 
 
 Delphi 2 - RAD-Studio 10.1 Berlin
 
 | 
Verfasst: 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  
          Beiträge: 2622
 Erhaltene Danke: 1448
 
 Win 7, 8.1, 10
 Delphi 5, 7, 10.1
 
 | 
Verfasst: Mo 17.09.12 22:00 
 
Hallo Delphi-Laie,
 	  |  Delphi-Laie hat folgendes geschrieben  : |  	  | 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
 		                       Quelltext 
 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.    Beste Grüße
 Mathematiker_________________ Töten im Krieg ist nach meiner Auffassung um nichts besser als gewöhnlicher Mord. Albert Einstein
 |  |  |  
| Horst_H 
          Beiträge: 1654
 Erhaltene Danke: 244
 
 WIN10,PuppyLinux
 FreePascal,Lazarus
 
 | 
Verfasst: 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.
 		                       Delphi-Quelltext 
 									| 1:2:
 3:
 4:
 5:
 
 |             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.
 		                       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.:
 		                       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;
 												| 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);
 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 
          Beiträge: 486
 Erhaltene Danke: 99
 
 Win7, Win81, Win10
 Tokyo, VS2017
 
 | 
Verfasst: Di 18.09.12 12:37 
 
	  |  Mathematiker hat folgendes geschrieben  : |  	  | 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 
          Beiträge: 1654
 Erhaltene Danke: 244
 
 WIN10,PuppyLinux
 FreePascal,Lazarus
 
 | 
Verfasst: 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 
          Beiträge: 1600
 Erhaltene Danke: 232
 
 
 Delphi 2 - RAD-Studio 10.1 Berlin
 
 | 
Verfasst: Di 18.09.12 13:42 
 
	  |  OlafSt hat folgendes geschrieben  : |  	  | 	  |  Mathematiker hat folgendes geschrieben  : |  	  | 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  
          Beiträge: 2622
 Erhaltene Danke: 1448
 
 Win 7, 8.1, 10
 Delphi 5, 7, 10.1
 
 | 
Verfasst: Di 18.09.12 18:24 
 
Hallo Horst_H,
 	  |  Horst_H hat folgendes geschrieben  : |  	  | 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.    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.    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  
          Beiträge: 2622
 Erhaltene Danke: 1448
 
 Win 7, 8.1, 10
 Delphi 5, 7, 10.1
 
 | 
Verfasst: Di 18.09.12 20:45 
 
Hallo an alle Mitstreiter,
  Geschafft! Weniger als 50 ms je Bild!   
 Durch die kleine Änderung am Ende der Fenster-Methode
 		                       Delphi-Quelltext 
 									| 1:2:
 3:
 4:
 5:
 6:
 7:
 8:
 9:
 
 |         if uy then beginfarbe5:=(farbe1+farbe2+farbe3+farbe4) shr 2;
 farbfeld[ym,xm]:=farbe5;
 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.     Ich danke allen, die hier fleißig mitgeholfen haben.    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 
          Beiträge: 1654
 Erhaltene Danke: 244
 
 WIN10,PuppyLinux
 FreePascal,Lazarus
 
 | 
Verfasst: 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.
 												| 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;begin
 Bitmap.BeginUpdate();
 {$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.
 		                       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.
 												| 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}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 1) AND 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<2) and (ye-ya<2) then
 EXIT;
 
 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  
          Beiträge: 2622
 Erhaltene Danke: 1448
 
 Win 7, 8.1, 10
 Delphi 5, 7, 10.1
 
 | 
Verfasst: Mi 19.09.12 16:15 
 
Hallo Horst_H,
 	  |  Horst_H hat folgendes geschrieben  : |  	  | 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 
          Beiträge: 1654
 Erhaltene Danke: 244
 
 WIN10,PuppyLinux
 FreePascal,Lazarus
 
 | 
Verfasst: 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 
          Beiträge: 1600
 Erhaltene Danke: 232
 
 
 Delphi 2 - RAD-Studio 10.1 Berlin
 
 | 
Verfasst: Mi 19.09.12 20:58 
 
	  |  Horst_H hat folgendes geschrieben  : |  	  | 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  
          Beiträge: 2622
 Erhaltene Danke: 1448
 
 Win 7, 8.1, 10
 Delphi 5, 7, 10.1
 
 | 
Verfasst: Mi 19.09.12 21:37 
 
Hallo Horst_H,
 ich muss noch einmal auf 
 	  |  Horst_H hat folgendes geschrieben  : |  	  | 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 
          Beiträge: 1600
 Erhaltene Danke: 232
 
 
 Delphi 2 - RAD-Studio 10.1 Berlin
 
 | 
Verfasst: Mi 19.09.12 21:57 
 
	  |  Mathematiker hat folgendes geschrieben  : |  	  | 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  
          Beiträge: 2622
 Erhaltene Danke: 1448
 
 Win 7, 8.1, 10
 Delphi 5, 7, 10.1
 
 | 
Verfasst: 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
   in der Assemblerroutine
 		                       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:
 
 |      function farbmitte(f1,f2,abweich: integer): integer;asm
 shr ecx, 1
 add eax, edx                shr eax, 1
 cmp ecx, 1
 jbe @ohnea                  push eax                    xor edx, edx                mov eax, ecx                imul edx, [randseed], $08088405
 inc edx
 mov [randseed], edx
 mul edx
 mov eax, edx                pop edx                     add eax, edx                shr ecx, 1                  sub eax, ecx                jc @null
 @ohnea: and eax, 255                cmp eax, 0                  jz @null
 ret                        @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 
          Beiträge: 1600
 Erhaltene Danke: 232
 
 
 Delphi 2 - RAD-Studio 10.1 Berlin
 
 | 
Verfasst: 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?
 |  |  |  |