GLScriptBasic

[metzzo]

Da man irgendwie keine Blogs/Worklogs/whatever erstellen kann, erstelle ich hier nun einen Thread. Es soll quasi ein Worklog sein.

Nunja was ist GLScriptBasic? GLSB soll die gleiche Syntax wie GLB haben, also auch gleiche Funktionen und so. Der einzige Unterschied ist halt dass das ganze direkt interpretiert wird, also ohne C++/C Code Erzeugung. Dadurch kann man mehr Platformen unterstützen usw.

Die Vorteile wären:
* Sehr schnelles Kompilieren: Da hier kein komplizierter Code erzeugt wird sondern simpler Zwischencode (Bytecode)
* Jede beliebige Platform: Anders als fürs normale GLBasic muss es für die Zielplatform keinen gcc geben oder dergleichen, sie muss ledliglich eine Turing Vollständige Sprache haben (was JEDE Platform hat). Da man ja "nur" eine VM schreiben muss Ich hab so Visionen von GLSB für Handys usw.
* Einfache Erweiterbarkeit: Der Code wird im Gegensatz zu GLBasic frei ersichtlich sein, womit jeder der etwas davon versteht den Code erweitern kann
* Verwendung von GLBasic als Scriptsprache: Wer kennt es nicht? Man will ein MMORPG/Strategiespiel/anderes Mega Projekt programmieren und hat keine vernünftige Möglichkeit den Spielinhalt auszulagern, damit ist nun Schluss.

Die Nachteile:
* Langsamere Laufzeit: Da der Code interpretiert wird gibt es einen entsprechenden Overhead
* Nicht alle Syntaxelemente umsetzbar: Höchstwahrscheinlich werde ich auf PROTOTYPE und CALLBACK verzichten, da diese zu implementieren ein sehr hoher Aufwand darstellt. Vorallem Inline C++ ist vollkommen unmöglich.
* Keine iPhone Version: Da Apple strikt gegen solche "Interpretierte" Sprachen ist wird es keine iPhone Version geben.

Da es mehr Vorteile als Nachteile gibt, finde ich dass es sich lohnt.

Folgende Dinge funktionieren bereits:
IF - ELSE - ELSEIF - ENDIF
WHILE - WEND
FOR - NEXT
REPEAT - UNTIL
LOCAL - GLOBAL

ToDo (nach der Reihenfolge):
SELECT - CASE - DEFAULT - ENDSELECT
Funktionen und Subs (sind im Prinzip dasselbe)
Arrays
Alle Funktionen "wrappen", damit man *fast* jeden GLBasic Code auführen kann.

Technik: GLSB ist intern ein single pass Compiler, das heißt er arbeitet den Code in einem Durchgang durch. Dadurch ist er besonders schnell. Implementiert wurde er als Rekursiver Top Down Parser, dieser ist eine sehr stabile und auch leicht wartbare Compilerbau Variante.

OpCodes gibt es bereits 25. Von Rechnen bis hin zur Variablen Verwaltung ist alles dabei.

Wie das mit der Lizenz aussehen wird, werde ich mit Gernot weiter besprechen, wir haben da bereits eine Idee.

Folgende Codes werden bereits ohne Fehler kompiliert und ausgeführt:

Standard Syntax:

Code (glbasic) Select Expand

STDOUT " Hallo "+5

IF 5*9-99
STDOUT 1*4 + " Hallo Welt"
ELSEIF TRUE
STDOUT "GAGA"
ELSEIF FALSE
STDOUT "DABA"
ELSE
STDOUT 73
ENDIF
IF TRUE
GLOBAL k=200
STDOUT k
ENDIF
STDOUT k
LOCAL i
LOCAL j

j=800
STDOUT j
i=100
STDOUT "Variable var: "+i

i=0
WHILE i<10
STDOUT "i: "+i
STDOUT "j: "+j
j=j-1
i=i+1
WEND

FOR i=0 TO 10 STEP 2
STDOUT "For: "+i
NEXT


Simples Pong:

Code (glbasic) Select Expand


GLOBAL SpielerX=320, BallX=320, BallY=240,Angle=RND(360), Life

Life=4


WHILE TRUE
DRAWRECT SpielerX,50,80,20,RGB(255,0,0)
IF KEY(205)
SpielerX=SpielerX+4
ENDIF
IF KEY(203)
SpielerX=SpielerX-4
ENDIF
BallX=BallX+COS(Angle)*8
BallY=BallY+SIN(Angle)*8
IF BOXCOLL(SpielerX,50,80,20,BallX,BallY,32,32)
BallX=BallX-COS(Angle)*8
BallY=BallY-SIN(Angle)*8
Angle=360-Angle
ENDIF

IF BallX>640-32 OR BallX<0
Angle=180-Angle
ENDIF
IF BallY>480-32
Angle=360-Angle
ENDIF

IF BallY<0
Life=Life-1
BallX=320
BallY=240
Angle=RND(360)
ENDIF

DRAWRECT BallX,BallY,32,32,RGB(0,255,0)

PRINT "Leben: "+Life,10,450
IF Life<1
END
ENDIF
SHOWSCREEN
WEND

mfg

[D2O]

He, das ist ne Coole Idee 

Ich hatte auch schonmal an sowas gedacht, aber mir fehlt hierfür der Skill.

[FlowPX2]

Hi.
Nette Idee, doch glbasic läuft doch schon unter Linux, Windows und MacOSX und das nativ recht schnell... Dafür einen Interpreter zuschreiben bedeutet schnelleres compilieren der Programme aber dafür einbusen bei der Geschwindigkeit. Bringt daher eher für die Entwicklung etwas und das Release sollte man weiterhin nativ compilieren...

Ich für meinen Teil bin immer froh wenn ich kein Framework oder einen Interpreter mit schicken muss.. Das hatte mich auch am Anfang sehr an .Net gestört. Der Einzige Vorteil ist die Bytecode file welche für neue Zielsysteme nicht neu compiliert werden muss. Jedoch muss für jedes Zielsystem ein Interpreter bereit stehen...

Und zu deiner Idee das es auf Handys laufen soll... Da kommt nur soetwas wie Android in Frage... Da alle Handys mit JavaME viel zu langsam sind... Dafür war Handy Entwicklung immer schrecklich... Man könnte zwar auch einen Interpreter fürs iPhone schreiben aber dieser würde nicht in den AppStore aufgenommen werden.

xD Es sei denn man macht ein Spiel für den AppStore und macht als EasterEgg heimlich den Interpreter rein... Wenn Apple das nicht weiß kommt das durch war schon so beim C64 Emulator damals so mit einem Basic Interpreter bis es gemerkt wurde.

Aber sonst wüsste ich auch keine Vorteile von der Skriptsprache. Kannst du dazu einbisschen mehr erzählen? Da ich mich selbst sehr gut mit Skript und Programmiersprachen auskenne... Würde mich dein Vorhaben schon weiter interressieren.

[metzzo]

Habe ich nicht schon Vorteile oben aufgeschrieben?

Aber naja, eines der wichtigsten Dinge ist halt, dass man damit seine Spiele leicht erweiterbar machen kann. Da man hierbei de Inhalt in einzelne zur Laufzeit kompilierten Dateien auslagern. Wie zum Beispiel einzelne Objekte wie Gegner usw. Dafür wird oft Lua verwendet, aber GLBasic wäre um einiges angenehmer, da man weniger Portierungsprobleme hat.

Außerdem wäre es möglich GLBasic im Browser auszuführen. Dabei braucht man lediglich einen Java Interpreter für Java schreiben.
Besonders diese Vorstellung finde ich sehr interessant.

Nette Idee, doch glbasic läuft doch schon unter Linux, Windows und MacOSX und das nativ recht schnell... Dafür einen Interpreter zuschreiben bedeutet schnelleres compilieren der Programme aber dafür einbusen bei der Geschwindigkeit. Bringt daher eher für die Entwicklung etwas und das Release sollte man weiterhin nativ compilieren...

Es ist nicht als Alternative zu GLBasic gedacht, sondern vielmehr als Ergänzung.

Ich für meinen Teil bin immer froh wenn ich kein Framework oder einen Interpreter mit schicken muss.. Das hatte mich auch am Anfang sehr an .Net gestört. Der Einzige Vorteil ist die Bytecode file welche für neue Zielsysteme nicht neu compiliert werden muss. Jedoch muss für jedes Zielsystem ein Interpreter bereit stehen...

Man braucht kein Framework mitschicken, die Exe IST nämlich die VM das heißt dass man nichts zusätzlich installiert haben muss.

[Schranz0r]

Ich finde die Idee super und wenn das super geht dann kann man auch mal scenen/events in spiele Scripten!
Unerlässlich für ein RPG z.B

Wenns was zu testen gibt, sag bescheid!

[FlowPX2]

Ah okay das Skript wird an die vm gehangen. Das ist doch schonmal etwas trotzdem muss man für jedes System weiter hin einzelne vm's mit liefern auch wenn es zu einem Packet gebunden ist. Ähm im Browser ^^ auch wieder eine nette Idee... Muss man halt mal schau wie die performence bei einem Interpreter ist der in Java geschrieben ist...

Was vll auch eine coole Sache wäre GLbasic in verschiedene Sprachen zu über setzen für die es schon Interpreter gibt.

[metzzo]

So SELECT CASE DEFAULT ENDSELECT funktioniert nun auch. Hier waren halt die Sachen wie SELECT i; CASE >6 usw. ein wenig komisch zu implementieren aber das funktioniert nun auch endlich.

Code (glbasic) Select Expand

k=1
SELECT k
CASE 5 TO 10
STDOUT "Case1"
CASE -1
STDOUT "Case2"
CASE k
STDOUT "Case3"
DEFAULT
STDOUT "HHH"
ENDSELECT

Als nächstes kommen Arrays dran. Diese werden aufwändiger sein zu implementieren

[Quentin]

das alles sieht nach einem großen und längerfristigen interessanten Projekt aus
Wenn du das ganze in einem eigenen Blog haben willst, solltest du dich vertrauensvoll an unserer Haus- und Hofmeister Schranzor wenden

[Schranz0r]

Richtig Quentin

Wenns ein "Blog" werden soll, schreib mir ne PM mit Blognamen und ich mach dir dann einen auf.

[Kitty Hello]

Total abgefahren!!
Ich finde die Idee gut. Damit könnte man GLBasic als PHP/Perl/Python Konkurenz machen...

ÃÅ"brigens, ich werde GLBasic so verbiegen, dass die Engine selbst den Lizenzcode abfrägt und damit Wege für eigene IDEs offen sind. Zusätzlich werde ich einen Befehl einbauen "HASLICENSE(feature$, password$)", mit dem Ihr eigene Lizenzen in die IDE einbringen und im Code abfragen könnt.
Den Code-Generator gibt's gratis dazu.
Problem wird dann die Verteilung von gbal Dateien sein, dass man die nicht einsehen kann. Wenn jemand eine gute Idee dazu hat, her damit (anderer Thread, bitte)

[trucidare]

Man nehme ein GPC dazu ein stückle code mache eine pre pre komponente namens .gbal man habe es verschlüsselt natürlich.
dann nehme man ein befehl LOADLIB "blah.gbal" und beim kompilieren macht gpc aus der gbal lesbaren code aber tut den nich niemals niemals nie speichern

[Schranz0r]

WOW Gernot o.O

Bin sehr überrascht!
Wie schaut es nun mit dem 2D-Part und GLB aus? (Wie wir mal im Chat besprochen hatten).

[metzzo]

@Schranz0r: Hier finde ich es besser aufgehoben. Warum? Weil hier einfach viel mehr Besucher schauen, als bei den Blogs.

Naja es geht weiter. Mittlerweile funktionieren die Arrays in ihren Grundzügen. Das heißt:definieren, dimensionieren, setzen und aufrufen ist bereits möglich. Siehe folgenden Code:

Code (glbasic) Select Expand

LOCAL Array[]
DIM Array[5]
Array[3]=100
STDOUT "Arr: "+Array[3]
LOCAL Array2[] //Der Stack ist manchmal bei zwei Arrays durcheinander gekommen
DIM Array2[10][55]


Array2[-1][5]=10
STDOUT "Array: "+Array2[-1][5]

Als nächstes kommt halt, dass man die Arrays als solches an Funktionen übergibt. Außerdem sollte das zuweisen von Arr[]=Arr2[] funktionieren.

[Schranz0r]

Echt nicht schlecht muss ich sagen

Bin mal so frei und mach es Sticky!
Gute Arbeit muss belohnt werden

[metzzo]

Wow cool Danke

Btw. Array auf Array Zuweisung funktioniert nun also: Arr[]=Arr2[]. Dabei wird wie in GLBasic das Array kopiert anstatt referenziert.