sehr schnelle, einfache und ressourcensparende Grafik

[aro]

Ich habe die letzten Jahrzehnte meines Berufslebens als Softwareentwickler gearbeitet. Heute betreibe ich das ganze noch, weil es mir Spaß macht, um meine grauen Zellen zu trainieren und um meine Erkenntnisse nicht mit in die Kiste zu nehmen. Deshalb habe ich mich auch entschlossen meine Ergebnisse zu veröffentlichen, in der Hoffnung, das es anderen nützt.

Leider besteht ein Trend, die Software so aufzublähen, das immer leistungsfähigere Hardware notwendig wird. Wenn sich am Anfang Intel und Microsoft gegenseitig den Ball zugeworfen haben, hat das Beispiel inzwischen leider Schule gemacht. Objektorientierte Programmierung ist eine gute und nützliche Erfindung, aber man kann das ganze auch zur Perversion treiben, um den Prozessor so richtig zum Schwitzen zu bringen.
Ich bin mir, an Hand der Fragestellungen im Forum relativ sicher, das der übergroße Anteil der Mitglieder glücklich ist, wenn er die gelieferten Komponenten zu Laufen bekommt und noch nie ernsthaft versucht hat die Quelltexte zu verstehen. Aber vielleicht kann ich doch den Einen oder Anderen zum Nachdenken bewegen.

Die Grafik benötigt im Verhältnis zu anderen Aufgaben, einen hohen Anteil der Ressourcen, weshalb man hier auch richtig den Turbo anzusetzen kann.

Grafikprogrammierung auf dem PC könnte so schnell und einfach sein - wenn man denn nur wollte.

Da der Beitrag den Rahmen der sonst üblichen Größe sprengen würde, habe ich alles, von der Beschreibung bis zum Quelltext in den Anhang gepackt.

[af0815]

Willst du das nicht auf einer populären Softwareplattform veröffentlichen ?

[aro]

Hallo,

hast Du da einen heißen Tip ?

[af0815]

Nein, keinen heissten Tip.

Github, Sourceforge,...

Ich selbst verwende primär Github, habe aber auch noch was auf Sourceforge.

[six1]

Ich verstehe, was du meinst.
Anfangs war ich nur auf kleinen Controllern unterwegs, selbst zusammengestrickt mit Latches, Ram, EEproms usw.
Da hat man jedes Bit gezählt und umgedreht.
Als ich dann in Windows anfing zu programmieren, hat man die Bitzählerei wohl als erstes über Bord geworfen...
Was möglich ist, wenn man "Hardwarenah" programmiert, ist erstaunlich.
Ich habe mal für ATMega und XMega eine Lib geschrieben, welche 2D und 3D Darstellungen ermöglicht.
https://youtu.be/wSR0QSfzf28

Auch AVI Videos mit einem ATMega in Farbe mit Sound abzuspielen habe ich so geschafft.
https://youtu.be/rljj1rjgs-c

Das Cliping im Video habe ich durch einen vorberechnete Tabelle für die Farben später gelöst.

Man ist dann eben Hardwarenah und nur noch mit sich selbst kompatibel

[mschnell]

Bei dem Thema muss berücksichtigt werden, ob die Hardware über einen zusätzlichen Videoprozessor verfügt.
-Michael

[aro]

Hallo,

Bei dem Thema muss berücksichtigt werden, ob die Hardware über einen zusätzlichen Videoprozessor verfügt.

Das stimmt so nicht.

Die Variante, die ich veröffentlicht habe läuft auf jedem Notebook oder PC. Das man hardwarenah, beispielsweise für de Raspi, nochmal zusätzlich wesentlich mehr rausholen kann ist ein ganz anderes Thema. Auch das Betriebssystem spielt für meine Lösung prinzipiell überhaupt keine Rolle!

Mein einziges Problem ist, das ich unter WINDOWS nie mit Lazarus gearbeitet habe, da ich Delphi hatte. Und jetzt kann ich meine Quelltexte nicht mehr unter WINDOWS testen, weil WINDOWS für mich unwiderruflich gestorben ist.

Mir geht es ausschließlich darum aufzuzeigen zu welchen Perversionen sich die Software entwickelt hat und praktikable Wege zurück zu gesundem Menschenverstand aufzuzeigen.
Wer sich dafür interessiert ist bei mir herzlich willkommen. Und wer gedankenlos hinter der Masse hinterher laufen will der soll es doch tun.

Ich weis, das ich an der Entwicklung nichts mehr ändern kann. Mit meiner Generation stirbt sowieso eine vernünftige Schulbildung für die Allgemeinheit aus. Wenn ich daran denke was ich in der Schule gelernt habe und sehe, was aber vor allem wie meine Enkel in der Schule lernen, habe ich alle Hoffnung längst aufgegeben. Aber ich denke, das will hier sowieso niemand hören.

[mschnell]

Je nachdem was Du für eine Grafik darstellen willst..
Ein gefülltes Rechtech geht mit einer GPU blitzartig und verbraucht fast keine CPU Zeit . Wenn Du es ohne Benutzung der GPU Pixelweise in die Hardware schaufelst dauert es viel länger. Wenn Du eine Hardware ohne GPU (mit reinem Memory-Array als Bild-Speicher) verwendest geht es bitweise viel schneller, als wäre da eine GPU.
Wenn Bewegung im Spiel ist wird es noch komplexer.
Was man vermutlich eigentlich will, ist ein auf die jeweilige Hardware optimierter OPEN GL-Treiber.
-Michael

[aro]

Hallo,

Eine GPU, die unabhängig von der CPU die eigentliche Arbeit erledigt, wäre natürlich perfekt. Aber das wird nur mit neuester Technik funktionieren. Es soll ja für WINDOWS Spiele geben, für die man spezielle Grafikkarten benötigt, sonst geht gar nichts. Und neueste Hardware ist unter LINUX nicht unbedingt die beste Wahl.

Ich gehe davon aus, das die meisten TImage und TBitmap verwenden, um ein Bild auf einem Formular darzustellen. Da wird zur Zeit lange und breit diskutiert, wie man einen bestimmten Button ohne Rand aufs Formular bekommt. Gerade für solche Fälle habe ich meine Grafik entwickelt. Ich zaubere jedes Bild aufs Formular. Und blitzschnell beim Klick ein anderes Bild darüber zu kopieren, um den anderen Status anzuzeigen - warum denn nicht ? Und wer unbedingt Komponenten aus der Palette so lange verändern möchte, bis sie wie gewünscht aussehen, der soll es doch gerne tun.

Wenn Bewegung im Spiel ist wird es noch komplexer.

Gerade bewegte Teile in meinem Hintergrund war eine Hauptaufgabe in meinen Projekten. Durch das schnelle kopieren meiner Grafik auf die jeweils nächste Position kann man Bewegung sehr realistisch darstellen. Man darf natürlich nicht vergessen, das Hintergrundbild in der Spalte oder Zeile aus der die Kopie verschoben wurde, zu aktualisieren. Das geht selbst auf lahmer Hardware schneller als das Auge folgen kann! Und wenn man den Alphakanal für den wandernden Bildausschnitt verwendet kann man sogar diese Bilder transparent einblenden. Man muss ja nur den Bereich zum Bildschirm senden der sich gerade verändert hat.

[mschnell]

Aber das wird nur mit neuester Technik funktionieren.

Stimmt.
Aber diese "neuste Technik" ist inzwischen der absolute Standard für alle Hardware, die ein Betriebssystem fahren kann. Z.B. ein RasPi für 30 Euro. Deshalb kann man sowas auch bei recht "kleinen" Anwendungen fast immer voraussetzen.
BTW.: Ich habe vor ein paar Jahren viel Zeit investiert um einen Lazarus "Widget-Type" "active_NoGui" zu bauen (Keine GUI, aber Timer und TThread.Synchronize, TThread.Queue etc) damit man auf sehr kleinen Linux System(ohne QT oder GTK) kompatibel und komfortabel komplexe Programme erstellen kann. Hat sich aber erledigt, da inzwischen quasi alle Linux-Systeme über Hardware-unterstütze Grafik verfügen.
-Michael (zwar kein Enkel aber immerhin 67 )

[aro]

Hallo,

Hat sich aber erledigt, da inzwischen quasi alle Linux-Systeme über Hardware-unterstütze Grafik verfügen.
-Michael (zwar kein Enkel aber immerhin 67 )

Das ist zwar alles schön und gut, bringt mich aber nicht wirklich weiter.

Broadcom soll angeblich sogar eine ausführliche Dokumentation über die GPU herausgebracht haben. Ich weis nicht wie oft ich danach schon gesucht habe. Entweder kam Reklame für irgend welche Bücher oder Dokument nicht gefunden.

Ich habe noch nicht ein vernünftiges Beispiel gefunden nach dem Prinzip, wenn du z.B. einen Kreis zeichnen willst, dann muss dieses oder jenes eingegeben werden. So lange die Nutzung der GPU für mich nicht nachvollziehbar ist nützt mir die schöne neue Technik nichts.

[Winni]

Hi!

Anbei die VideoCoreIV-AG100 PDF, die Broadcom immer wieder woanders versteckt hat.

Deshalb als Attachment und nicht als Link.

Winni

[thosch]

Klasse Arbeit. Ich sehe das genau so wie Du, aro. Werde den Fortgang Deiner Arbeit daher mit großem Interesse verfolgen. Ich sehe auch nicht ein, warum ich mir alle Jubeljahre einen neune Rechner kaufen soll, nur weil die Programmierer entweder zu bequem oder zu geldgeil sind (Rechner zum Programm dazu verkaufen), die Programme so reccourcensparend zu programmieren, dass sie auch auf betagteren Rechnern noch flüssig laufen.

Habe aber im Quellcode festgestellt, dass die Unit BaseUnix verwendet wird, und zwar von der Unit aroclasses. Bei den Units BGRABitmapTypes und BGRABitmap bin ich mir auch nicht wirklich sicher dass da nicht irgendwelche Linux oder Windows spezifischen Teile enthalten sind. Und ist denn die Unit Forms systemunabhängig genug, ohne Windows- oder Linuxspezifika. Momentan bin ich in Windows, da BaseUnix gebraucht wird und nicht durch bedingte Compilierungsanweisungen ausgeklammert ist, kann ich erst morgen genauer testen. Da kann ich in Linux booten und von dort aus alles ausprobieren.

[Winni]

Hi!

BGRABitmapTypes und BGRABitmap regeln die OS- und Widgetset- Abhängigkeiten selbstständig.

Sieh Dir mal die {$IFDEF ..} Kaskaden in der Unit BGRAbitmap an.

Herrlich dass man sich um den Kram nicht kümmern muss!

Winni

[aro]

Hallo,

Deshalb als Attachment und nicht als Link.

Winni

Besten Dank.

Das wird natürlich ein Weilchen dauern, bis ich das übersetzt habe. Aber das ist schon mal der Anfang. Ob ich mir daraus etwas ableiten kann, so das ich wirklich die GPU dazu bringe für mich zu arbeiten werde ich sehen.

Wenn ich mich recht erinnere hatte der Raspi auch ein Register als Taktzähler mit dem man die Effektivität jeder Funktion exakt prüfen kann. Dann werde ich sehen was es bringt.