tag:blogger.com,1999:blog-57465150713193081072023-06-20T06:24:26.692-07:00markspacemarksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.comBlogger20125tag:blogger.com,1999:blog-5746515071319308107.post-5550078561793336702015-05-20T19:32:00.002-07:002015-05-21T13:32:35.026-07:00Monkey2 translator output.One of the things I was hoping to achieve this time around with monkey2 was 'clean' translator output. Anyone who's looked at the native code monkey1 generates will agree it's a bit of a mess!<br />
<br />
I was hoping that the c++ output, at least, could look like a bit like 'real' c++, eg: this...<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">namespace mojo<code></code></span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
<span style="font-family: Courier New, Courier, monospace;">class Image</span><br />
<span style="font-family: Courier New, Courier, monospace;"> class Frame</span><br />
<span style="font-family: Courier New, Courier, monospace;"> end</span><br />
<span style="font-family: Courier New, Courier, monospace;">end</span><br />
<br />
...could translate to...<br />
<code></code><br />
<span style="font-family: Courier New, Courier, monospace;">namespace mojo{</span><br />
<span style="font-family: Courier New, Courier, monospace;"> class Image{</span><br />
<span style="font-family: Courier New, Courier, monospace;"> class Frame{</span><br />
<span style="font-family: Courier New, Courier, monospace;"> };</span><br />
<span style="font-family: Courier New, Courier, monospace;"> };</span><br />
<span style="font-family: Courier New, Courier, monospace;">}</span><br />
<br />
Alas, it's not that simple.<br />
<br />
The main issue with nicely scoped c++ is that it turns out you can't 'forward reference' inner classes - at all! This is a new one on me, but one of the things I really like about monkey1 is how all the forward referencing issues you have in c/c++ just don't exist, and I want the same to be true of monkey2. So I have decided to abandon nicely scoped c++ output for now.<br />
<br />
I was also hoping I could rely on c++'s function overloading to allow me to use the same function names for overloaded functions.<br />
<br />
This mostly works, except when using overloaded member pointers. You can 'cast your way' out of the problem (see: http://stackoverflow.com/questions/4364599/c-overloaded-method-pointer) but that's pretty nasty. It's easier for monkey to just mung a new name for overloaded functions, so I've decided to go with that for now too.<br />
<br />
So c++ output wont be as sexy as I'd hoped, but there is an upside to this: the translator is now much more 'universal' and will be easier to adapt to other target languages. This is probably what I should have aimed for in the first place.<br />
<br />
The output WILL be cleaner than monkey1's though, mainly because, for now at least, I only have to write one translator! Having to write 5 at once was a killer, and the quality of each suffered.<br />
<br />
<br />marksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com0tag:blogger.com,1999:blog-5746515071319308107.post-76740863742693551952015-05-14T23:59:00.006-07:002015-05-14T23:59:38.868-07:00...and Mojo2!<br />
And in further news...mojo2 is on the way!<br />
<br />
I've been working on this for several months now, in collaboration with Tony from Playniax (who has news of his own!) and it looks like mojo2 should be ready for release within a month or so.<br />
<br />
Mojo2 is, like mojo1, fundamentally a 2D engine. However, it adds a few useful 3d features such as lighting (with normal/specular maps) and the ability to use 3d projection/view matrices. Mojo2 is ONLY compatible with targets that support the OpenGL module. That is, the desktop, ios, android and html5 targets.<br />
<br />
A brief overview of features:<br />
<br />
You can render directly to the app window or an image using the Canvas class, eg:<br />
<br />
Local canvas1:=New Canvas 'render to app window<br />
canvas1.SetViewport...<br />
canvas1.SetProjection2d<span class="Apple-tab-span" style="white-space: pre;"> </span>0,VWIDTH,0,VHEIGHT 'set 'virtual resolution'.<br />
canvas1.Clear<br />
canvas1.DrawRect...<br />
canvas1.DrawImage...<br />
<br />
And to render to image:<br />
<br />
Local image:=New Image( 256,256 )<br />
Local canvas:=New Canvas( image ) 'render to image!<br />
<br />
The canvas methods available should be familiar to anyone who has used mojo1, although a few have been tweaked/renamed here and there.<br />
<br />
You can also perform simple 'direct mode' lighting using canvas, eg:<br />
<br />
canvas.SetLightType 0,1 'turn on light 0.<br />
canvas.SetLightRange 0,100 'set light 0 range.<br />
canvas.SetLightPosition 0,320,240,-25 'set light 0 position.<br />
canvas.DrawImage... 'image will be lit!<br />
canvas.SetLightType 0,0, 'light 0 off again.<br />
<br />
You can use up to 4 lights in 'direct mode' like this. Shadows are also possible using direct mode, but it starts getting tricky...<br />
<br />
To help deal with multiple lights and shadows, mojo2 also provides a 'Renderer' class that provides a sort of 'virtual scene manger'. You add layers and lights to a renderer, and when you call Render() it will take care of all the tricky multi-pass rendering stuff. It is NOT a complete scene graph, but something you can plug a scene graph (simple or complicated) into.<br />
<br />
There is also simple 'shader support' in that you can write glsl shader code that samples textures and produces values suitable for lighting.<br />
<br />
There are still a few details to be worked out, but that's about the jist of it! Price wise, it'll be added to the commercial monkey-x package and will be free to existing monkey-x owners.<br />
<br />
Bye!<br />
Mark<br />
<div>
<br /></div>
marksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com0tag:blogger.com,1999:blog-5746515071319308107.post-91078283967406680612015-05-02T16:34:00.002-07:002015-05-11T17:40:18.018-07:00Monkey2!Ok, some fairly big news: I've decided to start work on Monkey2!<br />
<br />
I'm going with an open source/crowd funded approach this time, as I don't consider the idea of selling languages to be commercially viable these days. I am planning to start with a patreon project (see: https://www.patreon.com/) which I hope to have up in a week or so.<br />
<br />
Is there any point to writing a new language? In a way, probably not, as I'm constantly reminded each time I read a slashdot thread about new language XYZ! But I do think there's a core bunch of people who like using BRL languages (myself included) and since I also really like making them, I'm gonna try to figure out a way to continue to do just that as a full time thing.<br />
<br />
The basic idea is to fix the problems in the monkey1 language, add some cool new language features, and take the build/runtime system in a much more blitzmax-ish direction. To this end, monkey2 will initially only support c++ targets that have a posix-ish api, which effectively means that only the desktop, ios and android targets will be supported. However, since the overall approach is basically the same as monkey1 - ie: everything ends up going through a translator - the potential is there to support more targets in the future. Alas, as I found out with monkey1, emitting code in bunch of target languages is the 'easy' bit...<br />
<br />
Losing html5 hurts, but without it the range of 'lowest common denominator' features becomes much richer, and the job of supporting all those features much simpler. Most of the other targets are pretty much dead now, so I'm not too sad about losing them. Besides, they'll live on in monkey1 which I fully intend to continue to support and tweak.<br />
<br />
Why not just 'fix' Monkey1? Mainly because it's gotten pretty tricky to sanely tinker with in certain areas - areas that I really, really want to tinker with. It was my first attempt at an OO language with generics, and I will freely admit that I didn't quite nail it first time around. But I've been hacking away on Monkey2 for the last week or so, starting from the ground up with a new parser, a new approach to semantic analysis etc, and I am very happy with how it's going and (finally) feel confident I can do much better this time.<br />
<br />
All in all, it is my hope that monkey2 will find a nice balance between monkey1's sexier language and blitzmax's 'hackability'.<br />
<br />
There is nothing to release yet, but I've added a Monkey2 forum to monkey-x.com so feel free to post comments and questions there.<br />
<br />
Bye!<br />
Mark
marksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com0tag:blogger.com,1999:blog-5746515071319308107.post-64604044910669657332014-04-28T18:59:00.003-07:002014-04-28T19:02:10.236-07:00BlitzPlus source code now available on Github!Hi,<br />
<br />
The BlitzPlus source code is now available on github:<br />
<br />
https://github.com/blitz-research/blitzplus<br />
<br />
It's a bit messy (there's probably lots of stuff that can be trimmed etc), and you'll need MSVC 6.0 to compile it 'as is', but it's all there!<br />
<br />
I'd also like to reassure Monkey users that when/if I one day 'retire' Monkey (ie: stop selling it), I will also be releasing the full source code to the currently proprietary bits of Mojo in a similar way. Ditto Blitz3D/BlitzMax...<br />
<br />
Peace out!<br />
Markmarksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com0tag:blogger.com,1999:blog-5746515071319308107.post-71391163073169753552012-09-14T22:20:00.001-07:002012-09-15T00:21:07.504-07:00Monkey stuff!Ok, this was initially going to be a forum post, but it got a bit longwinded so it's probably worthy of a post in my poor, neglected blog.<br />
<br />
On the Monkey front, I've pretty much got async loading of images/sounds going now - usage looks something like this:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">Class MyApp Extends App Implements IOnLoadImageComplete</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>Field _image:Image</span><br />
<span class="Apple-tab-span" style="font-family: Courier New, Courier, monospace; white-space: pre;"> </span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>Method OnCreate()</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>Image.DefaultFlags=Image.MidHandle</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>LoadImageAsync "cheerio.jpg",,,Self</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>SetUpdateRate 60</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>End</span><br />
<span class="Apple-tab-span" style="font-family: Courier New, Courier, monospace; white-space: pre;"> </span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>Method OnUpdate()</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>UpdateAsyncEvents<span class="Apple-tab-span" style="white-space: pre;"> </span>'must do this!</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>End</span><br />
<span class="Apple-tab-span" style="font-family: Courier New, Courier, monospace; white-space: pre;"> </span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>Method OnRender()</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>Cls</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>If _image DrawImage _image,MouseX,MouseY</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>End</span><br />
<span class="Apple-tab-span" style="font-family: Courier New, Courier, monospace; white-space: pre;"> </span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>Method OnLoadImageComplete:Void( image:Image,path:String,source:IAsyncEventSource )</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>If image</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>'image loaded OK!</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>_image=image</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>Else</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>'problem loading image!</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>Error ""</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>Endif</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>End</span><br />
<span style="font-family: Courier New, Courier, monospace;">End</span><br />
<br />
This works pretty much identically on all targets, except for PSM which can't do async image loading, even with a thread - it complains when you try to use the graphics context from a background thread. In this case, it's done synchronously so still at least works.<br />
<br />
On c++/java targets, the load executes on a separate thread. On html5/flash, 'onloaded' callbacks are used internally to 'fake' threading. Note that on targets with embedded data (xna/flash) this is really just decompressing data on a separate 'thread', so may not be all that useful. Also, on OpenGL targets textures must be created on the main thread so there may still be a 'pause' after the image has loaded in the background when it gets sent to GL. This is theoretically fixable, although my experience with multi-thread GL contexts in bmx was less than encouraging...<br />
<br />
In addition, image/sound loaders can now load stuff outside the data directory where possible. File paths are now more URL-ish, so (on some targets) you can do things like:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">Local image:=LoadImage( "http://www.monkeycoder.co.nz/tmp/cheerio.jpg" )</span><br />
<br />
This is down to the capabilities of the underlying native loaders, so for example http: currently only works on html5/android/ios. On Flash, it works if the image comes from the same domain, otherwise you need to configure the resource server - something Monkey can't help with. In the case of c++ targets, this can be used to load stuff from the filesystem but not http: (yet).<br />
<br />
This has meant some tweaks to the file path system, as the path "cheerio.jpg" can now mean several things: It could be a file in the app's 'data/' dir, or it could be a file in the (c++/java) current dir or the (html/flash) document base.<br />
<br />
To deal with this, I've added the 'pseudo' URI monkey: which works a bit like http: and can be used to locate monkey specific resources. Currently, there's only monkey://data/ to get at resources in the app's data dir.<br />
<br />
To maintain compatiblity, Mojo will for now convert all relative paths into monkey://data/ paths. It will not convert paths that start with "./", "/" or "blah:", so to load something from the 'real' current dir you will need to use the "./" prefix.<br />
<br />
This means these are equivalent:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">Local image:=LoadImage( "cheerio.jpg" )</span><br />
<span style="font-family: Courier New, Courier, monospace;">Local image:=LoadImage( "monkey://data/cheerio.jpg" )</span><br />
<br />
But these are not:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">Local image:=LoadImage( "cheerio.jpg" )<span class="Apple-tab-span" style="white-space: pre;"> </span>'gets converted to "monkey://data/cheerio.jpg"</span><br />
<span style="font-family: Courier New, Courier, monospace;">Local image:=LoadImage( "./cheerio.jpg" )<span class="Apple-tab-span" style="white-space: pre;"> </span>'does not get converted</span><br />
<br />
Whew! Sounds complex, but I think it's a reasonably sensible approach.<br />
<br />
The new Mojo async loaders are built on a new interal async event system in the brl module, brl.asyncevent. The core of this system is the IAsyncEventSource interface that provides a single method...<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">Interface IAsyncEventSource</span><br />
<span style="font-family: Courier New, Courier, monospace;"><span class="Apple-tab-span" style="white-space: pre;"> </span>Method UpdateAsyncEvents:Void()</span><br />
<span style="font-family: Courier New, Courier, monospace;">End</span><br />
<br />
...and a bunch of global functions...<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">Function UpdateAsyncEvents:Void()</span><br />
<span style="font-family: Courier New, Courier, monospace;">Function AddAsyncEventSource:Void( source:IAsyncEventSource )</span><br />
<span style="font-family: Courier New, Courier, monospace;">Function RemoveAsyncEventSource:Void( source:IAsyncEventSource )</span><br />
<br />
UpdateAsyncEvents() needs to be called regularly - once per OnUpdate() should be enough - and is what actually updates/polls the state of any async operations currently in progress. This is when various OnBlahComplete methods will be called.<br />
<br />
You can add your own async event sources by writing a class that implements IAsyncEventSource and using AddAsyncEventSource/RemoveAsyncEventSource to add/remove objects of this class to the global list of async event sources.<br />
<br />
Note that there is no 'event' class as such - each async event source must provide it's own mechanism for notifying the main app of progress/completion, eg: by providing an IOnBlahComplete interface.<br />
<br />
There's also a new AsyncStream class that uses the async event system to let you read/write from some types of stream in the background. Currently, only async TCP streams are supported, but future versions could include include AsyncFileStream (once we HAVE a file stream!) for streaming from 'slow' filesystems such as Dvd, and even AsyncAudioStream for realtime mixing.<br />
<br />
I've also made several reasonably major changes to the config var system.<br />
<br />
First up, you can now use '+=' to append to config vars (you still can't overwrite them with '=' though). This will append the RHS to the var, inserting a ';' if necessary to keep 'em separated. This is very much a WIP feature right now and mainly for the sake of REFLECTION_FILTER, although MODPATH and data file filters might also work. Also, both ';' and '|' are now valid separators for REFLECTION_FILTER.<br />
<br />
The reflection module no longer does a #REFLECTION_FILTER="*" by default, so it's up to you to set the correct filter(s) or it will be empty. Being able to append to config vars now means modules can add themselves to the filter with eg: #REFLECTION_FILTER+="mymodule*|mojo*" etc.<br />
<br />
CONFIG.TXT files are now plain Monkey files, although they're only ever preprocessed. I've renamed them CONGIG.MONKEY to try and limit any confusion here. Note that this means each line of CONFIG.MONKEY must now start with a '#', just like real Monkey code.<br />
<br />
The handling of bool true/false config vars has been changed/unified - you should now use the Monkey tokens True or False (no quotes, case insensitive - ie: Monkey code) instead of "true" or "false" for all bool vars. There's a minor issue with bool->string conversion here, since all config vars are actually stored as strings and Monkey doesn't support bool->string conversion. To deal with this, I've hacked the preprocessor so true gets converted to "1" and false gets converted to "0". This will only be an issue for those writing code that uses config vars internally, but it's something to be aware of. It's meant that I had to change any existing code that compared config vars with "true" to compare with "1" instead.<br />
<br />
This all represents some potentially 'breaking' changes for anyone who's mainting their own version of trans - apologies for that, and perhaps I should have saved these for a future release as there are more breaking changes coming...<br />
<br />
As for the future of Monkey, here's the current plan...<br />
<br />
A Windows 8 C++/DirectX target is underway and will hopefully be done 'soon'. I have gone with C++/DirectX because it seems to be the lowest level/highest performance/most flexible way to go. C# appears to involve using some GUI markup language called XAML, and doesn't appear to be able to access directx, erm, directly. Please correct me if I'm wrong here, but the impression I get is that MS is going 'native first' to compete with ios, android.<br />
<br />
Trans-wise, I want to add the ability to import source/lib files from modules into a project. Just how to do this cleanly became clear once += was added, eg: SRCS+="{CD}/native/lang.${LANG}". This way, the 'lists' of SRCS, LIBS etc are completely target dependant and 'quoted imports' can eventually be killed off, something I've always wanted to do.<br />
<br />
Also, I'd like to make it easier/possible to 'roll your own' targets. This is the biggy, and I think there are 3 main changes that need to be made to make this possible:<br />
<br />
First, targets should have their own modules/ dir, allowing them to provide target specific monkey APIs without having to provide a separate modules/ package.<br />
<br />
Second, all the 'native' app-specific classes/code such as view, viewcontroller, activity etc should be moved from Mojo to the target. This at first sounds like a step backwards, but it means each target becomes entirely self contained so can easily be kludged as necessary to support ad systems, social networking etc. It also means you can use interface builder and other high-level target SDK systems to create the initial target environment etc. So basically, target projects will become standalone, runnable projects that can be built and run without ANY Monkey code (except perhaps a nop Main) and the target modules provide the Monkey side interface to the target.<br />
<br />
Finally, the 'Target' class in trans should become 'Builder', and targets should specify which builder to use in a TARGET.MONKEY file. Examples of builders would include GccBuilder, XcodeBuilder, MsvcBuilder, MonoBuilder, FlexBuilder etc. So, for example, both the Mac ios and glfw targets could use the XcodeBuilder.<br />
<br />
The goal here is for people to be able to simply copy and paste a target dir, tweak the source code and/or TARGET.MONKEY settings, and end up with a standalone target that can be dropped into any Monkey release.<br />
<br />
The last 'big job' regarding trans is to split up the monolithic output 'main.cpp' style files into per module sources, and to be able to compile them separately. Once all of the above is going, this should be quite doable.<br />
<br />
Last but not least, there WILL be an official Linux version, although it will be Makefile based in keeping with the Linux spirit! Given what MS and Apple are doing with forcing developers to sign apps etc, the day when Linux becomes the last, free OS is, I fear, coming much sooner than I once thought.<br />
<br />
As for Steam-on-Linux, I'm in two minds about this. On the one hand, I agree with Linus's POV that anyone should be able to do anything with Linux, even DRM etc. On the other hand, there is zero evidence to suggest that Valve/Steam, as cool as they are now, wont eventually end up abusing their potential power. I already don't like the 'exclusivity' aspect of having to get your game approved for Steam, whether or not that's by popular vote or whatever. I think overall I tend to agree with Linus here: freedom has to be *absolute* or it's not freedom - even the freedom to be an asshole. But I also think we also need guys like RMS to keep reminding us where we stand in terms of the big picture, or we'll start forgetting that THERE IS ALWAYS AN ALTERNATIVE!<br />
<br />
Peace out!<br />
Mark<br />
<div>
<br /></div>
marksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com5tag:blogger.com,1999:blog-5746515071319308107.post-82361695768092596422011-10-23T18:49:00.000-07:002011-10-23T18:57:40.948-07:00Surprise!Surprise!<br /><br />Well, it's been quite a while since Monkey was officially released, and I finally feel like things are settling down a bit!<br /><br />So, a few thoughts about Monkey...<br /><br />As with any product release, there were a number of unforseen issues to be dealt with, but perhaps the scariest was the 'crappy graphics performance on Android' problems the arose immedately after release.<br /><br />I made several goofs here, but the major one was probably underestimating how grunty typical Android hardware actually is. I initally went with the 'Canvas' API under the impression it would work anywhere, and benefit from OpenGL acceleration where possible. Well, it turned out I was right about the former, but way off about the later - the Canvas API is SLOW and does not appear to be in any way accelerated.<br /><br />The situation improved by moving to OpenGL1.0, but Monkey games still weren't cutting it compared with other games out there. It wasn't until I moved to GL1.1 + VBOs ('vertex buffer objects') + weird-driver-behavior-workarounds that we really started getting acceptable speed.<br /><br />This really took longer than it should I have. I should have tried to work out what sort of hardware/OpenGL drivers were actually in common use, and gone from there. Instead, I kind of got stuck trying to work out what a bunch existing (but dated) sample code was doing - perhaps a case of 'too much' information in way? Still, I learned a lot in the process I guess.<br /><br />Another thing that bit me on release was the 'generics' system used by Monkey. I initially modelled Monkey generics on the system used by Java. However, for various reasons (the main one being my own inexperience at implementing generics in a compiler) this turned out to be a BAD choice, and I've only just managed to get generics into what I'd call a really usable state. And it turns out the way I've ended up doing generics is MUCH simpler and the potential for improving it much greater now. <br /><br />I actually feel that in an odd way that Monkey is the first compiler I've written that I really have a good handle on. Previous compilers have sort of reached both the 'finished' and 'unmanageable' started at about roughly the same time - more or less by design! But with generics now cleaned up, I feel very comfortable with the Monkey code. It's not perfect by any means, but I still have a rough idea of how everything works, where the weak bits are etc.<br /><br />And what next for Monkey? My current list of 'big picture' improvements under consideration includes:<br /><br />* Better control over app data - in particular, what data is used on what targets, and how. Currently, any data considered usable by a target is added to the target project based purely on file extension. But this can mean some data ends up getting duplicated in some situaitons, esp. when you are required to provide the same data in multiple formats to handle target limitations. The current plan here is for some kind of config/control file in the data dir.<br /><br />* Reflection - ie: the ability for your app to be able to dynamically call itself. And I don't think this will actually be all that hard. One thing that has struck me since release is just how flexible a translator is - you can actually do much more with a translator than I realized. To provide reflection data for an app should just involve generating suitable reflection classes/code - in Monkey - for each app decl, and then handing the whole lot over to the translator. The native target translators shouldn't have to do any thing.<br /><br />* Interpreter - which would be much more useful/intersting if built on top of reflection. For example, if you want interpeted code to be able to call DrawImage, it'd be preferable for the interepter to just be able to use reflection. You'd hopefully then be able to get rid of the need for users to write any 'glue' code. Interpretable Monkey would also be (more) easily debuggable, but I'm not sure how useful that'd be in practice, as interpreted Monkey wont be able to do everything native Monkey can, and is likely to be slowish. Still, you'd be able to stop/start interpreted code even on callback based targets, so perhaps it'd be OK. If not...<br /><br />* Stop/Start style debugger for the GLFW target. As Monkey users are well aware, debugging can currently be a bit, erm, challenging. Basically, if your app tries to access a null object or index an array beyond bounds, the app stops and you get a stack trace - and that's it. Unfortunately, a proper stop/start debugger for all targets would be impossible, as many targets cannot be stopped as they're callback driven. Therefore, I think the most practical solution to the debugger problem would be to concentrate on making a decent debugger for the one target that can really support it - GLFW. This isn't ideal, and I'm still considering options for debugging, but given the nature of Monkey, it's kind of a tricky one!<br /><br />I've got lots of smaller tweaks I'd like to make too, but these are the 'biggies' I'm currently considering.<br /><br />And on the non-Monkey front...<br /><br />I've just finished an excellent book called 'Ready Player One' - not by any means a literally masterpiece, but an incredibly fun cyberpunky adventure story that will appeal heaps to anyone who was involved in computers/gaming in the 80's, ie: me! Very highly recommended!<br /><br />I totally loved the recent True Grit movie too, somewhat to my surprise as I'm not generally a big fan of the Cohen brothers stuff. I usually find their movies highly entertaning, cleverly plotted etc, but ultimately pretty bleak. I mean, yes, there are pyschos out there with bad haircuts, doing nasty things to people with electric cattle prods...so?!? Probably related to me aversion to 'torture porn'. But I found True Grit to be very different. It's much more of a straightforward adventure story, with hugely likeable, if flawed, characters. Even the bad guys were kind of cuddly in their own way! I also checked out the book and 1969 version, and both are highly recommended too. <br /><br />And if you're into Anime, I highly recommend Katanagatari. It's got a highly unique visual style, almost reminiscent of the game 'Okami', lots of clever, frequently funny dialog and plenty of cool fighting sequences involving Ninjas and the odd sexy nun! It's also nice and unpredictable, always a plus for me.<br /><br />Finally, a big shoutout to anyone 'occupying' anywhere right now! Not sure what will ultimately be achieved, but I do thinks it's managed to raise the odd eyebrow in the upper/political classes, and does represent a faint hope that democracy wont lose out to complacency in the end. I'm not anti-capitalist or anti-free market and I'm definitely not anti-iPhone (apparently, protesters are allowed to use capitalist-derived technology), but I do think there's a very good case to be made that a very small bunch of wealthy, privilaged people are running off with all the loot (regardless of the havoc they wreak in the process of obtaining it) while things just get harder for everyone else - often as result of the reckless behavior of said looters! And govts, left or right, seem oddly uninterested in doing anything about it.marksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com7tag:blogger.com,1999:blog-5746515071319308107.post-17379610034449618282011-06-21T18:24:00.000-07:002011-06-21T18:27:46.473-07:00Websites majorly down!Hi,<br /><br />As you may have noticed, both the www.blitzbasic.com and www.monkeycoder.co.nz sites have been down for over a day now.<br /><br />Apologies for this, but it looks like there's been a pretty serious server crash. Our webhosts are currently working on getting the site back up, but we don't know how long that will take.<br /><br />So please bear with us, normal transmisson will resume as soon as possible.<br /><br />Bye!<br />Markmarksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com5tag:blogger.com,1999:blog-5746515071319308107.post-48339403015526935062010-12-19T19:13:00.000-08:002010-12-19T20:11:42.503-08:00Christmas update!Hi all!<br /><br />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!<br /><br />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.<br /><br />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!<br /><br />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.<br /><br />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!<br /><br />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.<br /><br />And there's that 'monkey' reference again - what can it mean?!?<br /><br />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'.<br /><br />In addition, the lightwight 2d app module that I am working on will be called 'mojo'.<br /><br />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.<br /><br />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).<br /><br />So stay tuned - interesting days ahead!<br /><br />Peace out,<br />Markmarksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com30tag:blogger.com,1999:blog-5746515071319308107.post-19996042179714630882010-10-09T16:23:00.000-07:002010-10-10T16:34:19.286-07:00UpdateHi,<br /><br />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.<br /><br />So, in a probably futile attempt to reduce confusion levels somewhat...<br /><br />* Bmx2 is NOT, erm, BlitzMax 2! bmx2 is just the code name for the next BRL programming language.<br /><br />* Bmx2 is, however, fairly similar to BlitzMax in terms of language syntax.<br /><br />* 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.<br /><br />* 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!).<br /><br />* 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.<br /><br />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!<br /><br /><object width="640" height="385"><param name="movie" value="http://www.youtube.com/v/XO1n-F4uj6U?fs=1&hl=en_US"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/XO1n-F4uj6U?fs=1&hl=en_US" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="640" height="385"></embed></object><br /><br />And don't forget, all this code runs just the same on HTML5, Flash, XNA and Android...<br /><br />Thanks to jonpittock for that!<br /><br />(And no, that's not 'real' 3D at the end there - just a nifty little raycaster).<br /><br />Bye!<br />Markmarksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com17tag:blogger.com,1999:blog-5746515071319308107.post-42403251463423134472010-08-30T20:36:00.000-07:002010-08-30T20:45:59.786-07:00Self compiling!Yipee!<br /><br />I am pleased to say that bmx2 (STILL haven't decided on a new name yet) is now fully self-compiling!<br /><br />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.<br /><br />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!<br /><br />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.<br /><br />Some more details about how it all works...<br /><br />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:<br /><br />* HTML5 - HTML5 compatible browser required for testing.<br />* Flash - Open source Flex SDK required.<br />* XNA - Visual C# Express + XNA framework<br />* Android - The Android SDK (plus Java SDK and 'Ant' on Windows).<br />* Native (ie: C++) - Mingw/GCC (will probably add visualc support too in future).<br />* iPhone - XCode.<br /><br />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.<br /><br />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.<br /><br />Some more details on the new language:<br /><br />* 'Type' renamed to 'Class'.<br /><br />* Identifiers now case sensitive.<br /><br />* Private can at last be used inside classes!<br /><br />* A single 'End' can be used to terminate blocks, eg:<br /><br />Function MyFunc()<br /> Print "Boo!"<br />End<br /><br />Ye olde bmx1 style terminators are still permitted too.<br /><br /><br />* Function/method overloading added, eg:<br /><br />Function DrawImage( image:Image,x,y )<br />...<br />End<br /><br />Function DrawImage( image:Image,x,y,frame )<br />...<br />End<br /><br /><br />* 'Proper' constructors, eg:<br /><br />Method New( x,y )<br /> Self.x=x<br /> Self.y=y<br />End<br /><br /><br />* Support for 'properties', eg:<br /><br />Method X() Property<br /> Return x<br />End<br /><br />Method X( x ) property<br /> Self.x=x<br />End<br /><br /><br />* Simple class template support, eg:<br /><br />Local list:=New List<Actor><br /><br /><br />* Simple 'boxing', eg:<br /><br />Local list:=New List<IntObject><br />list.AddLast 10<br />list.AddLast 20<br />Local n=list.Last()<br /><br /><br />* Auto type inference for initializers, eg:<br /><br />Local t:=New Actor 'instead of Local t:Actor=New Actor<br /><br /><br />* 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).<br /><br />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.<br /><br />I have a related theory on this: SuperStrict users prefer C# over C++; Strict users vice versa...<br /><br /><br />* Module 'Imports' can now be cyclic, eg:<br /><br />'Module A<br />Import B<br /><br />'Module B<br />Import A<br /><br />I can't BELIEVE I thought this wasn't a big deal in bmx1!<br /><br />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.<br /><br />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.<br /><br />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.<br /><br /><br />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...<br /><br />* 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:<br /><br />Local t:Object="Hello world" 'OK in bmx1, Error in bmx2.<br /><br /><br />* Multidimensional arrays are out, although you can still have arrays of arrays, eg:<br /><br />Local t[10,20] 'OK in bmx1, Error in bmx2<br />Local t[][10] 'OK in bmx1 and bmx2.<br /><br /><br />* Arrays can not be 'downcast' in bmx2, eg:<br /><br />Local t:Object[]=New Thing[10]<br />Local p:Thing[]=Thing[]( t ) 'OK in bmx1, Error in bmx2.<br /><br />This will mean that arrays may have to be manually 'wrapped' in some situations.<br /><br /><br />And that's it for now. Hope you found it informative!<br /><br />Bye,<br />Markmarksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com22tag:blogger.com,1999:blog-5746515071319308107.post-51262341209857917172010-07-19T18:34:00.001-07:002010-07-21T21:32:16.682-07:00UpdateHi,<br /><br />***** BMX2 news *****<br /><br />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...<br /><br />The source language will be very bmx-like, with a few tweaks and additions including:<br /><br />* Simple class templates<br />* Function overloading<br />* Constructors<br />* Properties<br /><br />...and some stuff removed, such as pointers. Yes, POINTERS! Function pointers too!<br /><br /><br />Target languages I'm aiming for upon release are:<br /><br />* JavaScript<br />* ActionScript<br />* Java<br />* C#<br />* C++<br />* Python (just as an experiment - probably wont be much lib support for this to begin with).<br /><br /><br />Target platforms I'm aiming for:<br /><br />* HTML5<br />* Flash<br />* XNA<br />* Android<br />* Native GL<br />* iPhone<br /><br /><br />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.<br /><br />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.<br /><br />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.<br /><br />More to come...marksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com23tag:blogger.com,1999:blog-5746515071319308107.post-29496357844669747272010-05-27T18:02:00.000-07:002010-05-27T21:37:25.067-07:00The plan!Hi,<br /><br />Ok, here's the plan:<br /><br />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'.<br /><br />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.<br /><br />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.<br /><br />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...?<br /><br />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.<br /><br />Anyway, development has now reached the point where I am interested in getting more people involved. <br /><br />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.<br /><br />Flash demo (well, not *that* flash - very simple actually! You may need to click window to activate too):<br /><br /><iframe src="http://www.blitzbasic.com/tmp/insectoids/main.swf" width="640" height="480"><br /><a href="http://www.blitzbasic.com/tmp/insectoids/main.swf" target="blank">Flash Demo!</a><br /></iframe><br /><br />Same demo running on HTML5, Android and XNA:<br /><br /><img src="http://www.blitzbasic.com/tmp/snaps.png"><br /><br />LOTS more info soon.<br /><br />Peace out!<br />Markmarksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com37tag:blogger.com,1999:blog-5746515071319308107.post-76644546521931325812010-03-29T15:25:00.000-07:002010-03-29T22:51:07.990-07:00BMX News!Hi,<br /><br />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.<br /><br />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!<br /><br />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'!<br /><br />Bye,<br />Markmarksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com16tag:blogger.com,1999:blog-5746515071319308107.post-65860103905062136072009-12-28T18:25:00.000-08:002009-12-28T19:58:16.793-08:00Yet Another Avatar Review!<p>Hi,</p><p>Well, just got back from seeing Avatar on the biggest movie screen in town and, well, yes, WOW!</p><p>***** Warning! Spoilers Below! *****</p><p>From a purely technical standpoint, I thought it was, as hyped, the best CGI movie yet.</p><p>Although I was disappointed with the previews shown earlier this year (it all looked a bit 'fake plastic blue' or something) the final product was somehow much more convincing.</p><p>I suspect this is mainly because you were bombarded with such a huge amount of gee wizziness that any cracks in the visuals were just lost in the flood, but I think there was also something else going on, and what I consider to be Avatars *real* achievement - the very convincing facial animation of the CGI actors.</p><p>This hugely helped 'sell' the characters as realistic entities, and not just CGI (erm) 'avatars' standing in for real actors. Granted, the characters aren't actually human, and if they had been it may not have worked so well. But they did successfully achieve a sense of realism I haven't seen yet in supposedly realistic CGI animation.</p><p>The 3D was fine, but not IMO particularly any better than, say, Up3D, and I still can't see myself being happy with having to watch ALL movies in 3D!</p><p><p>Finally, the scenery was stunning, surprisingly New Zeland-ish in fact with what look like plenty of ferns and 'koru's all over the place, and was teeming with plenty of imaginative and quite beautiful animals and plants.</p><p>As for the actual story, I actually enjoyed the first half of the movie immensely.</p><p></p><p>The story gets stuck in right from the outset, and before long our paraplegic hero has transferred into his brand new, 9 foot tall blue alien body and is hoofing it madly through the forest for the sheer hell of it. </p><p>It's an exciting, romantic moment, and the movie carries on in that spirit for quite a while. There's even a quite nicely pitched bit of human-alien romance in there which works surprisingly well.</p><p>But of course, this is an evil-humans vs virtuous-natives story, so the film has to eventually turn into a huge prolonged orgy of military violence - about an hours worth in fact.</p><p>At this point, the movie changes tone dramatically, and things start getting a bit weird. The virtuous-natives are apparently too stupid to save themselves without human help (there's some vague 'chosen one' device at work too) at which point it gets a bit (more) condescending.</p><p>But, the visuals remain strong, and the battles are pretty spectacular. It all manages to remain more or less entertaining right until the (pretty crappy) ending, although you feel like you've mostly lost touch with the characters by then.</p><p>A shame really. If this really is some kind of American Indian or Afghanistan allegory (as has been claimed) or something, I can think of far more interesting/subversive ways to end it. But hey, this is James Cameron, and he seems to be far more comfortable with characters who carry BIG SEXY guns - indeed, by the end even our hero has grabbed himself a gun and has ditched his wimpy bow and arrow/knife combo...</p><p>But bah, I liked the first half, didn't like the second - no doubt there are some people who think the opposite! A case of something for everyone, perhaps...</p><p>Whatever, it was, first and foremost, hugely entertaining.</p><p>Bye!</p><p>Mark</p><p><br /></p>marksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com1tag:blogger.com,1999:blog-5746515071319308107.post-17002250063735059362009-12-19T19:56:00.000-08:002009-12-19T22:14:18.790-08:00Happy Christmas!<p>Ho ho ho,</p><p>Well, it's that time of year again - must be time for a Christmasy blog!</p><p>It's been an interesting if low key year, during which I managed to fail yet again to get anything substantial done, but still managed to learn a lot of things along the way. </p><p>The evolution of BlitzMax into a threaded language has been probably the most interesting/challenging thing I've done, and in particular the development of an entirely new garbage collector.</p><p>It's still not perfect though, as there are some 'pathological' situations which can still upset the GC. The solution to these problems is to make the GC 'generational', which basically means keeping track of 'old' and 'not so old' objects. Ouch.</p><p>This apparently requires the addition of nasty things called 'write barriers' - little bits of code that get called every time a pointer is written to a variable (reference counting actually involves a write barrier of sorts) . I have a feeling this can be achieved 'on the cheap' using virtual memory techniques though, and it's something I'll probably be looking into next year.</p><p>And the $64,000 question - what about 3D?</p><p>Well, the truth is, I just don't really feel that I have anything new or particularly clever to offer 3D wise right now - and haven't for a while. There are plenty of good 3d libraries out there these days (and many of them free!) and competing with them has just become more and more scary. I guess what I'm really after is some kind of dinky new approach or something that simplifies life the way Blitz3D did.</p><p>I could certainly do more to promote and support the 3rd party 3d modules for BlitzMax around these days though. My general suckiness at marketing etc issues not withstanding, I'll make an honest attempt to do something about this soon!</p><p>I'd also like to do something *I'd* use to write a game with, and to be honest my requirements for a 3D engine are pretty minimal. As much as I'd like to a do a bumpy/specularly extravaganza, the truth is I just don't have the resources to do it justice. In which case, why not do something simpler, faster etc that works on more hardware. I guess what I'm saying is, as with programming languages, my first priority is to do something I'd be comfortable using myself, and all this next-gen stuff creates a certain amount of tension in that respect.</p><p>But all power to guys like Josh Klint and his leadwerks engine which requires a reasonably high spec - they're definitely pulling the technology in a good direction as opposed to, say, Intel and their craptacular graphics cards. Honestly, we'd have been better off with GeForce 4's!</p><p>Gaming wise, I've actually had something of a gaming renaissance in 2009, although this is probably more down to my being a bit more open to trying new gaming 'forms' than any resurgence on the industries part.</p><p>I have thoroughly enjoyed games such as Mirror's Edge, Infamous, Arkham Asylum, and esp. Uncharted 2 and kind of feel that gaming is heading in interesting directions these days.</p><p>Many of these games feel almost 'mini-game-ish' in nature, with set pieces sort of strung together by sequences of 'actual game'. The 'actual game' bits can sometimes get a bit monotonous, often consisting of 'wack a mole' style combat, but the set pieces are usually very cool - certainly cool enough to keep me playing for the next one!</p><p>Mirrors edge really stuck out for me though. The actual game bit basically consists of running very fast from point A to point B - and it works really well! Keeping your speed up is key, and do so allows you to run up walls and jump over huge gaps without it all feeling too silly/impossible. But I feel it's let down a bit by having too many restart points, which basically allows you to get lazy as you can always just try again. IMO, they should have made the levels a little easier, but with fewer restart points. It would've made for the same overall difficulty, but have given it all a little more tension.</p><p>I'm also very much looking forward to 'Demons Souls':</p><p>http://www.youtube.com/watch?v=VT89mvjxudk</p><p>Not available in stores here in NZ (why?) but I've got it ordered and it should be here next week. Good too see developers being brave enough to make a game *hard* again!</p><p>Anime-wise, I must confess to having watched a lot of 'high school romance' style Anime lately. In particular, I find the Anime adaptations of the Japanese 'girl games' by Key Visual Arts (haven't played the games...though they're apparently quite raunchy!) really entertaining. Not quite sure why, perhaps because there's usually an element of the supernatural in there or something, but they're definitely skilled at building up characters and manipulating the viewers emotions.</p><p>But 'Death Note' was probably the Anime highlight of 2009 for me. A simple premise - a guy discovers a note book that will magically kill off anyone whose name he writes in it - is taken in gloriously confusing directions. The amazing thing about the show is that despite the fact things keep getting more and more complex (the book has an apparently never ending set of rules governing its usage) you're never really lost by it all. There is the odd bit of exposition here and there, but overall it's just a brilliant bit of story telling.</p><p>Movie-wise, I didn't get to see all that many movies this year (too busy watching Anime and playing games!), but I did thoroughly enjoy Star Trek, Synecdoche New York and esp. Coraline.</p><p>The thing I always liked about Star Trek was the Kirk/Spock dynamic, and I felt the movie kept this intact very nicely. Yes, it was a bit of an incoherent mess ('racist' Vulcans? Surely racism is not logical!), had too many lens flares (Well, I liked them!) and featured probably the biggest god machine coincidence in living memory (Kirk AND future Spock AND Scotty all accidentally stranded on the same minor planet?!?) but I thought the actors caught the essence of the original characters just fine.</p><p>Synecdoche New York is probably a bit of an old farts movie, concentrating as it does mostly on death and 'what have I done with my life' issues, but it's also funny, wildly imaginative and thought provoking. The main character builds a 'miniature' of his world inside a huge warehouse, and after a while what's real and what's 'acted' becomes blurred. And, of course, the ending is killer...</p><p>Coraline is...awesome. A bit goth, but if you can handle that, see it!</p><p>Music-wise...is it just me, or was 2009 a bit of a loss? Waiting for someone to kick things into gear again...</p><p>Coolest moment of 2009: Obama getting elected. </p><p>Bummer moment of 2009: Obama's Nobel peace prize acceptance speech.</p><p>Anyway, getting WAY off track. Have an excellent 2010 and code the good code!</p><p>Bye,</p><p>Mark</p>marksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com7tag:blogger.com,1999:blog-5746515071319308107.post-59875456796639113052009-10-01T15:46:00.000-07:002009-10-01T16:12:54.795-07:00Little Big PlanetJust picked this up last week and…Woohoo! What a cool little (big) game!<br /><br />Yes, I'm a year behind the times, but I didn't actually expect to like it at all given that: a) I've never found physics based puzzle games all that fun, and b) I'd seen it an expo when it first came out and thought it looked pretty ugly.<br /><br />But now that it's hit the bargain bins, I decided to give it a blast, and I'm very glad I did.<br /><br />First impressions: It's a very 'English' game: the voice-over is very similar to that used in Hitch-hikers-guide-to-the-galaxy, and I think I even recognized some music from the excellent 70's TV show 'Vision-On' in there. It's actually nice to see a game 'projecting' personality like this.<br /><br />Second impressions: It's simple, but fun. There is a lot of variety in the environments/graphics, and the designers have managed to come up with a very impressive number of ways to reuse the physics elements - yet they haven't 'overcooked' the puzzles: they're generally short and to the point.<br /><br />Third impressions: I was totally wrong about the graphics, they're excellent! I think I may have been put off a little by the 'sack doll' player character. In default mode, he looks a little too much like the 'maggot monster' in 'nightmare before Halloween' for my liking - just a little bit creepy. But he does grow on you and you can customize him massively (I'm currently in soothing magical girl mode!). Ultimately, I think the realistic graphics complement the realistic physics beautifully.<br /><br />Fourth impressions (about a week later): It's still simple, but still fun! OK, I've probably only put 5 or 6 hours into it so far, but that's damned good for me!<br /><br />Minor grumbles: A fraction too much inertia on the player for my liking; sometimes you can't see where you'd like to and there's no manual camera (although 'leaps of faith' are seldom punished); while it's primarily a 2D game, there are in fact 3 'layers', and it can sometimes be hard to work out which layer you're on - worse, the game sometimes automatically moves you to a different layer, every now and then with fatal results (but this is probably worth it, as it also increases the speed at which you can whizz around levels).<br /><br />I haven't played around much with the game creation stuff yet, but it looks pretty impressive and was apparently used to create ALL the in game levels. The online user maps are less impressive, but again I haven't looked too closely at these. More later…<br /><br />Peace out!<br />Markmarksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com1tag:blogger.com,1999:blog-5746515071319308107.post-67973102020049729402009-09-14T19:24:00.001-07:002009-09-14T19:27:42.026-07:00Spillage!Hi,<br /><br />One of the things I was determined to implement in BlitzMax right from the start was a decent 'register allocator'.<br /><br />Register allocation is the process of mapping 'local' program variables (i.e. those variables declared 'Local' in BlitzMax) to CPU registers (i.e. the finite set of 'variables' inside the actual x86 CPU).<br /><br />Blitz3D and BlitzPlus largely ignored this. Instead, all local variables were simply stored in memory (on the stack), and loaded into CPU registers as required. For example, Blitz3D code like this…<br /><br />Local x,y,sum<br />x=1<br />y=2<br />sum=x+y<br /><br />…would involve approximately the following steps:<br /><br />1) Write the constant '1' into the memory location for variable 'x'.<br />2) Write the constant '2' into the memory location for variable 'y'.<br />3) Read the variables 'x' and 'y' from memory and add them together.<br />4) Store the result into the memory location for variable 'sum'.<br /><br />That's 2 reads and 3 writes from/to system memory, and system memory is generally slow (even with fancy caches) when compared with the CPU (but I guess it'll be catching up soon…).<br /><br />BlitzMax on the other hand will try to represent the variables x,y and sum using CPU registers, so equivalent BlitzMax code might involve something like…<br /><br />1) Write the constant '1' to CPU register EAX.<br />2) Write the constant '2' to CPU register ECX.<br />3) Write the sum of EAX and ECX to CPU register EDX.<br /><br />…none of which 'hits' memory so is theoretically much faster.<br /><br />And, happily, this time at least, theory matches practice - BlitzMax code runs significantly faster than equivalent Blitz3D code in general, and this is almost completely due to BlitzMax's register allocator.<br /><br />There is, however, one fairly major drawback to writing a register allocator - it's *@#!$^& hard! ESPECIALLY on the crappy Intel X86 which has only about 8 general purpose registers.<br /><br />In particular, the trickiest thing to deal with is 'spillage' - handling the situation where there just aren't enough CPU registers to go round and some local variables MUST be 'spilled' to memory.<br /><br />In this case, a spilled variable ends up behaving much like a Blitz3D/BlitzPlus variable above does - it must be constantly loaded/stored from/to memory. Therefore, the most important job of the register allocator becomes minimizing the number of spilt variables.<br /><br />This is tricky because it can be hard to know precisely what effect spilling a variable will have. Spilling a variable may even cause a 'cascade' of more spills, because even though a spilled variable is stored in memory, it still needs to be moved into a CPU register at SOME point to be used for anything useful (e.g. arithmetic, memory addressing etc)!<br /><br />And every now and then, someone will come up with a little piece of code in BlitzMax that causes this effect. The code will usually be small, involve about 8 or so local variables and will cause the compiler to lock up completely as the register allocator gets caught in an endless allocate/spill/allocate/spill loop...<br /><br />In fact, it happened again just yesterday - hence this post!<br /><br />I *think* I have it sorted now, but to be honest I seriously doubt I'll ever be able to say with 100% confidence that I know it works!<br /><br />Peace out!<br />Markmarksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com12tag:blogger.com,1999:blog-5746515071319308107.post-34007333648049307142009-09-05T22:26:00.001-07:002009-09-05T22:38:52.837-07:00Snow Leopard (and OS upgrades in general)Hi,<br /><br />As a software developer, I'm pretty much required to upgrade my OS's whenever the latest/greatest OS comes out. However, as a bit of an old fart, it has definitely become less a less of a thrilling experience!<br /><br />The worst software upgrade experience was easily Vista. No doubt, as an early adopter, I encountered many of it's teething problems earlier than others. But these were pretty major, including: terrible support for non-MS networks; incredibly slow file management; generally dodgy network behaviour (LOTS of network timeouts); and an incredibly 'random' (if more attractive) GUI.<br /><br />Some of these issues were resolved via various registry hacks, and no doubt service packs improved things, but I only lasted a few months on Vista before reverting to XP as my 'main' OS. And that is the first time I have *ever* gone backwards OS wise. I suspect Windows 7 will be better - but for the love of god, if it doesn't have a 'make all windows look like this' button I'm gonna go Joe 90 on someone!<br /><br />But before all this makes me sound like too much of a Microsoft hater (I only hate them a *little* bit, honest!) I would like to stress that my favourite OS of all time is easily Windows 2000.<br /><br />Perhaps it was the timing, perhaps I'd spent too long on the Win95 line, but I really, really liked Win2K: It was small, it was fast, it was stable and it was no-nonsense: All the 'options' dialogs were presented as nice tidy consistent 'key/property' dialog thingys. It rocked, and at the time I was looking forward to more of the same.<br /><br />Unfortunately, I think Microsoft failed to realize they were onto a good thing, and decided instead to 'ape' the Mac: The next release was XP, with big ugly buttons and unnecessarily dumbed down dialogs, and then Vista with the window renderer. I guess they had too though...<br /><br />I like the Mac, but I don't use it as my primary development machine - there are too many little annoying things about it: No 'up a folder' browse button; no full path name in browser window title bar; no ability to mess with 'hidden' files (ie: files starting with '.' - you can hack the OS to show them, but you can't modify them) - and more. Of course, at this point you're supposed to use the command shell (and the Mac shell is unix-grunty...) but stuff that - I'm a child of the GUI generation! I don't like the shell!<br /><br />Which brings us to Snow Leopard, the latest MacOS update. It is apparently faster; you can apparently do 'Microsoft exchangey' things with it; and it only cost 60NZD, BUT: For what I use a computer for, there is absolutely no difference whatsoever!<br /><br />And frankly, I'm disappointed - hell, if they'd forced a new desktop wallpaper on me I might even feel a bit better! From Apple, I'm a little surprised: 10.4 had the spotlight feature added (which would have required serious hacking of the file system) and 10.5 had the clever time machine feature (ditto), but 10.6...?<br /><br />But perhaps I'm being a bit harsh - OS development and maintenance costs, and perhaps it's more honest of Apple to release a cheap 'tweak' update than try to pretend it's something new.<br /><br />All in all though, it definitely feels like OS development (not counting sexy windows) is moving sideways much more than it's moving fowards. Perhaps we've exhausted the UNIX paradigm? Perhaps (gulp) there's nothing better?<br /><br />Whatever - it's been a LONG time since I've been excited about OS technology. Which is a bit of a bummmer.<br /><br />I am, howver, very much looking forward to whatever google do with Chrome...<br /><br />Peace Out!<br />Markmarksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com5tag:blogger.com,1999:blog-5746515071319308107.post-29134666180542665802009-09-02T15:19:00.000-07:002009-09-02T18:05:58.364-07:00BlitzMax Garbage Collection part 1...Hi,<br /><br />Ok, a few random comments on the history and design of BlitzMax's garbage collection system - probably not for the faint of heart...<br /><br />The GC system is BlitzMax has actually gone through several iterations by now. The first was, ahem, a little rough. It was basically a reference counting system that required the programmer to manually call a 'FlushMem' command every now and then. Worse than that, they couldn't just hide the FlushMem in a function somewhere, it had to be in the right place 'on the stack' as it couldn't 'flush' anything higher up the stack.<br /><br />Yes, users found it a little confusing!<br /><br />But it worked, and I eventually managed to get rid of the need for FlushMem entirely. This is the GC BlitzMax has used for a long time now and it has one very cool thing going for it: it's *fast*!<br /><br />However, it has 2 fairly serious disadvantages - it can't handle 'cycles' of objects (this is where a chunk of memory directly or indirectly points to itself - such memory can 'leak') and it doesn't work nicely with multithreading. And EVERYONE wants multithreading these days, right?<br /><br />So I decided it was time to implement a 'real' garbage collector - one that could handle both cycles and threading.<br /><br />Fortunately, thanks to the wonders of open source software, there is an excellent GC available that is *almost* perfect for BlitzMax: the 'Boehm-Demers-Weiser' (BDWGC) conservative garbage collector:<br /><br />http://www.hpl.hp.com/personal/Hans_Boehm/gc/<br /><br />This is already in use by many pieces of software, so is well tested, and is pretty easy to 'drop into' an existing project such as BlitzMax.<br /><br />And, best of it all - it just works! By using this in your software, you can allocate memory and forget about it. It is one seriously cool piece of programming...<br /><br />However, there were a few things I was a little uncomfortable with about it:<br /><br />* BDWGC was designed to handle any old generic code, yet I 'know' stuff about BlitzMax code that they don't - surely I could use this knowledge to make the GC more efficient? One example: C/C++ etc code can often generate 'derived' pointers. This is where a pointer points 'into the middle' of an object, not at the beginning. However, with BlitzMax code you don't have to worry about derived pointers (not coincidentally due to changes I had to make to get rid of FlushMem way back!) so the code in BDWGC to 'validate' a pointer is unnecessarily complex.<br /><br />* There appears to be a bug in BDWGC to do with 'cyclic finalizers' which can cause crashes or leaks. No doubt, this will be fixed eventually, but hey, it's open source so surely I can fix it myself? Unfortunately…<br /><br />* The BDWGC code is pretty hard to follow. It's designed to run on about a gazillion versions of EVERY OS ever, has a ton of optional features and is 'macro-ed' up the wazoo. After a few hours trying to hunt down the cyclic finalizer problem, I realized I was out of my depth and gave up (Actually, this may have more to do with me - I kind of suck at reading other people's code...)<br /><br />So, the last effort on the GC front has been to write a 'proper' cycle/threading friendly GC on my own (MSGC), that can take advantage of the way BlitzMax works - and the results are looking good!<br /><br />So far, MSGC is faster than BDWGC (although not as much as I would like!) with everything we've tested it with and appears to be very stable (although I'm sure the upcoming public release will change that).<br /><br />It's been a pretty interesting experience writing it too, and I'll go into some of the details in a future posting, but that's probably enough for now.<br /><br />Peace out!<br />Markmarksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com7tag:blogger.com,1999:blog-5746515071319308107.post-59426744995358729242009-08-31T01:13:00.000-07:002009-08-31T03:03:07.035-07:00WelcomeHi,<br /><br />Welcome to markspace!<br /><br />I am Mark Sibly, computer coder extraordinaire, currently located in West Auckland, New Zealand. I'm a big fan of blogs - well, the interesting ones anyway - so thought it was time to start my own.<br /><br />Actually, I did have a blog for a long time - before blogs were cool no less! - but it was located on my 'commercial' site and I ended up being uncomfortable with the professional vs personal issues that arose - eg: customer: "but you said you'd do this!"; me: "hey, I was just thinking out loud!".<br /><br />Hopefully, blogging in the googlesphere will reinforce the point that none of this is to be taken too seriously, and that my thoughts, plans and opinions are highly subject to change.<br /><br />A bit about me:<br /><br />* I became interested in computers at around age 10 (1977 - Star Wars year!) when I discovered a TRS-80 complete with an awesome "How to program in BASIC" manual while going into work with dad one Saturday. Been hooked ever since...<br /><br />* I did a bunch of games on the Vic-20, Apple2, C64 and Amiga. Some I even sold for actual money! Then things got all 'serious' with the PC and the gaming side of things sort of petered out.<br /><br />* Since then, I've mostly been involved in writing 'game oriented BASIC compilers' for the PC - BlitzBasic, Blitz3D, BlitzPlus, BlitzMax...yes, I like the word 'blitz'!<br /><br />* I'm a capitalist at heart, in-so-far as I believe that everyone should be able to make a living at what they're good at. However, I strongly believe this has to be balanced against a 'public good': It's not always the 'best' product that wins in the end, and just because someone is making oodles of money out of something doesn't mean 'everyone wins'.<br /><br />* I *love* music. In my teens and twenties, I put considerable effort into mastering the guitar. It didn't quite work out, but I had a blast playing in several bands along the way and still like to tootle around. Current bands of choice include TV On the Radio, DeerHunter, Marnie Stern (yeah!)...<br /><br />* I also *sort of* love games - by 'sort of', I mean that I'm incredibly picky when it comes to games. I'll happily buy any Nintendo machine purely to play the accompanying Mario and Zelda releases (which means I end up playing approx 500NZD a pop for those games - but it's worth it IMO), but FPS's and anything remotely resembling an RTS or RPG just leave me cold. My loss no doubt - I'd certainly like to be able to enjoy a greater range of games - but in my mind there is just this HUGE gulf between the (serious) games Shigeru Miyamoto produces and everything else. In fact, I find it kind of alarming to see Nintendo pursuing this whole 'casual gamer' thing these days...<br /><br />* I have also recently become something of an Anime junky. For people of, ahem, 'my generation', this may require an explanation/definition. Anime simply means 'Japanese animation'. It's not a genre or a philosophy or anything, it's simply a technique: animation. Therefore, to put it more precisely, I have recently become somewhat addicted to Japanese entertainment, which happens to frequently present itself in animated form. Actually, I suspect the main reason for this is budgetry - a voice actor is much cheaper than a real actor. But this just ends up being liberating for the creators - you don't need a mega budget to produce an awesome story via Manga/Anime, just a GOOD IDEA!<br /><br />* I like writing and would love to one day write some fiction, but years of writing technical documentation for various compilers etc have left me a bit drained...hopefully, this blog will get me back in the swing of writing.<br /><br />Anyway, that's enough for now. Future blogs are likely to be highly technical as I mainly plan to use this blog to share my experiences as a software developer, but I hope to throw in an anime/movie/album 'review' here and there.<br /><br />Peace out!<br />Markmarksiblyhttp://www.blogger.com/profile/15527495082612941633noreply@blogger.com3