Vorteil 2d in ogl gegenüber dd
-
Original erstellt von 0x00000001:
**Mag sein dass DD etwas schneller ist, aber wenn Du erstmal was mit Polygonen gemacht hast willst Du nix anderes mehr. Du kannst sie beliebig transparent machen, beliebig drehen, leichter animieren....
**Drehen kann man "2d bitmaps" auch, transparent machen ist auch kein Prob, was meinst du mit animieren?
-
soweit ich weiß kann man in dd nur colorkeys machen, nicht unbedingt was transparents zeichnen.
falls man etwas mit dd macht, wird's internet eh so gemacht, als ob man selber die 3d hardware benutzen würde, denn speziele 2d sachen braucht man ja nicht in hardware einzubauen, da die 3d hardware das schon optimal kann.rapso->greets();
-
...falls man etwas mit dd macht, wird's internet eh so gemacht...
das ist irrelevant für jemanden der eine 2d-api sucht. ausserdem ist es für "anfänger" besser die 2d-routinen zu benutzen anstatt sie alle mit 3d selber zu schreiben, da man ja auch dinge falsch programmieren kann und dd wahrscheinlich geschwindigkeitsoptimiert ist.
[ Dieser Beitrag wurde am 28.06.2003 um 17:58 Uhr von KXII editiert. ]
-
Man kann mit DD doch keine Bitmaps gescheit drehen. OK, um 90, 180, 270°, aber frei drehen kriegst Du nicht hin, zumindest nicht schnell.
Animieren kann man auch sehr gut, zB kann man Rauch langsam ausblenden.
Schau mal unter meinem Link in der Signatur, da hab ich einen Ballerburg-klon zum Download. Ist auch 2D, aber ich behaupte mal dass Du das nur schwer mit DD nachmachen könntest.
-
Jo, deinen Ballerbaurg Klon sieht schick aus
*lob*die Funktionen fürs Drehen und transparent zeichnen muss man ja selber schreiben, aber dann willste mir doch nicht weis machen dass es schneller wär en polygon zu drehen als ein "bitmap", oder? wegen des transparent machen genauso!
EDIT:
mal ne frage, sind das alles "ganz normale quads mit textur", dann gibt es doch das problem dass die texturen potenzen von 2 sein müssen(?), oder haste es wie bei OGL (weiß nicht obs sowas auch in dx gibt) im otho mode gemacht?[ Dieser Beitrag wurde am 28.06.2003 um 21:20 Uhr von DasPinsch editiert. ]
-
Natürlich kann man Polygone schneller drehen als Bitmaps. Dafür setzt man einfach eine Matrix die die Drehung enthält, dannach wird alles gedreht angezeigt ohne dass es irgendwelche zusätzliche Rechenzeit kostet.
Deine andere Frage versteh ich überhaupt nicht
Ja, das sind alles nur 'Quads'.
Ja, alle Texturen müssen 2er Potenzen breit/hoch sein.
Es ist ganz normale Projektion, kein Ortho. (Mit Mausrad oder RechteMaus kann man zoomen) Die Polygone stehen einfach nur senkrecht zur Kamera.
-
in 2d braucht man nur eine 3x3 er matrix
-
wo ihr grad mal so schön dabei seid
ich hab ne frage (bevor ich nen neuen thread auf machen muss)kennt jmd ne gute seite zu 2d opengl tutorials? ich muss mich damit gezwungenermaßen beschäftigen da ich ein paar spezielle algorithmen visualisieren muss
bye
-
Original erstellt von KXII:
das ist irrelevant für jemanden der eine 2d-api sucht. ausserdem ist es für "anfänger" besser die 2d-routinen zu benutzen anstatt sie alle mit 3d selber zu schreiben, da man ja auch dinge falsch programmieren kann und dd wahrscheinlich geschwindigkeitsoptimiert ist.[ Dieser Beitrag wurde am 28.06.2003 um 17:58 Uhr von KXII editiert. ][/QB]
er hatte gefragt ob DD schneller ist, wenn ich ihm sage dass DD intern das gleiche macht, als ob man das selbst machen würde, dann ist das nicht irrelevant, sondern eine erklärung, wie's einfacher nicht geht.
rapso->greets();
-
woher willst du aber wissen das es 100% so ist? es muss ja nicht so sein. und es ist auch egal ob es so ist.
denn...
du hast geschrieben:
...denn speziele 2d sachen braucht man ja nicht in hardware einzubauen, da die 3d hardware das schon optimal kann
es gibt sehr wohl 2d-beschleunigung! und selbst wenn die 3d-engine in der karte das optimal kann, heisst das ja noch lange nicht, das man es nicht noch optimaler machen kann, wenn man es nur für 2d macht. DESHALB meinte ich, ist es irrelavant zu wissen, wie es tatsächlich gemacht wird, wichtig ist nur, das es möglichst schnell gemacht wird. und da ist es nun mal wichtig ob opengl oder dd schneller ist (das wollte er ja wissen). opengl macht ja auch nix anderes als die 3d-unterstützung zu benutzen, wenn man opengl nur für "2d" benutzt.
ich meine, das wissen zu haben ist ja ganz nett. aber, um ein beispiel zu bringen, das hört sich so an, als ob man über "kuchen backen" redet und erwähnt, das man mit dem backofen auch "hänchen grillen" kann. das ist toll zu wissen spielt aber für das "kuchen backen" keine rolle!
ps: ich wollte dich nicht angreifen! es hat sich für mich nur etwas "überflüssig" angehört, und ich konnte meinen trieb es zu äußern nicht unterdrücken. entschuldige vielmals!
-
Original erstellt von KXII:
ps: ich wollte dich nicht angreifen! es hat sich für mich nur etwas "überflüssig" angehört, und ich konnte meinen trieb es zu äußern nicht unterdrücken. entschuldige vielmals!Ahahahaha...
Oh großer weiser Gebieter, der XII.!
Ich wollte euch auch niemals angreifen!
Entschuldigt meine Unwürde, meinen falschen Stolz, einen so gewaltigen Herrscher wie ihr es seid zur Rechenschaft zu ziehen!
Mit Genuß werde ich mich meiner Strafe hingeben, sei es nun ein feuriger Tod auf dem Scheiterhaufen, oder ein fleischiger in der Löwengrube.
Nichtsdestotrotz werde ich euch immer in Ehren halten, denn nur euch hab' ich die Treue geschworen. All euren Feinden werde ich mein Schwert entgegenschleudern!Euer treuer Ritter Sarge!
All hail to the King!
-
ich will es nicht wissen, das ist nur das was ATI und NVidia in deren papern sagen.
nämlich dass man durch DD die graka und deren treiber zur unoptimaler arbeit zwing, das ist ja der grund weshalb in DX8 DD nicht mehr supported wurde.
und es klingt irgendwie lächerlich, wenn du schreibst dass man es mit 2d schneller hinbekommt als mit 3d, wenn der treiber indern alles sowieso in 3d umsetzen muss
um bei deinen suessen beispielen zu bleiben, es klingt so, als würdest du ne maschine haben, die für jedes rezept ein spezielles optimales backprogramm hätte und du das durch manuelle einstellungen "besser" hinzubekommen glaubst, die maschine dann intern aber approximiert das passedste voreingestellte programm für deine individuellen einstellungen raussucht und dann doch alles so abarbeitet, wie's urprünglich gedacht war.... es kann nur schlechter werden, falls deine einstellungen so gravirend waren, dass für deine brötchen ein bretzel-backprogramm gewählt wuerde.
man baut heutzutage nichtmal mehr TnL rein und emuliert das mit vertexshadern weil die transistoren zu kostbar sind um sie selbst für TnL zu verschwenden, und das ist bei 2D funktionalität spätestens seit der GeForce generation so.
die grakas haben intern nur 3d, es wäre viel zu verschwenderisch extra 2d funktionen einzubauen, die alle genauso gut mit 3d gemacht werden können, denn da haben die hersteller sicherlich nicht rumgepfuscht und bei den ganzen funktionen einfach den z-wert auf 1.f zu setzen sollte ja nicht das problem sein.was man aber optimaler machen kann wenn man 3D nutzt anstatt DD ist z.B. power2 texturen verwenden, anstatt z.B. 513*513 surfaces die dann von der graka in 1024*1024 texturen gestopft werden, man kann texturepages bauen und diese optimal gefüllt in die graka schieben. anstatt jede textur wie man es will zu zeichnen, kann man die renderaufrufe cachen und am ende in optimaler reihenfolge zeichnen. sowas bringt extreme performancesteigerungen gegenüber stumpfen DD aufrufen und deswegen machen das spiele heutzutage so.
rapso->greets();
-
@raspo
Das hört sich interressant an was du da sagst. Könntest du das mal weiter erläutern, oder hast du irgendwelche pages oder beispiele darüber?Ich programmiere nämlich auch gerade einen 2D Wrapper für D3D9m, und weiß nicht genau wie ich das machen soll mit den ganzen Texturswitches.
-
also das ganze läuft im preprozessing soweit es geht, dafür gibt es viele möglichkeiten, zwei wären:
du machst dir ein programm das alle bilder auf möglichst wenig _gleich_grosse_ texturen verteilt. dann merkst du dir jeden renderaufruf immer die aktuelle textur, die position/ausmasse auf ihr und die position/ausmasse auf dem bildshirm.
das schwere nun ist das sortieren, du mußt dafür sorgen, dass die texturen die benutzt werden möglichst hintereinander liegen, dabei mußt du aber auch aufpassen, dass sich überlappende objekte mit transparenz nicht in der reichenfolge ändern dürfen.. das sortieren kann einem schon kopfzerbrechen bereiten.zweite möglichkeit besteht aus zwei möglichen wegen, es bassiert darauf, dass du dir während des renderns merkst in welcher reihenfolge das zeichnen aufgerufen wurde und dann kannst du die texturausschnitte die zusammen benutzt wurden auch in die selbe texturpage stecken, dabei ist die effizienz der ausfüllung der texturen nicht unbedingt so hoch wie beim ertsen algorithmus, aber falls du von deinen 400MB bildern nur immer 50MB sehen kannst, dann wird durch diese lokale haltung der daten viel performance gewonnen z.B. bei verschiedenen 2d menüs von denen man immer nur eines sehen kann.
alternativ kann man sich die texturepages zur laufzeit generieren, das wird benutzt, falls du z.B. in einer großen texturepage mit der level noch deinen animierten charakter reinstecken möchtest.und beim 2d rendering immer schön auf das texelcenter achten, ist bei ogl ja anders als bei d3d (falls dein wrapper beides können sollte)
ach ja, benutze niemals dxt texturen für animierte sachen, aber nutze sie viel für statische dinge, dxt texturen kann man ja genau wie jede andere textur auch, gut kopieren und in einer page zusammenlegen.
fragen?
rapso->greets();
-
Hört sich nicht schlecht an. Ich werde es mal versuchen ob ich es hinbekomme. sonst kann ich dich ja sicherlich nochmal fragen.
-
Hi! Erstmal danke für die antworten! Habe ich das richtig verstanden, dass theoretisch 2d schnelle sein müsste, da weniger gerechnet werden muss, tatsächlich jedoch 3d schneller ist, da die hardware darauf angepasst ist?
Kennt einer vielleicht ein Tutorial wo "2d in 3d" erklärt wird? Auf Ortho Mode hatte ich eigentlich kein bock, da man dann ja das standart 2d problem haben dürfte dass Objekte in verschiedenen auflösungen unterscheidlich groß sind, oder?
-
Der Ortho Mode ist genau wie der Perspektive Mode(nur eine Matrix die gesetzt wird mit der die Vertiezes verrechnet werden), nur das es dann eben keine perspektivische verzerrung gibt.
Die Objekte behalten immer die gleiche Form auch wenn sie ganz weit hinten im Bilschrim sind.Man kann es eingeltich nicht Mode nenn also sorry.
-
ups, ich hatte dich falsch verstanden.