Bei der Erstellung eines einfachen 2D - Spieles verwendete ich die Unit glBitmap.pas. Leider scheint die geladene Texture nicht die gleiche Ausrichtung zu haben wie eine Texture, die mit der Unit von Jan Horn erstellt wurde. Ein FlipVert hat nichts gebracht, da die Texture nicht nur auf den Kopf, sondern zu dem noch an einer Diagonalen gespiegelt zu sein.

Ich habe ein Texture wie folgt erstellt:

Lade ich diese mit der Unit von Jan Horn, das stimmt alles. Bei der Unit glBitmap kommt folgendes raus:

Nach FlipVert liegt die Texture wie folgt vor:

Dargestellt wird die Texture ganz normal mit:


Dank des sehr guten 2D Tutorial von SoS ging das schreiben des 2D - Spiele - Framework relativ zügig voran, nur diese Sache hält mich noch auf.

Gruß
KidPaddle

_________________
http://www.seban.de

Du kannst doch mittels glTexCoord* die Textur drehen und spiegeln wie dir beliebt. Wenn dir das zu umständlich ist (weil du z.B. den Texturenloader wechselst und nicht alle Koordinaten manuell ändern möchtest) wäre eine Alternative die Bilddaten der Textur entsprechend anzupassen bevor du die Daten an die Grafikkarte sendest.

_________________
Nichts auf der Welt ist so gerecht verteilt wie der Verstand. Denn jederman ist überzeugt, dass er genug davon habe.
Rene Descartes, frz. Mathematiker u. Philosoph, 1596-1650

Das was du dort sagst ist technisch nicht möglich oder ich stehe gerade auf dem Schlauch. Diagonal kann die normal gar nicht gespiegelt werden. Das würde ja bedeuten, dass ich Zeilenweise von oben nach unten mehr spiegeln würde. (Wenn ich das richtig verstanden habe.)

Zeig mir mal bitte ein paar Bilder. Und vor allem was für Dateien lädst du denn damit? Wenn es ein Fehler sein sollte, dann werde ich das natürlich umgehend beheben.

Das hat mich ebenfalls verwundert. Das erste Bild zeigt die Darstellung mit deiner Unit, das zweite Bild mit der Unit von Jan Horn und in Paint. Die Hauptanwendung wird nicht verändert, es werden für beide die gleichen Texturkoordinaten verwendet, wie sie im ersten Post stehen. Ich habe mir erst gestern die aktuelle Version, 1.17 vom 22.05.2004, von deiner Seite geholt.

Gruß und Danke
KidPaddle

_________________
http://www.seban.de

Lass mich raten. Deine Bmp hat eine Breite die nicht durch 4 Teilbar ist?

Ich benutze zum Laden von Bmp's die Klasse TBitmap von Delphi. Die Textures.pas (und die die glBmp.pas) machen dies händisch und haben dabei etwas vergessen. Wenn du Breite nicht durch 4 teilbar ist, dann existieren Spacerbytes. Kann es sein, dass das Problem vorher bestand und jetzt durch meine Unit weggegangen ist? Auch auf die Gefahr hin, dass das ein wenig arogant klingt. Hast du da vorher vielleicht deine Texturkoordinaten an die Textures.pas angepasst?

Du hast Recht, die Texture war 87x112 Pixel und nachdem ich diese auf 88x112 geändert habe, wurde diese nur noch auf dem Kopf dargestellt, was aber durch einen FlipVert() behoben werden kann.

Vielen Dank für den Hinweis.

Gruß
KidPaddle

_________________
http://www.seban.de

Allerdings finde ich es immer noch extrem merkwürdig, warum dieses Problem mit meiner glBitmap.pas aufgetreten ist! Kannst dur mit mal das Bild mit 87x112 zuschicken? Ich hatte zwar gerade schon mal mit Paint und der Unit rumgespielt aber dort sah das Ergebniss überall gut aus.

Ich habe das alles nochmal intensiv und aus allen Seiten beleuchtet und konnte es dann auch reproduzieren und meine das Problem gefunden zu haben. Hier meine wissenschaftliche Abhandlung darüber.

Als Erstes aber noch mal ein Hinweiß. Solche Texturen (87x112 oder auch 88x112) sind KEINE gültigen OpenGL Texturen. Diese müssen immer eine Größe von 2^x * 2^x haben. Also eine Potenz von 2. Außer es wird die Extension ARB_texture_non_power_of_two unterstützt.

Jetzt zu dem Problem. Folgendes Szenario ist bei dir eingetreten. Du hast eine Textur, welche keinen Alphakanal besizt und deren Breite nicht durch 4 teilbar ist. Sobald kein Alphakanal existiert geht mein Loader her und benutzt für jedes Pixel nur 3 Bytes. Bei dem BMP welches du verwendet hast sind am Ende einer jeden Zeile 3 Bytes. 87 (Pixel) * 3 (Bytes) = 261 (Bytes). Die nächste größere durch 4 teilbare Zahl ist 264. Also 3 Bytes unterschied.

Wenn man jetzt versucht diesen Speicherbereich direkt mittels glTexImage2D auf die Grafikkarte zu laden geht der Vorgang schief und man erhält nur eine weiße Textur. Da es sich ja nicht um eine gültige OpenGL Textur handelt. Mit der Hilfsfunktions gluBuild2DMipmaps funktioniert dies zwar, aber nur da die Methode die Texturen in ihrer Größe anpasst. Allerdings möchte diese Funktion wieder eine Breite (in bytes) die durch 4 teilbar ist. Die Textures.pas hat die Spacerbytes in dem BMP mit an die gluBuild2DMipmaps übergeben und das hatte somit funktioniert. Allerdings wenn du eine Textur gehabt hättest, die hell gewesen wäre, würde dir dort wahrscheinlich ein dunkler Streifen am unteren Ende der Textur aufgefallen sein. Dort wäre dann nämlich der Speicherbereich der Textur zu Ende gewesen, da die Textures.pas die Spacer nicht in seine Berechnungen einfließen lässt und sie unbewusst mit in den Texturspeicher übernimmt.

Da ich (mittels TBitmap) bereits auf die Spacer reagiere habe ich eine ungenaue Anzahl an "Fehlern" (nämlich einen) gehabt und diese haben sich somit nicht negiert. Was bei der Textures.pas (2 "Fehler") der Fall gewesen sein dürfte. Wenn du in die Textures.pas das selbe Bild als TGA laden würdest dürfte das genau so aussehen wie bei mir. Bei mir ist es mit einem TGA aber auch genau so wie bei einem BMP.

Lange Rede kurzer Sinn. Wenn du die Texturen ein wenig veränderst geht es ja.
Du solltest aber für 2D auf MipMaps (TglBitmap2d.BuildMipMaps := False) verzichten, da man die dort eh nicht braucht (sparrt Speicher und wird auch schneller geladen) und dann solltest du die Texturen auch alle in 2^x ablegen. Da sie sonst nicht akzeptiert werden würden.

Ich bin mir momentan noch nicht sicher ob ich etwas in die glBitmap.pas einbauen werde um auf dieses Phänomen zu reagieren. Das weiß ich allerdings noch nicht.

Vielen Dank für deine Bemühungen. Das die Texturen nicht 2^n konform sind, ist mir bekannt und wird auch geändert. Es wird später ein Texturmanager eingerichtet, welcher aus kleineren Texturen eine grosse mach soll. Bin mir noch nicht im klaren, wie ich es umsetzten soll, aber es gibt genügend Raum für Verbesserung.

Zur Zeit bin ich am Anfang des Spieles. Mittlerweile kann ich Gegner abschießen, ein SoundManager ist integriert. Hintergrundmusik und Soundeffekte werden abgespielt. Als nächstes kommen Animationen und Schriften, woran ich gerade bastle.

Gruß
KidPaddle

_________________
http://www.seban.de

Kurze Frage. Wie würdest Du am besten eine pixelgenaue Kollisionsabfrage mit deiner Klasse implementieren? Ich müßte auf die Pixeldaten mittels (X/>) - Koordinaten darauf zugreifen.

Gruß
KidPaddle

_________________
http://www.seban.de

Kein Problem. Ich will ja schließlich auch wissen, wenn meine Quellen nicht ganz so gut Funktionieren oder Eigenheiten an den Tag legen.

Aber zu deiner Frage. Ich habe da mal ein bisschen überlegt. Ich würde dabei nicht direkt auf die Texturdaten zugreifen. Das hätte den Nachteil, dass du die gesamten Texturdaten vorhalten müsstest und diese dann jedes Mal durchsuchen müsstest. Ich würde die Klasse TglBitmap2d ableiten und die Methode GenTexture überschreiben. In dieser Methode würde ich mir dann mittels GetData den Pointer von meinen Texturdaten geben lassen und dann entweder den Alphakanal oder den Farbkanal durchsuchen und Kollisionsinformationen in einem seperaten Bereich der Ableitung ablegen. Wie die Infos aussehen liegt an dem Einsatzgebiet und wie der Kollisionsalgorithmus aussieht. Evtl brauchst du eine Pixelmaske (einzelnen Bits oder ein ganzes Byte).
Wenn du dann deine arbeit fertig hast rufst du inherited auf, damit die Klasse die Textur laden kann. Aber erst am Ende der Methode, da meine Klasse normalerweise die Bilddaten nach getaner Arbeit frei gibt um Speicher zu sparen.

Einen direkten Pixelzugriff möchte ich von außen nicht einbauen (glaube ich jedenfall), da die Daten ja freigegeben werden und die Adressierung von einzellnen Pixeln nicht die schnellste Alternative ist. Wobei ich für meine Functions so etwas auch nicht schlecht finden würde. Pixelübergreifend. Ein Teufelskreis.
Ich glaube ich muss das mal überarbeiten, da ich SGIS_generate_mipmap auch noch anbieten möchte. Aber wenn du das ganze Bild durchsuchen möchtest würde ich sowieso empfehlen direkt auf den Speicher zuzugreifen. Und da ist die oben beschrieben Ableitung das Sinnvollste.