Messages

Hey guys!

(Un)fortunatly Gernot has decided to make his own HTML5 target for GLBasic(would have been nice if he mentioned it before...). So I can't take the name "GLBScript" anymore, the confusion wouldn't be very good... So I have to find a new name...

In the meantime I was very busy and was not able to continue GLBScript development as far as I wanted, but I continue stadily!

Code (glbasic) Select Expand

Version: 0.4
Improved: Google Closure update
Fixed: Charset problem
Added: Experimental bitmap font system - kerning is missing!
Added: Font Kerning
Fixed: "Super" in methods functions again
Fixed: Compiler crash when using ABSTRACT
Fixed: CREATESCREEN threw "Image not yet loaded", but it was already loaded!
Added: DRAWRECT x,y,w,h,TransparentColor <- "clears" the pixel of the Screen - useful for terrain destruction in worms style!
Added: GETPIXEL - slow as hell...
Fixed: Transparency with fonts
Added: INKEY$
As you can see just minor things...

Don't wonder: The samples are not available anymore - I have to restructure my whole concept.

GLBasic already has a command to open the webbrowser: http://www.glbasic.de/xmlhelp.php?lang=en&id=367&action=view

some off topic: GLBScript supports OOP. Inheritance and late binding is fully supported (even ABSTRACT) and of course methods.

auf systemen bei denen die PATH variable falsch eingestellt ist.

füge deiner path umgebungsvariable ";c:/windows/system32" hinzu.

jetzt sollte xcopy gefunden werden

Beim Programmieren von GLBScript ist mir das auch aufgefallen.

Mein Workaround war, dass ich den Catchcode in einer eigenen Funktion untergebracht habe.

Weiters ist mir noch aufgefallen, dass ein GOTO in einen Catchcode zu C++ Fehlern geführt hat (Allerdings habe ich das provoziert(dachte mir schon dass das kommen wird ), habe es nicht produktiv einsetzen wollen )

Coolo!!! when we can purchase about the "plugin" for GLbasic, you are thinked about lauch a pre - release and when 3D it´s done, launch this module?¿...

When it's done!

I don't want to rush. I want GLBScript to be stable and working well. So it will take its time. And the plugin will also be its own "chapter". So please don't expect it too soon.

Code (glbasic) Select Expand

Fixed: LOCAL E; FOREACH E IN Arr[]; NEXT <- reused variable "E" instead of declaring a new one.
Fixed: Default seed is not 0, it is the unix timestamp
Fixed: LOCAL a; ...; LOCAL a <- does not generate buggy JavaScript code
Improved: Lexer is much faster* (8000 lines in about 8 seconds instead of 16 seconds)
Improved: Parser parses in less than 1 second
Improved: Precompiler precompiles in less than 1 second
Fixed: RND returned sometimes values out of range
Fixed: GLOBAL foo; FUNCTION Bar: LOCAL foo[]; ENDFUNCTION <- threw syntax error
Fixed: Compiler shows correct character position in errors
Improved: Again! The lexer is much optimized and does its really fast! Compiling of the compiler itself takes now around 7 seconds (from 150 seconds to 7 seconds, a huge step forward :D) - GLBScript compiling time is now as fast as GLBasic's
Improved: Type creating much faster.
Improved: Function calls much faster (unref() calls are reduced) -> needs some debugging
Fixed: GOTO works again!!
Fixed: myArray[0.5] works
Fixed: ROTOSPRITE / ROTOANIM works as expected - rotates in the middle.
Fixed: Internal array cloning works again
Fixed: FOR has variable declaration is correct
Fixed: LEN with Kerning works (but no "real" kerning is performed...)

Faster Compiling
I made the compiler now as fast as the native GLBasic compiler. It compiles 8000 lines of code in around 6 seconds on my PC. I'm quite happy about this, because a few weeks ago, compiling of 8000 lines of code took around 140 seconds.

Further I also fixed a lot things and optimized the HTML5 code!

I'm working on a little "present". I don't want to spoil too much, but GLBScript will then the first time being usable for the first time!!

Next week, I am not at home, so I can't really work on GLBScript

Thanks.

But I'm not (yet) using OpenGL at all . HTML5 provides its own drawing functions, which are "similiar" to GLB 2D command set, but not equal. Sadly HTML5 does not provide a lot of drawing functions that GLB does. For example: Drawing of textured polygons is a pain in the ass in HTML5 - same with image tinting.

And on the language side, there are a lot of language features that are very difficult to port to other languages (ALIAS, All types on the stack, Not static dimension count at compile time, ...).

Don't get me wrong, the API of GLBasic is awesome, but the only reason why it runs on the browser is my hard work and "perfection"

[glscripts]

yes glscripts could been that and property best to doing that, so glscripts could add more platform support, but property command limited support for some platforms example 2d/3d and various possible other commands), and have think its better using glscripts and not glbasic for those other languages platforms.

Then Gernot could concrate to bugfixes and add GUI and such thing and GlScripts could add more support (but of course more money :-D). GlScripts downside is Visual Studio might been required to use with C# and GlScripts, but I think its complety ok (just like xcode is required to compile iOS apps).

This is no downside, it is the next logical step if you want to support XBox 360. GLBasic does the same with the Android SDK... Btw, the name is: GLBScript   

It would be useless.
The source code of a compiler is really complex and without any background knowledge nearly impossible to understand. If Gernot would have written an abstract enough compiler backend (I think he hasn't) it would not be that hard to write another backend for GLBasic.

But there is already something on the go: GLBScript. It has already an experimental (very experimental...)  C# target. Due to the very strict seperation of compiler backend and frontend it's really easy to add another languages to the compiler (The basic C# support was implemented in around 4 hours). And I am developing every free minute
Of course the C# target hass less priority than the HTML5 target, but maybe when I have time I could improve it and make it available for XNA (XBox 360 / Windows Phone 7) and/or PS Vita.
I don't know whether XBox 360 or PSVita have reasonable HTML5 support, but if they have, it's already possible to make games for these targets - GLBScript for HTML5 is already very advanced.

Yes I know. Uint8Array is used by the file functions... nothing much I can do against it because file commands really depend on that (Thats the reason why it doesn't work on IE, IE also has no Uint8Array implemented)

Try using Chrome for Android, maybe this browser supports it.

I think this is perfectly possible!

Code (glbasic) Select Expand

Improved: Faster compilation: Instead of tokenizer -> preprocessor -> tokenizer -> analyser ->... it's now tokenizer -> preprocessor -> analyser!
Fixed: Some bugs due to the new preprocessor
Fixed: Array bug (DIM had wrong behaviour when passed a float)
Improved: CAST2INT much faster when casting to integers (uses ~~ in JS)
Fixed: LEN() on uninitialized arrays (LOCAL arr[]; STDOUT LEN(arr[])) failed
Fixed: TYPE TGameObject; ABSTRACT FUNCTION Test:; ENDTYPE <- Failed (needed second function)
Fixed: XML parser can handle now tabs!
Fixed: DOESFILEEXIST / DOESDIREXIST function better
Improved: code cleanup
Fixed: ?IF works better (more robust, can handle NOT and much more)
Improved: Some optimizations compiler side - faster compiling (still too slow...)
Added: New Targetsystem - 100% extensible with XML files - no platform/target specific stuff is hardcoded.
Removed: ?BLACKLIST command - now configurable with XML
Improved: Compile time MUUUUUCH faster - One bootstrap (= compiles its own source code) takes 25s instead of 110s on my pc :) but still: GLBScript is not the fastest compiler...
Fixed: String prototypes in JavaScript
Improved: Ressource handling much (is not embedded into the  JavaScript file -> much slimmer!)
Fixed: Really strange compiler crash (did some weird assignments to get rid of the crashes in "CreateExpression")
Fixed: DOESDIREXIST/DOESFILEEXIST returned sometimes wrong results
Added: Little HTTP Server to test your games easily
Fixed: GLOBAL myGlobal = myConstant; CONSTANT myConstant = 100 <- works now (use constants before they are defined)
Fixed: GLOBAL myGlobal = MyFunc(); FUNCTION MyFunc: .... <- works again (use of functions in GLOBAL definitions before they are defined)
Improved: Casting faster
Added: FOR i = 0 UNTIL 10 <- syntactical sugar for: FOR i = 0 TO 10 - 1, useful for things like: FOR i = 0 UNTIL LEN(MyArray[])
Fixed: Late binding with ABSTRACT methods
Added: SPRITE2MEM
Fixed: INC/DEC with floats/strings function now (INC a, 0.5 <- with out cast to integer internally)
Improved: OOP system cleaned up -> more rubust
Added: super.MyFunction() in methods.
Added: MyBaseClass(myDerivedClass) <- Casting!
Fixed: INTEGER(1)/INTEGER(2) returned in JS 0.5 instead of 0
Fixed: If FILESEEK goes beyond the file size it does not throw an error but it sets the position of the file to the last byte!
Fixed: STARTPOLY without POLYNEWSTRIP and mode = -1 works!

In the mean time I was of course spending my time on GLBScript. There are several topics I want to highlight:

Bug fixing and some other improvements!
I fixed tons of bugs and did a lot of debugging.  I have also rewritten the whole  file management under the hood. Before every file got embedded into the JavaScript file and was put into an array. Now there is for every writable/readable file a ".GLBSCRIPT_DATA" file which contains all the bytes of your file as a string representation. This is because JS does not allow a synchronous file access with byte data, so I had to workaround this. Because of this system there is no need of the "?BLACKLIST" preprocessor command anymore, which basically said that the compiler should not embed this file.

Compiling time much improved
Initially compiling of 7000 lines of code took around 130 seconds. I optimized a lot (I even wrote my own HashMap implementation) and was fixing a lot of bottle necks. Now compiling of 7000 lines of code take around 30 seconds. Not the fastest compiler on the world, but much better than the previous time...

Target system
I have rewritten the whole target system and now it's 100% extensible without changing code. So if you want for example running GLBScript via node.js you can write your own target. GLBScript uses XML for defining the targets.

Currently the "settings.xml" looks like this:

Code (glbasic) Select Expand

<target name="html5" lang="js">
<template path="HTMLTEMPLATE_CONSOLE" name="GLBFile.html" mode="console" />
<template path="HTMLTEMPLATE_GRAPHICS" name="GLBFile.html" mode="2d" />

<lib path="lib.js" mode="console 2d 3d" />
<lib path="array.js" mode="console 2d 3d" />
<lib path="math.js" mode="console 2d 3d" />
<lib path="string.js" mode="console 2d 3d" />
<lib path="file.js" mode="console 2d 3d" />
<lib path="ini.js" mode="console 2d 3d" />

<lib path="2d.js" mode="2d 3d" />
<lib path="sound.js" mode="2d 3d" />
<lib path="input.js" mode="2d 3d" />
<lib path="sprite.js" mode="2d 3d" />
<lib path="collision2d.js" mode="2d 3d" />
<lib path="screen.js" mode="2d 3d" />

<extension name="exe" action="ignore" />
<extension name="png" action="ignore" />
<extension name="bmp" action="ignore" />
<extension name="tga" action="ignore" />
<extension name="jpeg" action="ignore" />
<extension name="mid" action="warning" />
<extension name="ac3" action="mp3 ogg" />
<extension name="wav" action="mp3 ogg" />
<extension name="png" action="ignore" />
<extension name="mp3" action="ogg" />
<extension name="ogg" action="mp3" />
<extension name="ddd" action="ignore" />
<extension name="ddw" action="ignore" />
<extension name="DIR_DATA" action="ignore" />
<extension name="GLBSCRIPT_DATA" action="ignore" />

<file name="GLBScript.js" action="ignore" />
<file name="GLBFile.html" action="ignore" />
<file name="GLBScript_opt.js" action="ignore" />
<file name="GLBScript_unopt.js" action="ignore" />
<file name="GLBScript_beautiful.js" action="ignore" />
<file name=".svn" action="ignore" />

<action type="embeddata" />
<action type="appbeforelibs" />
<action type="optimize" name="closure" />
<action type="save" name="GLBScript.js" />
<action type="run" command="$COMPILERDIRTools/GLBServer/GLBServer.exe '$PROJECTDIRGLBFile.html'" />

</target>

During this I also removed the definition of the built in commands (DRAWSPRITE, SETCURRENTDIR, ...) into an extra file called "Header.gbas" which basically is included into every project you compile with GLBScript.

Improved OOP
Now it's much more robust and has many features. "super.myClass()" works in methods. You are able to cast between classes: "(MyClass(DerivedFromMyClass).hello". You can also define ABSTRACT methods. Quite cool I think!



Here is a little demo I've ported to GLBScript: http://programming-with-design.at/files/GLBScript/Isometric/GLBFile.html

Hey!

I wanted to see if GLBScript is capable of compiling and running this nice piece of code. Compiling was no problem and for executing I had to fix some bugs (mainly related to POLYVECTOR)

Here is the running example: http://programming-with-design.at/files/GLBScript/Isometric/GLBFile.html
Sadly Firefox is really slow, but Chrome seems to be the fastest (InternetExplorer does not even start...)

Code (glbasic) Select Expand


X_MOVEMENT 0, 0, 0 //Reset position first
X_ROTATION 90, 1, 0, 0 //Rotate your world!
X_PUSHMATRIX //sets the origin to the current transformation matrix

//draw your world here

X_POPMATRIX


I think this should be what you need.

... or use GLBScript as standard compiler and extend it for the "old" targets


Hope you will recover your data . Maybe you will use in future SVN/Git so your data is safe and secure on a server?

What payment methods will you be accepting ? as "Throwing money at the screen" doesn't seem to work 

Stones

Just kidding. I think I'll use PayPal.