+ Fixed Import path bug, ie: imported bmx files in subdirs not using subdir
as currentdir for imports.

+ Fixed bug in register allocater with very deeply nested loops.

+ General tidy up of core Blitz module.

+ Fixed MacIDE so you can 'Save As' non-bmx type file.

+ Modified freetype module so you can hook IO. This means you can now Incbin imagefonts.

+ Changed object file name munging so cross platform projects can be developed in a common network directory without clashes.

+ Added SendMessage method to Object - see 'objects' in language reference.

+ Added pub.directx module. This currently only includes a work-in-progress of D3D9.

+ Added 'Extern Type' feature - see 'advanced topics' in language reference. This is a very useful feature for using Win32 'Com' object

Hi,

If you are having problems upgrading, please perform a full installation instead as described in the 'BlitzMax Updates' topic at the top of this forum.

A few low level things changed in this release, which meant that ALL modules needed to be rebuilt. Also, if you are working on your own modules, these will need to be rebuilt too.

Sorry for the inconvenience. I've tried to leave a few 'hooks' in there this time to hopefully prevent this from happening again in the near future!

Heya Blitzers,

We're getting close to the Win32/Linux releases of Max. There's a beta demo version now in testing and once that's been given the thumbs up, we're off!

Thanks to Skidracer's fine efforts, the new Max IDE is now going on all platforms. However, the Mac version wont be available for a while yet - at least until after the Win32/Linux release is out of the way. This IDE will eventually become the 'official' IDE, mainly because it's written in Max which I think is cool.

While Simon's been working on IDE/GUI stuff, yours truly has been tweaking Max, bug fixing and messing around with the new 3D engine (Max3D?), mainly trying to come up with a tidy-ish, high level architecture.

The way things are going, it looks like the engine will be split into 3 'layers': scene graph, render queue and render engine. In Blitz3D, all these bits got sort of mixed up together and things got a bit messy internally. Hopefully, Max3D will be a bit cleaner in this respect.

The scene graph layer allows you to manipulate things in a Blitz3D-like way - ie: setup a tree of cameras, lights, models etc, and update and render them with single commands. Much work to do here...

The render queue layer is responsible for queueing up render operations. The main point of this layer is to minimize renderstate changes - ie: it tries to 'batch up' operations that share common state. You can go to ridiculous lengths to achieve this, but you've got to be careful you're not introducing more overhead than you're eliminating! My first attempt here was not terribly successful. I could produce a 'render tree' that shaved 3-ish milliseconds off a raw render of a 'typical' scene (let's not go there...) - the only problem was, it took 5-ish ms to create! You could 'cache' such trees and recreate/update them when the scene or a scene node changes, but then you run into problems with culling/occlusion. I've since come up with a tidy compromise that I *think* will do the job nicely. More testing required though.

The render engine is the 'thin' API translation layer, with simple commands like 'SetVertexBuffer', 'SetShaderConstant' and so on. If you're not in the middle of a 'RenderWorld', you can hit this layer directly. There will also probably be a 'RenderPass' type that you can extend to perform custom low-level rendering during a RenderWorld. The render engine code is pretty sweet now and I don't expect it to change much.

I've also been playing around with ODE, the physics library. This is a really, really nice piece of software, and I just love the way the addition of physics makes so much cool stuff 'automatic'. Not sure yet if/how this will impact on the 3D engine, but my curiosity has definitely been piqued!

Bye!
Mark