Other languages > GLBasic - de

GLScriptBasic

(1/20) > >>

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) ---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

--- End code ---

Simples Pong:

--- Code: (glbasic) ---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
--- End code ---

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.

--- Quote ---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...
--- End quote ---
Es ist nicht als Alternative zu GLBasic gedacht, sondern vielmehr als Ergänzung.

--- Quote ---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...

--- End quote ---
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!

Navigation

[0] Message Index

[#] Next page