Grafik in C (PI4) - Versionsgeschichte

Satyria am 6. März 2025 um 12:18 Uhr

2025-03-06T12:18:52Z

Änderungen zeigen

Satyria am 6. März 2025 um 12:09 Uhr

2025-03-06T12:09:25Z

Änderungen zeigen

Satyria: /* Abbildung der Bitmaps im Speicher */

2025-03-06T11:40:45Z

Abbildung der Bitmaps im Speicher

← Nächstältere Version		Version vom 6. März 2025, 12:40 Uhr
Zeile 68:		Zeile 68:

	[[Datei:Koordinaten4.png\|rand\|600x600px]]		[[Datei:Koordinaten4.png\|rand\|600x600px]]

	Wie hier zu sehen ist, wird für den ersten Bildschirmpunkt die Bits 0-15 verwendet. Der nächste Bildschirmpunkt die Bits 16-31 usw… Dies müssen wir bei Berechnungen jeden einzelnen Punktes später berücksichtigen.

	== Der Postbote und TAGs ==		== Der Postbote und TAGs ==

Satyria am 6. März 2025 um 11:39 Uhr

2025-03-06T11:39:53Z

← Nächstältere Version		Version vom 6. März 2025, 12:39 Uhr
Zeile 13:		Zeile 13:
	== Auflösungen ==		== Auflösungen ==

	Der Raspberry Pi ~~kennt~~ viele Auflösungen~~, die er unterstützt~~. Eine ~~große Auswahl kann~~ über https://de.wikipedia.org/wiki/Bildaufl%C3%B6sung#Computer ~~nachgeschlagen werden~~. ~~Folgende~~ Auflösungen ~~werde ich hierbei verwenden~~:		Der Raspberry Pi unterstützt viele verschiedene Auflösungen. Eine Übersicht über die gängigsten Auflösungen findest du beispielsweise unter https://de.wikipedia.org/wiki/Bildaufl%C3%B6sung#Computer. Hier ein paar Auflösungen, die verwendet werden könnten:

	{\| class="wikitable"		{\| class="wikitable"
Zeile 26:		Zeile 26:
	\| HD \|\| 1920 x 1080		\| HD \|\| 1920 x 1080
	\|-		\|-
	\| UHD (only Pi 4) \|\| 4096 x 2160		\| UHD (only Pi 4 or Pi 5) \|\| 4096 x 2160
	\|}		\|}

	Die Auflösung ~~einer Anzeige ist allerdings~~ nicht ~~alles~~. Da Computersysteme nur ~~Binäre~~ Zahlen kennen, ~~als~~ nur "1" oder "0", könnte man jedes ~~Feld gerade mal an~~ oder ausschalten. ~~Dies erzeugt damit nicht~~ die ~~vielen~~ Farben, die wir auf ~~den~~ Bildschirmen sehen, ~~sondern erzeugt gerade mal ein Monochromes Bild~~, ~~ein hartes Schwarz-Weiß Bild. In diesem Fall wird dann nur eine Bitmap verwendet. Aus diesem Grund wurden für Computergrafiken~~ zusätzliche Standards definiert~~, wie die Farben dargestellt werden können~~.		Die Auflösung allein reicht jedoch nicht aus, um komplexe, farbige Bilder darzustellen. Da Computersysteme nur binäre Zahlen kennen, also nur "1" oder "0", könnte man jedes Pixel lediglich ein- oder ausschalten, was nur ein Schwarz-Weiß-Bild erzeugen würde. Um die Vielzahl der Farben, die wir auf Bildschirmen sehen, darzustellen, werden zusätzliche Standards definiert.

	~~Wiederholt man~~ die Anzeige mehrmals ~~aufeinander~~, so entsteht ~~mehr Tiefe~~. Wenn ~~nun eine Anzeige~~ zwei Bitmaps verwendet, so stehen für jeden Punkt zwei Bits zur Verfügung. ~~Bei zwei Bits sind damit schon mal~~ vier Zustände ~~möglich, also auch~~ vier Farben. ~~Um so~~ mehr ~~man diese~~ Bitmaps ~~vertieft~~, ~~um so~~ mehr Farben ~~sind möglich~~.		Wird die Anzeige mehrmals hintereinander vertieft, entsteht eine größere Farbtiefe. Wenn ein Bild beispielsweise zwei Bitmaps verwendet, stehen für jeden Punkt zwei Bits zur Verfügung. Das ergibt vier Zustände bzw. vier Farben. Je mehr Bitmaps verwendet werden, desto mehr Farben können angezeigt werden.

	== Farbtiefe ==		== Farbtiefe ==

	~~Auf dem~~ Raspberry Pi ~~werden 4 Modies angeboten, die verwendet werden könnten. Laut Dokumentation werden die~~ Farbtiefen ~~mit~~ 8-Bit, 16-Bit, 24-Bit und 32-Bit ~~angegeben~~. ~~Unter 8-Bit~~ wird ~~eine Farbpalette verwendet, die die entsprechenden Farben anbietet. Laut Dokumentation wird allerdings~~ von 8-Bit und 24-Bit abgeraten, da ~~diese~~ zu ~~Fehlern bei der Darstellung kommen könnte~~. Siehe ~~dazu~~ auch https://www.raspberrypi.org/documentation/configuration/config-txt/video.md ~~unter den Punkt~~ framebuffer_depth. ~~Damit wir~~ es einfach ~~haben~~, ~~beschränken~~ wir uns auf die 32-Bit ~~Darstellungen~~.		Der Raspberry Pi unterstützt vier verschiedene Farbtiefen: 8-Bit, 16-Bit, 24-Bit und 32-Bit. In der Praxis wird jedoch von der Verwendung der 8-Bit und 24-Bit Farbtiefe abgeraten, da sie zu Darstellungsfehlern führen können. Siehe hierzu auch die Dokumentation unter https://www.raspberrypi.org/documentation/configuration/config-txt/video.md im Abschnitt framebuffer_depth. Um es einfach zu halten, konzentrieren wir uns auf die 32-Bit Farbtiefe.

	~~Ich möchte mal mit einen kleinen~~ Beispiel ~~zeigen, welcher~~ Speicheraufwand ~~nötig ist~~, ~~entsprechende Bilder darzustellen~~. ~~Als Beispiel habe ich hier ein~~ Bild ~~mit einer Bitmap (Monochrome),~~ mit einer Auflösung von 20 x 20 Pixel~~. Der~~ Speicherbedarf ~~errechnet sich bei Monochromer Darstellung folgend~~:		Beispiel: Speicheraufwand für Bilder
			Um den Speicheraufwand zu veranschaulichen, betrachten wir ein Beispiel. Ein monochromes Bild mit einer Auflösung von 20 x 20 Pixel benötigt folgenden Speicherbedarf:

	<syntaxhighlight>		<syntaxhighlight>
Zeile 45:		Zeile 46:
	[[Datei:Koordinaten2.png\|rand\|400x400px]]		[[Datei:Koordinaten2.png\|rand\|400x400px]]

	~~Die Berechnung für mehr Bitmaps erfolgt mit folgender Formel und als Beispiel~~ ein Bild mit 4 ~~Bitplanes~~:		Für ein Bild mit 4 Bitmaps beträgt der Speicherbedarf:

	<syntaxhighlight>		<syntaxhighlight>
Zeile 53:		Zeile 54:
	[[Datei:Koordinaten3.png\|rand\|500x500px]]		[[Datei:Koordinaten3.png\|rand\|500x500px]]

	~~Aber verwenden wir mal~~ ein ~~reales Verhältnis,~~ HD-Auflösung ~~mit einer~~ RGBA32-Farbtiefe.		Nun ein Beispiel mit einer HD-Auflösung und RGBA32-Farbtiefe:

	<syntaxhighlight>		<syntaxhighlight>
	((1920 * 1080) * 32) / 8 = 8294400 Bytes ~~-> ~~~8,3 ~~MegaBytes~~		Speicherbedarf (Bytes) = ((1920 * 1080) * 32) / 8 = 8294400 Bytes
			Das entspricht etwa 8,3 Megabytes.
	</syntaxhighlight>		</syntaxhighlight>

	== Abbildung der Bitmaps im Speicher ==		== Abbildung der Bitmaps im Speicher ==

	~~Die~~ Bitmaps werden nicht als Bitmaps im Speicher abgelegt~~. Die~~ Grafikdaten ~~muss man sich~~ wie in einem ~~dreidimensionaler~~ Raum ~~vorstellen~~. ~~Als~~ Beispiel ~~habe ich hier ein 20x20~~ Pixel ~~mit~~ einer Farbtiefe von 16 Bits dargestellt:		Bitmaps werden nicht als eine Reihe von Einzelbildern (Bitmaps) im Speicher abgelegt, sondern die Grafikdaten sind wie in einem dreidimensionalen Raum organisiert. Betrachten wir ein Beispiel mit einer Auflösung von 20 x 20 Pixel und einer Farbtiefe von 16 Bit:

			Jeder Bildschirmpunkt wird bei einer Farbtiefe von 16 Bit durch 16 aufeinanderfolgende Bits dargestellt. Der erste Punkt verwendet die Bits 0-15, der nächste die Bits 16-31, und so weiter. Das müssen wir bei den Berechnungen für jeden einzelnen Punkt berücksichtigen.

	[[Datei:Koordinaten4.png\|rand\|600x600px]]		[[Datei:Koordinaten4.png\|rand\|600x600px]]

Satyria am 6. März 2025 um 11:28 Uhr

2025-03-06T11:28:36Z

← Nächstältere Version		Version vom 6. März 2025, 12:28 Uhr
Zeile 1:		Zeile 1:
	~~Bisher sind~~ die ~~Ergebnisse, die wir bisher programmiert haben, nicht allzu aufwendig gewesen~~. ~~Bisher konnte der~~ Raspberry nicht wirklich mit der Ausenwelt kommunizieren. Es war "nur" eine LED, die geleuchtet oder geblinkt hat. Natürlich ist mit diesem Wissen bisher, jeder Zeit möglich, den GPIO entsprechend zu programmieren, so dass viel mehr gemacht werden kann, als diese Beispiele bisher zeigten. Im Internet gibt es viele Beispiele, für welche Dinge genau diese Schnittstelle verwendet werden könnte. Gerne kannst du das tun. Mir selbst hat das nicht gereicht. Ich möchte mehr, ~~als nur das. Immerhin bietet~~ der ~~Raspberry Pi auch~~ einen HDMI Ausgang, der ~~nur darauf wartet, verwendet zu~~ werden. ~~Also machen~~ wir ~~uns dran, diesen zu nutzen.~~		Die bisherigen Programme auf dem Raspberry Pi waren vergleichsweise einfach und ermöglichten lediglich die Steuerung einer LED. Der Raspberry Pi kann jedoch weitaus mehr, insbesondere im Bereich der Grafik, da er über einen HDMI-Ausgang verfügt, der für fortgeschrittene Anwendungen genutzt werden kann. In diesem Abschnitt wollen wir den HDMI-Ausgang des Raspberry Pi verwenden, um grafische Ergebnisse direkt anzuzeigen.
	~~Wir schließen nun einen Monitor an~~ des Raspberry Pi ~~an und lassen uns die Ergebnis~~ direkt ~~vom Raspberry Pi anzeigen. Da vom Grunde her, da wir in Barre Metal schreiben, der Raspberry “Dumm” ist und auch nicht weiß, wie er es machen soll, müssen wir entsprechende Routinen schreiben.~~
	Der Raspberry Pi 4 besitzt zwei HDMI Ausgänge, mit dem er zwei Bildschirme ansteuern kann. Beide können hier bis zu UHD Auflösung anzeigen. Auf dem Raspberry Pi ist hierzu ein eigener Prozessor (GPU) zuständig, der die arbeit der CPU abnimmt.

	~~Übrigens: Die GPU ist auch zuständig dafür, dass der~~ Raspberry ~~überhaupt startet. Sie lädt die Firmware in den Speicher und übergibt dann die Arbeit~~ an die ~~CPU~~. ~~Dies ist während des Startvorgangs~~, ~~wenn ein Bildschirm angeschlossen ist~~, ~~gut sichtbar~~.		Zu Beginn schließen wir einen Monitor an den Raspberry Pi an, um die Ergebnisse direkt auf dem Bildschirm sehen zu können. Da wir Bare Metal programmieren, müssen wir sämtliche Routinen selbst schreiben, da der Raspberry Pi keine vorinstallierten Weisungen hat, wie er Bilder auf dem Monitor anzeigt.

	Der Raspberry Pi ~~ist ein wahres Wunder~~, ~~was seine Fähigkeiten der Grafikanzeige betreffen. Der Raspberry Pi 4 kann~~ bis zu 4096 x 2160 Pixel ~~(entspricht eine Auflösung von 4k~~) bei 60 Hz ~~anzeigen~~. ~~Wenn beide~~ HDMI-Ports ~~verwendet werden ist~~ die ~~Herzzahl halbiert~~. Ältere Modelle unterstützen ~~immerhin~~ 1920 x 1200 bei ~~60Hz~~.		Der Raspberry Pi 4 besitzt zwei HDMI-Ausgänge, die jeweils Bildschirme mit bis zu UHD-Auflösung (4096 x 2160 Pixel) bei 60 Hz unterstützen. Bei Verwendung beider HDMI-Ports beträgt die Bildwiederholrate maximal 30 Hz. Ältere Raspberry Pi-Modelle unterstützen Bildschirme bis zu einer Auflösung von 1920 x 1200 Pixel bei 60 Hz.

	~~Da wir~~ die ~~Grafik programmieren wollen~~, müssen wir ~~erstmal~~ verstehen, wie ~~eine Grafik überhaupt~~ dargestellt wird. ~~Die Anzeige, die visuell aufgenommen wird,~~ besteht aus einzelnen Punkten ~~(Pixel). Jeder Punkt hat~~ eine eigene Farbe. ~~In der Regel~~ wird der Bildschirm ~~mit~~ einem Koordinatensystem (x,y) dargestellt. Der erste ~~Punkt (~~links ~~oben)~~ hat die ~~Koordinate~~ 0,0. Der ~~nächste,~~ rechts davon ~~erhöht sich x um eins und~~ hat ~~dann~~ die Koordinate 1,0 ~~usw…~~ Nach unten wird y um ~~jeweils~~ eins erhöht, 1,0 2,0 usw.		Interessanterweise ist es die GPU des Raspberry Pi, die den Startvorgang initiiert. Sie lädt die Firmware in den Speicher und übergibt danach die Kontrolle an die CPU. Dies ist während des Startvorgangs deutlich sichtbar, wenn ein Bildschirm angeschlossen ist.

			Um mit der Grafikprogrammierung zu beginnen, müssen wir zunächst verstehen, wie ein Bild auf dem Bildschirm dargestellt wird. Ein Bildschirm besteht aus einzelnen Punkten, den Pixeln, die jeweils eine eigene Farbe haben. Normalerweise wird der Bildschirm in einem Koordinatensystem (x, y) dargestellt. Der erste Pixel oben links hat die Koordinaten (0,0). Der nachfolgende Pixel rechts davon hat die Koordinate (1,0) und so weiter. Nach unten wird die y-Koordinate jeweils um eins erhöht: (0,1), (0,2) usw.

	[[Datei:Koordinaten1.png\|rand]]		[[Datei:Koordinaten1.png\|rand]]

Satyria am 5. März 2025 um 07:34 Uhr

2025-03-05T07:34:08Z

Änderungen zeigen

Satyria: /* Anwendung der DrawPixel-Funktion */

2025-03-05T07:30:46Z

Anwendung der DrawPixel-Funktion

← Nächstältere Version		Version vom 5. März 2025, 08:30 Uhr
Zeile 368:		Zeile 368:
	</syntaxhighlight>		</syntaxhighlight>

	Der Sourcecode, für dieses Beispiel ist hier zum laden bereit: [~~http~~://~~assem~~.satyria.~~org~~/~~source~~/~~kurs~~/~~5.1.zip 5.1~~.zip]		Der Sourcecode, für dieses Beispiel ist hier zum laden bereit: [https://www.satyria.de/arm/sources/RPI4/C/4.zip]

	== Neue Befehle (1) ==		== Neue Befehle (1) ==

Satyria: /* Anwendung der DrawPixel-Funktion (5.1) */

2025-03-05T07:28:53Z

Anwendung der DrawPixel-Funktion (5.1)

← Nächstältere Version		Version vom 5. März 2025, 08:28 Uhr
Zeile 338:		Zeile 338:
	</syntaxhighlight>		</syntaxhighlight>

	== Anwendung der DrawPixel-Funktion ~~(5.1)~~ ==		== Anwendung der DrawPixel-Funktion ==

	Wir haben jetzt eine Funktion geschrieben, die es ermöglicht, etwas auf dem Bildschirm zu sehen. Jetzt müssen wir nur noch unsere neuen Funktionen im Hauptprogramm verwenden und wir dürften ein Ergebniss sehen.		Wir haben jetzt eine Funktion geschrieben, die es ermöglicht, etwas auf dem Bildschirm zu sehen. Jetzt müssen wir nur noch unsere neuen Funktionen im Hauptprogramm verwenden und wir dürften ein Ergebniss sehen.

	Als wir die TAG-Struktur erstellten, haben wir einige Variablen benutzt, die wir erstmal festlegen müssen.		Als wir die TAG-Struktur erstellten, haben wir einige Variablen benutzt, die wir erstmal festlegen müssen. Dazu verwenden wir unsere "config.h" Datei und ergänzen folgende Zeilen:

	<syntaxhighlight lang="~~asm~~">		<syntaxhighlight lang="C">
	~~.equ~~ SCREEN_X, 1920		#define SCREEN_X 1920
	~~.equ~~ SCREEN_Y, 1080		#define SCREEN_Y 1080
	~~.equ~~ BITS_PER_PIXEL, 32		#define BITS_PER_PIXEL 32
	</syntaxhighlight>		</syntaxhighlight>

Zeile 354:		Zeile 354:
	Die erste Funktion, die wir aufrufen müssen, ist die Erstellung des Bildschirms. HIer wird nichts übergeben und wir bekommen nichts zurück.		Die erste Funktion, die wir aufrufen müssen, ist die Erstellung des Bildschirms. HIer wird nichts übergeben und wir bekommen nichts zurück.

	<syntaxhighlight lang="~~asm~~">		<syntaxhighlight lang="C">
	~~bl FB_Init @Open Screen~~		Init_Screen();
	</syntaxhighlight>		</syntaxhighlight>

	Einen einzelnen Punkt auf einem Bildschirm zu sehen, ist manchmal recht schwierig. Dazu werden wir mehrere Punkte nebeneinander setzen und verwenden eine Schleife, die die Koordinaten entsprechend verändert und lassen uns jedesmal den Punkt zeichnen.		Einen einzelnen Punkt auf einem Bildschirm zu sehen, ist manchmal recht schwierig. Dazu werden wir mehrere Punkte nebeneinander setzen und verwenden eine Schleife, die die Koordinaten entsprechend verändert und lassen uns jedesmal den Punkt zeichnen.

	<syntaxhighlight lang="~~asm~~">		<syntaxhighlight lang="C">
	~~mov r5,#0 @Set r5 to 0~~ for ~~a loop~~		u32 i;
	~~loop:~~		for (i=100;i<=500;i++)
	~~mov r0,r5 @Copy r5 to r0~~ (x)		{
	~~mov r1,r5 @Copy r5 to r1 (y)~~		DrawPixel(i,i);
	~~mov r2,#0xffffffff @Color white according to r2~~		}
	bl DrawPixel ~~@And draw the pixel~~
	~~add r5~~,~~#1 @Add r5 with one~~
	~~cmp r5,#10 @As long as 10 is not reached~~
	~~bne loop @Continue the loop~~
	</syntaxhighlight>		</syntaxhighlight>

Satyria: /* Auf den Bildschirm zeichnen */

2025-03-05T07:23:18Z

Auf den Bildschirm zeichnen

← Nächstältere Version		Version vom 5. März 2025, 08:23 Uhr
Zeile 295:		Zeile 295:
	Diese Funktion nennen wir “DrawPixel” und übergeben ihr die Koordinate in x und y.		Diese Funktion nennen wir “DrawPixel” und übergeben ihr die Koordinate in x und y.

	~~<syntaxhighlight lang="c">~~		Für verschiedene Farbtiefen, sind verschiedene Berechnungen notwendig, um die richtige Farbe darzustellen. Genau so ist diese Farbtiefe auch verantwortlich, wo den die einzelnen Bildpunkte im Speicher zu finden sind. Zunächst werden wir diese Funktion relativ einfach halten und einfach davon ausgehen, dass wir eine Farbtiefe von 32 Bit haben.
	~~void DrawPixel(u32 x, u32 y)~~
	{
	~~if ((x < SCREEN_X) && (y < SCREEN_Y))~~
	{
	~~write32(DrawColor,graphicsAddress+(((SCREEN_Xy)+x)4));~~
	}
	}
	~~</syntaxhighlight>~~

	Für verschiedene Farbtiefen, sind verschiedene Berechnungen notwendig, um die richtige Farbe darzustellen. Genau so ist diese Farbtiefe auch verantwortlich, wo den die einzelnen Bildpunkte im Speicher zu finden sind. Zunächst werden wir diese Funktion relativ einfach halten und einfach davon ausgehen, dass wir eine Farbtiefe von 32 Bit haben~~. Die 16 Bit Unterstützung werden wir später erstellen~~.

	Zunächst überprüfen wir, ob der Pixel überhaupt im sichtbaren Bereichs liegt. Es würde sonst zu unerwünschten Nebeneffekten kommen, denn wir wissen nicht, welche Funktion die entsprechende Speicherstelle im System hat.		Zunächst überprüfen wir, ob der Pixel überhaupt im sichtbaren Bereichs liegt. Es würde sonst zu unerwünschten Nebeneffekten kommen, denn wir wissen nicht, welche Funktion die entsprechende Speicherstelle im System hat.

	~~<syntaxhighlight lang="asm">~~
	~~mov r3,#SCREEN_X @Load screen width to r3~~
	~~sub r3,#1 @Subtract it by one~~
	~~cmp r0,r3 @And compare it with transfer~~
	~~pophi {pc} @If it's higher then go back~~

	~~mov r3,#SCREEN_Y @Load screen height to r3~~
	~~sub r3,#1 @Subtract it by one~~
	~~cmp r1,r3 @And compare it with transfer~~
	~~pophi {pc} @If it's higher then go back~~
	~~</syntaxhighlight>~~

	Wenn wir es überprüft haben, können wir die richtige Position berechnen. Dies erfolgt nach folgender Formel:		Wenn wir es überprüft haben, können wir die richtige Position berechnen. Dies erfolgt nach folgender Formel:

Zeile 327:		Zeile 305:
	</syntaxhighlight>		</syntaxhighlight>

	~~Umgesetzt für unseren Code bedeutet es:~~

	~~<syntaxhighlight>~~
	~~((SCREEN_X * r1) + r0) * 32/8~~
	~~</syntaxhighlight>~~

	~~<syntaxhighlight lang="asm">~~
	~~mov r3,#SCREEN_X @width to r3~~
	~~mul r3,r1 @multibly with pos y~~
	~~add r3,r0 @add pos x~~
	~~mov r4,#4~~
	~~mul r3,r4 @multibly with 4 (32/8)~~
	~~</syntaxhighlight>~~

	Dies entspricht fast 1:1 der zuvor festgelegten Berechnung. Nur bei der letzten Berechnung haben wir 32/8 gekürzt und multiplizieren einfach mit 4, was das gleiche entspricht. Damit haben wir die Position im Screen definiert. Nun müssen wir einfach nur noch die Farbe im Screen ablegen.
	Dazu müssen wir die ScreenAdresse noch zu dieser Position hinzuaddieren.		Dazu müssen wir die ScreenAdresse noch zu dieser Position hinzuaddieren.

	<syntaxhighlight lang="~~asm~~">		<syntaxhighlight lang="c">
	~~ldr r4~~,~~=graphicsAddress @Load Graphicaddress to r4~~		void DrawPixel(u32 x, u32 y)
	~~ldr r4~~,~~[r4]~~		{
	~~add r4,r3 @add pos of Pixel~~		if ((x < SCREEN_X) && (y < SCREEN_Y))
	~~str r2,[r4] @Store Color to Graphic~~		{
			write32(DrawColor,graphicsAddress+(((SCREEN_Xy)+x)4));
			}
			}
	</syntaxhighlight>		</syntaxhighlight>

	Damit wird bereits der Pixel angezeigt. Wenn wir jetzt allerdings die Funktion so beibehalten, werden wir irgendwann feststellen, dass das System relativ träge arbeitet. Dies liegt an den Multiplikationen, die wir hier verwendet haben. Multiplikationen bedeuten für den ARM-CPU eine Menge Rechenaufwand. Auf dies sollte, wenn es möglich ist, verzichtet werden.		Damit wird bereits der Pixel angezeigt.

	~~Schauen~~ wir ~~erstaml die erste Multiplikation an~~. ~~HIer fällt mir auf die schnelle nichts ein, wie wir diese Multiplikation umgehen können, da wir nicht wissen, was als~~ "y" ~~übergeben wird~~. ~~Wenn wir aber den nächsten Befehl anschauen, wird hier ein Wert addiert~~. ~~Der ARM-Prozessor bietet hier einen interessanten Befehl an, der Multipliziert und kann zugleich eine Zahl addieren, genau das, was wir brauchen~~.		Damit ist unsere vorläufige “DrawPixel” Funktion erstmal fertig und erzeugen eine neue Headerdatei in der wir diese Funktionen beschreiben.
			<syntaxhighlight lang="c">
			//
			// 20.02.2025 www.satyria.de
			//
			// screen.h
			//

	~~<syntaxhighlight lang="asm">~~		#ifndef _screen_h
	~~mov r3,~~#~~SCREEN_X @width to r3~~		#define _screen_h
	~~mla r3,r1,r3,r0 @multibly with pos y and add pos x~~
	~~</syntaxhighlight>~~

	~~Immerhin haben wir hier zumindest mal die addition gespart~~.		#include "types.h"
	r3 müsste nun noch mit 4 multipliziert und zur Bildschirmposition addiert werden. Zahlenwerte, die mit 2, 4, 8, 16, 32, ... multipliziert werden, sind im Binärer Form sehr einfach umzusetzen, wenn wir hier einfach die Bitfolge ein Bit nach links verschieben, haben wir die Zahl mit zwei multipliziert. Wenn man nun zwei Bits nach links verschiebt, wird daraus eine Multiplikation um 4.
	mla war bereits eine kombinierter Befehl. Es gibt einige Befehle, die zusätzlich zu ihrem eigentlichen Sinn eine Shift-Operation zulassen. Darunter zählt auch der add-Befehl. Hier erstmal der Sourcecode dafür, wie ich es mir Vorstelle:

	~~<syntaxhighlight lang="asm">~~		void Init_Screen(void) ;
	~~ldr r4~~,~~=graphicsAddress @Load Graphicaddress to r4~~		void DrawPixel(u32 x, u32 y);
	~~ldr r4,[r4]~~

	~~add r4,r3,lsl~~ #~~2 @multibly r3 with 4 and~~		#endif
	~~@Add the result to the graphic address~~
	~~str r2,[r4] @Store the Color to graphic address~~
	</syntaxhighlight>		</syntaxhighlight>

	Wir schauen uns hier den add Befehl an. Hier wird ein lsl #2 angehängt. Dies ist ein Shift-Befehl, der Bits nach links verschiebt. Dies wird in unserem Fall mit dem Register r3 verwendet und anschließend mit r4 addiert. Das Ergebniss steht danach in r4. Obwohl hier r3 augenscheinlich verändert wurde, ist r3 nach dieser Aktion unverändert.
	~~Auf diese Weiße, haben wir hier eine ganze Multiplikation eingesparrt.~~

	~~Damit ist unsere vorläufige “DrawPixel” Funktion erstmal fertig und erzeugen eine neue Headerdatei (drawing.h) in der wir diese Funktion ablegen.~~

	== Anwendung der DrawPixel-Funktion (5.1) ==		== Anwendung der DrawPixel-Funktion (5.1) ==

Satyria: /* Der Postbote */

2025-03-05T07:16:56Z

Der Postbote

← Nächstältere Version		Version vom 5. März 2025, 08:16 Uhr
Zeile 259:		Zeile 259:
	=== Der Postbote ===		=== Der Postbote ===

	Nun kommt der Postbote ins Spiel. Wir geben ihm unsere TAG-Liste und erzeugen damit unseren Bildschirm.		Nun kommt der Postbote ins Spiel. Wir geben ihm unsere TAG-Liste und erzeugen damit unseren Bildschirm. Wir werden zunächst eine einfache Methode verwenden und später die Funktionen erweitern.

	Damit haben wir dem Postboten zumindest den Auftrag gegeben, dass er diese Informationen an den GPU zu übergeben. Leider laufen die beiden Prozessoren nicht synchron und wir wissen zu diesem Zeitpunkt nicht, ob nun wirklich die Anzeige erzeugt wurde. Für die GPU ist unser Wunsch auch recht aufwendig, welche Zeit benötigt.		Damit haben wir dem Postboten zumindest den Auftrag gegeben, dass er diese Informationen an den GPU zu übergeben. Leider laufen die beiden Prozessoren nicht synchron und wir wissen zu diesem Zeitpunkt nicht, ob nun wirklich die Anzeige erzeugt wurde. Für die GPU ist unser Wunsch auch recht aufwendig, welche Zeit benötigt.
Zeile 277:		Zeile 277:
	</syntaxhighlight>		</syntaxhighlight>

	Problematisch wird es allerdings, wenn die GPU nie irgendwas zurück gibt, dann sind wir hier in einer Dauerschleife. Aber wollen wir nicht so schwarz sehen und hoffen, dass es hier zu keinem Fehler kommt.		Problematisch wird es allerdings, wenn die GPU nie irgendwas zurück gibt, dann sind wir hier in einer Dauerschleife. Aber wollen wir nicht so schwarz sehen und hoffen, dass es hier zu keinem Fehler kommt. Hier verwenden wir später andere Funktionen, damit wir hier nicht in Problemen bei anderen Abfragen kommen.

	Die Adresse, die wir zurück bekommen ist ein "byte" Wert, mit dem wir so nicht arbeiten können. Wir müssen diesen zuerst für unsere Zwecke umwandeln, was wir mit einem einfachen "and" durchführen. Anschließend speichern wir den Wert für spätere Zwecke.		Die Adresse, die wir zurück bekommen ist ein "byte" Wert, mit dem wir so nicht arbeiten können. Wir müssen diesen zuerst für unsere Zwecke umwandeln, was wir mit einem einfachen "and" durchführen. Anschließend speichern wir den Wert für spätere Zwecke.