Hi all!
Well, I finally got around to dusting off the old Christmas lights for the web site so it must be time for a blog update too!
I was hoping to have SOMETHING out re: monkey by Christmas, but it became apparent a few weeks ago that that just wasn't gonna happen so the new target is now for a mid January release.
The software is IMO mostly finished, if a bit rough around the edges (still fixing little things on a daily basis) although the docs currently suck. I plan on spending my Christmas 'break' mostly on docs, hopefully with a hangover much of the time - just kidding!
The whole 'production' side of things is something I think BRL products are missing a a bit these days compared with the old Guildhall/Idigicon days. Despite our, erm, 'creative' differences, Guildhall/Idigicon did I think take a lot of the weight off my shoulders when it came to the docs and general production side of things, and I do kind of miss that.
I don't really enjoy being responsible for EVERYTHING - and there are aspects of what I do that I know I could be doing a lot better (or at least someone else could be doing a lot better!) - but I have somehow managed to end up existing in this weird kind of 'bubble' down here in Auckland, New Zealand!
So at some point next year I intend to make an honest attempt at getting someone with some kind of business sense involved in the BRL experiment, quite possibly with the initial aim of producing a 'physical' version of monkey.
And there's that 'monkey' reference again - what can it mean?!?
Well, after surprisingly little thought and consultation (although I DID check with the 'Mono' guy...) I have settled on a name for the next programming language from BRL: 'monkey'.
In addition, the lightwight 2d app module that I am working on will be called 'mojo'.
Note that the two are separate: monkey will be 'just' a programming language, with the only IO related function probably being 'Print', while mojo will be an optional extension module.
The plan at this point is to make monkey free and open (in all respects), while charging for mojo (possibly with a free html5 version, or maybe a dual license GPL release - haven't decided on the 'demo' yet).
So stay tuned - interesting days ahead!
Peace out,
Mark
Sunday, December 19, 2010
Saturday, October 9, 2010
Update
Hi,
Ok, a few people helping out with bmx2 development have expressed concern that the BRL community are expecting something far more 'BlitzMax like' with respect to bmx2.
So, in a probably futile attempt to reduce confusion levels somewhat...
* Bmx2 is NOT, erm, BlitzMax 2! bmx2 is just the code name for the next BRL programming language.
* Bmx2 is, however, fairly similar to BlitzMax in terms of language syntax.
* Bmx2 is MUCH smaller than BlitzMax, with far fewer modules. There are only currently about 10 'core' modules - most of these just deal with simple algorithmic stuff like lists, maps, math, random etc. There are no PngLoader modules or anything like that, no stream system or audio/graphics driver subsystem. Stuff will be added over time, but I want to be careful this time around not to let it all become a big nasty 'mega system' the way BlitzMax did - I want the core to remain VERY lightweight.
* Bmx2 will also include a very simple 2D gamedev module. And by 'simple' I mean SIMPLE! This is so that it can work on a wide range of target devices. This module will initially only include functionality that is available on ALL target platforms. The 2D module is not 'part' of bmx2 in quite the same way the brl.max2d module was 'part' of BlitzMax - it's very much separate and optional (although currently there's not a lot you can do without it!).
* Bmx2 will also include a very simple IDE written in the 2D module, but I expect seasoned developers are likely to turn to something like notepad++ (what I'm currently using) or Ziggy's next super duper IDE. The included IDE will really only be designed to get people up and running - I'm not planning to get into the IDE 'biz at all, but in the spirit of keeping the product fully 'self contained' (as all BRL products have been) some sort of IDE is a must.
Finally, here's a little YouTube vid of bmx2 in action - nothing too fancy, mainly just proof of concept stuff including giving the new touch commands a workout, although I do like the look of delidash!
And don't forget, all this code runs just the same on HTML5, Flash, XNA and Android...
Thanks to jonpittock for that!
(And no, that's not 'real' 3D at the end there - just a nifty little raycaster).
Bye!
Mark
Ok, a few people helping out with bmx2 development have expressed concern that the BRL community are expecting something far more 'BlitzMax like' with respect to bmx2.
So, in a probably futile attempt to reduce confusion levels somewhat...
* Bmx2 is NOT, erm, BlitzMax 2! bmx2 is just the code name for the next BRL programming language.
* Bmx2 is, however, fairly similar to BlitzMax in terms of language syntax.
* Bmx2 is MUCH smaller than BlitzMax, with far fewer modules. There are only currently about 10 'core' modules - most of these just deal with simple algorithmic stuff like lists, maps, math, random etc. There are no PngLoader modules or anything like that, no stream system or audio/graphics driver subsystem. Stuff will be added over time, but I want to be careful this time around not to let it all become a big nasty 'mega system' the way BlitzMax did - I want the core to remain VERY lightweight.
* Bmx2 will also include a very simple 2D gamedev module. And by 'simple' I mean SIMPLE! This is so that it can work on a wide range of target devices. This module will initially only include functionality that is available on ALL target platforms. The 2D module is not 'part' of bmx2 in quite the same way the brl.max2d module was 'part' of BlitzMax - it's very much separate and optional (although currently there's not a lot you can do without it!).
* Bmx2 will also include a very simple IDE written in the 2D module, but I expect seasoned developers are likely to turn to something like notepad++ (what I'm currently using) or Ziggy's next super duper IDE. The included IDE will really only be designed to get people up and running - I'm not planning to get into the IDE 'biz at all, but in the spirit of keeping the product fully 'self contained' (as all BRL products have been) some sort of IDE is a must.
Finally, here's a little YouTube vid of bmx2 in action - nothing too fancy, mainly just proof of concept stuff including giving the new touch commands a workout, although I do like the look of delidash!
And don't forget, all this code runs just the same on HTML5, Flash, XNA and Android...
Thanks to jonpittock for that!
(And no, that's not 'real' 3D at the end there - just a nifty little raycaster).
Bye!
Mark
Monday, August 30, 2010
Self compiling!
Yipee!
I am pleased to say that bmx2 (STILL haven't decided on a new name yet) is now fully self-compiling!
In theory, this just involved converting the existing bmx source files to bmx2 via a little 'convbmx' util, but in practice it has been a tricky and at times somewhat mind bending exercise.
In particular, with 2 sets of sources I had to stop and think several times which one I actually needed to modify - and occasionally even found myself modifying the wrong one!
But it all seems to be working remarkably well now, and although I've only managed to compile the compiler itself as a C++ target (because that's the only target with sufficient filesystem support right now), the 'new' compiler has compiled all my other little tests successfully to html5, flash, xna and android.
Some more details about how it all works...
Bmx2 will required that the appropriate SDK's for the various targets be installed separately. For example, to compile to c++ you'll need MinGW installed. Current list of supported targets/SDK's is:
* HTML5 - HTML5 compatible browser required for testing.
* Flash - Open source Flex SDK required.
* XNA - Visual C# Express + XNA framework
* Android - The Android SDK (plus Java SDK and 'Ant' on Windows).
* Native (ie: C++) - Mingw/GCC (will probably add visualc support too in future).
* iPhone - XCode.
This has the obvious benefit of making life a whole bunch easier for myself, but it also means you'll be able to take full advantage of the various SDK tools available. For example, iPhone projects will be 'real' xcode projects, so you'll be able to edit them in xcode, mess with the NIB file etc. When you compile your bmx2 program, the translator simply replaces a chunk of text in a 'main' file somewhere in the target project, and leaves the rest of the project alone.
Installation of SDK's can be a little messy in some cases, but the compiler already automagically deals with any PATH or ENV var issues which makes life a whole lot easier.
Some more details on the new language:
* 'Type' renamed to 'Class'.
* Identifiers now case sensitive.
* Private can at last be used inside classes!
* A single 'End' can be used to terminate blocks, eg:
Function MyFunc()
Print "Boo!"
End
Ye olde bmx1 style terminators are still permitted too.
* Function/method overloading added, eg:
Function DrawImage( image:Image,x,y )
...
End
Function DrawImage( image:Image,x,y,frame )
...
End
* 'Proper' constructors, eg:
Method New( x,y )
Self.x=x
Self.y=y
End
* Support for 'properties', eg:
Method X() Property
Return x
End
Method X( x ) property
Self.x=x
End
* Simple class template support, eg:
Local list:=New List<Actor>
* Simple 'boxing', eg:
Local list:=New List<IntObject>
list.AddLast 10
list.AddLast 20
Local n=list.Last()
* Auto type inference for initializers, eg:
Local t:=New Actor 'instead of Local t:Actor=New Actor
* Strict mode is back, but will effectively mean bmx1-style SuperStrict (or possibly even stricter). Default mode will be plain bmx1-style Strict (and probably even lazier).
I agonized for a while over whether bmx2 should go 'SuperStrict only', but after realizing that some of the superstrict crowd wanted things even stricter(!) while I wanted things more relaxed, I decided to keep Strict in there in the hope the final product will appeal to a wider range of people.
I have a related theory on this: SuperStrict users prefer C# over C++; Strict users vice versa...
* Module 'Imports' can now be cyclic, eg:
'Module A
Import B
'Module B
Import A
I can't BELIEVE I thought this wasn't a big deal in bmx1!
It was kind of mission to get going too - I basically had to change the compilation process from a top down, 2 pass algorithm to a 'compile on demand' one.
It worked out really well though - the entire program is compiled simply by compiling 'Main'...which causes anything main depends on to compile, and so on.
As a nice side effect, you end up with a very clear picture of what code the program actually uses, meaning apps should be nice and tight.
It's not all good news though (assuming you already though it was) - here are a few nasty 'detail' things that may or may not be fixed/improved over time, but for now would be very hard to do efficiently in ALL target languages. I consider them pretty minor, but you're free to disagree with me on that...
* Strings and Arrays are NOT objects in bmx2 the way they are in bmx1 - they are more like primitives such as int and float, eg:
Local t:Object="Hello world" 'OK in bmx1, Error in bmx2.
* Multidimensional arrays are out, although you can still have arrays of arrays, eg:
Local t[10,20] 'OK in bmx1, Error in bmx2
Local t[][10] 'OK in bmx1 and bmx2.
* Arrays can not be 'downcast' in bmx2, eg:
Local t:Object[]=New Thing[10]
Local p:Thing[]=Thing[]( t ) 'OK in bmx1, Error in bmx2.
This will mean that arrays may have to be manually 'wrapped' in some situations.
And that's it for now. Hope you found it informative!
Bye,
Mark
I am pleased to say that bmx2 (STILL haven't decided on a new name yet) is now fully self-compiling!
In theory, this just involved converting the existing bmx source files to bmx2 via a little 'convbmx' util, but in practice it has been a tricky and at times somewhat mind bending exercise.
In particular, with 2 sets of sources I had to stop and think several times which one I actually needed to modify - and occasionally even found myself modifying the wrong one!
But it all seems to be working remarkably well now, and although I've only managed to compile the compiler itself as a C++ target (because that's the only target with sufficient filesystem support right now), the 'new' compiler has compiled all my other little tests successfully to html5, flash, xna and android.
Some more details about how it all works...
Bmx2 will required that the appropriate SDK's for the various targets be installed separately. For example, to compile to c++ you'll need MinGW installed. Current list of supported targets/SDK's is:
* HTML5 - HTML5 compatible browser required for testing.
* Flash - Open source Flex SDK required.
* XNA - Visual C# Express + XNA framework
* Android - The Android SDK (plus Java SDK and 'Ant' on Windows).
* Native (ie: C++) - Mingw/GCC (will probably add visualc support too in future).
* iPhone - XCode.
This has the obvious benefit of making life a whole bunch easier for myself, but it also means you'll be able to take full advantage of the various SDK tools available. For example, iPhone projects will be 'real' xcode projects, so you'll be able to edit them in xcode, mess with the NIB file etc. When you compile your bmx2 program, the translator simply replaces a chunk of text in a 'main' file somewhere in the target project, and leaves the rest of the project alone.
Installation of SDK's can be a little messy in some cases, but the compiler already automagically deals with any PATH or ENV var issues which makes life a whole lot easier.
Some more details on the new language:
* 'Type' renamed to 'Class'.
* Identifiers now case sensitive.
* Private can at last be used inside classes!
* A single 'End' can be used to terminate blocks, eg:
Function MyFunc()
Print "Boo!"
End
Ye olde bmx1 style terminators are still permitted too.
* Function/method overloading added, eg:
Function DrawImage( image:Image,x,y )
...
End
Function DrawImage( image:Image,x,y,frame )
...
End
* 'Proper' constructors, eg:
Method New( x,y )
Self.x=x
Self.y=y
End
* Support for 'properties', eg:
Method X() Property
Return x
End
Method X( x ) property
Self.x=x
End
* Simple class template support, eg:
Local list:=New List<Actor>
* Simple 'boxing', eg:
Local list:=New List<IntObject>
list.AddLast 10
list.AddLast 20
Local n=list.Last()
* Auto type inference for initializers, eg:
Local t:=New Actor 'instead of Local t:Actor=New Actor
* Strict mode is back, but will effectively mean bmx1-style SuperStrict (or possibly even stricter). Default mode will be plain bmx1-style Strict (and probably even lazier).
I agonized for a while over whether bmx2 should go 'SuperStrict only', but after realizing that some of the superstrict crowd wanted things even stricter(!) while I wanted things more relaxed, I decided to keep Strict in there in the hope the final product will appeal to a wider range of people.
I have a related theory on this: SuperStrict users prefer C# over C++; Strict users vice versa...
* Module 'Imports' can now be cyclic, eg:
'Module A
Import B
'Module B
Import A
I can't BELIEVE I thought this wasn't a big deal in bmx1!
It was kind of mission to get going too - I basically had to change the compilation process from a top down, 2 pass algorithm to a 'compile on demand' one.
It worked out really well though - the entire program is compiled simply by compiling 'Main'...which causes anything main depends on to compile, and so on.
As a nice side effect, you end up with a very clear picture of what code the program actually uses, meaning apps should be nice and tight.
It's not all good news though (assuming you already though it was) - here are a few nasty 'detail' things that may or may not be fixed/improved over time, but for now would be very hard to do efficiently in ALL target languages. I consider them pretty minor, but you're free to disagree with me on that...
* Strings and Arrays are NOT objects in bmx2 the way they are in bmx1 - they are more like primitives such as int and float, eg:
Local t:Object="Hello world" 'OK in bmx1, Error in bmx2.
* Multidimensional arrays are out, although you can still have arrays of arrays, eg:
Local t[10,20] 'OK in bmx1, Error in bmx2
Local t[][10] 'OK in bmx1 and bmx2.
* Arrays can not be 'downcast' in bmx2, eg:
Local t:Object[]=New Thing[10]
Local p:Thing[]=Thing[]( t ) 'OK in bmx1, Error in bmx2.
This will mean that arrays may have to be manually 'wrapped' in some situations.
And that's it for now. Hope you found it informative!
Bye,
Mark
Monday, July 19, 2010
Update
Hi,
***** BMX2 news *****
Well, I still haven't settled on a name for this yet, but anyway, here's a quick update on where the project is going...
The source language will be very bmx-like, with a few tweaks and additions including:
* Simple class templates
* Function overloading
* Constructors
* Properties
...and some stuff removed, such as pointers. Yes, POINTERS! Function pointers too!
Target languages I'm aiming for upon release are:
* JavaScript
* ActionScript
* Java
* C#
* C++
* Python (just as an experiment - probably wont be much lib support for this to begin with).
Target platforms I'm aiming for:
* HTML5
* Flash
* XNA
* Android
* Native GL
* iPhone
The system will also include an interpreter for debugging/preprocessing. Ideally, you should also be able to use the interpreter for scripting, but that may end up being in a future release depending upon difficulty level.
I'm keeping the modules *very* simple for the initial release, but they should still be grunty enough to do some decent games with depending on your target platform.
The 'official' IDE will be a custom job written in the language itself. However, it should be usable enough (well, I'm using it) and it will at least run *everywhere*. Of course, there are likely to be 3rd party IDE offerings too, so hopefully everyone will be happy in the end.
More to come...
***** BMX2 news *****
Well, I still haven't settled on a name for this yet, but anyway, here's a quick update on where the project is going...
The source language will be very bmx-like, with a few tweaks and additions including:
* Simple class templates
* Function overloading
* Constructors
* Properties
...and some stuff removed, such as pointers. Yes, POINTERS! Function pointers too!
Target languages I'm aiming for upon release are:
* JavaScript
* ActionScript
* Java
* C#
* C++
* Python (just as an experiment - probably wont be much lib support for this to begin with).
Target platforms I'm aiming for:
* HTML5
* Flash
* XNA
* Android
* Native GL
* iPhone
The system will also include an interpreter for debugging/preprocessing. Ideally, you should also be able to use the interpreter for scripting, but that may end up being in a future release depending upon difficulty level.
I'm keeping the modules *very* simple for the initial release, but they should still be grunty enough to do some decent games with depending on your target platform.
The 'official' IDE will be a custom job written in the language itself. However, it should be usable enough (well, I'm using it) and it will at least run *everywhere*. Of course, there are likely to be 3rd party IDE offerings too, so hopefully everyone will be happy in the end.
More to come...
Thursday, May 27, 2010
The plan!
Hi,
Ok, here's the plan:
I am currently working on a 'light' version of BlitzMax designed to run on a wide range of target platforms. For now, let's call it 'bmx2'.
Bmx2 will be similar to bmx language wise, but will have a much smaller and simpler set of modules that will be targeted at simple 2D game creation.
But the major feature of bmx2 is that it will be a 'translator', designed to convert code from bmx2 syntax to as many target languages as possible - preferably in as human readable a form as possible.
I have already made considerable progress generating output for the following target languages: C++, C#, Java, JavaScript and ActionScript. I also plan to add python add some stage, and...?
In addition, I have a simple Blitz2D/Max2D-like module underway and some very simple 'system' modules for the following platforms: Win32, MacOS, Linux, HTML5, Flash, XNA, Android. There's an iPhone version too, but it's status is very much 'up-in-the-air' right now due to licensing issues.
Anyway, development has now reached the point where I am interested in getting more people involved.
Right now I'm interested in people who are keen on language design and/or have some experience with several languages. If that sounds like you and you'd like to get involved please contact blitzmunter at gmail dot com.
Flash demo (well, not *that* flash - very simple actually! You may need to click window to activate too):
Same demo running on HTML5, Android and XNA:
LOTS more info soon.
Peace out!
Mark
Ok, here's the plan:
I am currently working on a 'light' version of BlitzMax designed to run on a wide range of target platforms. For now, let's call it 'bmx2'.
Bmx2 will be similar to bmx language wise, but will have a much smaller and simpler set of modules that will be targeted at simple 2D game creation.
But the major feature of bmx2 is that it will be a 'translator', designed to convert code from bmx2 syntax to as many target languages as possible - preferably in as human readable a form as possible.
I have already made considerable progress generating output for the following target languages: C++, C#, Java, JavaScript and ActionScript. I also plan to add python add some stage, and...?
In addition, I have a simple Blitz2D/Max2D-like module underway and some very simple 'system' modules for the following platforms: Win32, MacOS, Linux, HTML5, Flash, XNA, Android. There's an iPhone version too, but it's status is very much 'up-in-the-air' right now due to licensing issues.
Anyway, development has now reached the point where I am interested in getting more people involved.
Right now I'm interested in people who are keen on language design and/or have some experience with several languages. If that sounds like you and you'd like to get involved please contact blitzmunter at gmail dot com.
Flash demo (well, not *that* flash - very simple actually! You may need to click window to activate too):
Same demo running on HTML5, Android and XNA:
LOTS more info soon.
Peace out!
Mark
Monday, March 29, 2010
BMX News!
Hi,
Ok, there's been a lot of conjecture about 'the future of Blitz' at blitzbasic.com lately, so it's probably a good idea to let everyone know that the fine minds at BRL are currently working on a solution to the 'BlitzMax on LOTS of platforms' problem - and yes, 'lots of platforms' includes the iPhone.
Given that game development these days involves developing for a wide range of platforms, I feel this is the logical next step for Blitz as a game development language, and I'm confident the end result will be pretty cool!
I don't want to give too much away about how this will work (or, of course, when it will work!) because, to be honest, I don't know 100% myself yet - more news 'when it feels right'!
Bye,
Mark
Ok, there's been a lot of conjecture about 'the future of Blitz' at blitzbasic.com lately, so it's probably a good idea to let everyone know that the fine minds at BRL are currently working on a solution to the 'BlitzMax on LOTS of platforms' problem - and yes, 'lots of platforms' includes the iPhone.
Given that game development these days involves developing for a wide range of platforms, I feel this is the logical next step for Blitz as a game development language, and I'm confident the end result will be pretty cool!
I don't want to give too much away about how this will work (or, of course, when it will work!) because, to be honest, I don't know 100% myself yet - more news 'when it feels right'!
Bye,
Mark
Subscribe to:
Posts (Atom)