....

Freitag, 10. September 2010 um 17:55 Uhr von c64

benutze zwar kein B3D mehr aber wenn ich deine Screenshoots so ansehe und mir vorstelle was da an Arbeit (an Code, Zeit, Gehirnschmalz) hinter steckt die du für die Blitz-Community "opferst" bleibt mir echt einfach nur die Spucke wech !

mfg. C64

Dienstag, 15. September 2009 um 16:50 Uhr von Dottakopf

Hm kann es sein das zu dem SGG Befehel createSGG(..) der gegensätzliche Befehel DeleteSGG(..) fehlt ?
Finde es in keiner Doku oder Beispiel.

Bzw. wie kann ich ein zuvor erstelltes Gui element welches mit createSGG erstellt wurde wieder löschen ?

Hectic du bist unser Mann! weiter so


Gruß
Dottakopf

WOW!

Donnerstag, 20. August 2009 um 20:50 Uhr von vanjolo

Sieht einfach nur perfekt aus!

Wie nicht anders zu erwarten...

Donnerstag, 16. Juli 2009 um 21:23 Uhr von faeX

...einfach nur genial! Als ich die GUI von CS2D das erste mal gesehen habe musste ich auch sofort an die Draw3D denken und dass du jetzt eine dementsprechende GUI (nur eben nicht fensterbasiert) programmierst, freut mich sehr, da ich schon nach so einer GUI gesucht habe / Gedankenansätze hatte ebendiese zu programmieren. Der gute x-pressive muss wohl langsam mal die Beine in die Hand nehmen und was tun, damit seine SpriteCandy attraktiv bleibt.

Ich selbst habe auch mit dem Gedanken gespielt eine eigene Spriteengine zu programmieren und schon einige Zeilen aufgeschrieben, wo ich mich von Draw3D hab' inspirieren lassen.

Im Übrigen: Bist du dir allerdings sicher, dass du keine Verletphysik mehr in der Draw3D2 lassen möchtest? (Angepasst auf 3D, da es ja eine Engine für 3D-Spiele ist - oder irre ich?) Was mir bei Physix aufgefallen ist:

Du hast den Ansatz (bei Knotenpunkten): Neue Position = Alte Position + Geschwindigkeit
Und nicht den für Verlet üblichen Ansatz:
- Geschwindigkeit = Neue Position - Alte Position
- Alte Position = Neue Position
- Neue Position = Neue Position + Geschwindigkeit

Dieser Ansatz hat den Vorteil, dass einem mit der Blitz-slide-kollision dann vieles abgenommen wird und du dir zusätzliche Arbeit machst, oder irre ich mich (wieder?)?

Alles in allem ist es super was du da mit der Draw3D2 neues erreicht hast. Ich liebe besonders kleine aber feine Spielereien mit Winkel, Skalierung, Alpha und Farbe von Bildern, die meistens mit Sinus/Cosinus hin und her schwanken Ich käme kaum auf die Idee ein 2D-Spiel zu machen, wäre ich auf deine Draw3D nicht gestoßen. Nochmal ein fettes Lob an dich!

Mfg faeX

Freitag, 29. Mai 2009 um 15:09 Uhr von Nicdel

Draw3D2 kenne ich ja schon. Ich freue mich aber sehr auf DrawSGG, das sieht toll aus.

Dienstag, 26. Mai 2009 um 13:08 Uhr von Noobody

So zum Beispiel könnte ein Fentersystem mit mehreren Elementen aussehen:

Montag, 25. Mai 2009 um 22:50 Uhr von hectic

Ich sehe deine Kritik nicht als schmälernde Leistung an. Denoch will ich mal die DrawSGG etwas erläutern, da dieses zuvor von mir echt nur sehr spärlich gebracht wurde.

- - -

Ich hab eben noch überlegen müssen was genau eine ComboBox ist. Also generell finde ich es für InGame schon komplett überflüssig. Die DrawSGG soll ja keine Konkurenz zu den unzählig für BlitzBasic verfügbaren GUIes stellen. Sie soll lediglich die Handhabe im Spiel vereinfachen. Besonderes Augenmerk ist da der SGGROSTER welche sowohl als abgeleitete RadioButtons gehandhabt werden können, als auch als Auswahllisten. Also auch in deinem genannten Fall einer Serverliste. Man hat zum Beispiel die Möglichkeit die Items einer Liste beim erstellen schon im vorab durch ein | zu trennen, oder eben auch nachträglich über AppendSGG neue Items hinzu zu fügen. Was man noch nicht kann sind Einträge (Items) zu löschen. Durch die Eingrenzung der Spannweite kann man auch innerhalb eines SGGROSTER scrollen. Der Grund warum ich so komische Namen zu den einzelnen Elementen vergeben habe, ist eben der, dass die Benutzung auch nicht 1:1 zu den ''originalen'' gegeben ist.

Jedes Unterelement (Label, Button, ListBox ...) schreibt jeweils drei globale Variablen und das Hauptelement (beinhaltet die Unterelemente) gibt beim zeichnen Werte zurück. Zum Beispiel werden alle Unterelemente eingezeichnet, sobald man DrawSGG schreibt. Dieses Hauptelement hat eine Breite und eine Höhe, erst dann, wenn sich die Maus innerhalb dieses Kastens befindet, werden die Unterelemente auf Mauskollision geprüft, ansonsten werden sie nur gezeichnet um Recourcen zu sparen. Befindet sich die Maus über so ein Hauptelement, gibt die Funktion eine 1 zurück, und eine 2 wenn ein Unterelement geändert wurde. Eine Änderung ist zum Beispiel ein Mausklick oder das verändern eines aktivierten Eingabefeldes. Durch diese einfache Logik kann man zum Beispiel schon einfache DropDown-Menüs machen. Allerdings muß ein DropDown-Menü nicht nur aus einer Auswahlliste bestehen, sondern kann auch Buttons, bzw. alle DrawSGG-Unterelemente beinhalten. So eine Logik sähe dann in etwa so aus:

Code: [AUSKLAPPEN] [EINKLAPPEN]

Jedes Hauptelement beinhaltet also Unterelemente, und es können mehrere Hauptelemente deffiniert werden. So könnte man zum Beispiel ein Hauptelement mit vier Buttons erstellen, die das Game-Intro deffinieren und weitere Hauptelemete die nur im Spiel selbst gebraucht werden. Aus der Kombination aller Sachen fallen mir folgende parallelen ein:

SGGOUTLAY
- ist in meinen Augen immer nur ein Label

SGGBUTTON
- ist bei nur einem Item ein Button
- ist bei zwei Items ein CheckButton (siehe erstes SGG-Bild den Button mit dem rotem Kreuz (wird gelb wenn man einmal drauf klickt))
- ist ein Auswahlelement wenn mehr als zwei Items hinzugefügt werden. Zum Beispiel kann man ''Easy|Normal|Hard'' eintragen und durch klicks eine Auswahl treffen

SGGROSTER
- kann als RadioButton gehandhabt werden (da immer nur ein Listeneintrag ausgewählt werden kann)
- ist eine normale scrollbare Liste wo auch neue Einträge hinzugefügt werden können (da so eine Funktion ätzend zu programmieren ist, bin ich froh nun eine einfache Alternative für meine Projekte zu haben)

SGGINTAKE
- ist ein (zugegebener massen sehr vereinfachte) Eingabebox. Da hier mit GetKey() gearbeitet wird, muß man selbst einmal zuvor SGGKey3D=GetKey() schreiben, damit der Programmierer nicht ewig und drei Tage auf Fehlersuche geht, wenn er selbst mit GetKey() arbeiten möchte. Somit bleibt der Wert in SGGKey3D ''erhalten''.

Hauptelement-Logik
- ein DropDown-Menü mit allen verfügbaren Unterelementen

- - -

Scrollbalken wollte ich auch noch einbauen, aber es wird echt schwierig wenn die GUI dann auch noch in X-beliebiger Stellung im Raum steht, und die genaue Mausposition relativ zum Objekt zu bestimmen. Was noch fehlt ist unter anderem die Möglichkeit über die Tastatur zu navigieren. Das geht zur Zeit noch nicht. Das kommt wohl dann später mal.

Leider konnte ich über die Google-Bildsuche keine vernünftigen Ergebnise erzielen die mit ''CS2D'' mit einer GUI in Verbindung gebracht werden könnte.

Aber nach wie vor. Ich kann mir beim besten Willen nicht vorstellen, wie eine Fensterbasierte GUI in einem Spiel (trotz sauber geordneter Struktur) gut aussehen kann. Also stell dir vor, du erstellst im Gamemenu eine tolle Hintergrundanimation damit dann die GUI die hälfte davon einfach überdeckt. Oder du fliegst ein Raumschiff mit einem tollem Armaturenbrett und klicktst nun im spiel auf eine fensterbasierte GUI, statt nur auf Knöpfe die sich dem Raumschifflayout mehr oder weniger anschmieden. Das soll im eigendlichen der Einsatzzweck sein, oder wie folgendes Beispiel auch noch zeigt:

Montag, 25. Mai 2009 um 20:41 Uhr von Noobody

Naja, mag ja sein, dass eine Ingame-GUI nicht alle Elemente braucht, wie man sie von Windows her kennt - aber gewisse Dinge wie Scrollbars oder Comboboxes für ein Optionenmenü oder mal schnell eine Listbox für die Serverliste können relativ viel Eindruck machen, wenn geschickt eingesetzt (beispielsweise die GUI in CS2D finde ich sehr gut umgesetzt und beeindruckend).

Wie das umgesetzt wird, kommt halt drauf an - ich finde ein Fenstersystem eigentlich noch recht hübsch anzuschauen. Natürlich macht es dann wenig Sinn, wenn man die Fenster noch x-beliebig skalieren/bewegen/minimieren/maximieren kann, aber wenn die GUI - Elemente sichtbar in einzelne Bereiche zusammengefasst werden, sieht das nicht schlecht aus.
Vielfältige GUIs habe ich schon sehr oft in den verschiedensten Spielen gesehen, auch Hobbyspiele; aber kommt natürlich stark auf das Genre drauf an.

Wie auch immer, ich möchte über der Diskussion auf keinen Fall deine Leistung schmälern, hectic.
Grossartige Arbeit, sieht sehr vielversprechend aus. *thumbs up*
Nur weiter so!

Montag, 25. Mai 2009 um 18:33 Uhr von hectic

Goodje, genau dass wollte ich auch erreichen. Allerdings beinhaltet sie wirklich nicht viele Dinge, aber eben die Sachen die ich für ein Spiel für wichtig halte. Irgendwann später denke ich noch es um zusätzliche Tastaturmanovrierbarkeit zu erweitern.

Valnar, die Draw3D2 ist schon seit längerem fertig und wird von etwa 5 Betatestern bereits einiger Zeit ausprobiert. Die Kompatibilität ist sehr hoch, jedoch einige Parameter ändern sich auf welche ich dann beim Release auch eingehe, damit eingeschworene nicht erst noch tagelang rumgrübeln müssen.

Eingeproggt, D2006, Dottakopf vielen Dank für das Lob/die Kritik. Letztendlich arbeitet man ja daraufhin.

coolo, klar wäre es schön, und wie du schon recht erkannt hast nicht besonders einfach oder gar langsam in der Programmgeschwindigkeit. Eventuell könnte man Noobody's brandneue Vektorkollision über Images umrum ziehen und es so berechnen. Wäre fast Pixelgenau, dafür sicherlich schneller als auf einzelne Pixel zu prüfen. Aber aufgrund des Aufwandes erstmal für spätere Versionen im Hinterkopf behalten.

- - -

Hier noch das Codebeispiel des ersten DrawSGG-Beispielbildes. Da ich nicht der Typ bin der sich das Wissen aus fremden Quellen aneignet, sondern eher alles selbst erarbeiten versuche (was auch der Grund für mein langsames - nicht professionelles - vorrankommen ist), ist die Handhabung eventuell auch nicht wie all die bisherig bekannten GUI-Engines. Also da hab ich echt kaum Ahnung von, wie andere es machen. Ich seh da immer nur Windows-Like-GUI und schalte ab. Aber seht selbst:

Code: [AUSKLAPPEN] [EINKLAPPEN]

- - -

Da DrawSGG auch wissen muß wie die UV-Koordinaten eines jeden Styles ist, muß die Information nun auch irgendwo gespeichert sein. Das geschieht in INI-ähnlichen Dateien die wie folg aussehen kann:

Zitat:

Eine genaue Erläuterung erfolgt dann beim Release.

Montag, 25. Mai 2009 um 14:24 Uhr von Dottakopf

Einfach wow !
Ich fand ja schon das vorgänger modell einfach spitze, aber das du dir nun die mühe machst dies noch weiter zu entwickeln ist einfach TOP ! Wünsch dir viel Erfolg

Gruß
Dottakopf