Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - metzzo

No, the socket commands do not work yet.
INLINE / ENDINLINE will never work. This is compiled directly to JS+HTML5, no C++ compiler is involved. I personally consider injecting "foreign code" into a language via syntax elements like "INLINE / ENDINLINE" as bad code, because it hinders the language itself and causes lots of problems, especially in regards to compability and encapsulation. This is something I want to avoid as much as possible.

Saving/Loading in the IDE is currently done in localStorage, when compiling source code, which is a temporary solution. Pasting text should work though.
Nice to hear! I did no tests on iOS (do not own a device) and Android was also quite untested (but as I can see Touch, Screen adjustment and Sound does not work yet properly, which will be fixed soon).
Thanks guys! Id love to see 123basic being used!

I just fixed the FF problem - which seems like only occured to me (it was a result of getImageData returning inaccurate pixel data which was needed for LOADFONT to determine the width/height of cells)
Hey guys!

Recently I've started working on 123basic again and I think it's ready to show it to you guys.
First of all the Changelog:

Code (glbasic) Select
Fixed: INIGET$ returns "NO_DATA" if data does not exist
Fixed: NETWEBEND redirects properly
Fixed: ALPHAMODE behaves more like GLB (but not quite the same)
Fixed: PRINT with unknown characters does not crash - ignores them
Fixed: SMOOTHSHADING works properly
Fixed: MEM2SPRITE works again on newer browsers
Fixed: SOX with libmad
Fixed: MUSIC playback & looping
Fixed: ALPHAMODE 0.5; SHOWSCREEN did cause weird graphical gliches

Fixed: NOT fixed.
Fixed: ROTOSPRITE/ROTOANIM/ROTOZOOMSPRITE/ROTOZOOMANIM use correct image handle when rotating
Changed: New file structure of project
Fixed: Default Font is now loaded properly - even if its not in the /Media directory
Fixed: "FOR i = 0 TO 0 STEP 0" had wrong behaviour
Fixed: SETSCREEN does not ignore Fullscreen parameter anymore and the width/height is set properly
Fixed: TYPE Foo; Bar; FUNCTION Asdf: Bar; RETURN Bar; ENDFUNCTION // this returned the value of self.Bar instead of the value of the parameter
Fixed: TYPE asdf; Foo; FUNCTION Bar: FOR Foo = 0 TO 10; NEXT; STDOUT Foo; ENDFUNCTION; ENDTYPE // Implicit self in For should create new local variable to maintain compatibility
Fixed: ZOOMSPRITE 0,0,0,-1,1 // position of image was not correct
Fixed: "settings.xml" with more than 1 target didnt function properly
Fixed: VIEWPORT sets origin properly
Changed: Began to work on VM - does not run yet
Fixed: Float in array access bug
Fixed: LEN("\n", TRUE) crashed
Fixed: SPLIT returned wrong array length
Fixed: POLYVECTOR with mode == 1 and no POLYNEWSTRIP crashed
Fixed: "Hugo" < "Manfred" evaluates as expected (<,>,>=,<= are overloaded properly)
Fixed: Arrays with ref that were not initialized with DIM/REDIM had wrong defaultval (caused to problems with strings for example)

I have mainly fixed a lot of bugs... I mean a _lot of_ bugs. Stuff like ddgui compiles and executes properly (but because it is not adapted to the GLB_ON_LOOP it freezes sometimes - but this is not the fault of 123basic :D). Things like Joystick support are also implemented (but not yet tested enough). The only demo that is not working properly is "Scramble", because it heavily uses POLYSPRITE which can not be executed properly in HTML5 without WebGL, because it lacks proper support for drawing textured and tinted polygons.

Personally, Id say 123basic should be capable of running every GLB game that does not use POLYSPRITE with tinting and is modified to not use a mainloop (GLB_ON_LOOP instead).

Use it?
The repository of 123basic is, so everyone can view the compiler and the library and maybe even contribute.

Currently there are two possibilities to code in 123basic:

Online is surely easier to use, because it is directly available with no installation. The macro is not as easy to set up, but you can compile your GLB project directly from the IDE. Compile 123basic from the IDE, than set up the macro (see "Macro.txt") and voilá you can directly compile to 123basic from the GLB IDE.

If you do so, 123basic will start a local server, because it needs it to access certain media without causing a DOM security exception.

My testing suite consists primarly of:

All samples are only tested with current Chrome version. Firefox is likely to function properly. IE/Opera/Safari not so much. EDIT: I've just tested some demos on FF - a lot of them are crashing. Im currently trying to fix this problem. EDIT2: The problem is caused by a Firefox bug.

What's next?
I would like you to use 123basic, show me bugs, maybe suggestions for improvement and so on. If you find any bug, it would make it much easier for me, if you send me some snippet so i can debug it.

I would also expand the IDE, library (NET..., X_..., GUI, other funny stuff), continue implementing VM, ... There is a lot to do!

Also in regards of tutorials, some YT videos and a proper website is also on the ToDo list.

If you have any questions, feel free to ask them :)
Nice to see that you like this step :)

Quote from: Hemlos on 2012-Oct-12

this poor baby!  :O

Im so surprised you dropped the ball here!
Your time invested "as is" would have been totally worth any reasonable price to me, regardless if future updates had only been, say 1 or 2 years apart. Heck ive bought software that never gets updated.
Nice to hear, but I think making it available to everyone makes everyone happier - the best thing that can happen is to see people actually using 123basic :)

Quote from: Hemlos on 2012-Oct-12
PPS. Did you do this for a grade at MiT?
Nope, this is just the license of the 123basic compiler & library. MIT is a very liberal license that allows basically everything :D
Quote from: Slim on 2012-Oct-12
Coolo, could you give a brief explaination of how/when to use GLBServer?


This is a little HTTP server that is used to test 123 basic apps that load images/sounds/... from disk locally. Some browsers (Chrome, Firefox, ...) do not allow loading data with an url without an http server (Doing this would throw a DOM Security Exception). So using a lightweight HTTP server was the best solution for this problem.


Because my time is very limited and I am not able to support and develop everything of 123basic on my own anymore, I decided to open source "my baby" :D. It is MIT licensed, so I think everyone can use this piece of code in his/her project.

Because I originally didn't plan to open source 123 basic, the comments are rarely written, in german and cryptic as hell. I hope this will improve in future.

Here is the URL:

To use it: Get the source code from git, compile the compiler and "install" the macro in / (set the path to the executable properly)

So please don't get me wrong: 123basic is not dead, but I am not able to maintain everything on my own, so I think making it open source is a good thing for everybody.

If you want to contribute, I would be happy :)
I'm working on it. Don't worry!

My time is limited at the moment, so progress is slow :(
I am trying to join this competition, but I dont know whether I will finish my game because this weekend is full with some RL stuff :/
Thanks guys! I will make soon some "short" videos where I show you the features of 123basic.

Quote from: spacefractal on 2012-Aug-03
why change the name? Gernot did not even have issues to keep the name and its use the same syntax with glbasic..... video is very long and few would play it to the end wihout skipping.
It is too much confusion, if there are two languages that does compile the same source language into the same target platform. Further: The "GL" in GLBasic stands for "OpenGL", but 123basic does not even yet use WebGL at all (so it runs on a much wider range of devices, escpecially mobile devices).

Last but not least: I like "123basic" more than "GLBScript".
I've made a little video about the IDE of the BASIC compiler:
Quote from: Hemlos on 2012-Jul-31
You guys are silly.
Monkey, AND GLBasic are buried under so many other languages that i cannot even find them with moderate patience of reading all the links, on Google when searching for a basic compiler.
How can you say Monkey is winning compared to GLBasic when neither is really on the main stream charts.
Until today i never even heard of monkey.
Of course you won't find anything about monkey when searching for BASIC compiler - if you search after "car" you won't get results for an amphibious vehicle... Monkey is officially not called a "BASIC" dialect (at least it is not mentioned on the website)

I think GLBasic and Unity/TGM/... are just two different horses. GLB is a programming language while Unity is a game engine (that doesn't even have its own language, just using C#). Unity has its own 3d editor with all that fancy stuff - GLB gives you the freedom to make it yourself. So I don't think it makes sense to compare GLB and Unity.

And as far as I know, monkey is the only programming language that has a similar "concept". It compiles its source to another high level language, is really just a language and not an overbloated game editor. I don't know any other language (maybe haxe) that offers that like GLB and monkey. So I say: These two are the main competitors.

Quote from: Hatonastick on 2012-Jul-31
Quote from: coolo on 2012-Jul-31
All in all: Monkey (I think one of the biggest competitors of GLB) supports more (important) targets, has a more powerful language and costs around the same (of course some other disadvantages...) - I think GLB should not stay and improve so Monkey is not winning :D.
I really loathe Monkey myself.  Two massive strikes against it for me are that a) it only has a simplistic 2D library with it and no 3D, and b) it's a source to source compiler which means you have to organise your own compiler for each platform (unless I've missed something somewhere).  I like GLB because it comes with (most of) what you need to compile for various platforms -- the obvious exception being iOS based devices thanks to Apple's obnoxious more-Microsoft-than-Microsoft approach to its business model.

The third strike against it is the fact that it's by Mark Sibly. :)

Disclaimer: Of course these are just my opinions and most others might not agree with them, and as I have a few bones to pick with Mark Sibly I'm probably not the most balanced person around when it comes to discussions about Blitz Research products.
So setting some enviroment variables it too much work? I can see your point - Initially it can be frustating to set up these compilers and find out what's wrong. But I don't think once you have got everything running that is a serious problem. When trying to compile to iOS, Android and webOS with GLB you also have to set up your machine. And the other targets, well, they are working awesome :D

Quote from: Hatonastick on 2012-Jul-31
Edit:  BTW the most interesting thing I find about Game Maker Studio and Yoyo's new approach to its pricing is the fact that they've decided (heck they even stated somewhere, and I'd find you the link if I could be bothered) that they are more interested in having its products used by "Professionals" than Game Makers usual users -- an attitude they have obviously reflected with their new pricing scheme.  The problem I see with that is the development package market is already flooded with tools that are more established in the "professional" arena, and most of those come with 3D available from the start (even though you may have to pay extra for it).  Sure Yoyo has stated they will look at adding that later, but I suspect most "professionals" would want that choice now.  Also by targeting this new market almost exclusively thanks to their new pricing structure they have managed to snub the people who have supported Game Maker all these years, therefore wont be able to rely on that market helping support them while they look to gain inroads into the "professional" market.
I don't know anything about Game Maker. But as far as I can tell, this piece of code is much overprized :D

Last but not least I want to say: I am a developer. And the most important thing as a developer is to stay as objective as possible when it comes to your toolchain and your work flow. Always consider using another target/platform/editor/banana, and just because you don't like the color of the website (I'm exaggerating) not using a software is, in my opinion, contra productive.
That's not true. For Android you have also set things up to get it running properly - GLBasic is also a source to source compiler ;).

EDIT: But the missing 3D engine of monkey is of course a problem.

I think the price of GLBasic is just right. You forget: GLB is "just" a language - Unity (and the others) contains a lot of other stuff (3D editor, ...). Especially Unity has some cool features you can't compare with GLBasic. And what you shouldn't forget: GLB has a lot of rough edges (Android, not supporting GRABSPRITE/USESCREEN properly) and there are also some language side problems (C++ errors).

All in all: Monkey (I think one of the biggest competitors of GLB) supports more (important) targets, has a more powerful language and costs around the same (of course some other disadvantages...) - I think GLB should not stay and improve so Monkey is not winning :D.