OpenGL ES Pascal-Header

[carli]

Ja zurück zum Thema
Da steht viel was ich nicht verstehe und ich kenne auch Pascal nicht(weis nur dasses ne Programmiersprache ist :-D ),
aber haben wir hiermit eine funktionierende 3d Beschleunigung auf der Pandora auf Ogles Basis?

Ja, definitiv. Klick zum ausprobieren

Wenn ja gibts auch einen Opengl Wrapper der die Befehle von OpenGL auf Ogles umsetzt?
Dann könnten viele von uns ja 3D Linux Spiele Porten die normalerweise ne OpenGL 3D Beschleunigung brauchen.
Hab ich das Richtig verstanden?

Das hast du richtig verstanden, es ist auch rein technisch möglich. Allerdings macht es performancetechnisch keinen Sinn. Der 3D-Chip auf der Pandora ist nicht der stärkste und durch das hin- und her wrappen wird es nur zusätzlich langsamer. Selbst beim Spiel "pfahrer", das ja total übersichtlich und klein ist, hat das Spiel extrem geruckelt vor der Optimierung. Wenn du da nicht optimierst, sondern auch noch einen Wrapper dazwischenschaltest, würde ich das Resultat als "unspielbar" einstufen.

Oder gilt diese 3D Ogles Beschleunigung jetzt rein "nur" für Pascal?

Nein, aber jetzt kann man sie auch mit Pascal nutzen.

 

[Kaworu]

Hi carli..

Habe grade mal dein Spiel kurz getestet und war erschrocken darüber wie wenige Bilder pro Sekunde gerendert werden.
Wenn so etwa 5 Panzer gleichzeitig dargestellt werden, bricht die FPS stark ein. Und das obwohl von Optimierung
die Rede war

Nun frage ich mich woran genau das liegt.. Du sagtest ja bereits Fließkommazahlen zu nutzen..
Das wird bestimmt einen Teil zu beitragen. Könntest du mal versuchen auf Integer umzusteigen
und dann nachzuskalieren?

Oder könnte es etwas mit den Warnungen 'Unknown EABI object attribute 44' zu tun haben beim kompilieren?
Vielleicht werden die Fähigkeiten des Prozessors nicht ganz ausgeschöpft?
Warum genau erscheint diese Meldung und ließ sich bisher nicht lösen?
(da das Thema im repo erwähnt wurde würde ich gerne mehr zu sagen können)

Man müsste mal nen Benchmark für C++ und Pascal schreiben, der alle möglichen Funktionen nutzt und dann
die Leistung ausgibt.


Ansonsten ist es schön zu sehen dass in diesem Fall die Portierung mit deinem Paket aus FPC und OpenGL ES Headern realisierbar war

 

[xyta]

Also der Screenshot sieht ja schon mal sehr vielversprechend aus. :juhu:

Wenn es ogles ist, heisst das dann, dass es eine volle 3D-Grafik ist, oder benutzt du es nur, um Hintergründe und Grafiken übereinander zu legen? ??

Da steht viel was ich nicht verstehe und ich kenne auch Pascal nicht(weis nur dasses ne Programmiersprache ist

Du kannst dir ja mal Freepascal runterladen, dann unter \Freepascalverzeichnis\Version\bin\Plattform (i386-win32)\FP.EXE starten, und dann dort dieses Tutorial durcharbeiten (Ab Kap. 1, Lazarus brauchst du erstmal nicht).

 

[carli]

Hi carli..

Habe grade mal dein Spiel kurz getestet und war erschrocken darüber wie wenige Bilder pro Sekunde gerendert werden.
Wenn so etwa 5 Panzer gleichzeitig dargestellt werden, bricht die FPS stark ein. Und das obwohl von Optimierung
die Rede war

Nun frage ich mich woran genau das liegt.. Du sagtest ja bereits Fließkommazahlen zu nutzen..
Das wird bestimmt einen Teil zu beitragen. Könntest du mal versuchen auf Integer umzusteigen
und dann nachzuskalieren?

Die Draw-Befehle gehen immer an die GPU raus, deshalb liegt der Flaschenhals eindeutig bei der GPU und nicht bei den Floats.

Oder könnte es etwas mit den Warnungen 'Unknown EABI object attribute 44' zu tun haben beim kompilieren?
Vielleicht werden die Fähigkeiten des Prozessors nicht ganz ausgeschöpft?
Warum genau erscheint diese Meldung und ließ sich bisher nicht lösen?
(da das Thema im repo erwähnt wurde würde ich gerne mehr zu sagen können)

Liegt am FPC, vielleicht gibt's auch nen Compilerswitch. Ich glaub, die Meldung hab ich auch schon in so manchem Bugtracker gesehen. Fatal ist sie allerdings nicht.

Man müsste mal nen Benchmark für C++ und Pascal schreiben, der alle möglichen Funktionen nutzt und dann
die Leistung ausgibt.

Da verlieren wir doch

Wenn es ogles ist, heisst das dann, dass es eine volle 3D-Grafik ist, oder benutzt du es nur, um Hintergründe und Grafiken übereinander zu legen?

GLES legt sich nicht auf 3D oder 2D fest. In meinem Fall nutze ich GLES, damit ich die Schatten, die Landschaft und die Drehung der Panzer in 2D so schön berechnen kann.

 

[Kaworu]

Die Draw-Befehle gehen immer an die GPU raus, deshalb liegt der Flaschenhals eindeutig bei der GPU und nicht bei den Floats.

Naja, da führt aber kein Weg an der CPU vorbei. Auch die CPU muss die Werte verarbeiten und weitergeben. Da ich nicht annehme dass du Berechnungen
für die Bewegung per Shader löst, wird die CPU diese auch berechnen müssen. Allerdings sieht mir das Spiel nicht danach aus, als müsste es mit sovielen
Werten umgehen, dass es die geringe FPS erklären würde.

Irgendwo muss etwas nicht richtig laufen, denn so schwach kann die GPU eigentlich nicht sein.
Man siehts ja an zig Beispielen was diese leisten kann.

Da verlieren wir doch

Halte ich für eine sehr subjektive Annahme an die ich nicht glaube.

 

[carli]

Irgendwo muss etwas nicht richtig laufen, denn so schwach kann die GPU eigentlich nicht sein.
Man siehts ja an zig Beispielen was diese leisten kann.

Ja, ich müsste da auch noch ein bisschen optimieren. Momentan lass ich die GPU z.B. die Koordinaten komplett ausrechnen, was aber genauso gut auch auf der CPU getan werden kann. Außerdem hab ich kein Culling implementiert, das heißt, die Vertexdaten für Panzer, die man nicht sieht, werden auch an die GPU gesendet (und diese verarbeitet die auch noch)

Da verlieren wir doch

Halte ich für eine sehr subjektive Annahme an die ich nicht glaube.

Objektiv. Ich disassembliere gerne mal ein kleineres Programm, um zu sehen, wie gut der Compiler wirklich ist.
Das Ergebnis ist erschreckend: während der GCC noch die kleinen Sachen hinbekommt und bei Datenstrukturen dann Schluss ist, macht der FPC sogar unbedingte Sprünge auf genau die nächste Befehlszeile und solchen Irrsinn.

 

[xyta]

Da verlieren wir doch

Halte ich für eine sehr subjektive Annahme an die ich nicht glaube.

Objektiv. Ich disassembliere gerne mal ein kleineres Programm, um zu sehen, wie gut der Compiler wirklich ist.
Das Ergebnis ist erschreckend: während der GCC noch die kleinen Sachen hinbekommt und bei Datenstrukturen dann Schluss ist, macht der FPC sogar unbedingte Sprünge auf genau die nächste Befehlszeile und solchen Irrsinn.

Ja, davon hab ich leider auch schon gehört, dass der FPC momentan generell leider schlecht optimiert, und auch bei Win-x86 Delphi wohl wesentlich performanter ist. :-( Bei ARM sieht es noch düsterer aus...
Ein Neukompilieren mit neuen Versionen kann sich hin und wieder also lohnen.

Der große Vorteil an Pascal ist aber die gute Erlernbarkeit sowie die hohe Verbreitung in Europa, wodurch es viele Leute, wie z.B. Fusi, können. Und das mit der Performance wird sich mit der Zeit hoffentlich geben. Turbo Pascal war da ja seinerzeit wegweisend, also schnelle Pascal-Compiler sind durchaus möglich.

 

[carli]

Ein Neukompilieren mit neuen Versionen kann sich hin und wieder also lohnen.

Leider auch nicht. Die FPC-Entwickler sehen es nicht ein, dass bei einer Programmiersprache unter anderem auch die Geschwindigkeit zählt.
Na ich persönlich arbeite eh gerade an einer etwas moderneren Sprache "gwscript", die vor allem eins ist: schnell, einfach und bequem. Das ganze basiert auf der LLVM und da arbeitet unter anderem die Firma ARM kräftig an der Optimierung mit: http://botwars.tk

Vielleicht portier ich mal nen GLES+SDL Header für gwscript

 

[xyta]

Naja, auf jedenfall findet man immer wieder Benchmarks, nach denen FPC-Code immerhin schneller ist als Java, und auch damit wurden schon Spiele programmiert. Und Scriptsprachen wie Lua sind AFAIK auch langsamer.

Deine gwscript-Seite sieht ja schon mal interessant aus. Es wirkt auf mich beim Überfliegen wie ein Zonnon-Derivat, was mehr auf C-Kompatiblität getrimmt wurde. ??

 

[carli]

Naja, auf jedenfall findet man immer wieder Benchmarks, nach denen FPC-Code immerhin schneller ist als Java, und auch damit wurden schon Spiele programmiert. Und Scriptsprachen wie Lua sind AFAIK auch langsamer

Ja. Aber zwischen Java und C liegt das 10-Fache, wenn nicht gar mehr (und ein bisschen weniger, wenn man optimierte Spezialfälle nimmt)
Zwischen FPC und C liegt auch noch mal das 2-Fache. Zwischen LUA und FPC liegt gar das 100-Fache an Geschwindigkeit.

 

[fusion_power]

Naja, auf jedenfall findet man immer wieder Benchmarks, nach denen FPC-Code immerhin schneller ist als Java, und auch damit wurden schon Spiele programmiert. Und Scriptsprachen wie Lua sind AFAIK auch langsamer

Ja. Aber zwischen Java und C liegt das 10-Fache, wenn nicht gar mehr (und ein bisschen weniger, wenn man optimierte Spezialfälle nimmt)
Zwischen FPC und C liegt auch noch mal das 2-Fache. Zwischen LUA und FPC liegt gar das 100-Fache an Geschwindigkeit.

Kann man das so pauschal sagen? ich höre von Hundert Leuten hundert unterschiedliche Meinungen zu Java und dem Thema Geschwindikeit. Notch sagt, Minecraft wäre nicht schneller wenn es statt in Java in C++ oder dergleichen geschrieben worden wäre. Aber ob das so ist kann man natürlich nicht fest stellen. jedenfalls ist fakt, dass das mobile Minecraft nicht in Java gecodet wurde und wesentlich performanter ist als die PC Version.

 

[Kaworu]

Mann mann, wird hier stark verallgemeinert und subjektiv auf und abgewertet..

Nein, mann kann nichts so pauschal sagen.. Dass FPC mit Java verglichen wird
finde ich lächerlich, und auch dass C 2x schneller sein soll absolut unglaubwürdig..
Höchstens zur Zeit noch bei ARM-Prozessoren und dann wird das sicher noch verbessert
(weil ich da kaum von gelesen haben und keine Erfahrungen gesammelt habe kann ich in dem Fall nicht viel gegen sagen).

Es kommt immer auf die Fälle an, FPC wird definitiv in manchen Dingen auch schneller sein als C++,
und umgekehrt wieder bei anderen Dingen. Kommt doch drauf an wie genau man programmiert,
und welche Libs man nimmt. In FPC kann man genauso ASM-Code verwenden..

Heutzutage sind Programmierer einfach nur schlampig. Würden sie besser optimieren,
gäbe es diese enormen Unterschiede nicht, die man gerne aufzeigt um einen Compiler schlecht zu reden.

Macht Pascal doch nicht so fertig

Mein Spiel an das ich arbeite läuft selbst auf alten Rechnern flüssig, auf meiner neusten Hardware gibts 2000-3000 FPS,
obwohl es schon recht aufwendig wurde und wesentlich aufwendiger werden wird.. Selbst 65535 Männchen die alle ein anderes Ziel
verfolgen funktioniert absolut flüssig. Programmiert mit Delphi 7.0 und den Delphigl.com-Headern.
Nen großen Unterschied erwarte ich kaum, würde ich es mit FPC kompilieren.

Wäre Minecraft in C++ geschrieben, wäre es definitiv viel schneller,
da z.b. auch bessere Hardwareunterstützung durch die Grafikkarte gegeben worden wäre.

 

[carli]

Ich hab zur Zeit ein Fach namens Programmierung von Hochleistungsrechnern, da ist Fortran bei der Matrixmultiplikation 3 mal schneller als der beste C Code (während schlechter C-Code noch bis zu 10x langsamer sein kann)

Aber am Ende ist man mit einem guten Algorithmus immer noch schneller als mit einer guten Programmiersprache. Java ist nicht deshalb so langsam, weil der Compiler so schlecht ist, sondern weil man Datenstrukturen extrem vereinfachen muss und der Compiler nicht mehr weiß "was will der eigentlich"

Trotzdem im Großen und Ganzen würde ich in fast allen Bereichen Pascal C vorziehen, weil C einfach ekelig und umständlich ist. Mit Pascal kann man schneller und sauberer coden und der Compiler läuft auch extrem schneller.

 

[fusion_power]

Fortran gibts noch? Das ist doch schon antik, oder? :-D
Na jedenfalls kann ich auch nix negatives über Pascal sagen, es war halt unsere "Schul-Programmiersprache" auch wenn wir später mit C gearbeitet haben, was ich viel schwerer fand. So richtig drinne im coden war ich aber nie, hab da kein Talent für, ich war schon froh, wenn ich mit readln und writeln irgend was auf den Bildschirm bringen konnte, von grafischen Sachen oder richtigem Objekt orientiertem programmieren gar nicht zu reden. ^^
Aber für "professionelle" Spiele wird Pascal in der praxis weniger eingesetzt, oder?

 

[carli]

Fortran gibts noch? Das ist doch schon antik, oder? :-D

Die HPC-Leute behandeln Fortran als die Sprache der Zukunft, da sie mathematische Probleme viel effizienter löst. (die Matrixmultiplikation als Intrinsik reißt das alles raus)

 

[xyta]

Hm, wird Matrizenmultiplikation nicht eh über MMX, SSE & co quasi direkt auf dem Prozessor erledigt? ?? Wenn das hardwarebeschleunigt läuft, dürfte es doch kaum einen Unterschied machen mit welchem Compiler ich die Register befülle... :huh:

Was mir nur letztens zu Ohren gekommen ist, dass gerade Großbanken nach Cobol-Programmierern suchen für die Wartung tiefer gelegener Code-Schichten ihrer Mainframes aus den 70ern... Anscheinend gehen da die alten EDV-Hasen zur Zeit vermehrt in Rente. :-D

Aber für "professionelle" Spiele wird Pascal in der praxis weniger eingesetzt, oder?

Bis Anfang des Jahrtausends gab es durchaus noch das ein oder andere professionelle Pascal/Delphi-Spiel. Aber inzwischen hat man sich wohl mehr und mehr auf C/C++ geeinigt. Es ist Quasi-Standard für alle Projekte (wie MS Word), die Spieleprogrammierer kennen die Tricks, und nicht zuletzt sind auch die meisten SDKs für Konsolen auf C/C++ abgestimmt, so dass sich diese Spiele viel leichter portieren lassen. Das ist eigentlich das Hauptproblem, wenn dus gescheit angehst bekommst du deine C/C++-Spiele auch recht flott auf PS und XBox. Die Bedeutung des PC als Spieleplattform ist in den letzten Jahren auch deutlich zurückgegangen, darunter leidet dann auch Pascal.

Für uns hier gilt das aber nur eingeschränkt, mit FPC kannst du für p&|a , Beagleboard und natürlich PC programmieren; also alles, was offene Hardware hat.

 

[fusion_power]

Die haben noch Code aus den 70ern in ihren Systemen? Das wird ja immer besser. :-D

 

[xyta]

Anscheinend ja, wobei wohl verscheidene Emulationsschichten darumgebastelt wurden...

Never change a running system!

Das war überigends auch der Grund für die Jahr-2000-Problematik.

 

[fusion_power]

Wenn ich eins gelernt habe bei meinem Praktikum in der IT eines Krankenhauses ist, dass man es tunlichst vermeiden sollte ein System so aufzubauen, dass man es nicht mehr ändern oder auf neuere Hardware/Software portieren kann. Aber den Fehler machen sicher 90% aller Firmen, ich sag nur Internet Explorer 6. :unsure:
Wir hatten da ein antikes Inventar System, ein DOS Programm mit BIOS Grafik. OK, es hat halbwegs gut funktioniert aber irgend wann muss man auch mal was neues machen, irgend wann funzt DOS halt nichtm ehr auf neuen Rechnern, zumindest nicht wenn man auch das OS mal richtig updatet. Mein Praktikum ist schon 5 oder 6 Jahre her, mittlerweile könnten die da schon flächendeckend Windows XP einsetzen, bei dem Umstell Temopo das ich damals miterlebte, dort war auch 2006 noch viel mit WinNT in der Mache und ich meine nicht mal Windows 2000 sondern NT 4.irgendwas... einfach nur gruselig. :-D

 

[xyta]

dass man es tunlichst vermeiden sollte ein System so aufzubauen, dass man es nicht mehr ändern oder auf neuere Hardware/Software portieren kann.

Naja, diese Bankensysteme etc. stammen ja aus den späten 60ern bis 80ern, da war man froh, wenn man jedes KB einsparen konnte und ein funktionierendes Programm auf der Hardware zustande brachte (vgl. auch den bis heute erhaltenen Magnetstreifen auf der EC-Karte mit seiner handvoll Bits an Kapazität). Deswegen wurde ja die Jahreszahl meist nur zweistellig gespeichert. Es gab auch kaum Sprachstandards, und an Crosscompiler oder sonstige Laufzeitumgebungen war überhaupt nicht zu denken.

Aber genug OT...