How well will BlitzPlus code drop into BlitzMax?

I haven't seen any official statements on this and if one of the guys would like to answer this I'd appreciate it.

I'm beginning to wrtie a BlitzPlus game to take advantages of some of BlitzPlus's features, but I am concerned about a lot of gripes I hear about missing features/bugs of BlitzPlus.

I was thinking that if I run into some of these missing features/bugs that I might be able to deal with them by simply dropping my code into the upcoming BlitzMax compiler which will hopefully not be plagued with the same faults.

Will this be possible? It would just be nice to know that if I can't make it work in B+, that perhaps I could use BMax without any MAJOR rewrites.

i think blitzmax is incompatible with blitzplus, blitz3d and blitz2d - here are many syntax-differences:

Local blub:image=CreateImage(...)
Print blub.width 'comment
Print blub.height
....

From what we know so far, you will probably have to run existing code through a converter. BUT, you may also find that the core BlitzMax compiler doesn't have a GUI module. Whether Mark will create one, or you will need a 3rd party one, I don't know.

Hopefully as far as the 2D stuff is concerned and after you run your existing code through said converter, there will be as many little tweaks you would need to perform, as there was from 2D-->Plus.

From Mark's worklog:



Nice :)

It looks like Mark has settled, more or less, on the direction he's going with Bmax, so maybe we'll see some sample code snippets in the near future to see what we'll be up against. <crosses fingers>

Russell

yeh that would be so kwl

It would indeed! But Mark's been remarkably tight-lipped of BMax's progress lately (other than the occasional worklog entry), so I don't think we'll see any real code snippets any time soon :( ...But I could be wrong!

One thing that really caught my attention in the worklog, is that BMax seems to be a REAL object oriented language (for good or for bad) with functions within structures and everything! (woohoo!) I'm sure it will be quite a departure, programming-wise, from the current slew of basics out there...including Blitz(2D\3D\Plus).

Percent-wise, I wonder how close Mark is to releasing this baby\beast...

Russell

Uhh, there have allready been numerous code snippets straight from Mark himself. If not in the worklogs (altho I thought there was one or two), then I remember some in the newsletters (probably #1) and several of his posts in threads here (you'll never find those anymore;).


I can't possibly see how it could be anything other than bad. Sure, the odd newbie might horrendously crash theirs and other peoples systems here and there, but that is a minor issue compared to the good it will do for us professionals. Or I should say, -the- professionals =] Not me, obviously...

Did you mean "anything other than good"? I'm confused...

I'm wondering what he meant too..

Uhh, yeh. What he said =]

@Hotcakes: Yes, I've seen the little pieces of potential code Mark has shown in his worklog, but what I was really meaning was some real snippets: complete functions and\or mini-programs that give us a true sense of what the language is about. Let's see Insectoids, for example, done the BMax way... :)

As far as the OOP thing is concerned, when I said 'for good or bad' I meant that the benefits of object oriented programming, to some, is way overvalued and can quite quickly lead to bloated and inefficient code (even though the source may LOOK more organized). Two and three levels of indirect accessing can slow things down and add unnecessary bloat.

Russell

While it was in no way complete code, I remember seeing a full function to do with the OpenGL implementation in BMax. Was quite a long time ago and I'm not sure what the thread was actually about. But it's around somewhere here =]

I can't get into this too much, but here's a really simple example of stuff that's already been posted here...

-------------------------------------------------------------------------------
Object definition...
-------------------------------------------------------------------------------

Type Player

    Field x = GraphicsWidth () / 2
    Field y = GraphicsHeight () / 2

    Method Update ()
        If KeyDown (KEY_LEFT)  x = x - 1
        If KeyDown (KEY_RIGHT) x = x + 1
        If KeyDown (KEY_UP)    y = y - 1
        If KeyDown (KEY_DOWN)  y = y + 1
        Draw
    End Method

    Method Draw ()
        Rect x, y, 8, 8
    End Method

End Type

-------------------------------------------------------------------------------
Demo usage...
-------------------------------------------------------------------------------

Graphics 640, 480

p:Player = New Player

Repeat

    Cls
    p.Update ()
    Flip

Until KeyDown (KEY_ESCAPE)

(Note that ':' is what replaces the current '.' and '.' replaces the current '\'... slightly off-putting at first but you'll get used to it.)

For those not familiar, 'methods' are basically just functions specific to the type, and can operate directly on the type fields (hence x and y in the methods above refer to the x/y fields of the Player type).

In the above example, I create an object of type Player (p:Player) and call its Update method in the main loop. The x/y fields are initialised to the centre of the screen when the object is created (optional).

The Update method above also calls the Draw method, partly just to show an example of more than one method, and partly because doing it this way means you can create different object types based upon this one ('extending' the type) and just have to replace ('override') the Draw method to make the new type draw differently:

Type Rocket Extends Player
    Method Draw ()
        Oval x, y, 32, 32
    End Method
End Type

(So objects of type 'Rocket' have all the same fields and methods as 'Players' but the Draw method is changed.)

There's loads more to it, of course, and you can do some really powerful stuff, but I won't go any further since everything is subject to change.

Anyway, I've always hated OO because I feared it until now, but once you've done a little of this yourself, you'll probably find you want to keep doing things this way. Speed has not been an issue.

(And for anyone horrified by this stuff, you can of course just carry on much the same as you do now!)

p:Player = New Player

*sigh* :(

can't it be simpler?

Player p

or with a function perhaps?

p=AssignType(Player)



can I only do "p:Player = New Player" .. or can I also do p:Enemy = New Player ? If no.. then "Player p" should be enough imho..

You can of course wrap that sort of thing up into a nice easy function, as now...

if Enemy inherits from Player then you can do p:Player = New Enemy and it all makes sense. So yes, both parts are needed as the compiled can't just bet you're creating an object of the same type as what the variable is declared to point to (if that makes sense to you). The only thing that is guaranteed is that the object created on the right part of '=' must be of type Player, OR any derived type.

ok, then explain to me why I think that a cryptic language like c++ looks cleaner in this department :)

In c++ I do:

Player p;

p.X=0;
p.Y=0;
p.Update();
p.Draw();

and tadaa.. it works. I find this way cleaner than the whole type thing in Blitz. But then again, I never liked Blitz-types, prolly because of these reasons..

If I want to inherit things, then I guess the declaration needs to be more advanced than a simple "Player p;", but if not, then I'd wish for a simpler declaration!

No problem, I can explain. This is simply a "automaticmemory allocation" vs "dynamic memory allocation". In C++ you have both.

Here you are doing automatic memory allocation (the object is allocated on the stack if you're in a function, and "statically" allocated once for all if it's outside any function). If you prefer, here p is treated as a "value object", ie a bit like primitive types (int, float, string) but if you'd allocated it on the heap (that is, dynamically), it would be an whole different story.

No, that's not that. It would very well work if Player was a derived classe. BUT, if you'd wanted to have "Player p" point to an "Enemy", you couldn't do it that way, at all. you'd have to allocate id dynamically (which will permit to have virtual methods working. With automatic allocation, it just doesn't work). So all in all, NO, it's not simpler in C++ (more powerfull, but you have to pay this power) as you have to
understand the differences between automatic and dynamic allocation and all the subtil implications.

In Blitz (like in Java btw) you only have dynamic allocation which is probably a good thing for such a language IMHO.


That said, there could very well be some kind of shortcut, a bit like you get an integer variable when you don't specify '%'. I'm not suer this would be any clearer though, and you still have to provide some proposition of good syntax for such a shortcut.

This is used in Blitz to create a Player type pointer rather than creating an actual Player object...

Local p:Player

You can then use this pointer to iterate in a loop through all Player objects, for example. In current Blitz:

Local p.Player

For p = Each Player
    UpdatePlayer (p)
Next

Wow, looks great!

I sure hope the help file includes a user guide this time around :) We're gonna need it, me thinks!

Russell

yeah, looks awesome. I was really hoping for Object Oriented programming, and until now I thought Bmax didn't have this either.

Gimme gimme gimme! :D