Typischer Tak-Style:
Sowenige Leerzeichen wie möglich.

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

Hallo, alle miteinander.

Ich habe in der Zwischenzeit folgendes erledigt:

1) Eine neue Dokumentation (für Programmierer) geschrieben, in der das Programm und sein derzeitiger Status beschrieben ist (liegt dem Programm bei). Ich bitte Euch, besonders Punkt 13 zu lesen, denn dort ist beschrieben, wie ein neues GUI-Element implementiert werden kann.

2) Nur kurz, was im Programm neu ist (genaueres steht in der Doku):
-------------die meisten Ereignisse funktionieren schon, ist getestet
-------------eine True-Type-Font gibts schon (zwei FreeFonts sind dabei), Stringausgabe funktioniert
-------------Texturen (mit Alpha-Blending) gibts schon (eine "Sträflings"-Textur ist dabei)
-------------ein paar RGBA-Farben gibts schon
-------------In der Unit GUIDescendants sind zwei GUI-Testtypen definiert, als kleine Demo

Es war ziemlich schweißtreibend und hat relativ lange gedauert, weil mir ein paar blöde Fehler schwer zu schaffen gemacht haben (besonders die Schrift grummel ).

@Tak: ich habe alle Dateien dabei, die notwendig sind. Es sollte jetzt funktionieren.
Ich habe bei mir inzwischen das Tortoise SVN installiert und werde die neue Programmversion auch ins Repository (in die Sandbox) laden. Die alte Version werde ich vorher löschen, das mache ich jetzt gleich (es ist nach ca. ein Uhr nachts), morgen früh hast Du es aktuell. Ich wollte das schon früher tun aber abends war das Forum nicht online. Sollte etwas nicht funktionieren stelle ich es für alle Fälle auch hier hinein.

Traude




@edit: auweia Tak - ist irgendetwas schiefgelaufen beim Kopieren ins Repository - meine Dateien sind zwar drin, aber ich habe möglicherweise Deine gelöscht - ich hoffe, Du hast eine Kopie, 'tschuldigung



@edit2: Hallo, I0n0s,
Betrifft Code-Stil:
Wer hat diese Regeln aufgestellt? Muss ich mich unbedingt daran halten, und wenn ja, warum? Richtlinien müssen schliesslich zu irgendwas gut sein. Wenn ich der einzige Programmierer hier bin, sehe ich nicht ein, warum ich mich an fremde Code-Regeln halten soll.

Die Code-Stilregeln sollen den Zweck erfüllen damit der Code für dieses Projekt keine Papierkorbarbeit ist sondern auch von anderen Leute, unter anderem die Community DGL, gelesen werden kann. Desweiteren gibt es automatische Codestyler, die solche Änderungen vornehmen.

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

Hallo, I0n0s,
Dann würde ich vorschlagen, in meinem Fall so einen Code-Styler zu nehmen. Ich habe mir diese Schreibweise vor circa zehn Jahren deshalb angewöhnt, damit ich eben auf Anhieb weiß, wie die Programmstruktur ist, auch wenn ich Monate oder Jahre später wieder einmal reinschaue und das funktioniert auch gut. Und es gibt für mich auch sonst noch gute Gründe: zum Beispiel sind mir die Einrückungen von zwei Leerstellen zuwenig (das hat was mit der Kombination Kurzsichtigkeit/Alterssichtigkeit zu tun - kommt mit rund 45 - kannste gar nichts dagegen machen: Brille rauf, Brille runter...). Meine Art Pascal-Code zu schreiben ist mir angewachsen wie eine zweite Haut. Ich kann gar nicht mehr anders.

Eigentlich kann keiner von mir sagen, dass ich mich nicht durch gute Argumente überzeugen lasse, aber in diesem Fall ersuche ich sehr um Euer Entgegenkommen: ich kann Euer Codestyling nicht übernehmen.

Traude

Ich hab diesen Codestiel vorgeschlagen und erwarte, dass man die eigenen einwände mitteilt.
Denn so kann man den Codestiel für alle passend machen.
Halten sollte man sich dann in der Release arbeit schon, denn sonnst macht es nur probleme.
Dann fängt jeder an zu überlegen, was der andere überhaupt geschrieben hat und wenn dann fixes gemacht werden, sieht der Author nicht mehr durch.

Da sich, wie schon erwähnt, keiner weiter zum programmieren gemeldet hat, können wir uns beide(traude und ich) überlegen wie wir was realisieren wollen und wer welche Arbeit übernimmt.

@Traude
Zu deinem Testcode muss ich noch was sagen.
Pack einfach alle files, die du für die testdemo verwendest, hinzu.
Ich hab zum testen extra nur windows api verwendet und so fällt nur mein testcode und die dglopengl.pas an.
So spare ich mir arbeit mit der version von jeder lib.
Also wäre toll, wenn du die header für die libs und die dll's selber noch mit ins repo packst.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

OK, mach ich.

Ich möchte nur kurz etwas verlautbaren.

Wir sind hier nicht etwa "eingeschlafen", sondern wir sind der Meinung, dass Ihr uns schon bereits so viele Ideen geliefert habt, dass wir mit dem Umsetzen dieser Ideen anfangen können. Das wollen wir aber nicht hier machen.
Für die tollen Anregungen möchten wir uns bei Euch bedanken und werden von Zeit zu Zeit über unsere Fortschritte berichten.
Traude

Ihr könnnt ja mal sobald ihr die Klassendefinitionen fertig habt diese hier reinstellen. Dann kann man diese nochmal diskutieren und erst dann mit der implementierung beginnen.

Hallo,
ich melde mich wieder mal mit einem Problem. Ich habe in der Zwischenzeit eine - wie ich denke recht fruchtbare - Diskussion mit Tak2004 über den grundsätzlichen Aufbau des Programms geführt.

Ein Punkt dabei war, dass er die durchaus vernünftige Forderung stellt, dass multi-Window-Support dabei sein muss.

Meine Situation ist folgende: ich hatte ursprünglich auf SDL gesetzt, das ist stabil, plattformübergreifend und hat eigentlich alles, was man so braucht, mit Ausnahme eben des multi-Window-Supports. SDL hat den Mailinglisten zufolge für die nächste Release 1.3 dieses Feature in Aussicht gestellt. Aber diese Release ist noch nicht freigegeben, sie arbeiten noch dran und einen Fertigstellungstermin habe ich nicht gefunden (die Homepage habe ich heute auch nicht erreicht). Nun bin ich eigentlich kein ungeduldiger Typ aber diese Ungewissheit macht mir etwas zu schaffen. Ausserdem ist da zu bedenken, selbst wenn sie es fertigstellen, dann handelt es sich um eine Erstausgabe des multi-Window-Supports, und es mag ja sein, dass Open Source gründlicher ist als proprietäre Software. Aber ich habe mit Versionen 1.0 durchwegs schlechte Erfahrungen gemacht, ganz egal, ob es sich um Autos, Rolltreppen oder Programme handelt. Und schliesslich müssen die JEDIS dann noch einen Header dazu herausgeben. Hört sich für mich gar nicht gut an. Etwas weniger drastisch ausgedrückt: das kann dauern und wann es soweit sein wird, kann ich jetzt nicht abschätzen.

Was Linux betrifft, so kann ich da gar keine Unterstützung bieten, weil mir dazu die Erfahrung und auch die Entwicklungsumgebung fehlt.

Aus den genannten Gründen muss ich zähneknirschend zur Kenntnis nehmen, dass ich im Augenblick nur Unterstützung für Win32 garantieren kann. Und das ist, wenn mans recht bedenkt, ziemlich wenig: Windows Vista ist im kommen, keine Linux-Unterstützung in Aussicht, keine SDL-Unterstützung in absehbarer Zeit.
Traude

@Nachtrag: die einzige Möglichkeit, die ich sehe, ist, den multi-Window-Support auf einem SDL 1.2-FullScreen zu simulieren.
@Nachtrag2: ich korrigiere mich: die SDL-Homepage http://www.libsdl.org/ lässt sich laden, aber derzeit nur mit unmenschlichen Ladezeiten.

Bedenkt übrigens im weiteren, dass ich als User auch euerer GUI ein schon erstelltes Fenster übergeben will.

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

SDL1.3 header kann ich auch porten, daran sollte es nicht scheitern und den Linux part kann ich auch übernehmen.


Dies ist kein Problem, in mein Testcode geht das aber vorraussetzung ist, dass der User die richtigen Wrapper beim compilieren in die includes gepackt hat.
In mein testcode hab ich TApplicationWindow(ein echtes Fenster) mit einem Property Handle:longint (wobei man das auf pointer umstellen kann) ausgestattet.
Also wenn man ein Fenster mit winapi,sdl,x11 oder ähnlichen erstellt, legt man dort den fensterhandler ab (z.B. HWND für windows und sdl_surface für sdl).

Alerdings wüsste ich nicht wieso jemand so etwas tuen sollte ?
Die GUI ist ein sorglos Paket, welches die Fenster und darunter liegende Widgets managed.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Tak2004 schrieb:

Super! Wusste ich gar nicht. Meine größte Sorge war, dass wir Linux nicht dabei haben.


Na ja, ein wenig Umsicht darf man vom User schon erwarten.


Wenn ich mich recht an Taks Code erinnere, war vorgesehen, dass die GUI dem Fenster übergeben wird, nicht umgekehrt (Das Fenster ist das übergeordnete Objekt). Das hat den Vorteil, dass es auch möglich ist, Fenster in verschiedenem Design darzustellen (es gilt wieder: man kann, aber man muss nicht).
Traude

Vieleicht hilft das Klassendiagramm ein wenig.
EventManager und TDGL_Canvas sind von der gewählten externen API abhängig müssen die gleiche nutzten.
Also wenn der EventManager nicht der mitgelieferte ist(wird nur für die demos mitgeliefert), dann muss drauf geachtet werden, dass es die gleiche API ist.
Für ein Fenster, welches von draussen kommt, müsste man also das Fenster mit der gewählten API selber erstellen, die gleiche API für EventManager verwenden und ein TDGL_AppWindow mit dem Handler und den grunddaten(left,top,height,width) füttern.

Ich hallte es für dumm, ein Fenster selber zu erstellen, wenn es die Klasse es wesentlich einfacher und ohne eventuelle Fehler machen kann.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004

Hallo I0n0s,

I0n0s schrieb:


1) Nachträglich leere Fenster einbauen:
Das sollte kein Problem sein, wir brauchen ja ohnehin einen "Fenster-Manager" für die ApplicationWindows, der kriegt halt bloss eines neues dazu.

2) Nachträglich Fenster einbauen, die bereits etwas zeichnen (meinst Du damit, Du möchtest es in ein bestehendes Programm einbauen? Könnte sogar eine Hauptanforderung sein, wenn ich das recht überlege):

Was Du jedenfalls machen musst, ist dem ApplicationWindow eine TDGL_Canvas(die ermöglicht das Zeichnen, kümmert sich um den Rendering Context usw.) und ein WindowWidget zu verpassen ('tschuldigung, die Nomenklatur ändert sich derzeit ständig, mit "WindowWidget" ist das GUI-Element gemeint, das für dieses neue Application-Window zuständig ist, die Unter-Widgets verwaltet und die Events erhält). Wie das genau im Detail sein wird, weiss ich jetzt noch nicht, aber verwaltungstechnisch lässt sich da bestimmt eine einfache Möglichkeit finden. Ich behalte es im Auge. Grundsätzlich stellen wir uns vor, dass "OnPaint" gezeichnet wird. Ist allerdings schon klar, dass wir hier ein wenig anders agieren müssen als das VCL-OnPaint. Irgendwie wird da eine Mindest-Framerate einzustellen sein, aber ehrlich: das ist im Augenblick noch reine Spekulation.

Was ich vorhabe ist, dass man die GUI als ganzes oder einen Zweig davon "wegschalten" kann (unsichtbar/inaktiv machen). Dh. man kann im Fenster zeichnen und bei Bedarf die Widgets dazuschalten, dann werden sie oben drauf gezeichnet. So weit war ich bei der TinyGUI schon, das hat funktioniert, zumindest mit dem ganzen Baum und mit OpenGl. Aber Du weißt ja: was man mit dem ganzen Baum macht, sollte man eigentlich auch mit einem Teilbaum machen können, in diesem Fall mit dem WindowWidget und seinen Unter-Widgets. Wenn Dir das mit dem "obendrauf" zeichnen nicht gefällt, dann musst Du eben Deine Zeichnung wegschalten. Oder ein Unter-Widget erzeugen, und dort Deine Zeichnung machen, so wie man in der VCL auf einem Panel mittels OpenGl zeichnen kann. Die VCL leistet sich den Luxus, für Panels eine eigene Canvas zu haben (hmm, ein eigener Rendering Context). Das haben wir hier nicht. Hab ich auch mit Tak noch nicht besprochen. Zumindest OpenGL hat Mittel und Wege, wie man trotzdem nur auf einem bestimmten Bereich des ViewPorts zeichnen kann.

Was ich sicher nicht möchte, dass ihr die VCL gleichzeitig betreibt, denn vermutlich (kann ich gar nicht abschätzen) wird es dann einen Kuddelmuddel mit den Events geben.
Traude

Zu den FPS:
Diese möchte ich aber wenn ich der GUI schon ein Fenster übergebe auch schon selber gestalten können.
In dem Zusammenhang fände ich es am besten, wenn ich mein Fenster, mein OpenGL-Panel und ähnliches schon habe und diese euerer GUI gebe damit die weiss wo sie zeichnen soll. Dann gebe ich selber euch die Events weiter und sage auch wann die GUI neugezeichnet werden soll. Und dies sollte nicht umständlich über Wrapperklassen oder ähnliches geschehen.

Und zu dem VCL und OpenGL in einem Fenster:
Wir sind hier in einem OpenGL-Forum. Aktuell benutzt man nur VCL und OpenGL in einer Kombination, weil es keine GUI gibt, die dies genauso komfortabel löst.
Daher könntet ihr euch im Prinzip auf OpenGL-Fenster(/Panels etc) beschränken und solltet auch keine Fallbackmodi für als Beispiel reines SDL ohne OpenGL schreiben.
Wenn ihr so flexibel seit und es könnt, dann zwar gerne, wenn ihr aber so flexibel werdet und dadurch extrem unkomfortabel schmeisst es raus!

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