Thema: Pixel malen

[bitmaster]

Standart und immer gleich???

Du weißt doch wie das immer ist. Immer Bedingungen einbauen, wenn so dann so, ansonsten so. ^^

[nooooooooos]

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?

[T0ast3r]

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

[bitmaster]

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?

[Jidder]

Und was willst du in das 4. Byte rein tun? Das bleibt immer 0.

[T0ast3r]

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

[nooooooooos]

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?

[T0ast3r]

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

[nooooooooos]

Aaaaaaaah
Danke viel mals.

Es bleib aber immernoch diese Frage:

Code: [Auswählen]

  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???

Code: [Auswählen]

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

[Jidder]

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

Code: [Auswählen]

mov   cx,   0x4105
and   cx,   0xFFF   ; Entfernt 0x4 (steht für den LFB.)
hat vielleicht früher irgendwie so ausgesehen:

Code: [Auswählen]

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.

[nooooooooos]

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.

Code: [Auswählen]


mov   cx,   [bp+0x4]
and   cx,   0xFFF   ; Entfernt 0x4 (steht für den LFB.)

Wieso wird dann zu bp 0x4 addiert???

[Jidder]

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]

[nooooooooos]

Aha, danke.

[bitmaster]

Also ich habe jetzt den Modus 101h gesetzt. Aber das folgende Funktioniert nicht:

Code: [Auswählen]

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?

[nooooooooos]

Ne, ich hab nur eine neue Adresse. Ist jetzt auch im Profil aktualisiert.

Gruss
Noooooooooos

[bitmaster]

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.

[nooooooooos]

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.

[bitmaster]

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!!!

[bitmaster]

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 )

[n3Ro]

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.