Bei mir kommt außerdem immer der Error, dass die erste Zeile länger als 1024 Zeichen ist.

Ist mir nicht unbekannt - muss mal schaun wie ich das löse. Öffne die betroffene Datei einfach mit notepad und speicher sie wieder ab, das sollte das Problem lösen.

_________________
I'm not the signature, I'm just cleaning the floor...

Derzeitiges Projekt:
FireBlade Particle Engine (Release R2 2009.06.29)

Mit FPC geschrieben und mit Delphi <5 gelesen?
Dann ist es das fehlende #13 bei Dateiendungen.
Einfach mit einem richtigen Editor öffnen und als Windowsdatei speichern.

_________________
Steppity,✲steppity,✴step,❆step,✳step!
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❅ ☃ ❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ☃ ❄ ❆ ❄ ❄

OpenGL stellt um auf OOP, und du stellst zurück auf Prozedural?

Vielleicht hat niemand was geschrieben, weil er keinen Vorteil zu einer änderung sah.

Anstatt dir Arbeit zu machen mit dem umschreiben, solltest du die Engine lieber konsequent weiterentwickeln. Welchen Vorteil sollte eine Library haben? Leichter benutzbar in einem OOP Programm ist es bestimmt nicht.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Da muss ich Flash recht geben. Ich hätte mit für eine nicht-library gestimmt, aber ich habe mich kaum an dem Thema beteiligt und kenne die Engine auch nicht so gut.
Wenn du es sprachlich portierbar machen willst, dann nimm keine Library sondern mach deinen Code möglichst zu andern Sprachen kompatibel (Klammern um Bedingungen in Ifs, Klammern bei Befehlen ohne Parametern...). Vielleicht findet sich ja dann sogar hier jemand, der das freiwillig übersetzen würde, wenn es dir darum ginge. Sonst sehe ich keinen Vorteil in einer Library, eher nur Nachteile (kein OOP, die Lib muss für jedes OS neu kompiliert werden...)

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Also ich bin für meine Fonts auch von einer OOP Lösung auf eine Library gewechselt. Den Vorteil sehe ich da auch ganz klar darin, dass es unabhängig von der Sprache ist. Allerdings bin ich auch der festen Überzeugung, dass es so etwas bisher auch in C++ nicht gegeben hat. Das gibt dem Ganzen zu mindest aus meiner Sicht noch einen gehörigen Schub in Richtung sprachunabhängigkeit. Und zu mindest für Pascal ist bei den Fonts immer möglich die Quellen direkt zu benutzen. Also keine externe .DLL, .SO, etc.

Allerdings halte ich eine freiwillige Portierung in eine andere Sprache doch wohl eher für unwahrscheinlich. Zu mal man erst einmal jemanden finden müsste und außerdem würde der Code mehrfach existieren, was grundsätzlich immer unpraktisch ist. Und dann wäre die Einbindung einer Library in jedem Fall noch das kleinere Übel.

OpenGL und Objekte. Mit solchen Aussagen wäre ich vorsichtig. Denn a. ist noch nichts Handfestes von 3.0 draußen und b. heißt es ja auch Vertex Buffer Object. Und dabei wird ein das Objekt via ID unterschieden. Die Schnittstelle können sie nämlich nicht auf Klassen umbauen, da die nämlich viel zu inkompatibel wären. Entsprechend wird die Schnittstelle procedural bleiben (müssen). Anderenfalls weiß ich wer den Header nicht übersetzen wird.

Ansonsten ist es bei mir wie bei Lord Horazont. Ich habe das Thema nicht ganz so aktiv verfolgt. Aber du solltest dir genau überlegen was du damit vor hast. Siehst du Chancen, dass die Library zu einem entsprechenden Erfolg kommt. Denn alle die sie derzeit benutzen müssen den Code umstellen und die wären sicherlich nicht sonderlich glücklich darüber.

Wenn du eine Library machst musst du dir auch 100%tig bei den Methoden sicher sein. Du kannst auf gar keinen Fall morgen mal sagen "och dann hat die Methode einen Parameter mehr". Das geht dann nicht. Du musst dir jetzt also schon sicher sein, dass die Schnittstelle so bleibt wie sie ist (neue Methoden sind okay). Aber aus dem Grund lasse ich mir mit den Font entsprechend sehr viel Zeit und habe jetzt an einigen Stellen schon diverse Dinge eingebaut die nicht veränderbar sind. Das Format. Derzeit ist nur RGBA8 möglich aber muss an verschiedenen übergeben werden.

Ich sage nichts gegen eine Librarylösung (könnte ich auch gar nicht). Allerdings musst du dir der Risiken dabei voll bewusst sein.

Was höchstens noch interessant sein könnte, wäre solche C-Like O-Dateien zu machen (Obj, oder wie die heißen, kann gut sein, dass ich die verwechsle). Soweit ich mich erinnere kann der FPC ja mit den GNU-C Object-Files umgehen und sie als Static-Library einbinden. Das hätte den Vorteil, dass man sicher eine Version einkompiliert hat, die Sprachenkompatiblität ist zumindest teilweise gegeben und bei einem Parameterwechsel kommt es nicht zu unvorhergesehenen AVs sondern man bekommt zunächst nen Syntax-Error (bitte korrigiert mich, wenn ich hier müll rede, ich erinnere mich nur noch dunkel, wollte die sache aber mal auf den Tisch bringen)

Gruß Lord Horazont

_________________
If you find any deadlinks, please send me a notification – Wenn du tote Links findest, sende mir eine Benachrichtigung.
current projects: ManiacLab; aioxmpp
zombofant network • my photostream
„Writing code is like writing poetry“ - source unknown

„Give a man a fish, and you feed him for a day. Teach a man to fish and you feed him for a lifetime. “ ~ A Chinese Proverb

Delphi kann solche object Dateien auch erstellen. Allerdings habe ich es nie probiert. Ich habe aber in den Dateien von Delphi gesehen, dass dort auch so spaßige Sachen drinne stehen wie SysUtils.obj. Das gibt es aber so nirgends, da Delphi die DCUs verwendet. Also würde ich mal schätzen, dass es mit delphi nicht gehen wird.

Wobei ich aber nicht weiß ob der Linker sich an der Stelle noch um die Typen kümmert. Aber das sollte eher egal sein, da Header und objects ja gleichzeitig released werden. Aber sonst sollte es theoretisch gehen.

PS: Aber solche Schnittstellen sollten sowieso nicht so häufig geändert werden.

@Flash
Das ist sicherlich einer der größten Kritikpunkte. Warum kein OOP? OK erstmal gehts in einer Lib nicht. Zweite Frage: Warum Lib? Hier wirds etwas komplizierter. Hauptgrund ist und bleibt die Struktur von FireBlade. Die Engine stammt aus einer Zeit, in der bei mir von "Stil" eigentlich noch nicht die Rede sein konnte. FireBlade hat 1001 Macken und Mängel in der Form, die mir schon stark auf den Zeiger gehen. Das fängt ganz einfach an bei den Routinen, die richtigerweise Update o.ä. heißen sollten. Bei TParticleEffectContainer ist das CycleContainer, bei TParticleFont ists einfach nur Cycle und bei TParticleScript ists IdleScript. So Dinger sind über die ganze Engine verteilt. Dann allein die Tatsache, dass TParticleScript und TParticleFont in der selben Unit wie die Engine selbst implementiert sind: Es sind Emitter und die gehören getrennt von FireBlade. Die Form des Interfaces behindert Erweiterungen. PerFace-Kollision zum Beispiel: Wozu brauch ich noch Heightmap Collision, wenn ich das gleiche dann auch mit PerFace machen kann, mit ähnlicher Performance? Für jeden Wert, der einfach nur mal gesetzt werden muss, muss ich zumindest Setter-Routinen schreiben, anstatt einfach ein Property zu machen. Der Grund: am Anfang hab ich es so gemacht, ich kann dann auch nicht "mitten drin" was anderes machen. Folge: Unübersichtlichkeit mit jeder Erweiterung, Redundanz. Ich könnte hier noch weitermachen, aber ich denke es ist klar, was ich sagen will. Ungern will ich diese vergleichsweise wirklich schlechte Basis (interessant, wie man seinen eigenen Code so runtermachen kann...), noch weiterverwenden. Eine Umstellung der jetzigen User wird in den meisten Fällen, wie schon gesagt, nicht zwingend nötig sein, da ich die OOP-Version weiter betreuen werde. Jetzt kann ich natürlich sagen, ich fange (die Struktur) neu an, aber trotzdem OOP. Ist Jacke wie Hose, so oder so müssten die Leute code umstellen, wenn sie die wenigen wirklich neuen Features wirklich bräuchten. In den meisten Fällen denke ich wird FireBlade längst nicht "am Limit" eingesetzt. Prinzipiell besteht also schonmal für diese Fälle keine Relevanz für einen Umstieg. Noch gehts mit der Übersichtlichkeit und bei der einfachen Benutzung bekommt man die meisten Mängel nicht mit.
Vielleicht seh ich hier die Welt durch eine pinke Sonnenbrille, aber ich halte FireBlade für State-Of-The-Art (von der Kollision mal abgesehn; Wer anderer Meinung ist, bitte her damit - ich kann konstruktives immer gebrauchen). Sie auf dem Level zu halten, wird aber schon bald nurnoch schwer möglich sein. Stichwort Spaghetticode.
Etwas ausgeschweift, egal. Wenn ich wieder OOP verwende, bin ich wieder auf eine einzige Sprache begrenzt (auf die .o Files hab ich irgendwie keinen Verlaß da...). Also warum diesen Vorteil nicht gleich mitnehmen und das Ganze funktional in eine Library packen - zwei dicke Fliegen mit einer Klappe. Davon abgesehn: trockenstes Non-OOP wirds nicht. Ich hatte an Kontexte gedacht, unter denen die spezifischen Routinen ablaufen.
Soviel zu meinen Gründen. Das OpenGL auf OOP umstellt ist mir aber neu. Ich weiß, dass einige Bindings OOP sind (Qt zum Beispiel).

@Lossy
Das ist klar. Dafür habe ich aber auch ein Paar Hilfen: Einerseits ist FireBlade schon sehr vielfältig, dass heißt eine Struktur lässt sich bei viel Funktionalität um so leichter auf Konsistenz prüfen. Dann gehe ich mit DEUTLICH mehr Erfahrung an die Sache ran, als ich das zu Beginn gemacht habe. Und als Anhaltspunkt wähle ich mir wie gesagt OpenGL, was ja auch in den meisten Belangen (bzw. in denen, die ich brauchen würde) sehr konsequent ist. In dieser Hinsicht bin ich recht optimistisch. Änderungen am Interface bzw. Workarounds wie Initialisierung uswusf. gibt es eigentlich nur aus obigen Gründen.

Ich habe auch schon mit dem Gedanken gespielt, das Ergebnis entweder FireBlade<place favourite version here> oder ganz anders zu nennen. Das ist vielleicht ein guter Weg um kenntlich zu machen, dass die Lib vom Äußeren her letztlich nichts mehr mit FireBlade zu tun hat.

Das es einen freiwilligen Übersetzer gäbe, wage ich mal zu bezweifeln.

Gruß

_________________
I'm not the signature, I'm just cleaning the floor...

Derzeitiges Projekt:
FireBlade Particle Engine (Release R2 2009.06.29)

Ich meinte jetzt aber auch nur die Schnittstelle nach außen hin. Was du intern machst ist ja dir überlassen. Und da sind Klassen vollkommen legal und nur zu empfehlen. Ich benutze ja auch ein umfangreiches Klassenmodel für meine Fonts. Allerdings nach außen hin sieht man auch nur die Methoden. Und ja. Dort haben sich auch schon 2-3 darüber "beschwert", dass es keine Klassen gibt. Theoretisch wäre es auch möglich direkt mit den internen Klassen zu arbeiten. Aber da die Fehlerbehandlung in den Methoden statt findet kann ich nur davon abraten. Allerings kann man zu mindest in Pascal die Quellen direkt benutzen. Also das externe binary (dll, so) ist optional.

Das mit den Klassenstrukturen ist ein Argument was ich voll und ganz verstehen kann. Mit der Zeit wächst ein Projekt und teilweise verwächst es auch. Und dann sehe ich es auch so. Da sollte man lieber einen sauberen Strich ziehen und alle Schwachstellen ausmerzen, als sich mit einem ungünstigen Design rumplagen zu müssen. Das nützt dann niemandem. Und da sich die Schnittstelle soweiso ändern wird, müssen auch alle ihren Code anpassen.

Wobei ich da auch zugeben muss, dass es für mich so aussah als wolltest du lediglich deine Klassen in eine Library packen. Denke mal die Anderen sahen das ähnlich. Und dann würde der Sinn einer solchen Umstellung eher nur gering ausfallen.

Also ich finde deine Partikelengine immer noch für eine der besten die ich bisher gesehen habe. Allerdings kenne ich seit einem halben Jahr jemanden der dir Kräftig Konkurrenz macht( Stichwort: Fluidsimulation.. Wasserfälle pseudokorrekt simuliert ).

Von einem non-OOP Ansatz rate ich allerdings grundsätzlich ab, und warum das Ding in eine Library verpacken wenn vielleicht eine Umstrukturierung auch
schon hilft.

( Falls das eben Crap war, bitte ignorieren, hatte nicht viel Zeit die Posts zu lesen )

_________________
Shareholder und Leitender Entwickler bei Pipedream-Games.

Zitat: Siehst du diesen Park da unten? Jeden Tag lernen sich darin Menschen kennen und verlassen einander. Und du hast dein ganzes Leben Zeit darin zu gehen.

Seh ich auch so. Deine Kritikpunkte beziehen sich auf deine Codestruktur. Es geht hier also gar nicht um OOP. Du möchtest deinen Code nur mal ordnen.

Refactoring ist das Zauberwort (inwieweit das in Delphi/Lazarus unterstützt wird kann ich nicht beurteilen).

Wenn du die Library nur nutzen willst um eine definierte Schnittstelle nach außen zu bieten, dann kannst du das vermutlich auch mit Interfaces lösen.

Ich will die die Library nicht ausreden. Ich will nur nicht, dass du sie aus den falschen Gründen wählst.

_________________
Blog: kevin-fleischer.de und fbaingermany.com

Das geht nur mit COM+ oder? Ich habe vor längerer Zeit mal nach einem einfachen Beispiel oder Tutorial für Interfaces ohne COM+ GUID gesucht, aber nichts gefunden. COM+ kann ich aus zwei Gründen nicht gebrauchen: 1. ist es sehr langsam, 2. ist es auf Windows beschränkt. Nicht nur, dass ich mit Linux kompatibel sein will, ich habe auch noch ausschließlich Linux . Ansonsten würde mich das brennend interessieren!


Mein Post sollte nicht so rüberkommen, dass ich mich ganz gegen euch stemmen will. Die Sache ist einfach die: wenn ich schon "neu" anfange, warum dann nicht gleich als Lib - Damit hab ich andere Sprachen ohne viel Aufwand mit unterstützt. Das OOP-Argument finde ich nicht sehr dramatisch, denn man kann a) auf Objektorientierung hin "optimieren" und b) habe ich z.Bsp. noch niemanden gesehen/gehört/gelesen, der sich darüber beschwert hat, das OGL so schlecht in OOP umzusetzen ist. Da gibts imho zwischen funktional und funktional noch Unterschiede.

@FluidSimulation
Ich bin mir nicht sicher, ob sowas noch (komplett) in den Bereich Partikelengine fällt. Das geht mehr so in Richtung Metaballs, zumindest für "Wasserspritzer". Metaballs an die Engine zu binden ist kein Problem. Da könnte man vielleicht auch mal ne nette Demo machen, aber ich hab leider keine Implementation von Metaballs.

Gruß

_________________
I'm not the signature, I'm just cleaning the floor...

Derzeitiges Projekt:
FireBlade Particle Engine (Release R2 2009.06.29)

Interfaces? Dann biste ja auch wieder bei Klasse nur, dass das Handling für den Entwickler erschwert. Kyro: Ne die sind nicht an COM gebunden. Allerdings sehe ich da bei dir wohl auch nicht das typische Einsatzgebiet von interfaces. Und dann würden sie den Aufwand zum Programmieren wohl nur vergrößern.

Aber ich muss da ein bisschen Partei für eine Library ergreifen. Denn ein Vorteil von Librarys ist es auch noch, dass der Code außerhalb liegt. Man kann also recht einfach ohne an der Anwendung etwas tun zu müssen gewisse Teile davon updaten. Speziell unter Linux wird dieses Prinzip ja recht groß geschreiben. Und es wurde schon die Unterstützung von anderen Programmiersprachen angesprochen. Und da sind Librarys wohl die einzig sinnvollere Wahl. Ich persönlich bin absoluter Anhänger von OOP und praktiziere es auch ausgiebig. Allerdings habe ich mich genau deswegen für eine Library entschieden auch wenn es echt weh getan hat. Denn eines sollte man sich vor Augen halten. Pascal ist geil! Und ich werde es so lange programmieren wie ich kann. Aber ist es nicht die am meisten genutzte Programmiersprache. Das mag der ein oder anderen evtl. als Schwarzmalerei oder pessimistisch ansehen aber das ist meine persönliche Meinung und Überzeugung.

Da muss man abwägen was man will und wo man Chancen sieht und ob es den größeren Aufwand auch wert ist. Und ich muss gesetehen so wie ich das derzeit habe ist der Aufwand alles andere als klein. Kann man nicht mit einer einzelnen units vergleichen. Ob die PartikelEngine sich durchsetzen kann vermag ich nicht abzuschätzen. Dafür kenne ich mich damit nicht gut genug aus.

Ich habe noch einen Bug gefunden.

Die Variable FDisplayList wird nie mit 0 initialisiert.
Wenn ich GL_QUADS als Rendermode angebe, wird (warum auch immer) eine DisplayList erstellt,
mit glGenLists. Aber nie glNewList mit dieser ausgeführt. Beim Destroyen des Containers wird dann irgendeine Displayliste
gelöscht, was mir andere Listen aus meinem Programm mitlöscht. Rendertime ist FB_RENDERTIME_DIRECT.

Markus