Surprise!

Surprise!

Well, it's been quite a while since Monkey was officially released, and I finally feel like things are settling down a bit!

So, a few thoughts about Monkey...

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.

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.

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.

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.

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.

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.

And what next for Monkey? My current list of 'big picture' improvements under consideration includes:

* 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.

* 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.

* 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...

* 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!

I've got lots of smaller tweaks I'd like to make too, but these are the 'biggies' I'm currently considering.

And on the non-Monkey front...

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!

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.

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.

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.

Websites majorly down!

Hi,

As you may have noticed, both the www.blitzbasic.com and www.monkeycoder.co.nz sites have been down for over a day now.

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.

So please bear with us, normal transmisson will resume as soon as possible.

Bye!
Mark