Hallo,
Nachdem GLBasic nun mit Versionsnummer 5.3xx sich dem Jahreszyklus einer neuen Version nähert, möchte ich im Vorfeld darauf hinweisen, dass GLBasic in Zukunft langsam umstrukturiert wird, so dass eine Spezialisierung auf Spiele und Entertainment zugunsten einer, auch für den professionellen Bereich verwendbaren, allgemeinen Programmiersprache schwächer ausgeprägt ausfällt.
GLBasic wird weiterhin eine sehr einfach zu erlernende, schnelle Sprache bleiben, die ihren großen Schwerpunkt auf schneller Grafik und großer Plattformvielfalt hat. Dennoch wird ein weitreichenderes Klientel angestrebt, das besonders im Bereich der professionellen Anwendung durch den starken Spielebezug bisher nur zögernd GLBasic verwendete.
Konkrete Veränderungen, die bereits in den nächsten Updates offenbar werden sind eine erleichtere Weitergabe von GLBasic Bibliotheken ohne Quellcode offenlegen zu müssen, Erweiterung von GLBasic um eine GUI Komponente, Datenbankanbindung, Skriptsprachenunterstützung sowie ein breiteres Anwendungsspektrum in Handbuch und Webauftritt. Ferner wird ein Echtzeitmodus implementiert, der es erlauben wird programmgesteuerte 3D Grafiken ohne den Umweg X_OBJ... darzustellen und eine stärkere Netzwerkunterstützung angestrebt.
Die geplanten Änderungen werden innerhalb des nächsten Jahres durchgeführt.
Ich möchte mit diesen Änderungen niemanden verschrecken, da GLBasic ganz sicher nichts an Einfachheit und Umfang verlieren wird, sondern lediglich in andere Richtungen erweitert wird.
Die exotischen Plattformen "GP2X" und "X-Box Linux" werden weiterhin unterstützt werden, selbst da es sich jetzt abzeichnet, dass keine Neugeräte für diese Plattformen mehr angeschafft werden können. Die bereits verkauften Geräte liegen in einer beachtlichen Zahl vor, so dass dieser Markt sicher nicht unterschätzt werden darf.
Wird notiert! :rtfm:
:good:
Boahh, da bin ich aber gespannt.
Das hört sich alles verlockend an :)
Wie wirst Du das ganze weiter mit den Updates handhaben?
Bleiben die wie bisher oder wird es das ganze als erweiterung wie GLB 3D zu GLB 2D zu kaufen sein?
(Wäre in meinen augen auch verständlich)
Das mit der weitergabe von eigenen Libs wird sicher interresant.
Trenn den GLB Kern von der IDE bzw. mach es per Parameter aufrufbar, so das andere IDE's benutzt werden können,
nein die Originale ist ja nicht schlecht ;)
Wär aber auch gut, dann könnte man eine IDE mit dem GLB programmieren, für GLB :good:
wär doch auch mal interessant :D
Nicht das die IDE jetzt schlecht wär, aber Multiplatform wär dann ja möglich?!
Ja, wenn Du x-compiler für alle architekturen machst :puke:
:whistle: Klar mach ich doch gerne :noggin:
der wirklich schwerste compiler ist darwin(x), alle anderen lassen sich schwupps innerhalb von ein paar stündchen pro platform erstellen.
(darwin(x) hab ich für linux schon fertig)
aber man soll abwarten. Gernot kann sich zwar um linux und win kümmern aber wer wartet das mac-package?
mfg
Hallo Gernot,
eine sehr positive Weiterentwicklung - ich schliesse mich den Vorrednern an.
Nur bitte lass die Plattformen GP2x & Pandora nicht aus dem Blick - GLB ist für mich z.B. für die GP2x-Programmierung ein grosses Geschenk gewesen :nw:
Und ich würde gerne auf dem Pandora mit GLB weitermachen :good:
Toi toi toi für Dein Vorhaben !!!
CYA !
upp.
selten aber wahr. ich habe noch keine richtige Meinung dazu...
Ich hatte ja ein bißchen auf Pandora Unterstützung gehofft. Heißt das, dass die Entwicklung "weg" von Multiplatform geht, hin zur x86 Architektur?
Greetz Antidote
Nein, sicher nicht.
Hat Gernot aber schon am Anfang des Threads gesagt:
QuoteDie exotischen Plattformen "GP2X" und "X-Box Linux" werden weiterhin unterstützt werden, selbst da es sich jetzt abzeichnet, dass keine Neugeräte für diese Plattformen mehr angeschafft werden können. Die bereits verkauften Geräte liegen in einer beachtlichen Zahl vor, so dass dieser Markt sicher nicht unterschätzt werden darf.
Hi Sebastian,
jein.
Er schreibt von XBox-Linux und GP2x. Der Pandora hat aber nur soviel mit den beiden Sachen zu tun, dass das Betriebssystem beim Pandora auch auf Linux aufsetzt.
Es müssten (so denke ich) Anpassungen speziell der verschiedenen Steuerungsmöglichkeiten gemacht werden... und da weiß ich bis jetzt nicht, ob es unterstützt wird.
http://www.openpandora.org/ (http://www.openpandora.org/)
Korrekt. Ich warte aber noch, bis ich ein Gerät habe und ein SDL port da ist.
Dieses Pandore Teil wär mir ja zu teuer...
QuoteDieses Pandore Teil wär mir ja zu teuer...
Mhhh, kan ich verstehen... 250 sind ja auch viel Geld, aber im Vergleich zu einer anderen Handheld-Konsole ist das der Hammer (Von den Specs). Und ich freue mich schon auf meine Tragbare PS1 ;) + Amiga.
Aber jetzt will ich nicht länger ot sein ;)
SDL port ist doch schon vorhanden. das komplette open2x sdk ist vorhanden. sonst hätten die wohl kaum so schnell so viel porten können.
Quote from: Kitty Hello on 2008-Jul-16
[...] dass GLBasic in Zukunft langsam umstrukturiert wird [...]
Ich hoffe man kann zumindest als Benutzer einige Ideen einbringen, ob sie umgesetzt werden ist eine andere Geschichte =D
Hier sind zwei kleine Punkte:
Der Compiler sollte die Bezeichner aus GLBasic mit einem Prefix versehen damit man unter letzterem auch Schlüsselwörter aus C/C++ verwenden kannn. So wäre "LOCAL private, public" u.a. möglich. Der Aufwand müsste gering sein, Macros + Prefix müssten in den generierten Dateien geändert werden. Alte sowie neue Programme würden ohne Änderungen laufen.
Ich würde es begrüßen wenn man beim Befehl "LOADSPRITE bmp$, num#" beim Argument "num#" einen negativen Index angeben kann. Der Befehl würde dann einen fortlaufenden Index generieren. Beispiel: "block = LOADSPRITE "block.png", -1". Ich hoffe der Grund ist ersichtlich =P. Der Aufwand sollte ebenfall gering sein. Alte sowie neue Programme würden ohne Änderungen laufen.
Bitte um Kritik.
Gruß,
minor
Beide Sachen NAJA...
Grade bei Punkt 2 frage ich mich nach dem Sinn, kann mir das grad nicht wirklich erklären, wieso negative Werte von Vorteil sind?!
Quote from: Schranz0r on 2008-Jul-26
Grade bei Punkt 2 frage ich mich nach dem Sinn, kann mir das grad nicht wirklich erklären, wieso negative Werte von Vorteil sind?!
Vielleicht wird es an einem Beispiel klarer;
pl1 = LOADSPRITE "player_01.png", -1
pl2 = LOADSPRITE "player_02.png", -1
scum1 = LOADSPRITE "scum_01.png", -1
scum1 = LOADSPRITE "scum_02.png", -1
[...]
DRAWSPRITE pl1, 200, 0
DRAWSPRITE pl2, 200, 64
DRAWSPRITE scum1, 200, 64
DRAWSPRITE scum2, 200, 64
[...]
Der negative Index steht symbolisch für eine automatische vergabe von Indizes.
Gruß,
minor
Quote from: Ocean on 2008-Jul-26
Wenn dies wirklich eine wünschenswerte Syntaxerweiterung sein sollte, dann wäre es einfacher, der letzte Argument (-1) optional zu machen. Wenn's nicht spefiziert wird, soll die Spritenummer automatisch zugeteilt werden...
Ich wusste nicht das es optionale Argumente gibt =P. Dann wäre es sicherlich sinnvoller diese weg zu lassen.
Gruß,
minor
Kannst dir doch ein Funktiönchen machen.
Ich lade alle meine Bilder mit meiner Function LoadImage (ist schnell, kurz und schmerzfrei) z.B:
GLOBAL Haus ; LoadImage(Haus, DatenPfad$ + "Haus.png")
FUNCTION LoadImage: BYREF Image, Datei$
STATIC EwigeImgNr
IF DOESFILEEXIST(Datei$) = 0
//Msg(Datei$+"| |existiert nicht.", 1, 2)
ENDIF
INC EwigeImgNr, 1 ; Image = EwigeImgNr ; LOADSPRITE Datei$, Image
ENDFUNCTION
FUNCTION LoadSprite2: name$
STATIC ID
IF DOESFILEEXIST(name$)
LOADSPRITE name$,ID
INC ID,1
RETURN ID-1
ENDIF
ENDFUNCTION
Also Bild wird so geladen:
GLOBAL Bild1 = LOADSPRITE2("MeinBild.png")
GLOBAL Bild1 = LOADSPRITE2("MeinBild.png")
[/quote]
Das geht nicht ganz so, das Programm kackt einfach beim Start ab und gibt auch leider keine Fehlermeldung aus.
An so einem Fehler hab ich mir mal den Wolf gesucht.
So gehts, wenn die Variable bei Global nicht direkt einen Wert bekommt:
GLOBAL Bild1
Bild1 = LOADSPRITE2("MeinBild.png")
Ist wohl ein Bug im GLOBAL!
Werds melden
Grrr. Der initialisiert die GLOBAL schon im Konstuktor, das hat zur Folge, dass u.U. das Arbeitsverzeichnis nicht gesetzt ist.
Muss man andersrum machen.
Was auch noch recht cool wäre (wenn du wirklich GUI etc. anstrebst): Kontrolle über Threads, sprich: Multithreading. Ich kann mir vorstellen, dass es dir da ein wenig eiskalt den Rücken runterläuft (vor allem weil ich meine gelesen zu haben, dass GLBasic bisher nicht threadsafe ist, d.h. du müsstest die komplette Codebase teilweise erneuern oder überarbeiten) aber nächstes Jahr werden wahrscheinlich keine DualCore Prozessoren mehr hergestellt, dann wird Tripple und Quad Core der Standard sein und gerade für mathematische Programme ist das wichtig. Ach ja, wo ich gerade bei Mathe bin (^^): wir brauchen Typen, die grössere und genauere Zahlen speichern können. Und komplexe Zahlen (k.A. ob die aus C++ einfach übernommen werden können, ich weiss, dass C99 komplexe Zahlen eingeführt hat) :S
Edit: und kann es sein, dass glbasic.de auf 1&1 gehostet wird und glbasic.com auf Strato? Nur wg. neuer Internetauftritt und so...
Threads kann ich mal einbauen, über Synchronisation muss halt jeder selbst Bescheid wissen. Ich hab' da nicht viel Lust Neulingen Hilfestellung zu geben, weil's echt komplex ist, wenn's Geschwindigkeit bringen soll.
Für Komplexe Zahlen würde ich eine 3rd Party library verwenden. Wobei ich die noch nie gebraucht habe. Kommt in der Praxis nie vor.
Ja, glbasic.de ist auf 1&1 gehostet, verweist aber auf diese Seite.
Jap, als ich Threaded Programmierung gelernt hab hatte ich auch oft das Gefühl, dass eine Migräne im Anflug ist :whistle:
Im Prinzip würde es ja ausreichen, eigene Funktionen als Threads zu definieren. Ich hab nämlich das Gefühl, dass es bei Renderfunktionen nicht so viel bringen wird ;) Aber zum Laden der Modelle und Texturen wäre es halt schön und für eigene Berechnungen.
Nachdem das nächste Update größer sein wird (neuer WIZ compiler) hab ich vorgenommen weitere Änderungen einfließen zu lassen. So wird es z.B. jetzt natürliche (auch negative) Ganzzahlen geben (integer), die man mit "#" am Variablennamen erkennen wird.
Somit wird es möglich sein noch schnellere Spiele für GP2X/WIZ zu schreiben, da die ARM Prozessoren keine FPU (Gleitkommazahlencoprozessoreinheiten - geiles Wort) haben.
Um sich schonmal darauf vorzubereiten kann man die Zahlen mit "_N" hinten anstellen und später durch "#" ersetzen. Ich muss dadurch leider Befele wie READLONG usw. abändern. Wird aber nicht weiter tragisch werden.
hört sich dochmal gut an :)
Uih uih
willst du wirklich # für INTEGER verwenden? Glaube in QuickBasic war das das Präfix für Floats, Integer war glaube ich %. Ist aber wirklich schon lange her.
Ok, wird nicht mehr allzu relevant sein, aber bei meinem Haarausfall, ich wette, irgendwann wird ein Spätberufener sich endgültig von QuickBasic verabschieden wollen, sieht GLBasic und stellt genau diese Frage *ggg*
glaube in BB3D war es auch so:
% = integer
# = float
Wie ist das in Glitz:
i% = 5
i = 7 // ist das eine eigene Variable, oder ist das i#?
Wenn ich mich recht erinnere war das in QBasic eine eigene Variable vom Typ Float.
Da kann ich mich aber auch täuschen...
Hello KH,
warum verwendest Du keine Festpunktarithmetik, wenn die Arm Cpu's keine Fpu haben ?
Einfach eine Integerzahl verwenden, von der ein bestimmter Teil als Kommaanteil verwendet wird.
Dazu wird die Gleitkommazahl mit einen konstanten Faktor multipliziert und gerundet.
Damit ist die Intergerzahl eine Gleitkommazahl!
Ungefähr so:
Addition 1.2*100 + 1.5*100 = 2.7*100
Subtraktion 1.2*100 - 1.5*100 = 0.3*100
Multiplikation 1.2*100 * 1.5*100 = 1.8*100 /100
Division 1.2*100 / 1.5*100 = 0.8*100
Man kann Schiebeoperationen verwenden bei Multiplikation,Division, mit eine 2er Potenz!
Kannst Du damit was machen? KH.
Ein Hash Sign steht immer für Float!
Man kann auch ein "!" verwenden für INTEGER, ist aber dann gelogen, weil 32 bit.
Mach ich intern. Aber der Güligkeitsbereich ist recht eingeschränkt.
in älteren Basic-Dialekten konnte man mit DEF... (DEFINT, DEFDBL oder so) arbeiten. Wenn ich mich recht erinnere, war % Int, ! float und # double
z.B. DEFINT a-c
definiert alle Variablen, die mit a, b oder c beginnen, als integer. Dann musste man im Coding auch nicht mehr das % anhängen. Ob das für GLBasic aber so sinnvoll wäre?
Ansonsten:
Da doch eh alles in C++-Code übersetzt wird, wie wäre es, wenn man sich dort anlehnt. Standardmäßig alle Variablen float wie gehabt. Ansonsten Deklarationen möglich, wobei man sich auf einige wenige Datentypen beschränken könnte
z.B.
a = 5 // a ist float
INT b = 6 // b ist integer
UINT c = 5 // c ist unsigned integer
oder was halt so Sinn macht. Vielleicht auch etwas sprechendere Bezeichnungen
Quote from: Kitty Hello on 2008-Sep-05
Wie ist das in Glitz:
i% = 5
i = 7 // ist das eine eigene Variable, oder ist das i#?
nein ist die gleiche Variable!
In Blitz muss man alles angeben ausser Integer.
Aber i# = 3.14 und i da schepperts... bzw. es wird als 3 gehandhabt.
OK, also kann man sowas machen:
LOCAL i#
i = 3 // hier wird auf i# zugegriffen.
genau in dem Fall wär dann i# = 3.0
Also bei QBasic war's noch so:
Single !
Integer %
Double #
Long-integer &
String $
Falls euch das was hilft...
Single !
Integer %
Double #
Long-integer &
String $
Bei Visual Basic oder VBNet ist es genauso.
wobei in den meisten sprachen das % und & zum problem werden kann :D
in machen sprachen ist % = Mod und & = ein verweis auf eine Speicheradresse :)
Ist halt die Frage, ob man das nicht anders lösen sollte:
z.B. i_Variablenname oder Variablenname_i --> als Integer
_d
_f
_l
_s
Wäre doch auch eine Variante, oder? Für mich persönlich (möchte nicht für andere sprechen) ist es so ziemlich übersichtlich.
Vielleicht sollte man einfach gar nix ändern?!
Also, ich wäre schon dafür zu haben! =D
Wichtig fände ich halt, wenn man BOOL als Datentyp mit dazu nehmen könnte. Die benutze ich persönlich nämlich sehr viel und jedesmal einen Integer für 0/1 zu verwenden, finde ich irgendwie auch nicht besonders sinnvoll, oder liege ich da falsch???
Aber jedesmal hinter einem Variablennamen nen Buchstaben schreiben zu müssen ist scheiße. C, C#, BlitzMax, etc. haben verschiedene Variablentypen und da muss man nicht _i, _f, etc. anhängen. Damit zwingt man allen Usern eine Konvention auf, die eigentlich überflüssig ist, bzw. die vllt. nicht alle benutzen wollen. Da wäre ja %, $, #, etc. noch besser (aber auch das fände ich blöd). Das unterbricht total den Schreibfluss, wenn man ständig auf Sonderzeichen über die Shift Taste zurückgreifen muss. Ich wäre lieber dafür, die Variablen nicht extra auszuzeichnen und eben die Sonderzeichen in den Namen zuzulassen. Dann kann es jeder so machen wie er will.
Pwnlicious rechtgeb,
scheint doch irgendwie zu lästig, jedesmal den Datentyp auch noch kenntlich zu machen. Aber die Typisierung von Variablen ist im Prinzip ja schon mit drin
LOCAL wirsing AS t_wirsing
z.B. Wenn man schon Variablen als Typen anlegen kann, wäre es doch sinnig, daß auch für andere Datentypen zu verwenden
LOCAL gemuese AS INTEGER
oder so. Wird nichts definiert, sind weiterhin alle Zahlenwerte FLOAT. So bräuchte sich niemand umzugewöhnen, aber wer will, kann die neue Funktionalität ja nutzen.
OK, die neue Version wirde gerade getestet.
Die Variablen bleiben wie bisher. Wenn man beim Erstellen oder 1. Verwenden einer Variablen ein % anhängt, ist das ein Integer, bei # explizit ein floating point.
Man kann die #% immer anhängen, muss man aber nicht.
Ich werde in den Beispielen wo nötig sowas machen:
LOCAL a#, b,c
READLONG(file, a)
...
Statt BOOL kann man jete Zahl nehmen. TRUE und FALSE gibt es in GLBasic.
cool... schubst du es grad hoch?