Seite 3 von 4
Verfasst: 16.08.2009 16:49
von DarkDragon
Falko hat geschrieben:Wenn das so ist, was hier auch in Wiki beschrieben wird, fehlt eigentlich eine Abfrage, zum BMP-Format ob die Höhe positiv oder negativ ist.
http://de.wikipedia.org/wiki/Windows_Bitmap
Nur wäre das dann nicht Spiegelverkehrt, sondern nur auf dem Kopf gestellt, oder? Aber in diesen Beispielen ist es beides.
Die neue Konstante #PB_PixelFormat_ReversedY , wie auch immer man diese verwenden kann, ist nur für die Y-Richtung ausgelegt.
Gruß Falko
In deinem Link steht bei biHeight:
Der Betrag gibt die Höhe der Bitmap in Pixel an.
* Ist der Wert positiv, so ist die Bitmap eine sogenannte "bottom-up"-Bitmap (die Bilddaten beginnen mit der untersten und enden mit der obersten Bildzeile). Dies ist die gebräuchlichste Variante.
* Ist der Wert negativ, so ist die Bitmap eine "top-down"-Bitmap (die Bilddaten beginnen mit der obersten und enden mit der untersten Bildzeile).
Exakt das hab ich damals gelesen und das hat sich bei mir eingeprägt, da ich das auch von einer WinAPI funktion (glaub BitBlt o.ä.) her kannte.
Vielleicht spiegelt Fred falsch und desshalb kommt es zu einer beidachsigen Spiegelung statt dass es nur auf dem Kopf steht.
Ich könnte mir vorstellen, dass das das Problem bei CatchSprite ist. Vielleicht sollte man mal die Bilder mit einem Hex-Editor bearbeiten und dort das Vorzeichen einfach mal verändern um zu sehen was dann passiert.
Verfasst: 16.08.2009 16:55
von Falko
Hast Recht. Die Bitmap im Beispiel ist wohl in Height negativ und sie hätte in Y gespiegelt werden sollen. Doch in Wirklichkeit wird sie in X gespiegelt und somit kommt es auch hin, das in beiden Achsen die Ausgabe gespiegelt ist.
Gruß Falko
Verfasst: 16.08.2009 18:34
von Falko
Ich habe das jetzt mal mit dem Hexeditor angeschaut.
PureBasic.bmp h00000010 00 00 A8 00 00 00 23 00 00 00 01 00 18 00 00 00
das wären Höhe 35 Pixel und nichts negativ
PureBasicLogo.bmp h00000010 00 00 7D 01 00 00 44 00 00 00 01 00 08 00 01 00
Und hier wären das 68 und auch nicht negativ.
Daran kann's nicht liegen.
Gruß Falko
Verfasst: 18.08.2009 19:35
von Falko
Trotz 2. Beta scheint es wohl noch nicht [Done] und wohl nicht so wichtig zu sein. Ich habe hier mal den Unterschied mit dem selben "
IncludeBinary" einmal als
CatchSprite und einmal als
CatchImage dargestellt.
Ich hoffe, das nicht nur ich den Unterschied trotz Beta2 sehen kann
Da die Höhe des Bitmaps nicht negativ ist, dürfe das Sprite auch nicht horizontal gespiegelt sein, oder?
Code: Alles auswählen
InitSprite()
OpenWindow(0,100,100,400,180,"Test CatchSprite")
OpenWindowedScreen(WindowID(0),0,0,400,100,0,0,0)
If CatchSprite(0, ?Pic)
DisplaySprite(0,10,15) ; Same IncludeBinary with Catch-, and Displaysprite is reverse and reflected?
EndIf
If CatchImage(1,?Pic)
ImageGadget( 2, 10, 105, 0, 0, ImageID(1)); Same IncludeBinary with Catchimage and Imagegardget
EndIf
Repeat:Until WaitWindowEvent()=#PB_Event_CloseWindow
End
Pic:IncludeBinary "F:\Purebasic4_4BetaX86\Examples\Sources\Data\PureBasicLogo.bmp"
[Edit]
Ich habe mich nochmal überwunden es im englischen Forum aufzufrischen.
http://www.purebasic.fr/english/viewtop ... 450#296450
[/Edit]
Gruß Falko
Verfasst: 18.08.2009 20:35
von jojo1541
Ich kann ihn auch sehen, der Sprite ist immernoch Spiegelverkehrt und falsch herum, während das Image ganz normal dargestellt wird.
Verfasst: 31.08.2009 20:57
von HeX0R
Na Gott sei Dank hab ich das hier noch gefunden, bevor ich mir die letzten Haare ausgerauft habe.
Bei mir tritt dieser Fehler im übrigen auch mit dem DirectX9 Subsystem auf.
Das fiese ist, ich habe vier Pfeile in alle Himmelsrichtungen und zwei davon sind natürlich (auf den ersten Blick) nicht gespiegelt (fies)...
Ich hoffe keine Antwort im englischen bedeutet "Wir arbeiten dran" und nicht "später vielleicht".
Verfasst: 31.08.2009 21:04
von Thorium
HeX0R hat geschrieben:
Bei mir tritt dieser Fehler im übrigen auch mit dem DirectX9 Subsystem auf.
Das einzige Subsystem was verschont ist, ist OpenGL.
Verfasst: 31.08.2009 21:25
von HeX0R
Das hab ich auch mal ausprobiert, da gibts aber offensichtlich den Befehl DisplayTranslucentSprite() nicht?
[Edit]
Hui ui ui, das OpenGL-Subsystem macht aber seltsame Sachen.
Alle Sprites korrupt, InitSound() gibt immer 0 zurück, usw...
Das lass ich lieber.
Verfasst: 31.08.2009 22:10
von Thorium
HeX0R hat geschrieben:
[Edit]
Hui ui ui, das OpenGL-Subsystem macht aber seltsame Sachen.
Alle Sprites korrupt, InitSound() gibt immer 0 zurück, usw...
Das lass ich lieber.
Hm, ja im Eimer isses schon aber InitSound funktioniert bei mir. o.O
Was im Eimer ist, ist StartDrawing. Das konvertiert ein 32bit Sprite in ein 24bit Sprite.
Verfasst: 31.08.2009 22:22
von HeX0R
Thorium hat geschrieben:
Hm, ja im Eimer isses schon aber InitSound funktioniert bei mir. o.O
Hier auch?
Code: Alles auswählen
InitSprite()
InitKeyboard()
InitMouse()
OpenWindow(0, 0, 0, 800, 600, "...", $C8001)
OpenWindowedScreen(WindowID(0), 0, 0, 800, 600, 1, 0, 0)
Debug InitSound()
[Edit]
Ah o.k., OpenGL mag wohl diese Reihenfolge nicht...