Das deutsche QBasic- und FreeBASIC-Forum

[E-P-S]

Hi zusammen,

ich plane gerade ein Programm welches notwendigerweise einen hohen Anteil an Grafik besitzt (Tile Engine). Zudem wird es nötig sein Linien und einzelne Pixel darzustellen.

Ebenfalls werden aber die API Elemente benötigt wie Buttons, Labels, Menü etc.pp.

Da ich nicht vor habe extra eine eigene GUI Oberfläche zu programmieren habe ich mich gefragt wie dies wohl am besten zu organisieren wäre.

Für Grafik allein würde man wohl zur FBGFX neigen. Soweit ich das hier im Forum in Erfahrung bringen konnte kann man in einem Grafik Screen jedoch keine API Elemente darstellen.

Ein reines "Windows Fenster" mit einem großen Bild darin wäre natürlich auch möglich. In diesem wiederum könnte ich nun die Tiles darstellen. Allerdings denke ich das dies a) wesentlich langsamer wäre und es b) wohl Probleme beim zeichnen der Linien und Punkte geben würde.

Wie würdet ihr das lösen? Vielen Dank schonmal
_________________
Man kann sich öfter als zweimal im Leben halb tot lachen.

[OneCypher]

@EPS: Da kann ich dir nur mein aktuelles Projekt empfehlen, welches aber erst kurz vor dem nächsten entscheidenden release steht. (welches dann interessant für dich sein sollte)

Das ist eine Gui welche man in eine separates fenster auslagern kann. So das du dein normales FBGFX-Fenster frei für dein Projekt hast: http://forum.qbasic.at/viewtopic.php?t=6757

Alternativ kannst du dir auch mal ein anderes kleinere projekt von mir anschauen: http://forum.qbasic.at/viewtopic.php?t=6841

Dort gehts um ein 2. GFX-Fenster welches mittels SDL realisiert wird.

Ich habe SDL bisher sehr gescheut, weil man eine zusätzliche DLL unter Windows mitbringen und das SDL-Package unter Linux installiert haben muss. Aber das ist weitgehend kein wirkliches problem. Man gewinnt aber unheimlich viel komfort, sobald man ein SDL-Fenster verwendet..

[E-P-S]

Erst einmal danke. 2 Fenster kommen aber in jedem Falle nicht in Frage und auch ein extra geschriebenes GUI möchte ich nicht verwenden - sonst würde ich das auch selbst proggen.

- nix für ungut aber GUI's zu schreiben ist ne harte Sache, das weis ich aus Erfahrung, insbesondere den Komfort und die Flexibilität wie unter Windows zu erreichen ist (nahezu) unmöglich. Das fängt schon bei der Texteingabe an und hat wohl kaum ein Ende.

Dann würde ich eher auf die "nur Windows" Variante zurückgreifen.

ABER: in BlitzBasic als Beispiel habe ich WinAPI Elemente in den DX Screen hineinbekommen - funktioniert natürlich nur im Fenster- und nicht im Fullscreen Modus. Letzterer wird aber auch nicht benötigt. Daher hab ich mich nur gefragt ob das mit der FBGFX lib eben auch ginge.
_________________
Man kann sich öfter als zweimal im Leben halb tot lachen.

[croco97]

Hi E-P-S!

Ich verstehe vielleicht noch nicht ganz, was du mit "API" meinst. API ist ja AFAIK eine Sammlung von Routinen "nach aussen" zum Ansprechen eines Hard- oder Softwaresystems. Ich nehme an, dir geht's hier um eine ganz spezielle Klasse von API's, nämlich um GUI-API's?

Wenn dem so ist: Wenn du GUI-Elemente brauchst, würde ich dir zu einer fertigen Engine raten. Es scheint ja in FB aus irgendwelchen Gründen unpopulär, sich an fertige GUI-Toolkits zu linken - allenfalls noch an die Windows-(GUI)-API.

Ich hab mich jetzt in GTK eingearbeitet und das läuft gut - du kannst dir selbst auf der Projektseite ein Bild machen. Qt soll noch besser sein, aber da gibt's noch kein fertiges FB-Binding. wxwidgets gibts auch noch, kenne ich aber nicht.

Wichtig ist: Diese Toolkits liefern ja wesentlich mehr mit als nur GUI-Klassen. Das sind eher Rundumversorgungs-Frameworks, egal ob es um Hashmaps, Listen, Sortierroutinen, Datenbank-Ankopplung oder sonstwas geht.

Die ganzen Diskussionen über 1 oder 2 gfx-Fenster kannst du aus dieser Sicht ad acta legen - du kannst soviele Fenster haben wie du willst, ohne jede Verrenkung. Und du kannst grafisch eigentlich alles machen - sogar direkt in den Bildspeicher poken, das ist bei GTK absolut kein Problem.

Bleibt der Aspekt: Single-exe oder Multi-DLL-Programm. Das ist sicher der kleine Haken unter Windows, dass es mit der kleinen schlanken exe vorbei ist, sobald du nicht voraussetzen willst, dass die entsprechende Runtime schon installiert ist. Auf der anderen Seite: Die GTK-Runtime mitzuliefern, kostet gezippt 8 MB - das sind heute auch nicht mehr Welten.

VG!

Croco

[E-P-S]

Hi croco97 - danke für die Antwort.

Du erkennst das völlig richtig - ich hatte mich etwas unpräzise ausgedrückt.

Die abschließende Größe des Programms oder der Programmteile ist mir ehrlich gesagt Wurst - das wär nicht wirklich das Problem.

Ob die Einbindung eines GUI Toolkits ne Lösung wäre - darüber hatte ich noch gar nicht nachgedacht, da ich davon ausging das sie eben nur Routinen und Funktionen für GUI Elemente bereitstellen.

Danke für die Aufklärung. Ich werd es mir in jedem Falle mal reinziehen.
_________________
Man kann sich öfter als zweimal im Leben halb tot lachen.

[OneCypher]

@croco97: GTK ist ein klasse toolkit, aber leider kann man die bedienelemente meineswissens nicht in ein klassisches FBGFX-Fenster einbinden. Die meisten leute die in Basic programmieren kennen die nativen-basic anweisungen sogut wie ihre westentasche. Da fällt der umstieg auf ein anderes toolkit mit anderen befehlssätzen schwer.

Wenn man gut darin ist FBGFX-basierende programme zu programmieren hat man nun mal die schwierigkeit, das man erstmal ohne komfortable bedienelemente auskommen muss... oder man schreibt sie selbst. (oder bedient sich bei den zahlreichen FB-Gui-Kleinprojekten)

Wenn die gui-elemente auch noch plattformunabhängig sein sollen, fällt die Windows-API ja auch noch weg. GTK/QT/wx sind unter linux meistens kein problem, weil die bibliotheken ja sogut wie immer direkt mitinstalliert werden. Da muss man dann keinen ballast mitschleppen...

[croco97]