Blitzmax WAS a good idea

*cheesy grin*

Well there is a topic discussing why blitzmax wasnt a good idea, so now we have a topic discussing why it IS a good idea.

I personally view blitzmax akin to php. They both offer a great amount of power without limitations getting in your way. They both offer a coding interface that is refreshing, fast and easy to program with. Slap this ontop of the ability to program once for X platforms, well, in my eyes this puts blitzmax far above the competition. Even without the official 3d module.

I havn't created any full games in blitzmax, mainly due to time constraints, but all the little spurts of programming I have done; I have enjoyed. The implimentation of OOP, alongside the blitz way of thinking is a perfect combination. Not too simple and not too complicated.

The whole methodology of blitz; as it has been for every product, is to give a wide spectrum of users the ability to do what they want. Blitzmax allows beginers to stick to old styles of blitz programming. Blitzmax allows intermediates to experiment with OOP and various other "new" techniques. Blitzmax allows advanced users to extend the language far beyond its roots. Dealing with external libraries, pointers and what ever api floats your boat.

In the early days of blitzmax I played around with a win32 module. It got quite far, but the important thing i got from this original experimentation, was that blitzmax is wide open. You can extend the language and wrap it all up nicely, allowing the blitz methodology to be present in your own modules. A universal convention. Many of the modules I have downloaded have stuck to this way of thinking. It is a good thing and manily thanks to what blitz research have spent many years trying to persaude us users to adopt.

Good job lads, now keep up the good work.

uhm, but all the positive aspects have been used as defence in the other topic already :P

hahahahaa... touche skn...

:)

--Mike

..now I see that my friend Hyoshi Kasuga was right.. :)

Heh, Didn't expect what was here to work :)

Yes it is. Shame I didn't get into it sooner. Shoulda listened to Indiepath...

Recently purchased BMax, I am impressed by it's 'stability' (granted this may be due to my utilisation of Grey's Game Framework) - the posts in the other forum about mouse pointer sticking etc - I have not experienced as yet.

I was a B3D user prior to jumping ship to BMax, the visuals you can achieve in B3D are impressive but have opted for the 2D development route in BMax for reliability / compatibility with lower specc'd systems.

I have a long way to go before I can fully appreciate the power of BMax - but my first impressions are all good ones.

I think the cursor problems are with the IDE rather than the actually language, if we are talking about the same thing...

Its easy in IDE 1.20F - open a new file, click anywhere in the tasklist, then move the mouse pointer back over the edit window. It's stuck on the standard arrow pointer, when it should be a text caret (vertical bar). It stays stuck until you restart the IDE.

Oh yeah. I haven't used the IDE for a couple of days since I upgraded (shock horror). Roll on 1.20G

Because I like it, and...


...Bah, forget it.

Hey, I never knew you could use Italics! Prey tell...

Go on Grey, guess what the tag is for italics. You'll be amazed! :P

@skn3[ac] I agree with your sentiment, especially:-

....is to give a wide spectrum of users the ability to do what they want. Blitzmax allows beginers to stick to old styles of blitz programming. Blitzmax allows intermediates to experiment with OOP and various other "new" techniques. Blitzmax allows advanced users to extend the language far beyond its roots. Dealing with external libraries, pointers and what ever api floats your boat.

Keep up the good work BResearch.

unless your boats floats on a 3d ocean... then you'll have to go outside the language to another 'engine'...

...or, write up your own OpenGL or DX engine.

--Mike

big10p no way! and I've been using *this* technique for ages.

lol, good one. or even below an ocean of course.

However, I agree with Blitzplotter on his statement that it works for lots of people at different levels.

BlitzMax needs to update the IDE. The tools sell the technology many times and really show off what it can do. I can't imagine how I would of done .NET development without the awesome IDE from MS. Similar needs to be done with BMax, and then all will be peachy. :)

I used Protean for BPlus and it was pretty good, but it was a bit slow at loading and adding new code structures when working with big projects.

Without BlitzMax I would pretty much be lost when I will emigrate to Linux - and it seems I will do so soon.

I used Protean for B3D and was very impressed, although not to sure of it's compatibility with BMax....

I think that there were two markets that brl could have been competing in in 2007

That of a SDK in the c++. c# or .net or whatever market, the SDK specificaly having been written round the "Improved" B3D DX9, with all the stuff that make it better than DX7
Or
As a full BASIC cross-platform Language, incorperating an Implementation of OOP, with a 3d engine designed specificaly for it

I think a greater market share could be maintained in the second case
If it had become a SDK, it would be competing directly with all these 3dEngines that everyone and his wife wants to wrap. And Dark Sdk.
You would need to pursuade someone that even tho they were programing in C++, they would need to learn this "Basic" structure to use it. You could argue that in making the SDK, a more oop nature would have been added to it, thus distingusihing it less from the rest of the market. And removing the "Blitz Basic" nature of it

In the second case, they will be presenting the market with, (as far as I Know), the only, or close to Only OOP BASIC. (Including a bells and wistles DX9 engine, or whatever)
It would be easy to get into (Honetly the major problem in moveing from B3D is remember its . and not \ ), for previous users of the product. (ie they wouldnt need to learn C++ or .net or whatever )
It would also stand out as the one to go for if you want a good game BASIC but that has to have OOP. (Which even though I dissagree with needing OOP, most people say Im wrong), thence putting BMax above any other selection in the BASIC market barring Microsoft VB itself

With A strong community and above all a strong user base, (Who will all "splash" the market with their BMax 3d Games, when max3d comes out), The Move to publish BMax wilst without a 3d engine could also prove to be a boon. And I think shows strong Longterm planning on the part of BRL. (Or Damb good Luck)

As an owner of B3D and BMax, I was very disappointed with BMax. It felt that to get few more features, we took a major step back by removing 3D portion of it.

Unless I own Linux or Mac or I want to develop for all three systems, I have no use for BMax, B3D does it just fine with it's 2D functionality. And Windows game development is at least 90% of any market. For the sake of the 10%, we removed 3D?

I perfectly understand the difficulties in developing an engine such as BMax. Mark has to know that this is not a put down on his coding skills.

But, after all is said and done, I have already published a game made in BMax. And for that, I am very grateful.

Personally, to me, BlitzMax is a good idea, it works, I like OOP, I like Blitz, perfect, though the mechanics surrounding it are, well, poor at least! *COUGH* IDE is, crap, in the nicest of terms! :)

Dabz

Everything about Max is great except the docs, the IDE could be improved a bit, and the overall slow progress on the 3D module/lack of updates.

Everything else is great.

Firstly, Mark could be working 70 hours a week on Max3D for all you know. Yeah its taking a long time, but big projects do.

Second, if you syncmods once a week you can almost guarantee something will have been updated.

Im aware of that.

And I appreciate all the works he's done.

Hmm, gayness!

when Blitzmax came out, I thought 3dblitz would die, so I told myself, alright, fine, let's move to the next step and I switched to c++.

yeah it was a good idea. for me.

As an owner of both Blitz3D and BlitzMAX, I stopped using Blitz3D the day I bought a Windows TabletPC Edition computer it didn't work on (still doesn't). It's okay tho' because BlitzMAX really is the second comming.

Before BMax I was one of the people who would harp on about how I loved the product but I wished it would have some OO features as that is what I am used to using.
Since BMax came out I'm happy.
Of course Im not trying to write a commercial app with it on the cutting edge to compete with DOOM or UnReal or whatever is in fashion these days.

The problem, if there is one, is that for the more advanced users they keep hitting limitations. Usually to do with graphics.. they want DX, they want OGL, support for the latest features in DX., shaders etc etc.. tis all gobbledy gook to me.

The thing is once you start adding all these advanced features the learning curve for a new programmer or even a programmer of another language gets soo big that its no easier to use than something like C++ or c# which have a much bigger userbase and lots more in terms of online tutorials, examples and ready built libraries to use.

Maybe these people really have outgrown the product... <shrug>.

Ive always thought Blitz Basic has been a great language for people learning how to program and people like me who love writing stuff as a hobby and just dont have the time to faff about remembering to include library x,y,z to get graphics and sound or networking just so I can write apps in the evenings knocking out simple games or seeing how hard coding a simple chat application is or just to try and implement something I read about the other day.

I'm happy with Bmax, I only use Linux, so I don't know much about how it works on other platforms, but it's realy nice to have a blitz compiler on Linux.

A little ironically, you would have been better off with Blitz3D for 2D work on lower specc'd systems =] Max's 2D uses 3D under the bonnet (hence the realtime scaling/rotating/alphablending etc). Blitz3D's 2D is pure 2D. Better still you could have gone BlitzPlus.

But, you know... oh well.

I like working with BlitzMax. Overall it's better than previous version of Blitz, but I've coded half a game in it now, and I have to say I still think the way Max implements lists totally sucks for doing anything even moderately complex with them.

The fact that the link pointers aren't constant when sorting or doing other operations is a pain, and the inability to loop through the links themselves rather than the objects the links point to, over a specific range of links, other than using while loops, is a complete headache and makes my code a mess and impossible to read.

Lists are currently the biggest black mark on the Max command set. The idea that we're not supposed to store link pointers and loop through the entire list every time we need to find a specific object is ludicrous. Such a scheme is suitable only in the simplest of situations with small lists. And why have the designed it this way? So you can use the same interface for binary trees as lists? Binary trees and lists are two totally different constructs. There is no good reason to try to wedge them into the same command structure.

sswift: In that case you might perhaps have some use for the data structures library I'm doing if you dislike BM lists that much :-)

(AVL Tree, linear linked list with stable node connections and WITHOUT the cyclic implementation of BM that creates a massive memory leak if clear is not called before dereferencing, HashTable as well as Heap, Queue and Stack are currently planned and partially implemented)

ooh whats that then? You don't just mean the sprite system do you? Also maybe it would be cool if BRL made a TList2 what allowed you have an index that was pointing at a certain entry and you could move it forwards or backwards or position it where you liked and it would update with insers/deletes. Delphi has this and it makes lists very usable.

have you tried PrevLink and NextLink?

oh yeah, but you there is no built in index that you can set and move around is there? Or do I need to investigate more?

well.. I'm not sure what you're after, but there's:
ValueAtIndex()
PrevLink()
NextLink()
InsertBeforLink()
InsertAfterLink()
++ much more..

Check the LinkedList source for more info..

"ooh whats that then? You don't just mean the sprite system do you?"

What do you think I wrote the sprite system for? :-) To sell? Ha! Not worth the time since my libs don't sell much.

Actually, like the Lego game, I've been hired to code a title for someone here. They'll be showing it off at an indie game developer conference in Seattle next week. It's not really secret, but until recently we didn't have any custom art for it, so there wasn't much worth showing off. Perhaps we can show you what's done so far next week or something.

Lars:
Thanks, but I am well aware of the commands that are available for lists.

But are you aware that if you create a link, and then store the pointer to it, that that pointer becomes invalid when you use SortList?

Sortlist doesn't shuffle the links, it creates whole new links. Why in the world it does that, I have no idea, since the HALF THE REASON for linked lists is that you can easily swap the positions of two links without reallocating the memory. But it does.

You might also be shocked to learn that InsertBeforeLink() and InsertAfterLink() perform the same trickery. Ie, if you have two balls in a list, and you want to swap their positions, and the balls have stored in their types, pointers to the links that point back to them (for speed reasons) then if you do that swap with those commands, you'll find your code is suddenly broken for no apparent reason, and you might suspect the insert commands don't work. But they do. The problem is they don't swap the links, they make new ones and put the object pointers into those in the new order.

Also, PrevLink() and NextLink() while useful, require the use of While loops to loop through the list, and that means a bunch of extra lines of code and setup over a simple For loop. It's the difference between just banging out the code fast for a for Loop, and spending a minute or to setting up your While Loop, possibly in the process making a dumb mistake and using a Repeat Until loop, which will crash if the list is empty.

I would LOVE to be able to do this:

For ThisLink = Ball1.Link To Ball2.Link

Or if you must:
For ThisLink = Ball1.Link To Ball2.Link In Ball.List

Or I'd even settle for:
Ball.List.SetRange(Ball1.Link, Ball2.Link)
For ThisLink = EachLinkIn Ball.List

But I'd truly be happy with the first one. It would make my code SO much cleaner.

@Sswift-

What's this about not storing links? I store links to quickly remove my objects from lists. Have I got the wrong end of the stick or has something changed in recent releases?



I know how you feel, Alex, but really a lot has been done behind the scenes with Max, and we have a far more powerful, expandable languahge with an optimising compiler. The trouble with the 3D end is that it will inevitably take a lot of time to put together - Mark's choice was release now or wait til the whole thing's done. A lot of us 2D nuts are glad he took option 1!

No Swift is the one with the wrong end of the stick. In fact he even has the wrong stick.

Nomen Luni:
Don't listen to Flameduck, he doesn't know what he's talking about.

This code demonstrates the problem with ReverseList(). The same problem exists with InsertBefore and InsertAfter, and Sort.

List:TList = CreateList()
Link1:TLink = List.AddLast(1)
Link2:TLink = List.AddLast(2)

List.Reverse()

Print Link1 = List.FirstLink()
Print Link1 = List.LastLink()

Print Link2 = List.FirstLink()
Print Link2 = List.LastLink()

Comment out the Reverse() line and run the code. You should get 1001, because the two link pointers we've saved are in the list. Now run it again with Reverse(), and you'll get 0000 because the pointers in the list now point to completely new links, and the ones we have pointers to have been orphaned and are no longer in the list.

Reverse() and SortList() do not move the links around. They create completely new lists from scratch.

InsertBefore and InsertAfter don't create whole new lists, but they do delete the affected links and create new ones.

(I would have simply printed the pointer values for the links, but I can't figure out how we're supposed to do that in Max.)

Haha the name is Flame for a reason!

Swift-
Ah ok it's the sort and swap functions you have an issue with. A minor irritation but I'm sure a man of your talents could write a good replacement. If only I could do the same to get proper C structs into Max...

Of course I could write a proper replacement, but that's not the point. It's better if the language comes with a proper list type that everyone uses. But as is, the list type in Max is worthless for most stuff.

Hell they didn't even get the compare method stuff right. You were originally supposed to sort lists by writing a new compare method, but then I found out that when you do that it messes up other list commands which you wouldn't think use it, but do. I think FindLink was one of those which is affected. It expects Compare to compare the link pointers, (or maybe it was object pointers) but obviously sorting a list by pointers is totally useless. So if you change the compare function so sort sorts by something sensible, like Order, then you screw up the other list commands. So what did they do? Instead of fixing the commands that shouldn't use Compare, they tacked a new compare function parameter onto the Sort function so you can pass a custom compare function to it. Allowing multiple compare functions is a good idea, granted, but it's still a kludge, and leaves buggy code in.

Amen to that sentiment.

sswift: OK thanks for the info about the game. Also that stuff about link pointers being recreated is worth knowing. I actually find Lists quite useful in my framework, I extended them and add extra functionality. They are fine if you know you need to loop through the whole thing. But it would be nice to have the For loop capability you mentioned...

I don't disagree, but at least you have that option
Spread the word, Gabriel.

I still don't understand why people use lists instead of
arrays. I just don't get it. It's been shown many times that
for any given application, arrays outperform lists in speed
and memory usage. All of the same functionality exists in
arrays.

So, tell me this, guys: What am I missing about lists that's
so great?

Quick+easy to add and remove stuff from lists, e.g: aliens, bullets,keys,diamonds.

@Drew.
An Array sort of destroys the little "Object" mind set that you get into with oop.
Imagine.
An Array ,(when all said an done,) Is this great big block of objects, all lumped together. Whenever you have to deal with one of the objects in the array, you have to deal with the whole array. (As a conceptual Idea)
A List on the other hand, is one Object followed by another object, (Or whatever), so when you have to deal with one object in the list, you just deal with one object in the list. (As a Conceptual Idea)

I (For example), have arrays of objects, if they are going to be a field in an other object. But am scitish about an array outside a type. (Even when Its the right way to do it).
However, please remember that I dont know what Im doing ;)

drew: PLUS you can extend lists to make your own add, draw, manage functions etc. very useful...

Array slicing makes it very easy to do it with arrays too.


I'm not sure what you mean with all of that, sorry. As far
as the programmer is concerned, array objects and list
objects are not significantly conceptually different.


A perk, yes. These functions are easily written for an
array, though. The downside is that it may not be as neatly
integrated as "list.draw". This is a tiny price to pay.

I'm still firmly convinced that all of you should stop using
these slow, memory-guzzling lists in favour of quick, simple and
powerful arrays!

Viva le Revolution! Who's with me?

[edit] And yes I agree with the OP. "Blitzmax WAS a good idea". Best language I've ever used, it is.

@drew
What I ment, was the reason that "Most" ppl here go one about list list, when as we know there is very little practicle difference, (in some of the uses).
I was sudjesting the difference was more a mental one in the way we think about lists and arrays. I think of a list as one "Object" after an other "Object, but an array as a "Big lump" of "Objects"
When I was told to try and think of an object as a discrete thing, I found it eayer to do that when I think of a list of them rather than a group of them, this led me to start to think I needed to use list. (Which I know we dont). And I was just passing on this observation

I've used arrays since day 0 (uh that would be about 1983) but I find lists more useful for OO despite the speed loss. If arrays could be extended from say TArray, I'd used them instead.

It may be easy, but slicing arrays up and restitching them to remove an element every loop (as you may have to in the example I gave) is a very slow way (at runtime) of handling things - you potentially have to copy a large portion of the array to a new position every loop - none of this overhead with lists.

Of course arrays are damn handy too for other stuff...

But in a situation were you are going to be doing it every loop (And you have chosen to use arrays rather than lists), you wouldnt bother resizing, you would just NULL that entry.
(ie, If you use arrays you optimize for arrays, if you use lists you optimize for lists)

But iterating through an array with a load of nulls in it is wasteful of memory and time.

Ahhh but Nomen, that just shows that I cannot optimize arrays or lists
(There will be a point, when the expected number of NULL is low, that it would be "easyer", just to go with arrays)
(But I dont think I would bother, if it was that simple a data structure, I would just "Flag" the cell as empty)

Exactly, but....


Also correct. So the solution is simple.

1. You have an array and entry 23 dies.
2. Swap the last item with that item
3. Slice down by 1 entry.
4. tada! You've deleted an entry without iterating through the whole thing.

Nice one! That's a pretty handy technique - you don't even need to slice the last entry off as long as you keep a count of how many live elements you have.

My next scenario [purely for the sake of argument at this point, you understand ; ) ]... some elements are added to the array - say however many elements you first envisaged as the maximum, plus 1... now what? Or say you have to maintain the order of your objects - the draw order is important for example, then what?

Lists have their uses I tell you!! I only hope Frank Taylor doesn't join the Fray - a big campaigner on the evils of lists.

People who only have hammers, tend to attack every problem as if it where a nail.

Deep
Is that a Daneish saying, or did you make it up? How about.

People who only use nails, think a screwdriver is stupid.

nar Yours is better.

Almost true. You see, I have used lists in the past to
write programs before. After I got the gist of them and
then found out about their processor and memory-hogging, I
decided that I wasn't getting a better deal. So I reverted.

Download my unfinished rpg from my website. Run the editor,
go to character placement mode, and drag the left mouse to
place characters (hold o for ultra-dense placement). Watch
as you're able to fill area with 2500 to 3000 animated,
AI-enabled sprites before the fps drop below 60. Now
consider that there are an average of 50 - 80 environment
items (trees, boulders, houses, etc), plus 200-500 snowflake
sprites rendering simultaneously. All of these items are
Z-sorted by an "array.sort" on every loop!

Any speed loss from using array.sort is still a lesser evil
than the speed AND memory loss of using lists. Period.

Blitz is great!

I think the speeds issues are that minor, they aren't worth thinking about. What if you want to expand you array? DOn't you need to copy all the contents to a temp array, expand, then copy back? I think that's the case in blitz3d.

Another point. You can store multiple different variable types in a type collection. Strings, floats, int... etc etc.

With an array, you can't really do this.

Don't get me wrong though. Arrays are great for some things :o)

Sounds like you are unfamiliar with array-slicing. This is
very powerful. Check it out.



I'm not sure what you're talking about. You can indeed have
an array of objects (or "types") - so you can have any data
you want.

C'mon guys, you're not doing a very good job convincing me!
Heh heh.

Ross C, I don't think the issue is with types but arrays vs lists. Also, with Bmax, increasing/decreasing arrays sizes is easy with slices. I've never thought to check array vs list speed. There were quite a few posts and not much real results. Maybe it's laziness as BRL have supplied functions for lists but arrays, imo, are a bit more 'fiddly'.
Anyway, my answer to the topic title is that Bmax is the best programming language that I have never accomplished anything with.
In fact that's not strictly true. I've used it for knocking up a quick GUI app at work but, at home, I keep messing with it rather than *doing* anything.
Still, for me, it's just for fun so I don't really care that much.