Hallo,

aus welchen Gründen implemenierst du das mit FPC neu? Einfach nur so weil du Lust drauf hast, oder hat Java irgendwelche Nachteile die du mit FPC umgehen möchtest?

MfG Bergmann.

Ich bin mir 99% sicher, dass FPC intrinsics hat, ich schätze du meinst keine intrinsic für SSE und NEON.
Zu FPC Zeiten hab ich so den code geschrieben, dass der compiler SIMD optimiert hat aber aus heutiger sicht war das keine Gute Idee, da unterschiedliche Compilerversionen dann unterschiedliche Ergebnisse haben können und man sich auf lange Sicht in Teufels Küche begibt.
Ich wette, dass sich schon wer die Arbeit gemacht hat den nötigen asm code zu schreiben bzw. kannst du ja auch mit gcc eine c++ lib nehmen und den asm code generieren lassen und dann in fpc benutzen.
Sonnst ist es ein recht großer Aufwand alle nützlichen SIMD Operationen zu implementieren.
Um mir Arbeit zu sparen hab ich z.B. meine Optimierungen mit dem SSE satz geschrieben und nutze ein NEON wrapper um dann auch noch ein gewissen grad an optimierung auf ARM Systemen wie NV-K1, Raspberry Pi und Orange Pi zu haben.
In der Praxis hat sich gezeigt, dass SIMD in Klassen zu kapseln und dann diese zu verwenden die Geschwindigkeitsvorteile stark reduziert hat und daher schreibe ich nun für die meisten Sachen passenden Code und hab mich von der Kapselung getrennt.
Optimiert sind auch nur einige Teile, wie z.B. ne Hand voll String Operationen mit SSE4.2 und SSE2, sowie ein paar Container Klassen Operationen.

Mich interessiert vorallem das Thema "Entity Component System", da ich selber mal ein Fast Entity Component System nachgebaut hab und es sich vom Klassischen System doch ein bisschen unterscheidet.
Bisher hatte ich aber noch nicht erlebt, dass ein Game seine größte Last auf dem ECS hat, sondern meistens bei der Resourcen Verwaltung(Clientseitig) und Logging(Serverseitig).

Debug-Visualisierungen kann man leider nicht soviel im Netz finden, obwohl es so wichtig ist.
Ich hatte so manche Alpträume bei dem Thema, in meiner letzten Firma.
Wenn man ein ganzen Kontinent hat, der voll mit Sphären, Polygonen ist, um Audio Emitter zu visualisieren oder Viele Spheren für tausende vom Bäumen, weil Artists in einem generierten Cluster nochmal jeden einzelnen Baum anfassen wollen.
Unsere Debug Visualisierung war recht renderintensive, weil wir ein riesiges Areal hatten und man erkennen sollte ob ein Objekt den Boden Schneidet oder verdeckt wird und damit haben wir ein Mehrpass Verfahren benötigt. Erst die Szene rendern, dann Tiefentest auf kleiner stellen,farbe wechseln und die Debug Visualisierung rendern und dann den Tiefentest auf größer/gleich, farbe wechseln und nochmal rendern.
Auch die Geometry, die man braucht benötigt man eigentlich nicht in normalen Games, daher mussten wir erstmal Code schreiben für Linien, Bogen, Kreise und so weiter.
Da ging dann auch die GF960 mit 800x600 auf 12FPS runter, wenn man in einigen Debug modies in den Horizont geguckt hat :\ .
Wir hatten nie Zeit bekommen uns gedanken darüber zu machen, wie man sowas überhaupt optimieren kann.