Tigre - Mobile 3D Grafik Engine

Die Tiny Graphics Engine Tigre ist wie der Name schon sagt eine Grafik Engine mit dem Ziel schnelle und stabile 2d und 3d Anwendungen programmieren zu können. Gerade bei Spielen oder aufwändigen User Interfaces ist es wichtig das professioneller Code die Qualität sicher stellt. Während auf dem Desktop und Konsolen diverse Engines verfügbar sind ist im mobilen Bereich fast nichts zu finden. Tigre stellt eine API zur Verfügung die dem Programmierer viel Arbeit abnimmt und auch fortgeschrittene Grafikeffekte ermöglicht. Selbst Anfänger können damit relativ einfach 3d Anwendungen erstellen. Da die Engine auf OpenGl ES setzt werden aussergewöhnliche flüssige und beeindruckende Animationen möglich. Die Bibliothek ist kostenlos und auf das .NET Framework 3.5 ausgelegt. Um Programmieren einen schnellen Einstieg zu ermöglichen und auch Interessierten zu zeigen was alles möglich ist, gibt es die Tigre Demo Suite welche derzeit 11 verschiedene Beispiele zeigt. Die Engine befindet sich in fortlaufender Entwicklung, wer also Ideen für neue Features hat oder selbst entwickeln möchte ist dazu herzlich eingeladen. Derzeit befinden sich bereits 2 Spiele und eine Anwendung in Entwicklung die Tigre nutzen, mehr dazu wird sicherlich bald folgen.

Überblick der aktuellen Demos für Interessierte
Mehr Details zu Tigre für Entwickler
Anhang 21227

das sieht ja soweit schonmal nicht schlecht aus - aber netframework ? das geht wohl nicht etwas effizenter....

ich glaube, das mobiltelefon, als konsole wird sich erst mit dem tegra durchsetzten....

Ich habs intern getestet, gleicher code mit c# und c++. Der Performance unterschied ist minimal, oft weniger als 1 bild pro sekunde. Dank .net ist Tigre aber viel kompatibler und wird wohl auch direkt auf wm 7 laufen. Zudem denke ich das die Performance für aktuelle Geräte durchaus als gut bis sehr gut zu bewerten ist (Mesh Demo -> 30 bis 50 FPS je nach Gerät).

Wie man bei der Konkurrenz von Apple ja sieht haben mobile 3D durchaus ihre Berechtigung. Da könnte Tigre doch durchaus helfen das mehr Spiele kommen, denn die Entwicklungszeit kann wirklich drastisch gekürzt werden.

Statt dem Tegra würde ich eher sagen das sich ein grosser Schritt abzeichnet wenn mehr Geräte OpenGl ES 2.0 unterstützen, egal welcher chip die Arbeit übernimmt. Ach ja, Unterstützung für OpenGl ES 2.0 ist bereits in Arbeit, dadurch werden theoretisch Spiele möglich die die Grafikqualität von aktuellen Konsolen haben!

Erwarted jetzt aber nicht die gleichen Spiele wie von den grossen Platformen. Auch wenn es technisch möglich ist macht es keinen Sinn z.B egoshoter auf das phone zu bringen. Auf mobilen Geräten sind ganz klar mehr Spiele für zwischendurch gefragt!

Ist ja sehr interessant. Werde das sicher mal zumindest in einer Testapplikation ausprobieren.

Zitat:

---

netframework ? das geht wohl nicht etwas effizenter

---

Gibt es immernoch diese Vorurteile? Aber wie ich sehe, bist Du FISI :). Die stehen MS ja oft kritisch gegenüber :D.

EDIT: Gibt es eigentlich XNA für .net CF?

Wieso kann ich eigentlich keine animation gescheit sehn? da bewegt sich was, aber es lassen sich keine formen erkennen?!

@Holzbrett: XNA gibt es eben nicht für WM, das war einer der Gründe wieso ich die Entwicklung von Tigre gestartet habe.

@WeisserWolf: welche der demos meinst du denn? Hoffentlich kann ich dir helfen:)

Zitat:

---

Zitat von Holzbrett

Gibt es immernoch diese Vorurteile? Aber wie ich sehe, bist Du FISI :). Die stehen MS ja oft kritisch gegenüber :D.

EDIT: Gibt es eigentlich XNA für .net CF?

---

nunja, ich bin eig recht ms freundlich ;)

aber es ist ja so, dass software unter c++ oder anderen hardware nahen sprachen einfach schneller ist. Denn nicht umsonst werden die meissten 3D engines nicht mit einer framework basierenden sprache (java, .net) geschrieben.

Ich find es einfach nicht so toll, wenn man leistung "verschwendet"

Gebe dir recht das die meisten engines in c++ geschrieben werden und dass keine Leistung verschenkt werden sollte. Wie bereits oben erwähnt ist der Unterschied jedoch minimal. Ich habe mich schlussentlich für .net entschieden da eigentlich so gut wie keine Leistung verschenkt wird, jedoch ist die kompatibilität und stabilität deutlich besser. Erwähnenswert ist viellecht auch das intern fast alle kritischen Stellen "unmanaged" sind.

Das eigentliche Problem ist nicht das Framework, sondern die Tatsache, dass der Code erstmal von CIL in Maschinencode kommt.. Drum kann einen unsafe Code hier auch nicht viel helfen. Aber die CIL bietet viele Vorteile. Und der Code ist i.d.R. recht gut optimiert. Früher hatte der Prozess des Ladens der .Net Komponenten etc. recht lange gedauert. Ich erinnere mich noch, dass wir zu .Net 1 Zeiten für langsame Rechner ein kleines Splashscreen in C++ angezeigt haben, weil man manchmal meinen konnte, es passiert nix. Ich denke daher kommt das ".net ist langsam".. Klar läuft hier vieles durch die Laufzeit durch, dafür ist das dann aber (wenn nicht anders deklariert) "safe". Unsafe hätte nur den Vorteil nicht nocheinmal überprüft zu werden, aber ich denke inzwischen (.Net 4) gibt es dafür, aus Sicht der Perfomance, kaum noch Gründe. Und bei den heutigen Rechnerleistungen ist das eh irrelevant. Soll jetzt nicht heißen, dass wir für einen benötigten Bit jetzt int64 hernehmen, weil wir's ja haben, aber im Großen und Ganzen ist das inzwischen etwas anderes als damals.. Bei WM-Geräten müsste man jedoch noch ein wenig drauf schauen, da gebe ich recht. Nicht jeder PPC hat mal eben 512 MB RAM oder mehr und einen 1GHz Prozi :).

IMHO liegt der größere Leistungsunterschied oft an den Entwicklern. Ich kann z.B. in Schleifen Images bearbeiten, die Referenz jedoch stets nur verbiegen, sodass alle bisherigen Objekte solange im Speicher bleiben, bis das OS schreit / der GC aktiv wird. Man kann's aber auch lassen :). Dispose / Using ;).

Aber mal abgesehen von alle dem, find ich das, was Du da hingestellt hast wirklich super!

Grüßchen

Ich hab mir das hier runtergeladen und aufm Touch HD installiert Tigre Demo Suite ( 622.78 Kb, 141 downloads).
Wenn ich jetzt aber irgendeine Demo starte, flimmern da ein paar Striche und Farben durch die gegegend und mehr nicht, das ist bei allen Demos der Fall :-/

@Holzbrett: danke;-) bin absolut deiner Meinung. Nicht vergessen dass der IL Code zur Laufzeit in native Maschienensprache übersetzt wird. Ab dann ist der Code dann eigentlich nativ und damit gleich schnell, so sollte das Rendering wirklich in etwa gleich schnell sein.

@WeisserWolf: Was hast du denn für ein Gerät und verwendest du auch den richtigen Treiber? Öffne doch mal die Textur Filter Demo, dann Menu->Info und sagst mir was unter "OpenGL ES" bei "Renderer", "Vendor" und "Version" steht.

Mit einem HTC Touch Diamond mit dem "Q3Dimension MSM7500W" funktionieren einige der Demos nicht.

Welche Demos sind denn das und was heisst "funktioniert nicht"? Kommt es zu einer Fehlermeldung, startet die demo nicht oder ist nichts zu sehen?