BlitzMin?

I would love to get a copy of BlitzPlus with all libraries stripped out, leaving only support for basic maths. I usually use my own libraries anyways, and the resulting executables would be tiny.

I think you want the soon-to-be-announced MaxMin mod.

You can do this with BlitzMax right now.

I'm using PureBasic for such purpose, not that hard for converting B+ things to PB.

BMax should do that too.

The MaxMin mod runs at pre-compile time and deletes your mods directory.

Lol @ Vanilla :)

... and sets your Framework to "pub.empty" which looks like this:

Strict

> You can do this with BlitzMax right now.

But BMax isn't 'as' fast.

SIEVE OF ERATOSTHENES speed tests (Max, PureBasic, Blitz3D, C++)

I typically find Max to be around 1.7 times quicker than PB in the above number crunching test.

@Halo,
Just for the record, the following BlitzMax example produces a 14.5K executable (using UPX -9 compression ):

Framework BRL.System
AppTitle$="Tiny Max example"
Notify "Hello World"

BM is surely faster than any older Blitz product. You just have to drop the integer handle programming style because then it will be surely slower than BB+.

What else can you use for handles if not integers?

Do it "properly" and use objects, not integer handles.

Don't you need handles for the objects?

Not in BlitzMax. In BlitzMax, images for example can be identified with integer pointers or objects of type TImage. And this applies to most everything.

Umm, yes, but that object reference is stored somewhere - ultimately as a memory address to where the object lies in memory. So... how is that different to passing an integer variable containing an object's address in memory? The only difference is that Max is handling the reference internally - which I can't see affecting speed at all - maybe the garbage collector speed, maybe. It wouldn't be at all noticable I wouldn't think. There are much better reasons why Max is faster than previous Blitz's, such as better compiler optimisations, including storing as many Local variables as possible in registers, rather than on the stack.

The Max2D module may be slower, depending on the system, but of course that could be overcome by writing a Max2D driver that did REAL DX7 2D and then it would be exactly the same as previous versions. Of course then you lose everything nice about Max2D.

Some time this week.

Now... when will you change yous .sig? How about now? When is your new .sig due? Now? Why not? anyone knows when he'll change his sig again?

Yes I know... 5 days and counting (20 if my usual BRL estimate estimator is correct)... and the sig gets changed when it happens... seeing is believing!