Lowlevel
Lowlevel => OS-Design => Thema gestartet von: BlitzChecker am 19. April 2006, 18:20
-
wie kann man mit c++ einen pixel in farbe xyz an position xyz malen?
-
erst mal brauchst du ein OS Grundgerüst, bevor du das nicht hast, brauchst du gar nicht erst daran denken irgendetwas in C++ zu machen
wie weit bist du denn?
-
also, wir sind schon recht weit, aber jetzt wollten wir ne gui machen, und da wollt ich halt wissen, wie man sowas machst. muss man dann für jede grafikkarte nen eigenen treiber proggen?
-
also, wir sind schon recht weit, aber jetzt wollten wir ne gui machen, und da wollt ich halt wissen, wie man sowas machst. muss man dann für jede grafikkarte nen eigenen treiber proggen?
Eigentlich ja, aber es gibt gewisse Standards wie z.B. VGA und VESA. VGA ist da die einfachere aber auch nur für den Anfang geeignete Metode. Wie kommst du auf Position z? Es gibt nur 2D, sprich x und y. Mal ein ganz kleines Beispiel:
mov ax,0013h ;vga Modus
int 13h ;geht nur wenn man im RM ist
mov ax,A000h
mov es,ax
mov di,y*320+x ;Position wo der pixel gefärbt werden soll
mov al,Farbe
stosb
Mit den Ports musst du vorher die Farben festlegen. An Adresse A000:XXXX befinden sich die Pixel. Wenn du das beherrscht kannst du auch auf VESA umsteigen. Der ist viel besser (16. mio Farben glaube ich, und bis 1280*1024 glaube ich). Dazu musst du aber im PM sein um die Adressen dafür ansprechen zu können (oder im Unrealmode ;) ).
bitmaster
-
Wie kommst du auf Position z?
xyz hab ich nur so geschrieben, ich meinte damit natürlich x und y. es gibt ja auch die farbe xyz nicht :wink:
aber danke, du hast mich echt weitergebracht. gibts irgendwo ein tut für den vesa-modus?
-
ein tutorial gibt es, wurde einmal im forum veröffentlicht, ich suche gleich...
am besten du ladest dir die Vesa 3.0 (oder 2.0) spezifikation (eigentlich heißt sie vbe) runter:
dokumente am ftp (über VBE):
http://www.vesa.org/Public/VBE/
direktlink zur VBE 3.0 spezifikation:
http://www.vesa.org/Public/VBE/vbe3.pdf
-
gefunden, der link zum thread:
http://lowlevel.brainsware.org/forum/viewtopic.php?t=516
leider ist das Tutorial down (habs getestet, sowohl das PDF als auch die HTML Version), ich stells aufm ftp (habs auf der Festplatte) und schreib dan den link hier rein
-
der link zum vesa tutorial:
ftp://t0ast3r.t0.ohost.de/vesa.doc
http://t0ast3r.t0.ohost.de/vesa.doc
www.ToasterOS.at.tt/vesa.doc
-
die links funktionieren alle nich *heul* bei einem wird nach nem passwort und nem benutzernamen gefragt und bei den anderen komtn404 error: seite nich gefunden...
-
dito
-
waaas heißt
Dito
-
<OT>Dito bedeutet soviel wie: Bin der gleichen Meinung bzw. Man wünscht dadurch jemanden das gleiche was man von ihm gewünscht bekommt.</OT>
Mich würden auch das tut interessieren, muss mich aber meinen Vorrednern anschließen. Keiner der Links funzt.
MfG JensFZ
-
stimmt, tut mir leid
dabei ist's am ftp oben...
jetzt gehts aber
ich glaub es ist daran gelegen dass es im root war...
Vesa.doc (http://t0ast3r.t0.ohost.de/know%20how/vesa.doc)
-
joh^^ jetzt gehst...
-
stimmt, tut mir leid
dabei ist's am ftp oben...
jetzt gehts aber
ich glaub es ist daran gelegen dass es im root war...
Vesa.doc (http://t0ast3r.t0.ohost.de/know%20how/vesa.doc)
Nicht schlecht, muss ich echt sagen. Dann bin ich mal auf dein Buch gespannt.
-
Dieses Tutorial hat doch gar nicht Toaster geschrieben.
Das war doch AnotherStupidCoder. Aber ich muss sagen nicht schlecht.
Aber wie geht das mit den Farben?? Muss man da eine Farb-Palette definieren oder gibt es da ein System???
mov edi, [VbeModePhysBasePtr]
mov ecx, 640 * 480
mov eax, 0xCC
rep stosd
Beim Modus, der im Tut verwendet wird, hat man doch 8Bit Farben, warum wird dann ein DW (stosD) geschrieben????
Gruss
Noooooooooooos
-
Paletten gibts nur im VGA Modus!
Bei Vesa verwendest du direkt die RGB Farben
-
Und wie werden die RGB-Farben im 32Bit Modus codiert???
-
wie meinst du codiert?
falls dus so meinst wie ich denke dann schreibst du je nachdem den wer hin, du kannst z.B. wählen 8:8:8
das bedeutet du hast je 8 bits für Rot grün und blau pro pixel
aber wenn du wirklich je 8 bits nimmst, musst du 2 implementierungen vorsehen, für ATI und NVidia
denn bei der einen geht NUR 8:8:8, und nicht 8:8:8:0
-
Also wenn ich aber 8:8:8 benutze, dann hab ich doch von den 32Bits nur 24 genutzt.
Was ist denn unterschiedlichbei ATI und NVida? Ich habe gemeint VESA sei ein Standart und immer gleich???
Gruss
Noooooooooos
-
Standart und immer gleich???
Du weißt doch wie das immer ist. Immer Bedingungen einbauen, wenn so dann so, ansonsten so. ^^
-
OK aber wie muss ich das jetzt mit den 8:8:8 machen???
aber wenn du wirklich je 8 bits nimmst
Hä????
NUR 8:8:8
Wie soll ich nur machen???? Ich hab ja dann erst 24Bit aufgefüllt. Was muss ich mit den restlichen 8Bits machen????
Und wie muss ich diese Werte dann zusammenrechnen????
-
also:
wenn du 8:8:8 nimmst hast du 24 bits pro pixel, wobei es eigentlich leichter ist mit 32 pixel zurechen, weshalb es auch die Codierung 8:8:8:0 gibt, die vorsieht dass das letze byte 0 ist
ich glaub es war NVidia (oder ATI?) bei der die codierung 8:8:8:0 NICHT geht, obwohl sie eigentlich vorgeschrieben ist
dass ist das einzige was du beachten musst
Zitat:
NUR 8:8:8
Wie soll ich nur machen???? Ich hab ja dann erst 24Bit aufgefüllt. Was muss ich mit den restlichen 8Bits machen????
Und wie muss ich diese Werte dann zusammenrechnen????
tja dann musst du halt gut programmieren können ;)
da musst du byteweise arbeiten, da kannst nicht einfach ein dword hernehmen
-
also:
wenn du 8:8:8 nimmst hast du 24 bits pro pixel, wobei es eigentlich leichter ist mit 32 pixel zurechen, weshalb es auch die Codierung 8:8:8:0 gibt, die vorsieht dass das letze byte 0 ist
ich glaub es war NVidia (oder ATI?) bei der die codierung 8:8:8:0 NICHT geht, obwohl sie eigentlich vorgeschrieben ist
dass ist das einzige was du beachten musst
Zitat:
NUR 8:8:8
Wie soll ich nur machen???? Ich hab ja dann erst 24Bit aufgefüllt. Was muss ich mit den restlichen 8Bits machen????
Und wie muss ich diese Werte dann zusammenrechnen????
tja dann musst du halt gut programmieren können ;)
da musst du byteweise arbeiten, da kannst nicht einfach ein dword hernehmen
Also wenn ich das richtig verstanden habe, dann heißt das: Ich muss die ersten 3 Byte nehmen und bevor ich das vierte nehme muss ich testen ob ich das darf (wegen NVidia oder ATI). Ist das so richtig?
-
Und was willst du in das 4. Byte rein tun? Das bleibt immer 0.
-
Und was willst du in das 4. Byte rein tun? Das bleibt immer 0.
nein, das ist schlichtweg falsch
wenn man den mode setzt (oder irgendeine initalisierungs funktion aufruft) bekommt man eine table mit werten zurück, da gibts ein feld bitsperpixel
indem steht die tatsächlich mögliche bit anzahl per pixel
bei ATI ist es glaub ich 32, bei NVidia 24, oder umgekehrt
es stimmt also überhaupt nicht dass im 4. byte einfach immer 0 steht
zudem gibts codierungen die auch nur 16 bit (oder auch mehr oder weniger) groß sind
-
Ja eben, wenn man bei NVida (oder eben ATI) das letzte Byte nicht mit Null auffüllen darf, mit was denn sonst. Irgendwas muss da ja drin sein????
-
dann beginnt die rote farbe (erstes byte) vom nächsten pixel!
db Pixel1_Rot
db Pixel1_Grün
db Pixel1_Blau
db Pixel2_Rot
db Pixel2_Grün
db Pixel2_Blau
um es zu verdeutlichen
-
Aaaaaaaah
Danke viel mals.
Es bleib aber immernoch diese Frage:
mov edi, [VbeModePhysBasePtr]
mov ecx, 640 * 480
mov eax, 0xCC
rep stosd Warum wird da ein DW geschrieben obwohl vom Mode nur ein Byte erfordert wird??????
Und: Wenn man den Mode 0x101 setzen will, wiso so kompliziert???mov ax, 0x4F01
mov di, VbeModeInfoBlock
mov cx, 0x4105
and cx, 0xFFF ; Entfernt 0x4 (steht für den LFB.)
int 0x10
Das mit der vier entfernen tscheck ich ja noch, aber dann bleibt ja immernoch 0x105 und nicht 0x101????? Und warum schreibt man den Modus nicht gleich ohne die Vier??????
Gruss
Noooooooooooos
-
dann beginnt die rote farbe (erstes byte) vom nächsten pixel!
db Pixel1_Rot
db Pixel1_Grün
db Pixel1_Blau
db Pixel2_Rot
db Pixel2_Grün
db Pixel2_Blau
um es zu verdeutlichen
Ja, aber das entspricht doch dem 24 Bit Modus. Im 32 Bit Modus sähe es so aus:
db Pixel1_Rot
db Pixel1_Grün
db Pixel1_Blau
db 0
db Pixel2_Rot
db Pixel2_Grün
db Pixel2_Blau
db 0
@nooooooooos: Ich bin kein VESA-Experte, aber für mich sieht das mit dem stosd und der 0x101-vs.-0x105-Geschichte einfach nach Tipp- und Flüchtigkeitsfehler aus. Das mov cx, 0x4105
and cx, 0xFFF ; Entfernt 0x4 (steht für den LFB.)
hat vielleicht früher irgendwie so ausgesehen:
mov cx, [bp+0x4]
and cx, 0xFFF ; Entfernt 0x4 (steht für den LFB.)
und ist einfach ein Relikt aus älteren Codetagen, als der Parameter noch nicht überprüft war, oder so.
-
Ja, aber das entspricht doch dem 24 Bit Modus
OK, dann kann ich ja in der zurückgelieferten Tabelle einfach schauen ob 24- oder 32-Bit erwartet wird.
mov cx, [bp+0x4]
and cx, 0xFFF ; Entfernt 0x4 (steht für den LFB.)
Wieso wird dann zu bp 0x4 addiert???
-
Die Zahl ist ungünstig gewählt, hat aber nix zu bedeuten. Ich hatte auch mov, [bp + 0xabcd], mov cx, [di] oder mov cx, [123] schreiben können.[/quote]
-
Aha, danke.
-
Also ich habe jetzt den Modus 101h gesetzt. Aber das folgende Funktioniert nicht:
mov edi, [VbeModePhysBasePtr]
mov ecx, 640 * 480
mov eax, 0xCC
rep stosd
Es wird nicht gefärbt. "es" zeigt auf einen Deskriptor der als Limit 4 GByte hat und als Basis Null. Aber man muss doch wissen welcher Wert in VbeModePhysBasePtr ist, bzw. was ist wenn der Wert größer ist als man Arbeitsspeicher hat? Ich verstehe das alles noch nicht so richtig.
EDIT: @nooooooooos: Hast du mich bei MSN geblockt?
-
Ne, ich hab nur eine neue Adresse. Ist jetzt auch im Profil aktualisiert.
Gruss
Noooooooooos
-
Ne, ich hab nur eine neue Adresse. Ist jetzt auch im Profil aktualisiert.
Gruss
Noooooooooos
Also unter nooooooooooos@hotmail.com bleibst du bei mir irendwie immer Offline.
Also ich habe mir jetzt mal den Wert ausgeben lassen, der in [VbeModePhysBasePtr] geschrieben wird. Bei Bochs ist es E0000000h und bei VMware F0000000h. Aber sende ich halt an diese Adresse Werte, passiert gar nichts. Es werden keine Pixel gefärbt, es bleibt alles schwarz. Wieso? Und die Adressen sind ja so weit hinten im Speicher, so viel Arbeitsspeicher habe ich ja gar nicht. Kann der die deswegen nicht ansprechen? Wie aber dann? Ich kapier das nicht.
-
Ne eben nooooooooooooos@hotmail.com ist nicht mehr meine aktuelle Adresse. Die neue ist: dominik_ruettimann AT hotmail DOT com. Ich habs vergessen im Profil nachzutragen.
-
Also ich habe es jetzt geschafft Pixel zu malen. Es geht ganz einfach. Ich muss aber ein normales mov nehmen und darf kein stos(b), stos(w) oder stos(d) nehmen. Warum eigentlich nicht? Und noch etwas. In Bochs ist der Modus 144h der 1024*768*32 Modus (glaube ich). Aber das ist in VMWare etc. nicht so. Wie teste ich, welcher Modus der 1024*768*32 ist?
danke!!!
-
Hmm.... Scheinen ja nicht viele Antworten zu geben. Bis jetzt habe ich Herausgefunden, dass in [VbeModeBitsPerPixel] die Pixeltiefe geschrieben wird, in [VbeModeXResolution] die Anzahl der Pixel pro Zeile und in [VbeModeYResolution] die Anzahl der Pixel pro Spalte. Also könnte ich mit diesen Werten auf den gewünschten 1024*768*32 Modus prüfen. Soll ich dann einfach alle Moden von 4000h bis 4FFFh durchgehen? Die 4 muss darf ja nicht verändert werden, oder kann ich sogar von 0000h bis FFFFh prüfen?
danke!!! (falls ich eine Antwort bekomme ;) )
-
Fast richtig! Für VBE sind nur einige Videomodi (bis 0x120 oder so) fest definiert, der rest ist Herstellerabhänging. Das Beste ist wirklich, sich zu jeder Mode-Nummer die Daten geben zu lassen (auf eine Liste unterstützter Modi zeigt ein Pointer im VBE Info Block). Allzuviele Mode-Nummern gibt es übrigens auch nicht, weil nur die unteren 9 bit eine ModeNummer darstellen und die restlichen Bits für gewünschte Eigenschaften stehen. Und da in Abgrenzung zu VGA Modi die VBE Modi erst bei 0x100 starten, ist der Bereich auf 0x100 bis 0x1ff beschränkt.
Das der Base Pointer bei LFB außerhalb des eigentlichen Speichers liegt ist auch ganz normal, weil man dann den Arbeitspeicher der GraKa anspricht und dieser halt woanders gemappt ist.
-
Fast richtig! Für VBE sind nur einige Videomodi (bis 0x120 oder so) fest definiert, der rest ist Herstellerabhänging. Das Beste ist wirklich, sich zu jeder Mode-Nummer die Daten geben zu lassen (auf eine Liste unterstützter Modi zeigt ein Pointer im VBE Info Block). Allzuviele Mode-Nummern gibt es übrigens auch nicht, weil nur die unteren 9 bit eine ModeNummer darstellen und die restlichen Bits für gewünschte Eigenschaften stehen. Und da in Abgrenzung zu VGA Modi die VBE Modi erst bei 0x100 starten, ist der Bereich auf 0x100 bis 0x1ff beschränkt.
Das der Base Pointer bei LFB außerhalb des eigentlichen Speichers liegt ist auch ganz normal, weil man dann den Arbeitspeicher der GraKa anspricht und dieser halt woanders gemappt ist.
OK, gut dann werde ich also alle Mode's von 100h bis 1FFh auf 1024*768*32 testen. Ach so, habe ich mir schon so gedacht das dann der Speicher der Grafikkarte genutzt wird. Nur wieso geht das nicht mit stos und muss direkt mit mov kopiert werden?
bitmaster
-
Komisch, müsste eigentlich gehen, schonmal auf nem RealPC probiert? Außerdem, mit:
mov edi, [VbeModePhysBasePtr]
mov ecx, 640 * 480
mov eax, 0xCC
rep stosd
schießt du über das Ziel hinaus;) , da du mit stosd immer gleich 4 bytes beschreibst. Also in dem Bsp. würde ich stosb nehmen, und zur Sicherheit auch noch vorher ein CLD machen, damit das Ganze auch sicher in die richtige Richtung geht. Wenn MOV geht muss auch STOSx gehen, das iist meine Meinung dazu.
-
Komisch, müsste eigentlich gehen, schonmal auf nem RealPC probiert? Außerdem, mit:
mov edi, [VbeModePhysBasePtr]
mov ecx, 640 * 480
mov eax, 0xCC
rep stosd
schießt du über das Ziel hinaus;) , da du mit stosd immer gleich 4 bytes beschreibst. Also in dem Bsp. würde ich stosb nehmen, und zur Sicherheit auch noch vorher ein CLD machen, damit das Ganze auch sicher in die richtige Richtung geht. Wenn MOV geht muss auch STOSx gehen, das iist meine Meinung dazu.
Tja, nur leider geht das nicht. Und mit stosb schon gar nicht, weil stosb es:di und nicht es:edi nimmt. Aber wenn ich 640*480/4 schreibe funktioniert es auch nicht. Leider funktioniert der 1024*768*32 Bit Modus mit VMware nicht. Mit Bochs darf ich nur 3 Bytes beschreiben (obwohl der sagt das es 32 Bit also 4 Byte Modus ist). Und wenn ich die Bytes einzelt hintereinander schreibe, geht es auch nicht, nur mit ein dword aufeinmal. Hmm.... Verstehe das ganze nicht so...
bitmaster
-
Cool, ich habs jetzt. Vergesst alles was ich gesagt habe. Ich hatte zwar den Modus auf 1024*768*32 getestet, dann aber vergessen den Wert bzw. die Nummer des Modus von cx nach bx zu kopieren um den dann nacher zu aktivieren. Deswegen lief alles falsch. Aber jetzt habe ich es gemacht, und es funktioniert auf Bochs, VMware und allen meinen PCs (außer auf dem 486er ;) ).
bitmaster
-
Schön, dass es jetzt geht ^^
Und mit stosb schon gar nicht, weil stosb es:di und nicht es:edi nimmt.
Stimmt wieder nicht so ganz. Ob es:di oder es:edi benutzt wird hängt einzig und allein vom Adressmodus ab: 16bit = es:di und 32bit = es:edi. Der einzige unterschied zwischen den Befehlen ist der Teil von eax, der an die Speicherstelle geschrieben wird und die größe um die edi erhöht wird: b=al & edi+1 , w=ax & edi+2 , d =eax & edi+4 und q= rax & rdi+8 (64bit).
-
Stimmt wieder nicht so ganz. Ob es:di oder es:edi benutzt wird hängt einzig und allein vom Adressmodus ab: 16bit = es:di und 32bit = es:edi. Der einzige unterschied zwischen den Befehlen ist der Teil von eax, der an die Speicherstelle geschrieben wird und die größe um die edi erhöht wird: b=al & edi+1 , w=ax & edi+2 , d =eax & edi+4 und q= rax & rdi+8 (64bit).
Echt? Das wusste ich gar nicht. Ich dachte stosb und stosw nehmen immer es:di und lodsb und lodsw immer ds:si. Also gilt das alles nur für den RM? Na ja, mit stosd etc. klappt es ja nicht deswegen mache ich es mit:
mov [es:edi],eax
Und damit klappt es bei allen PCs die ich habe und bei Bochs und VMware. Also sollte das so schon richtig sein. KA warum das mit stosd nicht geht. Na ja, hat es denn bei einen von euch mit stosd funktioniert?
bitmaster
-
Ach ja, noch etwas. Wenn ich in eax den Wert für die Farbe habe, werden die letzten 8 Bit irgendwie ignoriert. Wenn ich z.B. weiß haben will, dann ist es egal ob ich: 00FFFFFFh oder 55FFFFFFh oder FFFFFFFFh etc. schreibe. Es werden also nur 24 Bit berücksichtigt, obwohl ich im 32 Bit Modus bin. Was ist denn mit den letzten 8 Bit? Ist das nur für die Helligkeit etc. zuständig?
danke!!!
-
Das letzte Byte ist dann der Alphakanal, würde ich sagen, und hat auf die Darstellung keine direkte Auswirkung.
-
Das letzte Byte ist dann der Alphakanal, würde ich sagen, und hat auf die Darstellung keine direkte Auswirkung.
Aha, also kann ich den einfach immer schön auf Null lassen?
-
Ja, aber im Prinzip kannst du damit machen, was du willst. Das eine Byte dient nur als Platzhalter, weil sich an 4byte ausgerichtete Werte schneller und einfacher auslesen lassen als an 3byte ausgerichtete Werte. Das ganze nennt sich auch 8:8:8:0, das heißt, dass es 4 Teile gibt von denen nur 3 a 8bit benutzt werden, im Gegensatz zu 8:8:8 (24bit modus), 5:6:5 (16bit modus) oder 5:5:5:1 (15bit modus, da ist nur das mit der 1 komisch) .
-
Ja, aber im Prinzip kannst du damit machen, was du willst. Das eine Byte dient nur als Platzhalter, weil sich an 4byte ausgerichtete Werte schneller und einfacher auslesen lassen als an 3byte ausgerichtete Werte. Das ganze nennt sich auch 8:8:8:0, das heißt, dass es 4 Teile gibt von denen nur 3 a 8bit benutzt werden, im Gegensatz zu 8:8:8 (24bit modus), 5:6:5 (16bit modus) oder 5:5:5:1 (15bit modus, da ist nur das mit der 1 komisch) .
OK, gut. Dann habe ich es ja so wie ich will. danke!!!
-
Mist, ich hatte was falsch gemacht. Jetzt geht es auch mit (rep) stosd.
bitmaster