PureBoard

Naja, irgendwie schon. Es fehlen einerseits diese wenigen Befehle, andererseits habe ich mir schon den Kopf zerbrochen, wie die neue Dokumentation sein soll. Hatte da irgendwas stark umstrukturiert.

Die Frage ist: "Würde das überhaupt jemand nutzen?"

Wegen irgendwas würde ich die sowieso noch mal neuschreiben (wenn ich die in 3 Tagen schreiben konnte, war das wohl kaum ein riesen Aufwand), aber auch in Verbindung mit SDL(.dll) (wegen Tastatur und Maus Kontrolle) und eventuell so dass man relative anstatt absolute Koordinaten auf dem Bildschirm angeben muss/kann.
Und einer im englischen Forum hatte das auch shon gemacht, in der Art.

Ich habe nun den ganzen Juli Praktikum, da habe ich leider keine Zeit für irgendwas, aber dann wenigstens noch 4 Wochen Sommerferien, in denen ich eigentlich schon an ein anderes Projekt dachte. Man wird es sehen.

LoL, natürlich würde ich das nutzen und viele andere auch, wenn es: a) schneller ist, und b) nen Bloom oder gar HDR-Effekt hat^^ boa da könnt man die geilsten Effekte machen^^. Hoffe du machst das weiter!!

mfg

Naja, das Ding arbeitet ja schon fast so schnell wie möglich... aber ich denke ich werde es ohnehin nochmal neu schreiben um es zu optimieren. Und da ich endlich mal vernünftige GL Codes gesehen habe, welche Befehle ich nun wann aufrufen muss und wann nicht (war mir vorher bei manchen Fällen wie glPerspective_() nicht klar ob immer oder nur bei Programmstart).

Die Effekte hatte ich am Ende sogar als überflüssig angesehn Aber so wie ich das verstanden habe wäre Bloom zum Beispiel gar kein Problem, programmiertechnisch ist es einfach (die "schmutzige" Variante).

Aber ob das wirklich so viele nutzen würden bezweifle ich. ^^ Was solls, ich habe mal wieder Lust irgendwas fertig zu stellen, was sich auch sehen lässt...

Da fiel mir schon glatt ein beim überfliegen des DelphiGL, eine eingebaute 2D Partikel Engine wäre ja auch schon ganz hübsch, oder? Da kommt man wieder ins schwelgen... Beleuchtungseffekte wären natürlich auch möglich, nur ob das so Sinn macht... ok, das wäre ohnehin ein Kandidat für spätere Versionen.

Ich denke eine Kombination von SDL (also für Eingabe usw.) und OpenGL wäre wahrscheinlich. Das alles erfordert eine komplette Rekonzeption.

Wegen SDL: da müsste dann immer die SDL.dll dabei sein, was allerdings kein Problem darstellen sollte, stört ja keinen, und halt, ich bin mir nicht sicher ob es so sein muss, die kleine SDL Lizenz Textdatei. Aber das dürfte auch niemanden stören. Am Ende interessieren sich die Endkonsumenten, die wahrscheinlich nicht mal Ahnung davon haben, gar nicht für die Technik selbst.

Also ich würde es alleine aus dem Grund nutzen das es schneller is...
(Bloom-Effekte wären richtig geil...)

Aber man muss ja auch überlegen, 2D mit solchen Effekten sieht nicht zwangsmäßig so aus wie 3D. Und vor allem HDRR, über die Technik und den Sinn habe ich mich nochmal informiert, also ob das so nützlich wäre bei 2D ist fraglich.

Halleluja, wenn ich alles wirklich optimal machen will, muss ich mit Shader (glSlang) arbeiten. Das wird lustig (kompliziert)... aber Effekte stelle ich erstmal hinten ran.

So, nun habe ich endlich eine Lösung gefunden wie ich die Dokumentation mitliefere; gar nicht! :P Die wird sich online befinden, in einem selbst geschriebenen Wiki. Wo allerdings dann auch nur ich beiträge schreiben kann (mehr-User Zeug wird noch kommen, bestimmt, aber für dies lohnt es sich ja nicht). Da kann man mal sehen, welch nützliche Nebenprodukte entstehen können. Die "nanoWiki" Software wird aber auch noch verbessert und Ziel ist es sie auch für jedermann klar zu machen, ob proprietäre Lizenz oder GNU GPL ist noch unklar. Auf jeden wirklich sehr einfach zu handhaben und benötigt nur PHP (5? weiß ich nicht) und 2 Tabellen in einer MySQL Datenbank.
Ich weiß bloß nicht, ob ich das auf meinen derzeitigem Webspace machen soll... kostenloser Webspace kommt nicht in die Tüte, da es kein Vertrag ist und die einfach mal eben meinen Account löschen können (und somit die eventuell mühevoll angelegte Artikeldatenbank). Das ist nur mal der Stand der Dinge bezüglich der Dokumentation, jetzt geht's an das wesentliche.

Frage an alle interessierten

Wäre es für die die diese Bibliothek verwenden besser,wenn die Engine an sich Grafiken nur aus dem Speicher im Rohformat (RGB(A)) liest, sodass seperat DLLs erstellt werden können, die Formatspezifisch in das Rohformat im Speicher übersetzen, oder dass die Illusion Bibliothek von Haus aus Grafiken lädt?

Ähhhh keine ahnung, verstehe die Frage nich. Wo ligt da der Unterschied?

mfg

Ich hab mir mal die Beispiele in dem runtergeladenen Ordner angesehen.

>> Positiv ist anzumerken, dass die Beispiele ohne Fehler gleich von der Stelle weg funktioniert haben. Großes Kompliment.

Schade war, dass deine "Demos" mir scheinbar nichts gezeigt haben, was ich nicht auch so mit PureBasic schick hinbekommen hätte

>>>> Richtig schlimm fand ich, dass du zwar OpenGL im Fenster ausführst, ich aber keine Maus habe, also mein Windows trotzdem nicht benutzen kann. Das fand ich richtig mies.

Was die Performance angeht, hab ich jetzt nur die Beispiele mir angeschaut und hatte das Gefühl, dass der rote Mauszeiger nachzieht.

-------------------------------

Fazit: Es gibt keinen Grund für mich eine *.DLL zu benutzen, die mehr nicht mehr kann als normale Sprites, die dafür aber Plattform übergreifend funktionieren.

Worüber ich mich gern freuen würde wäre eine TechDemo, eine Art Demonstration deiner Technologie, Vielleicht auch eine Art Performance-Test oder Benchmark.

Schau dir mal ParticleIllusions an.

Hersteller
http://www.wondertouch.com/

Download einer kostenlosen Version
http://www.vollversion.de/download/part ... _1778.html

(ich weiß nicht, ob bei euch die Werbung auch ist, aber diese bewegenden Bildchen im Kreis, das wäre eine schicke Demo mit deinem "PlugIn" für PureBasic)

Für deine Mühe

[edit] noch mal genauer angesehen

Was mir noch gefällt, ist die einfache Syntax. Man kann schon mit sehr wenigen Befehlen ein Programm schreiben. Das ist prima.

Auch die Qualität der Transformation ist beeindruckend.

Bin gespannt, was draus wird. Werde es auf jeden Fall weiterverfolgen.

Es soll ja als Ersatz fungieren Eine Art Subsystem, eine alternative zur PureBasic internen Sprite&Screen Library. Und Das was du über hügelige Umwege bei PureBasic erreichst, ist hier nativ möglich. Transformation (Rotation; Skalierung) und ebenfalls Alpha Kanal und Einfärbung. Alpha Images sind normale Images, da gibt es keine Unterschiede. Nicht so etwas wie DisplayAlphaSprite() was ein bestimmtes Sprite braucht, und dieses dann (relativ) langsam noch mit dem Prozessor auf die Bildausgabe klatscht. Das geht bei IG2D ohne wirklich spürbare Performanceeinbußen.
Primär stehen Transformation und so an erster Stelle (jetzt noch).

Aber ich habe gestern angefangen, und es sieht so aus als würde es noch besser werden, ich werde wahrscheinlich auch noch 2D Partikelemitter einbauen, und mir ist die Idee gekommen, dass man das ganze später dann um eine 2D Physik Engine als Plug-In erweitern kann (genau wie ein GUI System, aber ich schaufel mir lieber erst nicht schon wieder zu viel auf den Teller, und mache erstmal das was minimal drin sein soll).

Dass die Maus nicht gefangen wird müsste man ausschalten können (IllUseMouse am beginn des Quelltextes entfernen), kann ich nicht nachschauen.

Aber da ich nun SDL benutzen werde für die Eingabe und das Öffnen des Renderingfensters, fällt auch API Zeug weg und wird auch plattformunabhängig. Außerdem wird der Eingabekram dann wesentlich verbessert...

Dass der Mauszeiger eventuell nachzieht (bei mir nicht) liegt wahrscheinlich an dem Inputhandling von mir (ich glaube, das mache ich sogar nur mit WindowMouseX/Y).

Bei PureBasic ist das Laden von nicht quadratischen Texturen nicht so der Knaller und vor allem sieht man selbst bei wirklich quadratischen 3D Sprites beim rotieren manchmal Artefakte (Ränder; in der Mitte eine Diagonale Verschiebung, liegt daran dass das 4eck in 2 Triangles unterteilt wird). Und der Unterschied ist auch, dass es keine 2D und 3D Sprites mehr gibt, sondern einfach nur Grafiken. "Sprites" ist ohnehin ein Begriff für eine (laut Wikipedia) veraltete Technik.

@Artus: Die Sache ist die, dass man dann für ein spezifisches Format oder welche Quelle auch immer, einen Decoder schreiben kann, über den könnte die Engine somit jedes Grafikformat laden, für welches der Entwickler einen entsprechenden Loader schreibt, da die Engine dann nur die RGB Werte aus dem Arbeitsspeicher liest, und all so ein Kram wie Header und so weiter wegfällt.

Ist die Engine noch in Arbeit?
Würde die auf jeden Fall verwenden, vorallem wegen RGBA und:

Vermilion hat geschrieben: Frage an alle interessierten

Wäre es für die die diese Bibliothek verwenden besser,wenn die Engine an sich Grafiken nur aus dem Speicher im Rohformat (RGB(A)) liest, sodass seperat DLLs erstellt werden können, die Formatspezifisch in das Rohformat im Speicher übersetzen

Wenn das rein kommt, wärs super. Würde mir einiges erleichtern, wenn ich mein eigenes Bildformat implementieren möchte.