Messages

Alles klar. Wir werden sehen, wohin mich mein Weg führt. Meine Zielplattform ist auch vor allem Android.

Wie gesagt, ich schaue es mir nach meinem Projekt an, eventuell steige ich um, wenn es auch für mich überzeugend genug ist und ich für mich mehr Vorzüge gegenüber GLBasic erkennen kann. Ansonsten bleibe ich bei "der einfachsten Programmiersprache der Welt".

Ahja! Ich habe deshalb gefragt, weil das ja mit der Einfachheit von Basic nichts mehr gemeinsam hat. C# ist allein schon syntaxtechnisch nicht sehr liebsam und die OOP hatte ich, zumindest vor vielen Jahren, nicht ansatzweise verstanden. Ich kaufte mir ein Buch C++ for Kids, konnte jedoch keinen Zugang zu dem Prinzip finden. Mittlerweile weiß ich grob, was es damit auf sich hat, doch diese Möglichkeiten wirklich ausnutzen zu können und die Details tatsächlich zu durchblicken, davon bin ich meilenweit entfernt. Dennoch werde ich mir Unity einmal genauer ansehen, gerade jetzt, wo du sagst, dass du offenbar prima damit zurechtkommst. Vielleicht sogar besser als mit GLBasic (?)

Na wie auch immer, ich rede zu viel am Thema vorbei. Danke für die Rückmeldung, trotzdem.

Ein paar Eigenheiten gibt es zwar schon, mit denen man erstmal richtig umzugehen wissen muss, aber dann ist es eigentlich einfach. Bei meinem Handy erhalte ich mit GETMOUSECOUNT 32 Pointer, maximal 8 davon sind aber tatsächlich nutzbar und ich erhalte im besten Falle 8 unterschiedliche Koordinaten. Blöd ist, sobald man einen Finger vom Bildschirm nimmt, muss man beim richtigen Koordinaten-Paar bei der Auswertung bleiben. Habe ich noch mit 2 Fingern eine Zoom-Geste gemacht und nehme einen runter, kann es passieren, dass ich mit dem anderen dann erstmal nichts steuern kann. Erst wenn ich neu aufsetze, werden die Pointer wieder neu geordnet. Außerdem werden immer die letzten Koordinaten-Werte zurückgeliefert, als der Pointer aktiv war, also der Screen berührt wurde. Das ist bei der Maus ja anders.

In der Regel wird man nur bis 2 Pointer brauchen, wenn man ein Spiel mit z.B. Pinch-Zoom-Geste schreiben möchte. Muss immer nur auf eine Berührung gleichzeitig reagiert werden, braucht man nur GETMOUSESTATE. Ansonsten Anzahl der Pointer ermitteln, dann eine Schleife mit SETACTIVEMOUSE, wo dann mittels GETMOUSESTATE die 4 Werte in ein Typenarray gegeben werden, dann kann man damit arbeiten und den Spaß auswerten.

Ach du bist jetzt bei Unity? Solange man dort nicht Coden muss, ist es sicherlich einfacher bzw. man hat halt etwas Greifbares. Aber kein gutes Spiel kommt auch dort ohne Skripte aus und da ist ja Schluss mit einfachem Basic. Wie machst du das dann?

An dieser Stelle würde ich dich bitten, dir bereits vorhandene Beispiele heranzuziehen. Die gibt es unter Garantie. GETMOUSECOUNT() und GETMOUSESTATE() sind da nützlich

Danke für die Stellungnahme. Also wenn alles gut oder sogar ein bissel besser werden sollte, ich bin dafür 100 pro offen

[Schranz0r]

Kleine Zwischenfrage, Schranz0r, du sagst du arbeitest gerade mit C#? Wie kommst du damit so zurecht, ist das sehr viel schlimmer als Basic? Ich frage deshalb, da ich aufgrund der ungewissen Zukunft von GLBasic mit überlege, mich nach Abschluss meines aktuellen Projektes auf die Spieleentwicklung mit der Unity Engine einzulassen und da müsste ich ja dann wahlweise mit C# skripten. Was glaubst du, wie heftig ist der Umstieg oder anders ausgedrückt, wie groß sind die Chancen, damit ebenfalls prima klarzukommen, wenn man das mit Basic hinkriegt?

Yes, there it is!

HKEY_CURRENT_USER\Software\Dream_Design\GLBasic\

All in there - thanks Gernot

Zum Seitenverhältnis wollte ich noch etwas sagen, hatte ich vorhin erstmal vergessen. Berücksichtige ich bis jetzt auch noch nicht und werde ich noch einbauen. Ich denke, die Vorgehensweise sollte in etwa so sein, dass erstmal das Verhältnis des aktuellen Bildschirmes bestimmt werden muss. Würde die längere durch die kürze Seite teilen. Ebenso muss bestimmt werden, welches Verhältnis die Grundauflösung deiner App hat. Stimmen die beiden Werte nicht überein, wird die skalierte Auflösung mit der längeren Seite der Bildschirmbereite (längeren Seite) eingepasst und in der Höhe mittig ausgegeben, so dass schwarze Balken bleiben.

Mathematisch bin ich nicht der Schnellste, ich müsste das dann ausprobieren. Krieg ich aber auf jeden Fall hin, wenn ich es einbaue. Ich würde dann dem Anwender jedoch stets die Möglichkeit lassen, zu wählen, ob das Verhältnis angepasst werden soll oder die App bildschirmfüllend ausgeführt werden soll. Bei kleinen Abweichungen stört das nicht jeden.

Zu beachten wäre dann natürlich, dass die Pointer Eingaben ebenfalls umzurechnen sind und die linke obere Ecke bei Anpassung des Seitenverhältnisses von 0,0 abweicht. Das ist wichtig, sonst sind alle Toucheingaben verschoben.

Zu deinem Gedanken, die Grafiken schon vorher zu skalieren würde ich sagen: bringt keinen Vorteil, macht die Sache, so wie ich das überblicke, keinesfalls einfacher - eher im Gegenteil.

Ich kann dir sogar mehr als nur ein Hello World geben. In der Zip im Anhang befindet sich ein altes Testprogramm für eine Dialogbox Demo, allerdings lädt er die Medien unter Android nicht, tut deinem Testzweck aber nichts ab. Unter Windows kannst du sehen, wie es eigentlich aussehen soll.

Da ich derzeit ein Android Spiel in der Mache habe, kann ich dir sagen, wie eine Möglichkeit des Handlings mit verschiedenen Auflösungen aussehen kann. Zunächst erstellst du einen virtuellen Bildschirm.

Code (glbasic) Select Expand

CREATESCREEN 0, 0, Width, Height
Die Breite und Höhe stellt die Auflösung dar, in der du dein Spiel schreiben möchtest. Je nach Qualitätsanspruch wählst du hier eine eher höhere Auflösung, so dass die Darstellung auf den Zielgeräten scharf genug ist. Mit GETDESKTOPSIZE ermittelst du, ebenfalls zuvor, noch die Auflösung des Bildschirmes, auf dem die App gerade läuft.
Dann kommt die Hauptschleife.

Code (glbasic) Select Expand

USESCREEN 0
CLEARSCREEN
[...]
USESCREEN -1
STRETCHSPRITE 0, 0, 0, DeviceScreenWidth, DeviceScreenHeight
SHOWSCREEN
Dort, wo die eckigen Klammern stehen, packst du alle deine Grafikausgaben hin. Mit diesem Code werden alle Grafiken vollautomatisch richtig skaliert und du brauchst dich beim Programmieren um nichts mehr kümmern und schreibst dein Spiel nur für die feste Auflösung des virtuellen Bildschirmes, die du dir ja beliebig festlegen kannst. Es gibt zwar noch ein paar Kleinigkeiten zu beachten, aber das wäre erstmal das Grundprinzip, welches ich verwende. Und es funktioniert wunderbar. Im Übrigen arbeite ich mit einer Grundauflösung von 1024x576 Pixeln.

Habe vorhin schon vergebens in der Registry nach in Frage kommenden Einträgen gesucht. Gibt es nicht Tools, die Änderungen in der Registry überwachen und direkt melden, dann könnte man das schnell herausfinden. Ich finde das ja eine lästige Masche, dass Anwendungen immer irgendwas in die Registry schreiben. Warum nicht immer direkt in den eigenen Programmordner?

Ja natürlich meinte ich auch mehrere Aufrufe von DRAWSPRITE, nicht, dass der Befehl wegen mehrerer Karten auch mehrfach im Code steht

Selbstverständlich! Für jede darzustellende Kartengrafik ein DRAWSPRITE.

Wie es in der Hilfe so herrlich formuliert ist: "GLBasic benutzt versteckte Bildschirmseiten für flackerfreien Grafikaufbau." Diese Phrase gefällt mir bis heute saumäßig gut
Durch diese Methode hat man einen sauberen Bildaufbau. Grafiken, die bspw. verschoben werden sollen, müssen vorher nicht mit der Farbe des Hindergrundes übermalt werden. Dadurch kann ein Flackern entstehen - jeder kennt das von früher. Die auf die versteckte Bildschirmseite gezeichneten Grafiken werden praktisch auf einen Schlag in den Vordergrund gebracht.

Eventuell könnte für dich der Befehl CLEARSCREEN -1 interessant sein. Damit werden Grafiken zwar auch nicht unmittelbar auf den sichtbaren Bereich gerendert, jedoch bleiben sie bei jedem Aufruf von SHOWSCREEN auch ohne erneutes Zeichnen erhalten. Das zumindest interpretiere ich selbst aus der Beschreibung. Allerdings solltest du diese Variante nicht verwenden, sondern dir die gebräuchliche Methode aneignen. Schließlich machst du es, wie es dir am liebsten ist.