Matt Bennett: CAD & Code

This has come up a few times so I decided to write a little demo.

The terrain and the eraser are defined as sets of horizontal lines.   Clipping one horizontal line to another just involves trimming one end or the other, or splitting it into two, or deleting it altogether:

The line sets are sorted by height allowing collision and trimming checks to early out once they come across a line segment that is beyond the target depth.

In the demo, move the red eraser with the mouse to shape the terrain and there’s a couple of hundred particle pixels on the screen too just to bring it to life a little.

Download demo source here

What’s new? A few major things..

• Sprites can now be procedurally generated and still managed by the system, just the same as sprites loaded from disk via resource scripts. There’s a new sample that shows just how this is achieved.
• You can write your own custom sprite animators. I’ve already provided animator code for Sine waves, Linear Interpolate, Bouncing and Accelerate/braking, and they’re used extensively to animate the GUI elements and all kinds of things. Now it’s possible to extend this animation system with your own code. The animator sample has been updated to show how it’s done.

And a few minor things… see the changelog.

This sample (check out sample #6) shows 100 sprites that have been procedurally generated to have bitmap animations as well as scripted animators acting on them.  I used a simple blue ball image, and overlaid the yellow spot in several places to generate a turn left/right animation.  It looks better in motion!

Version 1.5 makes a couple of potentially project breaking changes, but they are quite minor;

• The AppModule Draw method no longer requires the sync:int parameter
• Updating the Sprite deltatime no longer accepts a float delta, it requires a millisecond integer value just as the rest of the framework uses.

The tutorial code is now available right up to and including adding the high scores.

The tutorials are underway and the very first one exposed some omissions from the framework.  First of all there was no way to work with individual X and Y values for a sprite without accessing their fields directly.  Not that there’s too much wrong in that, but I’d prefer it wasn’t necessary anywhere in the framework code.  Once users are happy using fields directly it can cause chaos when they begin accessing those they shouldn’t.  (For non Blitzmax readers; while Blitzmax handles OOP, Polymorphism and Inheritance it is rather lacking in the Public / Private department).

Another thing missing was a simple way to handle lots of sprite objects.  I always use a list of free sprites that I create at start up, then take one from it everytime I need one and put it in a list of live sprites.  The live sprites are drawn, updated and used for collision detection etc.  When one of those live sprites is finished with, I take it out of the live list, and put it back in the free list so it can be recycled.  Simple enough.

Except, I’ve added a SpriteList type to the framework to handle this for you.  I’ve also updated the first tutorial to use this new type.

I’ve added some new parameters to the particle system to allow more emitter types.  You can now;

• specify a random scale range for particles to spawn at

• have a cone angle at which particles escape from the emitter
• give an emitter an angular direction

• spawn particles at a min/max distance from the emitter

Not big news, but not being able to do this was a bit of a glaring omission.  I’ve also tweaked the editor to run at 60FPS from the original 20.

The particle editor comes with render source code so it can be used seperately (and freely) from the mbmFramework.

I’ve brought the framework release up to the latest version (V1.2).  That can be found in the usual Downloads section.  I’ll also try and keep the Changelog viewable online too, along with the documentation.

Happy coding!

There’s a new version of Gem Smasher available today in the Download section (V0.52).  I don’t send this out for beta testing so please comment or email if you have any issues with it!

Work continues on the framework, which is the reason for the updated game release.  I’ve greatly improved the timing system and it now defaults to vsync on for a smoother experience that stresses the CPU much less too.  I’ve also added a simple profiler to allow you to track where your code is spending its time.

A full release of the latest framework will come in the next few days.

A proof of concept demo of a Computer Aided Machining package I did in the summer of 09.  Written in C++ using good ‘ol MFC for the UI.  The objective was to load and display STL files, define cutter geometry and calculate collisions and contacts between them to generate 3d cutter movements over the STL triangles.

That worked!

Next step was to provide simulation of the cutter actually removing material.  I’ve been intruiged by this algorithm since I first saw it in action over 10 years ago and after looking for ways to achieve it on the Z-buffer I finally settled on my own solution (which, actually, must be the way to do it)…

That worked too (see inset in the image above).

The solution involves 2 set-up steps:

1) raytracing through the material, to generate solid depth information (depth at which it enters, depth at which it exits)  The color information is taken from the point it enters.

2) raytracing through the cutter as above, but taking the color information from the point at which it exits.

Because these scene is rendered without perspective, it’s possible to transform the cutter rays through space and subtract them from the model rays, which makes the actual “material removal” code really quite pacey as there’s no realtime ray tracing invovled.

Next step was to wrap it in a front-end with dialog forms for managing and defining stock material, boundaries, cutters, cutter paths and outputting CNC programs.

MFC has been around so long it’s hard to ignore it, but ultimately I’d consider using a cross platform solution because the rest of the code is.

Where next?

When I have some time to commit to it, I’ll try and push it onwards with the ability to create different types of cutter paths, picking out features such as sharp corners and drilled holes etc.  But it may just stay as yet another experiment…

I posted a particle system over in the Blitzmax code archives a while ago.  It’s actually part of the framework but it stands alone quite well and I thought it might be useful to someone.

A full download is here.  Containing Win32 and Intel Mac compiled versions of the editor, full blitzmax source code and sample emitters.

A cool tile matching game, created under contract from the owner of zhanggames.com.. Mystic Worldz

Cross-platform (PC & Macintosh) written in Blitzmax.  As well as the game code I also provided a fully functional and fairly friendly (given the time constraints) level editor, also written in Blitzmax, using MaxGUI.