What have you got against BlitzMax?

Okay... so you've heard me complaining that a lot of people 'don't like Max', but I don't think they're giving valid reasons for the most part. This is the thread to raise all those issues. The idea is that we either show they're non-issues, or come up with a constructive solution if possible, which I add to the master list. Fight.....

Good idea

as for 1- i'm going to go into a bit more detail:

if you *really* must, Create one list. Use it. piece of piss.

Global ObjectList:Tlist=new Tlist.

Type OneOfYourTypes
     Function Create:OneOfyourTypes()
              local obj:OneOfYourTypes=new OneOfYourTypes
              Objectlist.Addlast(Obj)
              Return Obj
     End Function

     Method Delete()
            objectlist.remove(Obj)
     End Method
End type

I don't understand why it is an issue? since you're going to have a New/Create and a Delete anyway. it's *2* lines of code for every type!?

If you are complaining about this, you aren't thinking about it properly.

You could go one step further, and this isn't much of an effort at all, and place the "Global list" in the Type, and then it'll become a local list containing *only* the object type you want, thus possibly massively speeding up any itteration of that list.

As for not using OOP. If someone doesn't want to use OOP that is fine, you're holding yourself back IMHO, but you don't *have* to use it. I would just get your head out of the sand, dive in and do it. You wouldn't believe what a headache I gave Evak when I first started using OOP in Max, and now I can't live without it.

I have also found alot of my "problems" with max can be sorted by changing your coding technique- and I have found the changes to actually be a personal improvement.

Cygnus,

Okay... we're agreed on the OOP non-issue, unless someone can argue it off the 'non-issue' list.

I'm leaving the auto type lists on the issue list, because it is a bit more work to roll your own, and a few people have said they find it annoying. I agree it's not a massive amount of extra work, but I think the fact that it's a piece of repetitive code that you have to add again and again to different types is what causes the irritation for some.

BlitzMax is a fine language, and its OO-model is minimalist, but sufficient and easy to grasp. I really don't understand why so many folks here have a problem with OOP - once you've understood the concept, coding OO-style is so much easier and your code has much better maintainability than its functional/procedural counterparts.

BlitzMax' biggest problems are the lack of a roadmap and communication from BRL, its suboptimal documentation and that is is positioned as a language for creating 2D computer games ONLY, while it is an excellent multi-purpose language when you give it the chance.

Its other problems are a lack of certain key features that a modern language should have, and I've mentioned them already a million times: A thread class. A 64-bit compiler. A mature and enhanced GUI class library. A mature database layer. Through documentation. An IDE and a GUI Builder would be nice, but are not anywhere near as important as the other features.

BRL should raise Venture Capital and hire people to do it. With the right marketing behind it, this baby would sell better than sliced bread, especially in the Mac market, where you only have the choice between Objective-C, Objective-C and Objective-C. (Realbasic sucks, and all those Cocoa-bridges are not very attractive.)

But since BRL is more interested in developing another 3D engine, this will never happen, and BlitzMax won't have a real future. It just drives me nuts to see that the creator of the language obviously does not see the full potential of its creation. I don't mind if Mark spends the rest of his life writing game development tools. If that makes him happy, that's fine and I wish him all the best luck and success.

But he should hire more staff who take care of the features that he is not interested in, but are nevertheless in demand by his customers.

If the price of BlitzMax (for OS X) goes up to 500 or 1000 USD - I DON'T CARE and would buy it anyway if it would give me those features. And if BRL choses to sell it on a subscription model, I'd also buy it to get my updates.

As it is now, I cannot with confidence start a project with BlitzMax that I have to maintain for five to ten years or longer, but must fall back to alternatives that I do not like half as much as BlitzMax.

That little language was love at first sight and yes, I know that I am nuts. But so are you guys, too - otherwise you wouldn't be here. ;-)

BlitzMax isn't cute like Blitz3D.

It doesn't have built-in 3D.

Until the day I die, Blitz3D 2 was the path that BRL should have taken.

One word: Documentation.

Perceived learning curve & understanding of BlitzMax are probably more of a reason why people haven't moved over.

I dont' want to be too critic or offensive, only my opinions.

- A thread class: could be interesting (and I think it will more important in future)

- A 64-bit compiler: considering that - at the moment - the main market is Windows and it is still based on a 32 architecture there is very small chances. MacOS and Linux, Windows64 and Vista64 are a minority. Drivers are not mature. Only if Windows7 is 64bit (completely) the situation could change.
Of course on MacOS and Linux a 64-bit compiler - now - could be a good thing. But at this point is something that only BRL can evaluate: how many Mac/Linux only user on the total?

- A mature and enhanced GUI class library: well, MaxGUI is easy (and it's not OO to be honest...) and quite powerful. It has not ALL the things but it works well. Or you can get wxMax by Brucey

- A mature database layer: see Brucey works...and if I remember there is a Vertex's mod for MySQL only somewhere.

- Through documentation: ...

- An IDE : there are plenty of free and no free solution. MaxIDECE is the one I prefer - you can get the source and change for your needs.

- GUI Builder would be nice: I'm sure there are some free gui editor around.

I agree that an 'all-in-one' solution for GUI+GUI builder is BETTER than the only module.

PS: 'Code to generate a type list causes bloat'. Thanks God BlitzMax allows the user to create an object and put where the user wants! I have never understood why Blitz3d has this absurd concept TYPE->ONE_LIST.

PS2: and what about things that BlitzMax can do (or can do easy) and in Blitz3d are impossibile or not so easy? One example: Arrays....

Okay... now we're cooking.

Winni- Some good ideas there, and although you have pointed to a lot of features that are lacking in Max, they're mostly not valid reasons for B3Ders
not to make the switch, because they're thing B3D doesn't have, either. Maybe I should have made clear I was aiming this at that crowd. I think I'll stick some of your points in a 3rd list. I, too would be willing to pay good money for some of those features, but if Mark raised the price to those levels, he would lose a lot of support.

Puki- Lack of built in 3D. Fair point, but it's a work in progress, so not a lot you can do about that. What state is miniB3D in at the moment? Why don't you like it?

Winni/Mark- Documentation. Definitely. Added it to the list. Mark you mention the perceived learning curve of Max. I hin you may be right if I have read correctly that you think it has a lot to do with the documentation.

@Degac

Good idea. I'll stick in a 'better in Max' section if anyone has ideas what to put there.

The IDE (on ALL platforms) is the only thing that I beg Mark to overhaul. It is atrocious, especially on Linux.

That said, BlitzMax is amazing. The fact that I can make a huge game and it be playable on FOUR different platforms (Windows, Linux, MacOS-PPC, MacOS-Intel) with minimal effort is incredible. Basilisk Games would not exists with it.

I've said it a dozen times before: Thank you Mark & Crew for your efforts!

degac, my point is that all these things should come from the language vendor, not from the community, and they should be commercially supported - with a roadmap.

I also have a hunch that there might be more Mac/Linux users for BlitzMax than Windows users or at least that users of those systems are much more interested in it that the Windows folks, who are more likely to stay with Blitz 3D anyway and use Visual Basic.NET or C#.NET for application development. BlitzMax' only real competetion on OS X and GNU/Linux is Realbasic, and that is its opportunity. On Windows, its position is entirely different.

John Galt, ok, if this is for Blitz 3D users, then forget what I've said. They're probably only interested in game technologies, and that is where there is a huge difference between them and many BlitzMax users.

I agree that the IDE needs a major overhaul. I'd be using something different by now if I could find something for Mac OS. I have been using the CE (the only one for Mac OS), which is better than the built-in one... but I'd love to see an overhaul.

Oh, and I love BlitzMax for 2D!

IDE and Documentation.

I feel that there are too many ways of doing things in BlitzMax so you hav tothink about how to do somethign rather than what it is you want to do.

When BMax3D comes out and if mark reworks the documentation to something like b3d's then I will definatly use it (I have already bought it)

Basically, I've always stated the IDE stinks to the high heaven, BlitzMax language wise IS the best Blitz yet, but its all wrapped up horribly and does the language no justice at all!

I hate the IDE, it does the job to get started, but as soon as a program gets to a decent size, you realise its not up too the job... At all!

Thankfully, Matt Smiths IDE (Project Studio) saved the day for me... I'd probably have moved if it wasnt for that.

I think the language is great, I dont really have any issues with blitzmax

Lets create a community project to create high-quality documentation then.

Winni- you made many valid points, mate, and this thread is a free-for-all. I have made a 3rd category and stuck some of your stuff in there.

Okay- I'm hearing from the masses that the IDE is more of an issue than maybe I thought. I agree this shouldn't be left to 3rd party solutions, so I'm escalating it to the full blown issues section. Talking of the IDE, what the current state of the debugger when you use 'Debugstop()'? I have found it unusable in the past (random crashes). Has it improved?

Oh... I'm adding lack of C style structs. One of my personal bugbears.

Ok, sorry maybe I misunderstood. (expandibility in this case is similar between Blitz3d (.decls file + .dll) and BlitzMax (mod+everything) - with the same risks per both the products - ie: the extern-vendor closes...)

PS: Please dont' say that the Max IDE is ugly...maybe Mark reading these comments gets back to his old idea to create a new-ide....and I think this is not the great idea!
And more:
- the standard IDE for Blitz3d supports only 1 LEVEL UNDO...
- in blitzmax you can returns arrays, in Blitz3d you need to use types or use global array.

Eh?

But it is... its, in laymens terms, cackier than a fudged up bottom!

This thread was about letting it go what bothers people about BlitzMax, luckily, its not the language that narks the majority of people.

That in itself is a good thing.

I dont get it either:


1. Which not only makes it more powerful, but code can also be unbloated with things like methods etc.
2. Totally agree
3. s mark said recently, Max3D is underway in the form of a completely spanking new "B3D-like" engine lib.
4. Agreed(was b3d's much better?), but for windows theres loads of alternatives.


1 Dont invoke it then. Just use it as you would blitz3d.
2. Lol (someone actually said that??) you could always rename the exe & change the logo!.


Dont forget:
More futureproof, faster, Line splitting, Optional Stricts & easy interface with c/c++


Great idea. But it needs to ba able to be added to the ide (for those who dont like using a browser and love f1f1)

Re: various comments about the IDE....

They're somewhat true, although the IDE does provide the basic functionality is just about usable. But it would be better if an improved version were available from BRL.

But please, please, please BRL, do NOT spend your time on the IDE. It is not your forte. IMHO, the ideal would be that the CE IDE should become the primary "official" IDE, with mark taking basic veto rights on changes / direction. I can understand completely why this might not be desirable from a support perspective, however I strongly believe that BRL could adopt a position whereby a *REALLY* basic IDE (i.e. even less than the current version, basically just highlight, compile & help) gets shipped with the product, but the CE IDE gets promoted as an optional extra download subject to community support and basic BRL support.

That might sound a rather selfish thing to say from my perspective, but I honestly believe it to be a viable way forward.

@Dabhand...if you read all my sentence and what Mark Tiffany wrote (But please, please, please BRL, do NOT spend your time on the IDE...) you can have an idea of what I mean :)
Unfortunately my english is not so good to express the ironic sence of my sentence (of course I know what is basic IDE - and under Linux...but there are other solutions to 'this problem'. So basically I prefer to not consider the IDE a problem at all.)

Project Studio Pro would make a damn fine 'standard IDE' for Blitzmax.

Anybody who would complain about getting that with Blitzmax, would be complaining for the sake of complaining about something.

I'm in agreement that the IDE shouldn't be a priority for Mark S. There are more pressing issues. Either some official support for the CE IDE or the inclusion of Project Studio Pro would be fine, quickfire solutions to this problem, IMO. [Edit] Actually, isn't project studio Windows only?

Dan- Some good plus points from Max there which I have put in the list. As for the extra ease of interfacing with C or C++, is it any easier? I have found it a pain in the RRRR.

Haha well kind of... I was taking a bit of artistic license with some of Puki's comments <extracting the urine>

Precisely the problem: while I'm quite sure Project Studio and others are very nice IDEs, I don't believe there are ANY cross-platform IDEs out there other than CE IDE or the official one. And the official one for BlitzMax has to be cross-platform.

I also think there are plenty of other benefits to the "official" IDE being open to a select group of the BlitzMax community (i.e. like the CE IDE is).

I completely agree. As I was saying, I would be using Project Studio by now if it was cross-platform. But, is someone going to continue to be on top of the Mac version, as I at least don't have MaxGUI to compile myself...

My major annoyance with BMax, apart from the docs and IDE like many others have already mentioned, is the fact the some commands do not highlight correctly in the IDE. Why does TSound highlight properly yet TImage does not? To me the inconsistency is really irritating and should be addressed.

Jason.

So, what we are saying, is that to make an IDE cross platform, it has to resemble an app on Windows 95!

Wahey for X-Platform solutions!

No, it just has to be seriously developed (either by Mark S. (which may not be such a good idea - he has better things to do) or the community.) I seriously dislike the IDE in it's current state, and am even having the current problem of when loading in a code file, everything from the first commented line down gets highlighted gray!

maybe most people did not understand the reason for developing a new language while you can simply use a consolidated commercial one

Being only halfway there is the sole reason I didn't buy Max. The promise of an in-house 3D module/engine kept me interested, but even my patience wore through the floor. I'm not convinced we'll be seeing something other than another 'glimpse' at Christmas either. But I am convinced we'll get something excellent eventually.

Overall I guess it`s just lots of little niggles that people have that could probably be tidied up quite quickly if they were given the attention that they deserve. As said already, the language itself is excellent.

Still, things like a decent official IDE (the part that the user uses the most after all) would be welcomed by most in this community.

Jason.

Presumably you own at least one of the Blitz family, so you saw a reason for using it rather than say C or Java? For me it's the simplicity and ease of use.

What does this mean?

I like BlitzMax a lot. The documentation isn't bad. If you need a new feature you can usually just import a third-party library. I do not understand why people complain about the GUI module: It is the best GUI library I have ever seen. It's brilliant, especially compared to the other choices you have like wxWidgets, which are bloated and hard to work with.

I have two problems with BlitzMax that are sort of related. At first I was hoping BMX would catch on as a viable alternative to C++, but BRL's lack of any marketing strategy ensures that won't happen. It's really a great language, but it gets sold as a "2D Game Maker" instead of the cross-platform open-ended wonder it is. BRL should offer it to schools for free. That would cost nothing, and build legitamacy. There is so much they could be doing to make BlitzMax an established language, but that won't ever happen because Mark doesn't trust business people ever since George Bray screwed him over. Why do you think I have built a relationship with TGC? BRL doesn't have any connections to NVidia or Microsoft. I am not going to get on microsoft.com by working with BRL on anything, not that they would even respond to my emails.

The second problem is it does not appear there is any plan for significant future development, and the latest news on Blitz3D 2 confirms this. I am not slagging BRL. I hope I am wrong. But if I had to put money on an educated guess of what the future holds, I would say there will be no multithreading support one year from now, and the IDE will be about the same as it is now.

If BRL had a plan to eventually add multithreading and had some ads on the internet somewhere, I would feel good about using BlitzMax. But the current situation makes it look like it will always be an unknown, and I get tired of people giving me a blank stare when I say I use BlitzMax. They usually think I am talking about Dark Basic when I say that. I was offered a position teaching a computer games course, and they told me they were not happy with their tools, and wanted something easier to try to get students into it without scaring them away with too much C++ maths. I didn't take the job, but I recommended they try Blitz3D, and they liked the idea. I was actually offered a job working on the Windows version of Unity3D (I've been to their office in Denmark). I tried to convince them to do the editor in BlitzMax, because then it would work on Mac and Windows with no changes, but they were scared to do that. I get tired of advocating solutions I know are better, but are completely unknown. It's like you can't help someone who doesn't want to help themselves.

So right now I am thinking we will probably make the switch to C++, once the engine is finalized. This is not a move I want to make, and it is going to hurt productivity, especially when I am implementing new things, but right now I don't see BlitzMax ever expanding beyond this website. I wish I was wrong, but everything I have seen indicates to me that BlitzMax is a dead end.

Both fair points, Josh, which I will be add to the list.

Thing's I would like to have seen..

1. 3D - I know there are some amazing looking engines out there, leadwerks for example looks stunning. HOWEVER, I want standardization from Max, so I want a 3D Solution from Mark. Iv gotten so used to doing things his way that looking at other peoples idea's is annoying, no offence guys.

2. See above, but replace 3D with physics. I know AGAIN there are solutions out there. but, again read above.

3. Fix the audio. why were being forced to use openAl or *insert audio driver* is very annoying. I paid for blitz, I dont want to have to pay for anything else to finish my projects.(thats just me tho, those of you in better paid jobs wont have this complaint)

Documentation is better I would say, or more presentable in Max, but still needs a lot more detail added to it. When a programmer needs to actually open and read the core Max files to understand what a function is doing or is supposed to do then you know your docs are crap.

Support for creating Max Dll's dont know if this was done by some one already I know I read something about it, but it should be built in.

Threading

Ability in the IDE to set the Icon for the exe.

Project Managment.

Thats all for now.

Going on what Josh said I've always wondered why BRL never advertise or sell their software a high prices.

Take other 3D Engines and Programming Languages (Torque, Real Basic etc.) which have different pricing models for indies and commercial developers. These, even though priced high still sell like hot cakes.

I'm wondering if the price of BlitzMax, Max-GUI etc. puts people off by making them think this is something cheap and a toy like. I'm just thinking that if BlitzMax were priced at $150 or more for indies and a seperate license and price for non indies then it may attract a lot more people.

Sometimes selling for cheap backfires and I consider $80 for BlitzMax on the very Cheap side. But then that's just me. I paid $500 for TV3D and would gladly pay $500 for Max3D if it was any good.

Josh might be right about MaxGUI. It is a nice library, but it has bugs that don't get fixed and if you need more advanced gadgets, e.g. for data browsing, it just does not have them. I'd also prefer a more object-oriented approach to it, and that's where I probably disagree with Josh. At least when I read wxPython code, I don't think it's bloated, I just think that they are doing it right. I had a similar impression of QT Jambi, by the way, but the Trolltech guys have insane ideas about their prices.

I don't see C++ as an alternative, but that's because I do not write 3D and physics engines.

For me, Python will most likely be the option unless Mark publishes a statement about the future of BlitzMax that is reassuring.

What does this mean?

C# ,JavaScript, Phyton, LUA.......

What do you mean by consolidated? And isn't Bmax commercial?

I would like to see a complete IDE overhaul and a complete docs overhaul (the docs need decent examples for every command like the Blitz3d ones).

There are loads of places where the docs is just a header and nothing else, sometimes its a basic description. Each entry needs: Command and arguments, return values, explanation, and finally example.

Its not beginner friendly, please dont say it is, the docs are sporadic and the OOP aspect still feels alien in Basic to me.

I program for pleasure, I have Max, I bought it and B3D, its not patch on Blitz3D for easy of use... I want OOP I use C++, its faster and more intuitive for me.

I was sooooo disappointed with BlitzMax when it came out, it was not B3D2, obviously, I wish it was... I left this community for a couple of years looking for an alternative to Blitz3D restrictive GFX engine.

As I said, I did buy BlitzMax though, more as a gesture towards Mark and the fun I had from B3D, its never really been used though...

It may not be beginner friendly but have you poked your head in the tutorials forum? Spend a day in there and you're good to go.

Personally, I love Max. Sure the docs need work, and sure every time I use the official IDE on a Mac I feel as though a) I have been stabbed in the eyes, and b) I have been stabbed in the hands, but the language itself it awesome. So thanks, Mark. Here's to the future. :)

What do you mean by consolidated? And isn't Bmax commercial?

How many people are using C#, JavScript or Phyton, regardless of game application and how many Bmax ?
Dont you agree that it is better to use a software with a vast audience of end users ?
Unless Bmax provide some advantages over the above languages for game programming I dont see any reason for using it

I don't really see how more choice is a BAD thing when it comes to programming -- but to each his own.

I was asking what you meant by the word consolidated.

And no I don't really agree.

To directly answer the thread topic, I have nothing against BMax... I think it is very accomplished. In conjunction with Grey Aliens' framework it can make you realise your programming dreams.

I would never have achieved a software product as a freelancer/indie that has been sanctioned by becta otherwise. BRL has provided a product that enables people that are otherwise engaged (with that awkward full time employment thing) to realise their dreams of creating something in software for the masses.

I actually think Mark's announcement will strengthen Blitzmax - albeit indirectly. If completed it will make Blitzmax a much more attractive 3d solution - which is really its main deficit as far as a gaming language goes.

The GUI issue I think is in the process of being solved by wxMax.

And I have a strong feeling that an excellent cross platform IDE for Max will emerge sometime this year. Call it intuition...

But hey - I'm all aboard when it comes to the documentation and lack of roadmap. Difficult to excuse those faults, really.

I have tried B3D before i bought Bmax. There were several things, but OOP and the way arrays can be handled in recursive functions were the final point (at that time). When you look for more advantages then array slicing, tmaps and the new reflection makes things easier to program.
Bmax is really a great language and i use it also for a lot of applications, not only games. MaxGui does the job quite good and is still pretty easy and small. The lack of the missing Gui Builder i have solved myself as there was nothing else around and i needed something definitely.
The mentioned multiple lists per type are absolute positive, can't really understand what's the problem here. The documentation and ide could really be better though.

What would be nice to have:
a thread type/class
dynamic types
don't know if a roadmap will help if it changes all the time, but better communication would help definitely

i'm a b3d-er and i liked b3d's demo as it was not timelimited. if bmax's demo was the same i would most likely have chosen it instead and used minib3d. but i can't get used to the language in the amount of time provided in in the demo.

I was a b3der 1st, stumbled upon limitations due to my lack of time to address issues as an indy, resorted to BMax demo, tried Grey Aliens framework in tandem with BMax which resolved my time issues, that is what sold me on a full version of BMax.

Counters

The CE IDE is just as bad, so I don't see how it'd help.

This is a non-issue, as it does not affect our work, only BRL's sales. If you can come up with an example of this affecting your work without it being a pointless "but if they don't market it, they won't get money to improve the product I'm already using, and if the product I'm already using doesn't improve, I won't be able to finish my work" argument, then you may have something. Haven't seen anything of the sort lately, so I'm doubtful any good reason exists for this affecting anyone's work.

This is an issue with you not knowing what you want and doing it. If anything, this is caused by a lack of planning and knowledge on your part. Your inability to do something is only your fault, not BMax's. Don't blame the tool, lest you become one yourself.

I've read this in different forms from different people over time. I've probably said it myself numerous times, and I can't help but look at all the cries for standards now and think it's just stupid. This is programming, standards are very far from standard, they change very frequently and you just get to pick a standard to implement. Standardization won't benefit you at all in programming today.

The other option here is that rather than standardization, you just want BRL to do all the work. The nice thing about BRL doing all the work is that 1) if something goes wrong, you can sometimes blame them (rarely, since it's usually your terrible code's fault) and 2) you don't have to actually look for a solution, it's being sold right here.

I think this originates from the fact that most programmers here have little skill and are still learning how to tie their own shoes (so to speak), and so they simply don't know what they need, much less where they should find it. My solution to this? Yeah, go ahead, let BRL sell solutions. Stop acting like it's a problem with BMax though, this is a problem with you.

You don't have to use OOP features, so stop complaining. Nobody is telling you what you have to do, the language is very open.

You don't have to pay to use OpenAL. There is the opportunity to pay for more advanced solutions, but you are not required to as OpenAL is sufficient for most tasks.

Issues

In no particular order.

1] As mentioned, documentation. However, my issues more stem from the fact that bcc's arguments aren't documented. This is really annoying, since I would like to use scons for building my projects, but working out how to use bcc has been too annoying for me to bother.

2] Import does not handle files that are dependent on each other. E.g., console.bmx depends on script.bmx and script.bmx depends on console.bmx (arbitrary names, don't place too much meaning on them). This has actually caused me a good headache, and as such I've just ended up switching to include. Sure, it pretty much requires a complete rebuild for any change, but it solves the problem.

3] Circular references aren't handled by the garbage collector. This isn't a huge issue, provided you program safely, but there are a good deal of people here who don't know how to do that and it's not an issue that's fixed by programming safely, only more likely to be avoided. In the end, it can still come up.

4] Not all data types are objects. I would really like to see the primitive types as objects, not just strings and classes. This, however, is not a big issue and should not be seen as one, it just requires that we use have a work-around when dealing with lists of numbers and such. It's just a design feature I would have liked to see, and does not impact us much.

5] Method callbacks. Just a nice thing to have, can be worked around easily.

6] The debugger really needs work. The default and community IDEs are nigh-useless in helping this, and working with it in a console is only slightly less difficult. I think something that would really help is a completely separate program that gets launched when debugging. This program will attach itself to the process and handle the debugging from then-on. This could probably be done now as an interface to the console debugger. However, I'm used to the Visual Studio 2005/2008 debugger, so I may be spoiled.

The Zen of Python
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Many Pythonistas actually believe that choice can be a bad thing, and they only need to point at the billion Java frameworks of very different quality, but all written to serve the same purpose, to underline their argument.

As for Noel's statement about many programmers --here-- having little skill: You would be really surprised how little skill you will find out there in the "real world" of "professional" programming. Around 4 million Java developers expect their IDE to do all the coding for them, because they are actually incapable of coding anything themselves, and they would certainly be completely lost without Eclipse or Netbeans.

But they are in good company - the typical C# and Visual Basic developers are no different, and probably most C++ application developers are also in that boat. The COBOL guys might still know what they're doing, but that is because mainframes don't have IDEs. (No, ISPF is not an IDE.)

And for all the things that are not bundled with their IDE of choice, "professional developers" just buy additional libraries and click their app together. Or does anybody actually believe that all those well paid Java programmers really read and fully understand all that horrible code that Netbeans' GUI builder creates for them? Visual Studio is not any better.

Which leads to the theory that IDEs make developers dumber; even Charles "Programming Windows" Petzold believes this:

http://charlespetzold.com/etc/DoesVisualStudioRotTheMind.html

So you might be better off NOT asking for a better IDE. MaxIDE does the job quite well. Only the documentation sucks.

All I’m missing is a suitable cross-platform 3d module. The other ‘failings’ I can work around. The BlitzMax language, while not perfect, is simple, powerful and flexible. I’m highly productive in it, more-so than with any of the other dozen languages I’ve used in the past 25 years. This is, of course, regarding games programming. I'd possibly choose another tool for a different type of application.

> Which leads to the theory that IDEs make developers dumber;

I saw plenty of dumb ones before the modern IDE. Modern IDEs do make us lazy, er more productive - but since the largest expense in a computer program being the time taken to write it, well a productive IDE is a money saver.

The problem is that BlitzMax exists in a world completely cut off from mainstream programming. It's been around for a while, but there are still no books on programming with BlitzMax, popular libraries don't offer BlitzMax modules on their sites, and none of this will ever happen. So it's a developmental dead end, and will never be taken seriously or even noticed, even though BMX and its associated libraries are far better than a lot of other languages out there.

I hate this disgusting self-love that Python users have. Language choice does not make you better than someone else.

I would like to know how this affects you. All you've done is made a case for how it affects BRL.

I would like to second Noel's points 3 and 6. The GC handling circular references would indeed be nice, and put my mind at rest. (Yes, I'm a poor coder.) The debugger seems to crash with infuriating regularity after your app reaches a certain size. I reached that point half way through development of my game and now 3 out of 4 times that I use DebugStop the bugger will simply dump my entire list of globals. So I have to resort to debuglog rather than debugstop which is a pain.

I agree with all of Noel's points, though mainly #3 and #6 because these are the only areas where BlitzMax is actually inferior to Blitz3D. A garbage collector that fails to collect circular reference is practically useless: memory leaks in a garbage collector should be an oxymoronic statement, but not with BlitzMax. Garbage collection must be transparently functional, otherwise it only adds way more complexity and problems than it's supposed to be solving.


I agree. Working with an obscure product is no fun, for the reasons you mention. If anyone doubts this, compare the example / documentation / support base of C# or Java vs. BlitzMax. I'm not saying that I expect BlitzMax to reach the status of C#/Java/C++, but it could do a whole lot better in terms of marketing.

another downside of that is the perception that it's just a "toy language" in the minds of others, since they've never heard of it.

The toy language and never having heard of it is a problem when your approaching possible clients for contract work. They may only want windows and possibly mac but some obscure unknown language doesn't exactly inspire confidence in your team and its ability to perform the work, even when you have samples to show. Many would rather you used flash and papervision 3D just because they have heard if it.

Normaly we just say we are using Ogre and C++ for our low level coding, interfaced with a high level Basic/C hybrid language for framework and scripting gameplay.

I was asking what you meant by the word consolidated.

Maybe I did not use the right english word , for "consolidated" I mean
" well established"
Dont you agree taht JavaScript is more " well established"
than Bmax ? or what ?

Not really. Perhaps you're confusing JavaScript with Java?

about docs:
I bought Blitz3d when it was vers 1.68 (I believe - I don't remember...) so some time passed from its first public version 1.00 (how much years?). The question are - as I have no evidences - How good was the docs for the earlier Blitz3d version? How many years to get the actual 'final' version?
We need to put on the same time-scale both Blitz3d and BlitzMax to this aspect.
This is not a excuse of course, because some commands could be more documentated.

@alberto:

Java, Javascript, PHP, Pyton and C/C++ have a little - slightly - difference with BlitzMax/Blitz3d: in general you don't need to pay something for using it. They are 'well estabilished' because they became standard (ie: Javascript on the browsers) and because the are cost-less compared to Bmax. You can only compare Blitz3d/BlitzMax to Darkbasic/RealBasic and other paid language.

"Perhaps you're confusing JavaScript with Java? "

What ? Java is mumber 1 but JavaScript is number 4 or 5 as far as number of users is concerned

"You can only compare Blitz3d/BlitzMax to Darkbasic/RealBasic and other paid language. "

This is exactly " what I have got against Bmax"
DarkBasic or Torque or Lite_c or..., make sense , being integrated with the relevant engine consequently they offer some additional advantages vs other multi purpose programming languages
But what the reason for using Bmax with for example TrueVision3d ?
If I use C#, for example, I can relay upon a " well established " OO programing lamguage supported by a great company

Well... thats what this is all about isnt it. BMax has no native engine (yet). As for the rest of the post i've got no idea what you are trying to say.

The fact that people CAN use other engines with bmax is great & once the native one is released most people would be using that so i dont see why the fact you can use other engines is an issue :/

I'm back. We're really cooking with gas now, boys.

There have been quite a few posts, so please holler if you think I haven't addressed any points raised.

Okay, we all know the Blump doesn't pull any punches, and no offence to the guys who have put a lot of effort in, but in reality I have to agree the CE IDE is not brilliant when I think about it. I say this from the standpoint of someone who has only booted it up a couple of times, so I'm sure there are a lot of behind-the-scenes improvements I'm unaware of. Still, it's not an ideal solution, but it's all I can think of at the moment.

Promotion/Advertising: I still think this is an issue, because as Josh mentions, popular libraries don't offer bindings. So I'm going to add the specific issue of 'support from 3rd party libraries'.

Audio: Keep arguing about this one. I'm not sure whether it needs to go on the list, but I don't know anything about the issue.

'Import does not handle cross dependencies','Garbage collector doesn't handle circular refs', 'Lack of method callbacks' : These will all go on the list.

Que?

I'm not going to add the 'all data types aren't objects' because I think it would impact the speed of the code generated. I'm open to attempts to convince me otherwise.

Debugger: Yeah I'm not expecting VC standards of debugging, but what we have is poor and bust IMO.

Dynamic types: What do you mean by this, jsp? Sounds like something that could slow the language down?

Mr Ian Thompson, come on down.

I want to address your post specifically, because this is the type of 'I don't like Max but I can't explain why' statement I want to understand.

A fine statement, but pointless unless you justify it by highlighting the problems.

This is on the list and I agree totally.
So what? You don't have to use it, so what's the problem. I wrote a (nearly) complete game before I realised OOP was even an option.

Yes.. but why? So far you only mention the docs.

So use BlitzMax without OOP. How is Max, which is identical in Syntax with B3D, so much less intuitive? (Docs aside)

See point 2 on my 'non-issues' list.

"The fact that people CAN use other engines with bmax is great & once the native one is released most people would be using that so i dont see why the fact you can use other engines is an issue :/ "

It is not an issue , it is of no use.
The point is that the " native one " was the top priority at the time rather than a new programming language
If the " native one " is coming it is welcome but let me say it is a
" late arrival "

Funny. That is exactly how I feel about most C++ coders. Still, it is probably the weakest and most disqualifying argument you can give in a discussion.




1. What Alan Kay said.
2. OOP and speed in one sentence is a contradiction in itself.
3. When the overly complex and complicated language C++ is more intuitive to you than the simple and minimalist BlitzMax, then you cannot have seriously looked at BlitzMax in the first place.

@Alberto-
I hear where you're coming from, and you're not the only one who has been waiting a long time for a new 3D solution from BRL, but hacking something into the existing B3D would have been tantamount to building a house on the proverbial sand. Max has taken a while; it's had some teething troubles, but it is a solid foundation.

Nothing to add. It was worth repeating.

John Galt :

Did you see my post about the TImage and others not highlighting properly in the IDE? Why does TSound highlight and not TImage? In fact there are a few more keywords that do not highlight which I find very inconsistent. Hopefully this could be addressed.

Jason.

Sorry QuickSilva. I do read them all but sometimes I forget to add bits to the list. I'll add your points.

Quote from Winnie:-



Section of Marks worklog:-



Which means Mark hasnt seriously looked at BlitzMax too! :P

.

Dabs ya monkey....

I think you're being a bit purposely controversial here, but I reckon most people are agreed that C (or ++) is easier to use than Blitz when talking to the OS and misc APIs, primarily because most of them were probably written in C and it's a better supported language.

For general coding, Blitz is easier any day.

So what's the solution to improve Max's interface with externs? I have 'addition of C type structs on the list'. Is there anything else that would be required?

Talking of highlighting, code::Blocks has a place where you can make a list of your own keywords & stuff you want to highlight. Anyone working on an ide should consider this as a handy addition.


erm... he means for the actual engine itself!
Would anyone seriously consider writing a (fast) 3D engine in anything else than a middle-low level language? (B3D's sure as hell wasn't written in "b3d".)

Well, its of use to me. Im using it with irrlicht until native 3d comes along.

Then you cannot have seriously looked at C++.

Modern C++ compilers (especially MS Visual C++) are extremely good at optimizing OOP, and are surprisingly "intelligent" when it comes to code generation.

For example in a benchmark comparing the speed of C++ (OOP) to C (non OOP) using GCC, an identical hashmap algorithm was used on both languages (but the C++ version was OOP-ified, of course). The results showed that the C++ version was actually a little faster than C, the reason being that since the OOP features provided the compiler with more information about the algorithm than was possible with the non-OOP version, the compiler's optimizer was able to make more assumptions, and therefore more low-level optimizations.

Here's the link:
http://unthought.net/c++/c_vs_c++.html

without doing a dictionarry link the way ive ever used consolidated (aside from the band) is in regards to money
"consolidate your debts into one low monthly repayable sum bla bla bla" sort of thing from the adverts

taking all loans (or other numbers i guess) and totalling them up
loan a
loan b
credit card c
total d (total = consolidated ammount)

so yes wrong word to choose

the only way i could see the word consolidated working in regards to programming would be everything you need in the box
IDE compiler debugger linker etc
but dont they all
(the only thing they lack in general is a 3d modeler and paint program)

as for books
the 4 that i know of
game programming for teens (maneth seti?) blitz 2d iir does the user still post or was he someone who got a publishing deal and picked blitz as his subject?

3d game programming for teens (forgotten who) i think this guy is more of a forum regular (but i could be wrong)

both these books are "for teens" but one written by someone i had never heard of from within the blitz community, although its not a 'bad' thing as the brl product owners vs forum users is a wide gap

krylars book which in parts is out dated as it was from the b2d days

the one you can buy from this website (but no idea if you can get it from any book shop)

C / C++ / C# ok its an old language so you expect a plethora of books
java not as old but just as many books
VB ditto

now you can find game programming books for most languages, but tbh the ones for blitz are purely on that subject (ok b3d is about the games) but if max offers more this is the only repository of information (short of trawling through every users websites for tutorials)

Nothing at all... As soon as there's native 3D I'll move over to it, until then I'll stick with B3D... and if the native 3D doesn't come soon enough I'll be going in the c# XNA direction (well... already started moving in that direction) as Max3D was supposed to be out over 2 years ago or something wasn't it?!

Nothing, it's great. I could get nit picky about a few tiny things but it's not worth it. At the end of the day its a viable (and fun) tool for realising my dreams of making games for a living.

@Grey-
Go on... get nit-picky, for the sake of the discussion. I want the definitive list. If things are really minor, I just won't add them.

@Rob-
Can't argue with that point.

And the two reasons why it hasn't progressed much beyond the official IDE? Relatively few people have / want to contribute (but many thanks to those that have), and secondly that of motiviation: why try to improve if people prefer to use other IDEs, or (as was thought to be the case for the last year) mark's working on a swankier new one.

Oh I agree totally, Mark. I know that a relatively small group have put a lot of effort in. This highlights the problem of a community solution. A lot of people (and I include myself in this) want these tools but don't want to work on them. Though far from ideal (no pun intended), at least a supported community IDE would allow gradual improvement by the users.

If it were the "official" IDE, I think it would have marginally more support. Those already involved would have more motivation to add to it as well - there is an "almost ready" code area including function folding in the repository to add in, but it's not a small job, and previously had little motivation to expend that effort.

And in real terms, the CE IDE has probably had more attention paid to it than the official one, even if that still isn't all that much!

No comment :)

Undoubtedly. Unfortunately, I think the chance of this actually happening is virtually nil.

Note: This post will be getting edited as I come across things to reply to.

John GaltApologies, John, that was just my way of breaking my post into my arguments against previous issues and such and then my issues. Counters is not a proposed issue.

I'm certain it would without a great deal of optimization. I just figure it would be nice to have everything as a object, since it isn't a significant issue, if one at all.

Mark TiffanyI'll tell you why I won't work on it: it's the same old IDE. I'm sure you think the code is neat and creative, but the result is the same piece of trash as before. You can come up with all the creative code you want and make the insides look pretty, but in the end you're doing nothing to make the program a more desirable alternative to, say, ConTEXT, Crimson, and other editors that provide the required functionality of a programmer's editor.

If you want to see real progress, focus on the design and not the code. Scrap what you have now, call it trash, print out the source and burn it if you like, but stop going down the road the default IDE took. You're only heading to the waste-bin if you go there. Something you should do is take a look at good editors, like those mentioned above, and Blitz-specific editors and see what they have in common. Take Visual Blitz, Project Studio, Protean, and such and figure out what makes/made them great.

WinniMembers of Gamedev.net as well. I was mostly just referring to the fact that you seem to imply that a Python user is a wholly different kind of programmer ("Pythonista"). We all write the same code, don't forget it- language almost never changes the way we write code, only how much code we write, which tends to depend on just how low/high-level the programming language is. If it's very low-level, you will not write different code, just more code to do the same thing at times.


1] I'm sure he's said some nice things, being the guy who coined a term, but whether or not it's what he had in mind, C++ has turned into one of the most versatile and useful programming languages around. What he says does not in any way discredit C++ as a language, it only serves to show that ideas change in implementation and over time.

2] This is just plain wrong. OOP and speed are not tied together. It is just as possible to write slow code (note: slow code is not always bad code, as it may be slow but still as fast as you can get it) with object-oriented features as it is to do so without them. If you can prove otherwise, I would love to see it, but so far time and the collective experience of programmers everywhere has you wrong.

3] What is intuitive is completely subjective. What you find intuitive is never the same as someone else. What do you define as a serious look at a language? Also subjective. What is "complex and complicated" (same thing) and "simple and minimalist" to people is also subjective.


I think I managed to touch on everything I felt like replying to. I suppose if anyone in particular wants a response to something I could add that too.

...and there's me thinking there's this new programming paradigm I should know about! :)

BLIDE is a great professional-looking IDE. The only problem I have with it is the slow startup times. I tend to use BLIDE when I am going to be working on the same thing for a while, and I use the default IDE to open files and make quick edits.

I would really like to see rendertargets introduced for bmax2d (buffers). XNA does them so they're possible and just seem to have been dropped for no good reason; their use can massively speed up scrolling and other effects.
I'm pretty sure there used to be an addon mod that tried to add some form of buffer so why can't it be added as standard.

Noel,

Fundamentally I agree with you.

But I am not in a position to expend the effort and time to write a completely new IDE, hence I opt for the path of least resistance: take something that basically works, add functionality where feasible (todo, better find / replace), and amend the code structure where I can to enable further improvements (integrated C editing). The CE IDE hasn't taken up *that* much of my time...well, apart from trying to resolve linux / gtk woes recently that is!

And John, re: CE IDE = official IDE

I agree, and know this to be mark's position and understand his desire not to go down this route. However *I* still think that having a small population of trusted developers drawn from the community, all working on an official IDE (i.e. not just mark & skid) is a viable option. So not 100% open, but not 100% closed as it is now.

Ah yes, forgot that one. I think the render targets are missing for reasons of cross-platform-ability. Can one of the experts comment whether they're available in OGL2.0?

These have been possible under all systems for quite some time in numerous forms. The current and most efficient one that I know of is to use gl_EXT_framebuffer_object.

"Pythonistas" - Well, I never said that I am one or ever want to be one. It's just the term that many Python developers use for themselves (you even find it on python.org), so I used it here to quote them.

Alan Kay: Well, I think what he means is that C++ as a hybrid language does not represent what he defines as an object-oriented language. And I think it already starts with the fact that it does not have a garbage collector, but offers multiple inheritance, which is widely considered a BAD THING (TM). More of anecdotal value is that most C++ developers that I've met in my career only use encapsulation and leave most of the other OO-features of C++ untouched.

Performance and OOP: There are enough benchmarks out there that show that e.g. C is usually faster than C++ which is usually faster than Objective-C, which is the most dynamic language of the three. It -has- to do with language features and their implementation. And that's not a negative thing, one just has to be aware of the fact and must decide whether it is harmful for the project or not.

"It's possible to code in Java (or COBOL) in any language" also comes to my mind here. When you try to use all languages in the same way, it usually results in horribly performing and ugly code. If you want to take full advantage of a language, you simply cannot use the same programming techniques, and so it won't be the same code or program in the end. Languages and their individual strengths and weaknesses do matter, and they make a difference for a project and its result. I don't think anybody would want to write a Quake 5 engine in COBOL. And certainly nobody would want to write a project management software in Assembler (which is wrong; I know at least one guy who would).

C++ might be a versatile and widely spread language. But it is also the language that has one of the longest histories of failed and buried software projects. That's why my former CEO at Alaska Software, Inc., Steffen Pirsig, being a C++ developer and language architect himself, always said: "C++ is a nice system language, but whoever uses it for application development has masochistic tendencies." And he also believed that the language was broken and flawed and in many (OO) aspects just did not work.

Anyway. People believe whatever they want to believe, and none of this has anything to do with the topic anymore. So I close this discussion now and wish everybody luck and success with their individual choices. Everybody should use whatever makes him or her happy. Ultimately, this is the only thing that counts and the rest are just academic geek discussions that never lead to a result.

I know a guy who's been trying to write an MMORPG in many languages, including one variant of assembler. He never said which, I'd guess HLA though. Stupid fellow, would blame the compiler for his mistakes usually, always seemed intent on trying to get me to write code for him. Gave up on him a long time ago though, he turned into a creepy stalker sort of guy.

I am a monkey John! :)

I program in C++, C# and VB.NET, as well as the language at hand... I've also been to Win32, DX7, DX9 and .NET

The language I prefer IS and always will be C++, the language I like to use because I've grown up with it is Blitz.

I can tell the difference between which one is better for what than the other one... But its not my place to say so on any forum.

My programming preferences is of no relevence to anyone but myself and any individual's programming prefences has nothing to do with anyone else.

It just sort of peev's me when I see comments like that! :) <--- Note the smiley Winnie! ;)

What about the unicode file system issue? Has that been fixed yet?

Generally I would agree, but putting the original statement in the context of this thread, it does. If someone finds B3D easy but reckons Max is less intuitive than C++, fine. The question remains, what is the key point that differentiates the two Blitz languages in that respect.
True? maybe; constructive? no.They're useless statements without the whys and wherefores. They don't answer the question. I'm trying to needle down to the core issues and get people thinking about the considerations that lead them to these conclusions.

Good point, David. Not sure of the state of play on that one.

No, files/paths using unicode characters do not work.

You can do ChangeDir("unicodepath") then load a file.

I'd like to see you do that with filename that has unicode characters in it.

I would already like to see that happen with full ascii paths like c:\möööpmip\böööäääüüüü

:)

Thats already above BMs ANSI compliance (ie any outside US-GB-NZ incompliance)

Just imagine how much it bugged me to learn that almost all useful scripting languages and BlitzMax could not be used to rename the files in my collection of artwork by Zdzis&#322;aw Beksi&#324;ski (all of the files have his name in them, spelled like that).

I think Max2D could be improved a lot but I don't know that its current state would deter Blitz3D users.

I agree the documentation is not detailed enough. Many parameters are not explained *at all* and those that are make assumptions about what you should know.

The IDE is `okay`, I use the standard one, and the community one is okay too. Could both be more advanced/helpful but after all is said and done a program is just a text file.

I think the `image` of BlitzMax is about a 7 out of 10. Marketing it more online and putting more into advertising and improving the `appeal` of it, perhaps also with a better website, would be great to see. It's not that it really changes whether I use the language or what I do with it but it would improve the community and add an extra sense of excitement and security to know BRL is passionate about their product. With Max3D strapped on and an improved Max2D I think it would be much more attractive overall. The other language issues I don't have a problem with.

What follows is rambling related to what ImaginaryHuman said.

Just something I feel like adding on as a consideration, but it may not be a good time now to even try marketing BlitzMax. Perhaps once Mark has come up with a 3D solution he's happy with, then doing some proper advertising/marketing/circus sideshows would be a good idea. As-is, the appeal of BlitzMax is mainly that you can write whatever you want on three platforms, and you get 2D code with it. It's not necessarily something that will attract new users.

I suppose what BRL has to do first is decide how they want to present BMax, if at all, to others. Is it the new Basic language that features OO features and a robust compiler for three platforms, is it the 2D game programming language, is it the application programming language, or is it the 3D game programming language? I don't think you're likely to attract a great variety of new users with the first, however true it may be, the second is rather weak, the third could work but MaxGUI is really in no position to offer a better alternative to C# and Windows.Forms, and we're still waiting to see what Mark will do (I'm interested in the tech behind it, not so sure if I'd use it though when I've got TV3D- but that's unrelated).

The short of it is, I think BMax needs to decide on what its goal really is, and then marketing can be done. Right now, it's a bit up in the air since some people expect it to be a Blitz3D 2, others expect it to be their new BlitzPlus, some of us like using it for everything under the sun from writing small utilities to engines, and some use it for 2D games (successfully, I should add, whether or not I like the results).

Considering the last of those has the most successes to back BMax up as a tried-and-true tool, it would be at least a safe bet, but probably wouldn't attract the kind of professional and experienced people like Josh seem to want (I may be misinterpreting, but I gathered that you wanted BMax to gain attention from those people). I personally hope that BMax can be sold on its own as a very comfortable alternative to C++, C#, and the like, since it's a very versatile language that, provided you put the work in, can do close to anything you'd want.

Well, I still haven't purchased BMAX, but from what I saw from the demo, I have noticed this:

BMAX is more complicated for beginners than B3D. All those modules, all the options, plus OOP makes it more difficult for those who never programmed anything before. It does give more power to the user, and it's a good language, but for those who are just starting, it's a little overwhelming.

The IDE and DOCS are BAD - and that just makes the reason above worse. If I didnt know BRL from B3D, I would have given up entirely on BMAX! The IDE can be much better - I myself coded a free simple IDE for "Turbo Pascal" (called MSXPad) - using Visual Basic, on Windows 98 - and it has a project manager, coding highlight and several features every IDE (even the most basic) should have - and BMAX doesnt!

BMax should come with some 3D module. Even if it was just a wrap aroung a 3rd party engine. Having to download extra stuff after purchasing and downloading BMAX may put some people off.

Also some more simple problems: no way to center a window automatically (or start a program with the window hidden/minimized), no way to change application/window icon... things that people complained on B3D, and are also present on BMAX!

Also how can someone test the BMAX portability with no demos for Linux or Mac?

BMAX is a great language, but it still has a long way to go to become more popular...

There is a Mac demo, both for PowerPC and x86. Linux is the only one where a demo wouldn't be easily handled.

Whys that noel? All bmax compiled stuff ive seen runs on the main ones like fedora, ubuntu etc. Or do you mean a language demo?

I mean demos of BlitzMax, not demos made in BlitzMax.

I've recently got into Max, and as a beginner would have to agree the amount of options are somewhat difficult to work out. I'm actually happy with the CE version of the Ide for now because at least it keeps the options to a bare minimum! That said, I knew BlitzMax would be more complex because it's more flexible than B3D, so I won't say that's a problem with it. Also, with regards to OOP, I found while scripting in Flash OOP principles absolutely rock, so I know that bit of extra learning is going to make things better down the track.



That really is my problem. The docs are awful. Really, really awful. For a beginner they're borderline impossible to follow. B3D's docs weren't great either, but at least I could find the functions I was after. With Max's docs it feels as though they were written for people who've many years of programming experience (and exposure to the many programming standards, terms, etc) behind them. If I could ask for one improvement to Max it'd be with the docs. Bad docs make it half impossible for beginners to learn the language, make it hard for people to get in and get something done quickly, and make learning the language frustrating. Why the BRL crew haven't figured this out yet makes me shake my head at times.

BlitzMax desperately needs properly laid out docs, and properly written code examples. If BRL need to hire someone that's especially gifted at teaching to arrange everything and teach on the language, they should do it. Trauling forums for the understanding of basic functions is an incredibly poor substitute to proper documentation.

The problem, Reactor, is that due to the modular nature of BlitzMax, they cannot simply write a big document and call it done. Rather, they need to go back and revise their documentation generator so that it's actually useful and produces quality output. Right now it's just terrible both on formatting documentation in code and its output.

For me it's even the bits Mark has written himself about the language... his code and comments seem targeted at anyone but the beginner.

@Slotman-
The old OOP thing again. There's a cycle here. People mention OOP putting them off, they're informed it's totally optional.... then silence.... no response... until the next person comes along and mentions it ad nauseum.

I hear what you're saying about the docs, that's one of the biggies a lot of people are mentioning, and I can understand the modules being daunting, but I think that's again down to the way it's documented. What do you think? Do the docs also lead you to think that you have to learn OOP to use the language, or is it that people are put of by the possibilities, even if they know they never have to use it? Maybe that's it? If so, there's no way BMX can be changed to appeal.

Please come back to me on this, Slotman. A lot of people are saying similar things, so it is an issue, but they never respond when questioned on it. Is it a misunderstanding, or purely down to misleading documentation, or is it the array of options, even in the knowledge you don't have to use them?

Oh and we do need some updated Max demos. That's going on the list.

I don't know what the problem is with learning OOP. Can someone explain why it's such an issue? I've always seen OOP as something that makes life much, much easier... not harder.

Here's an itch I have, tho I may be looking at the issue from a wrong point of view.

When I have an array of my object I need to initialize all these indexes. Maybe there's a point in it, but I don't see it. Whenever I create an array of those objects, I want to use them right away so I init all those indexes right from the start anyway. Same with slicing the array to a bigger one, need to initialize the new indexes again.

Note that I don't create time-critical things like games, only apps.

So, I wonder whether this could/may be possible in the future:

Type bla
  field somefield:int
  ..and lots and lots of other stuff here
End Type

local poo:bla[20]
poo[3].somefield=5
poo=poo[..40]
poo[30].somefield=41

Or am I missing something obvious here? :P It would already be quite cool when auto-initializing happens upon slicing.

It may be two-fold. What I like about OO is the data-hiding, having all the relevant variables and methods tucked away into one big container (which has a good effect on namespace!). The thing which I don't really seem to get in to is the idea of object inheriting, creating a complex object by inheriting from simpler objects, etc. My objects are usually not that big or complex, and never really need to have a place in a complex hiarchy. Often enough it's this hiarchy that you will read about in books 'n things, it may be that this hiarchy stuff may spook some beginners.

The thing about blitz types, to use a bit of C talk, is that they're pointed structures. So say you have a type whose fields take up a total of 10 bytes, well when you create an array of these, you're not creating an array of conscutive 10 byte structures, you're creating an array of pointers with each one pointing to a structure. The structs themselves could be spread out all over the place.

None of this precludes the type of auto-initialisation you're talking about, but it does make it a slightly dangerous assumption. What's to say you don't actually want an array of NULL pointers, which you'll later fill to point to type instances that meet some criteria? If they're automatically created full of types, then you overwrite with NULL, there would be a load of wasted allocation and deallocation going on behind the scenes. In a nutshell, it's safer to let the user do it.

I see the itch, but I can't think of a decent solution.

How about a command like:

Initialize object[]

?

This command could inspect the given array of objects, and auto-initialize NULL elements?

Yep. You could probably even write such a function yourself, if there's a way to identify the type of the array programmatically.

This is a good point. Why not bundle MiniB3D with BlitzMax?

I don't know if anyone's mentioned this before, but I can't help thinking that it would really help if someone at BRL sat down and wrote a proper installer. I mean one that does everything. How long could it possibly take? At the moment, it's "install this, download that, put this there, download something else, check these options, make sure you get this version, environment variable this, path variable that, copy these files from here to there, add this to that, turn around, touch the ground, touch your nose, touch your toes."

I know it really doesn't bother some people, and I know this because I am one of the some people it really doesn't bother, but there's really no excuse for it, and it must put some people off. There seems to be a common misconception that all programmers like ferreting around in dark corners of computers, and clearly that isn't the case for everyone. Some people just want to open an IDE and get going, but BlitzMax makes that utterly impossible. Certain modules absolutely require MinGW be installed ( and let's face it, we BlitzMax users are guilty of telling people how great all the modules are, so we're making them want to use these modules! ) and it's a pain in the Khyber.

Is it really impossible to bundle MinGW with BlitzMax? I know it's GPL and all, but nothing's carved in stone. You can usually get a custom license if you ask nicely, explain the purpose and limitations, and provide a good reason for it. I can't help thinking that the status quo is simply because no one's tried asking.

That aside, you could integrate the path and environment variable steps into the installer. You could have the installer automatically find and begin downloading MinGW if it truly can't be bundled together. The vast majority of all this faffing about could be taken care of.

Let's face it, the instructions on how to do it aren't even in the most obvious place ( They're in the Module Tweaks forum, if memory serves ) and after all this time, Mark's original instructions are still wrong. People have posted below him adding what additional steps need to be taken, but he still hasn't updated his top message to reflect that, leaving dazed newcomers who have no idea who is smart and who is an idiot ( I should probably wear a t-shirt to help them identify me ) to pick between several dozen replies, guessing which ones are providing the information they need and which ones aren't.

As I say, I couldn't personally care less, but this can't be helping the (completely inaccurate) impression that BlitzMax is more complicated than Blitz3D.

Bundling miniB3D is not a bad idea, but I'm sure it will lead to the misconception that it's the official 3D module and of course people who invest time with it will complain when the real Max3D appears as it no doubt will, eventually. If it was handled in a way that made it extremely clear it's only 'a demo' or whatever, it could work.

The MingW point is a good one. I found it a pain to find the info to do it. This is one of those little niggles that could probably be resolved easily by BRL. I wish they would at least attempt a couple of these quick fixes.

I do have a list of issues i have somewhere. Most of them were resolved by good programming ethics, but some aren't

one i'm going to add now:

Inability to make members of a class (type) Private.

IE I want to make TActors _timer:int member private, so no external access can fiddle with it.

This really helps to enforce correct programming, IE use [SM:int=Me.GetSceneManager()] instead of [SM:int=Me.SceneManager]

^^ Damn it, Cygnus!

Here's a couple issues I've neglected to point out:

Firstly, one that I feel is necessary for proper OO programming, but probably only because I learned to do it in C++ first:

1] Lack of private, protected, and public members. Everything is private or public on the file's level, you cannot set what degree of access is given to global/static members/methods of types when inheriting or when used. May also need to be able to specify friend classes/functions. About the only thing we can do to get around this is hope nobody ever touches members that are for the class's internal use only.

Secondly, one that is not so much an issue but something that is nice to have at times:

2] Generics/templates. The problem with having this is some people get way too happy using it and end up causing a lot of problems in code. However, this is more an issue with the programmer not showing restraint.

Since some think BlitzMax must be as beginner-friendly as possible (which at times leads to wanting a dumbed-down language without OO features, modules, and such because those are confusing), this may be one of those features that group would boo. I say too bad to that, you should get used to learning how to use new features or just not use them. Stop being a bunch of pansies. ;)

We can currently work around this, in a way, since all types inherit from the base object class and can be up- and down-casted when necessary without any seemingly great impact on speed (I think it depends on whether or not BMax performs runtime checks when casting to make sure you're casting to the correct type; I think it may since you won't get a useful pointer by casting to different, unrelated types, but I'm not sure), but it's not perfect.

Good luck making sense of that wall of text.

Me, but it wasnt minib3d, it was the new 3d engine mark is writing for bmax:

I proposed this:
Get max docs up to standard and then:

That way the 3D version would be one product and the 2D another, with the option to buy the module later if desired.
-The next generations of B3D and BPlus if you will, but fully compatable with each other.

I can't see why anyone wouldn't see the advantages to a properly implemented private/protected/public. In fact I had not thought of Protected myself until you said it, but it does fit too.

Firstly I would like to say to everyone, CODE COMPLETE this book was a fantastic read and has improved my own programming style a lot.

It's mostly all down to discipline, but when you are writing something like FLOW and want to avoid users causing bugs because they are accessing members that should be private, it becomes a problem. Bug report X,Y,Z, resolution: Stop accessing X,Y,Z incorrectly.

I nearly replied to this thread. But then I didn't bother.

Bored much? Our of booze? :-)

Good post Gabriel. I agree to an extent. BlitzMax does veer dangerously close to the C++ world of pain when it comes to setting certain things up.

I am one of those people... I didn't realised BlitzMax was such a pain in the arse to get running... Sounds like a damn good reason not to bother as far as I'm concerned. The XNA C# deploy to XBox360 is easy.

if making the installer set the path and including MingW is too hard:

then.... when someone buys blitzmax and installs it, a help file should pop up automatically detailing the steps needed to take and why.

Dont forget, a lot of users of BMAX are doing more clever stuff like using external 3d engines and gui systems that require the painful mingw setups(esp. on vista) or need to alter and recompile modules etc. That alone is the main reason its a pain to setup and have moaned about it myself before, with some similar points to gabriel.

However, Blitzmax in its basic 'out of the box' state seems to work fine, with few hassles. If a compiled & ready 3dlib was part of it like the 2dlib is then the setup pain would for most would be n/a.

Okay most of these ideas have gone on the list. Whilst the Ming thing is an issue, let's not overstate it. As Dan said, many users will never need to bother, and it's not a tremendous effort. The biggest problem is digging the instructions up. If the install was clearly explained in the docs it would be fairly painless.

If I coded our engine in Java (and speed weren't an issue) I would get more respect at the GDC than using BlitzMax.

I had a conversation with the founder of a major 3D engine today, that went something like this:

Is that for real, Josh? If so, I feel for you. I laughed when I read it, but I feel for you.

Still if you can write a decent engine in 500K and make a Coco Pops game all in one language, that proves how versatile it is, right?

LOL, indeed.

I have a question for everyone.
I am considering buying Blitz Max, but I don't currently have enough
cash. I will probably be able to get it around Christmas, but will it really
be worth it?

Should I just wait for Blitz 3D 2 to come out instead and buy that, since
Blitz Max is pretty much being ignored by the Blitz Team anyways?

The Confused WERDNA(Who has his online elf girlfriend back:)

Well one gives you a better language and one gives you a better 3D engine, so it depends which you really want. Those who cling to Blitz3D and refuse to look at BlitzMax, for whatever reason, are of the opinion that a better 3D engine is of more benefit than a better language. It's a valid opinion, but it doesn't match my experience.

I've spent the past two years using both a better language and a better 3D engine, and I can tell you that my experience is quite the opposite. I *could* have written the game I'm using now with the Blitz3D graphics engine. It would have been slower, more expensive to make, it wouldn't have looked as good and some features simply wouldn't have been possible, but it would probably have been fast enough, it would have looked decent, and I could have lived with losing some cool features.

I couldn't have written it in Blitz3D. It's just not remotely possible. A huge portion of the game would have been literally impossible, and what little remained would have been much, much more difficult. So if I had even managed to struggle through it, it would have been a pale shadow of what it could have been, and would have lost several of it's biggest selling points.

But you're not me, you're not making my game, and you don't have my skills or lack-of-skills. So that's purely my situation, based on my experience, and perhaps it will help you figure out whether you want a better language or a better 3D engine. Of course, the Blitz3D2 3D engine will be coming out for BlitzMax first ( and indeed it may not come for Blitz3D2 ever ) so it's not exactly an either/or, financial constraints permitting, it can actually be both.

As a beginner I'm glad I invested in Code Complete. Most of it is beyond me, but it has certainly helped in laying good foundations.

@Werdana.

In his latest worklog mark said that he has not given B3D2 much serious thought and is sill just a mabe. He has said he is definitely writing a new B3D-like engine(which all starts with C++ i suspect) not a new language. Then he is going to intergrate it into BMAX.

Well, I do know C++/OOP - that's not a problem for me (I did a demo/game purely with it, using a Brazilian OpenGL engine "Fly3D", called Penguin Racer - if anyone wants to see it, it's on my website) - But I've seen several people who even knew how to code in C, looking at C++/OOP and getting completly lost.

But in my view, the docs are the biggest problem, hands down. They need instructions on how to setup MingW, they need examples for all commands, it really needs to be more complete. The forum here does help out A LOT, but how many people would even take the time to look at it? Specially since you can only post if you purchased at least one BRL product...

One example why docs are bad? Why cant I do a simple SEARCH for the command I need? For ex: it took me a while to find the Framework command - It was on Language->Modules, and at the end of the page... and even the the description is rather simple, for such a powerfull command.

Information seems scattered around on the docs... I took a look at the "community help" done in a CHM file, and it's waaaay better then BMAX default one. Much more easier to find info on what you're looking...

But, again on OOP: There's a "paradigma" here... the language is BASIC - which was created to be learnt as a first language - so it should stay simple.

One could easly just learn C/C++/C# (or even Python) instead of BMAX - there's not much of a difference between both languages (at least not in my eyes), and both (when done right) are portable. The biggest advantage on BMax side, is that it already have a graphical/sound engine "built-in" which is also portable, and has a garbage collector (so you don't have to worry about de-allocing something), while on C you have to start OpenGL from scratch (window creation, setting up matrix, loading images/3d files... believe me, it's a pain, I've done it), or use SDL or some 3rd party engine.

So, for a completle newbie, try argumenting that BMax is better, and he should learn it instead of C# and XNA... or C++/OpenGL/Glut/whatever. The difficulty would be almost the same to learn both, so why not go for a "wider", more known solution?

Can you see the problem? BMax is BASIC, so it's easy to learn; it's portable, stable, very fast and has OOP and several options (yay!), which makes it not so simple for first timers... also the IDE doesn't help much, the docs are not very helpful, and you will have to install and setup extra stuff if you want to use it to it's full potential; and there's no built-in 3D...

That being said, if someone asks me which language/engine could someone use to do a 2D game, I'll recommend BlitzMax without thinking it twice. There's also Torque, which is growing a lot (specially now that it works also on the 360) - but I just don't like Torque :P

[dream mode on]
Hey, here's an idea... maybe Mark could contact Microsoft and see if there's a way to "port" BMAX into the 360/XNA stuff? Would be cool to have portability from PCs/Macs and also to consoles :)
[dream mode off]

For me, BMax is on a tough spot - it is a very good language, and it has lot's of potential, but everything around it needs to be improved, to be recognized as reliable option to other solutions out there...

(wow, didnt think I was gonna write that much heh)

Actually, given that this should be possible now, it would be quite nice to see this done. Either that, or write a program for the documentation. Seperate from the IDE so we're not locked into using it. Note to self: attempt to write a program to read BMax documentation and browse it easily. When I have spare time and am not loaded up on painkillers.

Would be neat and I think it's definitely possible from a technical standpoint, but Microsoft is unlikely to ever approve of something like this. Not even Dark GDK works on the 360, and TGC still struck a deal with Microsoft.

Not being able to find what you're after is only half the issue. The other half is the info you'd expect to be in the docs just doesn't exist. I used the search function in the chm'd docs and couldn't find a thing on Tgraphics... which was quite baffling to a newb like me, since people were referring to it everywhere.

I agree, but it's implemented a lot more cleanly in Blitz.

Thanks for your response, Slotman, but you still haven't directly answered my main query, which is, why is OOP a concern if you can happily ignore it? If I had to read between the lines of what you're saying (and please correct me if I'm wrong), the presence of OOP puts you off, whether you have to use it or not. If this is a major problem people have with the language, then the problem is insoluble as just as many people wouldn't be without it.

I had visions of talking it through and making suggestions to reunite the Blitz masses under the banner of Blitzmax, but I concede now that it's just not possible.

I think even Mark's come around to the idea that 'B3D2.0' (and whatever that implies) is all some people want.

Beaker summed up the attitude best in another thread:
Still, I think we have managed to consolidate a lot of ideas that could substantially widen the appeal of Max. Tally ho!

@Simonh- what are the chances of someone at BRL revisiting the docs? They're still a major stumbling block for a LOT of people.

The problem with OO in BMax is the fact that ppl on the forum can come up with examples and answers to questions using OO. If the one who reads or asked isn't up to OO then it may be all scary substance.

It's the same as with that inheriting I mentioned yesterday: one can use OO by having simple a container for fields and methods or one can use intensive inheriting, breaking up all kinds of parts into the smallest individual types only to reconstruct some kinda hiarchy using inheriting later on. If someone who reads this isn't 100% at home in inheriting then such examples are the biggest examples of obfuscation.

CS_TBL,

Thank you!!! You are the first person EVER to raise a sensible objection to OO in Max.

I concur and I really don't understand why people come up with 'clever' examples using OO when asked simple questions. The example should be as complicated as needed to answer the question and no more. Not a lot BRL can do about it, though!

fook me, sensible reason against OOP in a beginners language! X-)

Personally I say users should learn it, I'm not sure how I would keep my code manageable without it anyway. I'm not going to repeat things here, everything else has been said. :-)

Well, I think I could teach the container idea to any beginner, I could even explain Thing.do() instead of do(Thing).

It's the inheriting part that bothers me, or rather: the idea of creating a hiarchy of objects. I never feel the need for a hiarchy and I wouldn't be able to point out any potential hiarchy in my objects. And *if* there could be an element to be pointed out which could be so generic it should be a seperate object, then it's usually a small object and it's hardly worth breaking it up. I mean, let's not inherit purely for sake of inheriting and nothing else.

way I see heirarchy:


Player object: a robot and an alien are player objects. so Robot/Alien extends player.

Sittingplace: A sofa and a chair are somewhere to sit- extend sittingplace.

or, for Mazemonkeys:

Actor: Everything dynamic in a scene. Player: an actor Robot: is a player. grenade: is an actor.

an Actor can be set on fire, blown to pieces etc. because of this, so can a robot or a grenade. a Player can score, so therefore so can a rotbot. a grenade however is not a player so cannot score.

Eh?, how is that any different from say.. 10 pages of b3D code using Transformation Matrices or surface/vertex/bone/normal/UV manipulations to people that have only ever just loaded pre-made meshes and moved them around with some gamelogic? Compared to that, the oop in bmax is nowhere near as complex. In fact the basics are not hard, if people could spend all the energy used on moaning about it to actually learn it they would realise its fuss over nothing.

I agree, Dan, but to be honest, if I thought OOP was a solid requirement in BlitzMax, I would never have switched over. It can be daunting for a beginner.

I think Max needs two separate help systems, one of which is very similar to the B3D help system, doesn't touch OOP, and only shows a reduced set of the functionality. The B3D commands could be used as the basis in picking out the commands documented here. The whole idea that these commands are in 'modules' could also be left out. The second, complete help system could be based directly on the current docs, but as mentioned, with some (substantial) work required on them.

Cyg: Yes, those are the same examples you see everywhere, and to me they don't make sense.

You talk about players and who those players are, I otoh would talk about a generic entity with properties and let those properties dictate what something is supposed to be/do.

So, instead of a player object and a derived alien and robot, I'd have:

Type TEntity
  Field class ' 0 man, 1 woman, 2 alien, 3 robot, 4 bird, 5 frog, 6 puki
  Field control ' 0 computer, 1 player
  Field attack ' 0 attacks human controlled entities, 1 attacks computer controled entities, 2 attacks both
  Field defence ' 0 flee, 1 counter attack
  Field detectionwidth ' 0 straight, .., 60 human, .., 360 omni
  Field movementangle ' 0 any, 1 angles of 45, 2 angles of 90
  Field canfly ' 0 no, 1 yes
  Field canmoveonland ' 0 no, 1 yes
  Field canswim ' 0 no, 1 yes
  Field canresurrect ' 0 no, 1 yes
  Field canbury ' 0 no, 1 yes
  etc.
End Type

With this I could make all kinds of enemies, including your alien and robot *and anything in between*. Moreover, I could decide that, by changing the control field, a player can take over control of an enemy. Also, I could decide that a land animal could suddenly fly away (for instance after applying some magic onto it). To me this is vastly more flexible than a derived system of entities in which some animals can really do nothing else than the stuff they've derived. Apart from this, I simply see no reason to strip apart my type, I see no added readability or improved overview.

Unless I have a completely wrong idea about inheritance of course, but afaik a key element of inheritance was to 'take what you need' and 'leave out what you can'. In my entity case I'd say: I need everything, always. And if you think you should limit your entities to exactly what they should do and nothing more, then I'd say: "why?". Why define a special flying class when this could just be a field upon which you can apply this ability to *all* possible units?

But its not a solid requirement so there is no problem.
As long as there are enough examples supplied, which are either free if it or using simple stuff like basic types & methods (which at a basic level are not that much different to b3d custom types, except they are programmable) then that would be enough i reckon to get any noob started.

> Unless I have a completely wrong idea about inheritance of course, but afaik a key element of inheritance was to 'take what you need' and 'leave out what you can'

A better idea is to say "put everything in it's proper place, and only write the code once". So in your example, putting everything in one base class is fine. If you were writing a framework of some kind, and wanted to limit what other programmers could do with each class - then you would need to seperate things out.

I know that, but despite all logic, people have a problem with it being there. How about a compiler directive 'NO_OOP'. It would do exactly nothing but give beginners that nice cosy feeling of safety. ; )

IN CASE THE SMILEY DIDN'T MAKE IT CLEAR, THIS WAS A JOKE. NO FEATURE REQUESTS FOR A NO_OOP SWITCH PLEASE!!!!!

@SlotMan

I made - years ago - a little change to the Index.html page (you can see it in action here
click here - in this case I integrated it in my MaxIDE CE version)
I can assure that the javascript allow you to search in the commands database in a easy way (you can search 'Gadget' and you will find every words that contains 'gadget' - ie: ClearGadgetList; or you can search for GADGET* - all the words that STARTS with gadget; or *GADGET - all words that finish with GADGET). I find it *very useful*.
So a solution it's possibile.

We need proper support from BRL for a real 'blitz' on the documents. Community efforts are great but it's not enough.

LOL! that may actually work :D (joking too! ;)

CS_TBL,

Cleanliness of code. Doing it your way ends up with a lot of code in one place that can be hard to work through. It is personal preference of course but for stuff that *all* actors can do, I put it in the root Actor class. if only flying actors can fly then I only give flying abilities to entities that fly. if a robot becomes a bird, turn the robot into a bird.

A robot has a specific entity layout, so robot has the code to deal with setting that up.

Etc etc.

Wouldn't some of them argue that BlitzMax is too complicated becouse you have to deal with compiler directives?

Nope, as you don't have to deal with them. :-)

Bmax needs official streaming audio preferably with EAX support and some native video playing functionality. I also want to see Rendertargets but I have learnt to love the OOP aspect and have worked around the docs by using the chm files produced by community members and HotDocs.
Extra things :
a) BRLs seeming lack of commitment to Bmax. Updates are few and far between with the major change in the last being reflection. I am sure it's very useful but it would have been nice to have something more 'visual'. A lack of any development route for Bmax or any mention in Mark's worklog suggests it has been finished.
Looking at the homepage and it lists B3d as the flagship product. I have nothing against B3D but I was hoping BRL would have put more emphasis on Bmax.
What would have been nice is to 'officialise' more 3rd party modules.
b) (Not such a problem now but) updates could cause problems with 3rd party modules. IGlass suffered plus problems with Tim's modules and FonText needed updating to name a few. My own DX based modules suffered (probably due to poor programming on my part) by the DX changes in 1.20(ish)

@ziggy, John was joking. (edit: oh, so were you. - sorry, im a little slow this afternoon :)
@tonyg, marks last worklog said a new 3d engine was comming, using bmax as the priority language for wrapping it with.

Blitzmax module interface was "finalised" a few versions ago, 1.22 or somewhere around that? before that it was all subject to change.

There's a lot of talk here about what beginners would or wouldn't find hard to learn. I am a beginner. I think I'm different from most beginners, but in my mind OOP is just par for the course... and it's that because pretty much everything to do with programming is hard to learn. Sorry, not 'pretty much'. Every single little thing is hard to learn, even when it's as basic as Blitz3D (no pun there :) I purchased BlitzMax knowing full-well it'd be tough to learn, and would have still purchased it even if OOP was mandatory. With everything that's involved with game development OOP really is the least of my worries. Max is a great language for those who want to learn to program, but also gain a deeper knowledge of some of the more complex aspects of coding as they do, so they don't die of shock if one day they have to use a more complex language.

What doesn't help the situation for learning BMax are things like badly written docs (we're all agreed on that), badly written code examples which break many good coding guidelines, and badly written tutorials (mostly by community members). Sorry, but those are the biggest stumbling blocks to me as a beginner (aside from my own brain), when it comes to learning BlitzMax. Give me OOP any day of the week. If I could have an overly complex language and OOP forced upon me in exchange for good docs and a few good teachers who'd read and taken Code Complete to heart, I'd take that deal in an instant.

Yes, I am aware of that. I wonder if it will have it's own audio/video/rendertargets/2d/printer support, DX9 etc. If it has then it's not really developing Bmax.

I think you're right and it leaves Bmax a bit short but so tantalisingly close to very very good (imo)

What exactly does #6 do?

I like you, you make sense.

Never read this Code Complete book everyone is talking about. Will have to look it up and see whether or not it's worth having. I'm pretty picky about programming books, since a lot of them seem to contradict each other.

From the last posts it seems we need a 'media module' supported directly by BRL.
But considering the license limitations of some media format (ie: mp3) I think an 'official' solution is/will not possible at 100%. These arguments are already discussed by the way. So the 'limit' is not in BlitzMax but in law/copyright/license/contract acts. [Honestly I don't miss the .mp3 format - .ogg format is good and provide a cost-less solution]
And I would like to see (and buy) an official Media Module for BlitzMax ala MaxGUI, of course if it supports video & co.

Something I like to see directly supported by the compiler is

Global x:float, y:float, z:float

with

Global (x,y,z):float

It would be faster to write and read.

I don't know about you, degac, but I don't see those as three global variables but a single global tuple. It would introduce varying problems with reading, so I'd have to disagree with that sort of syntax, since thus far I've never seen anything like that in a language that didn't have some sort of structural meaning attached to it.

I don't own BlitzMax,so i have no right to say,but it looks like you are learning the C++ language slowly.

John,

Surely issue 12 is not unique to BlitzMax? And possibly more of an IDE function, or possibly symptomatic of the first (and primary) point about the docs?

Can I ask someone to clarify what we mean by "sort the debugger out". It's a bit woolly - what is it that we want it to be able to do?

Personally, I'd like to have the ability to:
- ability to stop the code from the IDE without needing to code a debugstop() in advance.
- have the debug code pass changes in data in variables back up to the IDE.

These two would do me, and would also enable the IDE to implement variable watches (i.e. stop when a var changes, or hits a certain value). Ideally, I'd also like a way to type a simple command in and run it (e.g. Print x.z*5), but can see that as being truly evil to implement!

Run for a few moments without crashing, taking Blide and my application with it. Whenever I start opening up the debug tree to find all the fields of a particular object, perhaps nested inside another object, there's a 1 in 3 chance that the debugger will just promptly freeze and take everything else with it. And I know it's not Blide because it does it in the official IDE too, when I can bear to use it.

In terms of what abilities I'd like it to have, well it would be nice to be able to stop the program, change some values and set it off again, but I'd really settle for it just not tripping over itself every five minutes.

Which is odd, because I regularly debug the ce ide using the ce ide without crashing. I did find and fix a bug a while back in ce ide that could cause things to hang, so it is certainly quite easy to make any interaction between any ide and the debugger fall over...

Ah yes, add that to my list.

A proper display showing the values rather than the ugly little monospace-text treeview off to the side. Why is the font in that monospace? Who thought that was a good idea? LEMME AT HIM.

Seriously, I think the painkillers are starting to cause some problems in my brain.

Exactly! And the reason i try to avoid the debugger if possible. I hate to restart and reload everything, although it's now better/faster with the new CE IDE. But when you need the debugger then you try it again and there is a big chance it also freezes again, nice loop...

- "What exactly does #6 do?"
Turns into a pacman style character who gobbles up all media in the game world.

I have been using BlitzMax for, what, two years? And I still think memory management is stupid.

1. Unless you are writing an extremely simple application, there is no way you are going to get away with not having a Free() command to get rid of objects. Even the MaxGUI module requires you to use FreeGadget(). And since BMX doesn't handle circular references, what is the point of even using it, since we have to do all this manual memory releasing anyways?

2. It makes interfacing with other languages and script a lot messier.

3. The only thing it is good for is math objects like a Vec3 class, but C++ handles this without using memory management.

It seems like something that was implemented just because it was kind of a new curiosity that C# was using, and once the novelty wore off, the author didn't want to bother finishing it. Circular references aren't that big of a deal to me, because I have to do so much to manually free my objects anyways. The thing that bugs me most is how it makes it a lot harder to interface with other languages. I don't like having things in my program happening without me having control of it.

Maybe I just have outgrown the language and I need to move on to C++.

C++ will always give more control... things just take longer to set up.

C# has a special class to deal with unmanaged COM objects. Something like this could be done for BlitzMax, to make interfering with other languages easier. Apart from this I would never go back to an unmanaged language I just would like Max to handle circular references.

To the debuger issues, I *think* the internal Max debuger is not flushing the pipes properly at some point, when the data alocated to the debuger is too big it, at some point, raises the 4096 bytes limit, waiting for the host application to get all the text while the host application is waiting for the debuger to send a complete package. I think the flush operation should be done in a per-item iteration istead of being done per block, but this would slow down a lot regular debuging. Not sure what else can be done here apart from integrating the debuger front-end in the debuged application as B3D has been always doing. There are other options such as sharing directly data between the running application and the host, without using pipes, but this could become a nightmare becouse of the very different APIs Windows, MacOsX and Linux have in this particular area.

My only real gripe with Bmax is that it doesn't have a seperate debugger (as Blitz3D does). If it did then I would be able to use any generic IDE (such as UltraEdit).

Other than this I think some small tweaks would reduce it's general level of complexity: slightly more evolved help (with search, crosslinks, online help), perhaps automatic installation of mingw, and a front-end app for brl SVN.

"I couldn't have written it in Blitz3D. It's just not remotely possible. A huge portion of the game would have been literally impossible"

Gabriel

I agree with your post except for one point
You should compare Bmax with C# rather than Blitz3d

Of course Biltz3d is not suitable for large projects, while, as you said,the Blitz engine could be ok unless you are looking for special effects
Many smashing hits, take the SIM's, for example , do not need a a super graphic but they definitly need a well structured programming language

The question is
What advantages offer Bmax over C# as far as game programming is concerned ?
I am not ironic , jus a question
Honestly I have no so much experience with Bmax but going through the code it does not seem to me that user friendly language

Can you make an example Bmax vs C# ?

I would like to see variables, functions etc etc to be case sensitive, and improve the Mac & Linux editors (the Mac version has a limit to how many times you can indent text, and the Linux version is rather odd in places).

No, Thanks.

How about an option for that instead? I could sure use it.

I'm gonna say no to case sensitivity. What reasons are there for it that would really justify this sort of complication?

It's a great thing for beginner, since correct case is a good habit to adopt. For example, I personally want all of my variable names to be written the same way. If I miss typing something I want to be told about it.

If it were an option, how would it be a complication for you?

Remember how the QBasic IDE auto-corrects cases?

I always wanted a strict mode SuperDuper or whatever that was case sensitive. I capitalise my globals/Fields and locals are lowercase and some terms, like "id" I'd like to be able to re-use locally. But it's not a big issue for me - and of course completely style-related. I'd vote for the option though.

This is what we call a bad practice.

Secondly, this is BASIC, whether you like it or not. The amount of people who think case-sensitivity is worthless is likely to far exceed the number who think it has even the remotest benefits. Secondly, to address the idea of it being good for beginners, I don't see how pissing off the beginners is a good idea, regardless of whether or not they learn to type like something other than a chimp. Also, David's example even provides a reason some people give that is very, very bad. Ambiguity between names when the only difference is case is not going to help anyone, and certainly not the beginners.

If you can't type the way you want to type only because of your own errors, that's your problem, not the compilers.

Well considering the thread subject and what forum this is, I'd wager a comparison between BlitzMax and Blitz3D is more useful and more appropriate for most people. Also, I've completed a few games in Blitz3D, so I know I'm at least somewhat qualified to make this comparison. Any comparison I made with C# would be as a programmer who has never finished a game in C#. Also, while I acknowledge that Blitz3D is not the most suitable tool for large projects, I'd wager that a number of people here believe it is.

As for where BlitzMax beats C# for me, it's mainly small, irritating issues.

The C# Maths class uses radians instead of degrees, and while conversion and/or writing your own isn't difficult, it's an irritation, and easy to forget when you're coding large chunks of code fast as I am prone to do.

When writing chunks of reuable code, BlitzMax lets you use modules which are elegant and as easy to use as could be. With C# you really have to be using class libraries, as far as I can see, and they're just not as elegant as modules. Again, it's a trivial point, but one which irritates me.

With C#, you're forced to ask end users to install the .Net framework and many don't want to. Now while I don't see any logic in this decision, nor do I believe that the commonly expressed reasons for not doing so are even accurate, I acknowledge that those people are not going to change their minds until they are forced to upgrade to a version of Windows which already has it installed. When that happens, I'll have one less reason to use BlitzMax over C#.

For many people, I would imagine the fact that the best Mac and Linux implementations of the CLI are nowhere near complete would be by far the biggest problem. It isn't an issue for me, however, as I'm not developing for those platforms.

Neither BlitzMax nor C# let me directly interface with external C++ classes, but because BlitzMax has GCC tucked discretely into the build process, wrapping them for use with BlitzMax is pretty easy, and because it uses the module system again, very elegant. I can't say the same about writing a managed wrapper for C#.

I have expressed and acknowledged in the past that - unless BlitzMax gets major further development - I will likely have to move to C# at some point in the future. At the moment, both languages are relatively new, and so they share common weakpoints, but C# is being developed heavily ( too heavily in some areas, it's starting to pick up a few of C++'s weaknesses along the way ) while BlitzMax looks more and more like Mark considers it a finished product.

I don't believe there is a huge gulf between them though, as BlitzMax is clearly inspired in part by such modern languages. However, at the moment, I feel BlitzMax has far fewer little niggles, particularly the everyday niggles, and for that reason, it beats C# for me. It has what Blitz3D used to have before I outgrew it. Simplicity and elegance for a relatively high level of power and control.

Ahem. Except me :-)

I do see your point Noel, and it's a good one. In my case, the style is consistent and having case resolve ambiguity simply works. To my coding eyes "FRED" and "fred" are easily distinguished. So yes, I would vote for the option - but I'm not going to get hung up on it.

[edit]
Actually, the more I think about this, the more persuasive Noel's argument becomes. I appear to have unwittingly provided the best argument as to why case sensitivity should NOT be introduced. Sure, it would enforce case consistency, but it would also allow coders like myself to tie themselves in knots with their ambiguous variable names. I feel like I've been hoisted on my own petard here. :-)

Gabriel

Thanks for your reply
While I definitly agree that Biltz3d programming language is not suitable for large projects , you have very honestly admitted that the difference BlitzMax \ C# is just a matter of "small, irritating issues"
In other words it is more a matter of personal tastes rather than a real issue.
You would agree that it was much better to expose Blitz functions to C# or C++ ,same as they did some years later, rather than wasting a lot of time for developing a new programming language
However I realize thay it is of no use to talk about the past
BlitzMax is welcome if it comes along with a brand new engine ( may be Leadwerks ? its game architecure looks like Blitz)

Beginners are pissed off at programming almost 100% of the time. They hate indenting. They hate trying to figure out other people's bad naming conventions and magic numbers. One more thing won't hurt a beginner. As a beginner, I know, and I'm happy to practice good principles... even if it makes things slow going for a little while, or is another thing that annoys me (which it doesn't).



Eh? David's example was that, because of his bad practice it could cause him issues. If he didn't use the bad practice the case issue would be a mute point. Plus, why is it a bad thing for beginners? If a beginner can't create proper variable names in the first place he has more problems with his programming than case conflicts. Variables should have well chosen names.



Again, eh? It's a computer program designed to help. Who cares whose problem is it.



Easy solution- just learn to create proper variable names.



Same.

Hi, fellows. Been away for a few days on a stag do in Tallinn. Damn the women over there are good looking! Anyway, back on thread:

Simpler.How is it harder than B3D? Be specific.

Whilst some of the improvements you mention would be niceties, what I mean is it crashes, making it useless. It seems others are having these problems.

This is an important one for me. Generally speaking, I have come round to the garbage collected way of doing things, but I have had all kinds of problems handling callbacks from the fmod API, and I'm convinced it has to do with the GC. The only workaround in the end was to write the callback in C, but then it meant I had to write so much of the application in C that I wondered what Blitz was adding. I know this is a controversial one, but I kind of agree that the headaches outweigh the benefits with the garbage collection. It's not a problem when writing in pure Blitz.

Sorry, no way that's going on the list. no NO nO No.

Well, everything is a matter of personal taste. I gave my personal opinion, but I doubt you would find it to be the prevailing opinion among BlitzMax users. A lot of people are serious about developing for Linux and/or Mac, and the fact that the CLI is far from complete on those platforms is not going to be a "small irritating issue", nor is the fact that you have to go use SharpDevelop instead of Visual C# if you even want to try and write cross-platform programs. My issues with it are personal taste, sure, but then I did also say that I haven't done enough programming with C# to be able to say categorically that there aren't other huge problems with C# or indeed other huge benefits with C#. It could easily be much better or much worse than I have found it to be when you start getting deep into a big project.


Well, no, obviously I wouldn't agree. I'm not using the B3DSDK now, nor would I have done if they had released it three years earlier. Back then, I had no idea that a more powerful language would benefit me so much, so there's no way I'd have started using B3D's graphics engine in C++ or C#. And now I have TV3D which is far more powerful. Evidently, I am using BlitzMax, so for me it was obviously much better that they did what they did.

Or were you asking me if I agree it would have been better from BRL's point of view? I really couldn't speak for them, but I do note that the B3DSDK forum is very, very quiet, so I wouldn't have thought sales have been soaring. Then again, as you say, they could have done it three years ago if they hadn't developed BlitzMax, so perhaps it would have been much more popular then. There were less alternatives and it was less dated. So possibly.

Wow.. it's been awhile, but the same old arguments about OO and same misconceptions still exist here..

Here's the unpopular truth:

Over here in the states, universities offer Java, C# and C++ as 101-level classes. "Basic" as you know it is not even a skill that is being offered to teach future programmers. Nor is offered to those that intend to just use it casually (such as those learning it just to get a math credit against their major). From my understanding, some high school curriculums now utilize Python to teach their elective programming classes.

So, the misconception that beginners can't learn OO syntaxes has already been largely disproven. At the risk of offending some of you, I'd say the issue is more along the lines of intimidation, fear and complacency. It's different, it's scary, you have no desire to learn something new, even if it's a skill you will easily carry over to the other scary languages. Therefore it's bad. If 1/2 the energy complaining about the evils of OO were applied toward actually learning about it, you'd probably see how well its model-based ideas fits into the paradigm of simulation programming (which is really what most games are).

From a non-selfish perspective, why would Mark want to pursue a demographic that, while obviously very vocal, is going to be in the very small minority in the future?

To further support a point John Galt has been making, object oriented approach has nothing to do with the syntax anyway. Just because you have a "class" keyword, doesn't mean you are developing an object oriented program. You wouldn't believe the number of applicant's code-samples that come across my desk that, while written in C#, a supposed OO language, are very procedural in nature.

Someone mentioned something about standards. They do exist to a large degree in object oriented design. Usually they are referred to as "patterns and best practice". And again, these are markers of design, rather than syntax. So, you can apply these standards to Blitz as well as C# or Java.



Assuming you're referring to "modules" as just chunks of code you can call from anywhere and act like a singleton, you're probably not familiar with static classes, methods and members in C#, which accomplishes exactly that. Incidentally, this is the easiest way to make a very procedural c# program.


But if you can easily re-write the library to utilize your desired output, you only have to do that once, save off the .dll as a class library, and use it in all future projects instead of the one in the .Net framework.



You can call external and "unsafe" code in c# through the extern keyword and unsafe code blocks. The .Net framework will wrap the call for you as well.

If you want to in-line C++ source, you can have C++, VB, IronPython, or any other .net language intermixed within a Visual studio solution. They just need to be in separate projects since they are compiled to IL at that level.


The lack of strict memory management in native code is one of the reasons why Vista has been such a burden for so many people. Contrary to what many think, the enormous amount of incompatibilities encountered on Vista have more to do with the programs they are running than the operating system itself. The problem being that these rogue programs make "insecure" calls that either cause the application to act like a system administrator and do things the application shouldn't be doing (this is why it's so easy to target windows for viruses), or attempt to access memory outside of it's allocated memory space. Thus the annoying warning message pop-ups.

Memory management ensures that the application does not violate boundaries, and if implemented system-wide will make O.S. incredibly stable. XP implemented some of this already in it's OS, and as I eluded to above, even more so in Vista. But OS-level implementation doesn't go far enough to protect memory consumption while an application is actually executing. Sure, you could manage this yourself, but a managed runtime environment like .net or java is going to know more about the current state of memory and the best time to dispose of your out-of-scope items than you will. Plus, if you take advantage of the abstract nature of this, your applications will benefit from improvements Sun or Microsoft makes to the disposal process without ever having to re-code for it. Same can be said for Marks implementation within BMax (though in his case, you'd have to at least re-compile since there's no JIT)


It's a code-agnostic look into software design. I agree alot of books contradict each other. Code complete certainly has it's opinions, and I don't agree 100% with all of them either. But at least it gives good reasons for the opinions it presents, which, right or wrong allow you to judge that for yourself. I'd say a vast majority of the book is pretty close to the mark.


Case sensitivity at the compiler level is useful if the IDE doesn't auto-correct the casing of your declared variables/methods. Typically, case sensitivity is enforced to eliminate a compiler pass to "normalize" the references in the source code. As a side effect, it makes the code more readable and consistent by enforcing each reference to look the same. Anyone that's worked on a mult-programmer application, where there's no consistent set of programming standards quickly grows to appreciate the case-sensitivity enforcement of most compilers.

There are also some issues with case-insensitivity when unicode enters the mix. I'm indifferent until it bites me, but there is a reason why case sensitivity exists in the first place.


Not entirely impossible. First step would be to make BMAX compile to IL rather than native code. From there, wrap the XNA framework calls within BMAX's equivalent commands and make sure the application doesn't fall outside of the constraints of an XNA project (i.e. do not reference any libraries the XBOX's JIT doesn't have access to, such as the standard Windows UI/Forms libraries).

Heck, if it targetted .Net/XNA and Java/LWJGL and could emit both assemblies and java byte code, it would be worth it's weight in gold from a platform independence standpoint.

XNA targets C# mostly because the team within Microsoft that's responsible for it is very small. From my understanding, using any of the .Net languages is plausible if you're very careful about the libraries you reference.

Not that I'm going to be in that environment any time soon, but... yup.

Nice read there Rocket! :)

May I suggest a lock + continue_in_a_#2?

No, I wasn't talking about just chunks of code you can call from anywhere and act like a singleton, and I am aware of static classes. Modules could contain a static class, but they're much, much more than that. They can be as little as a few procedural functions or they can contain a few hundred classes. They can contain BlitzMax code, C Code, C++ code or a combination of all of the above. They have their own namespace too. They're much more akin to a class library.


Sure, but as as I already said, I just don't like class modules. I find it messy having DLL's all over the place, and there's no forced structure about them. I can put the source to a class module anywhere I like, and I'm lazy, so I probably will. When I come to back up all my class modules, where are they? All over the hard drive, of course, because I'm just that disorganized.

BlitzMax forces me to keep all my modules in one place, which I guess could be viewed as restrictive, but I find it a helpful restriction because it stops me from being stupid and lazy, which I am prone to be. I guess it's akin to SuperStrict forcing me to explicitly declare variables. It saves me from myself.


I know how it's done, I just don't think it's as elegant as it is with BlitzMax. Again, this may be because BlitzMax has modules and you can encompass all your external code in one of those.


I completely agree. It's obvious from a quick read of the BlitzMax beginners forum that complete beginners are almost always happy to jump straight into OOP, and you see a lot less people struggling with types, in fact, than you did with B3D where they are somewhat "bolted on".

I can guarantee you that no such effort will ever be made. It is a good idea for cooperation with a major company, and thus contrary to the very character of BRL.

Ahh.. ok.
Unlike java, C# doesn't require you to have one class/namespace per file, so you could at least put multiple unrelated C# namespaces/classes/methods, in one monolithic file.

There are plenty of good reasons why you shouldn't do that (whether it's homogenius C# code or a mixture of a bunch of other languages), but that's more of a coding standards/best practice debate.


I agree. It's messy to have dll's all over the place. But then, there's really no reason for it. And there's really no getting around class modules in any OO language (or OO-ish language), including Blitz. So you're going to be miserable for your remaining days as a programmer, or you'll learn to embrace it :)

Heck, the .Net Math module is a class library. It just happens to reside in the GAC (which I suppose is an option for your own modules as well)

You also don't have to reference DLLs. Studio also lets you reference other projects, and will use relative paths when possible to find them.

If you must reference DLLs, make a "libraries" folder outside of your project and reference them.

Studio doesn't have any real "enforced" organization standards, but there are some implied ones mostly borrowed from Java. For instance, folders in a project represent a subdivision of a name-space, and when you add a class under that folder, it will append the folder name to the generated name space of that file.

By default and when VS interacts with source control programs, it tends to want you to organize your code folder stucture in a Solution->Project->Namespace->file(s) fashion.

I personally don't agree that solution folder should be the root of all it's referenced project files (what if you want to share those projects in a different solution?), so I usually end up re-organizing and re-pointing my solution files (which is not always a very pleasant experience).

I guess the point here is to make a structure you're comfortable with that doesn't bend the rules too much and be consistent about it. You might end up fighting the system on a few things, but you will eventually bend it to your will.



Elegant is apparently subjective.

Typically in an OO design, you keep all calls (external or not) in the class in which it's relevant. Having one big monolithic file to handle things like violates this principle and creates artificial dependencies that could potentially bite you later.

But again, that's another organizational debate. A good chunk of OO design is understanding how to effectively organize your class and service layers so that they are well focussed and their functionality scope doesn't creep outside of their purposes.


Unfortunately, I'd agree with you here. I've said this a number of times in the past: BMax should be targetting "abstract" JIT compilers and emitting java byte-code and/or .Net assemblies, rather than compiling straight to native code (though that would be a nice 3rd option to make everyone happy). Abstract compilers are not going away, and I'd wager that this is where the future of software development of 4GL's will continue to ground themselves in. Even Delphi recently bit the bullet and now targets .Net.

Scalability across multiple competing O.S's (as well as moving from 32 to 64 bit processors) will further strengthen the position. Imagine how quickly operating systems could evolve if backward compatibility issues for software were resolved simply by writing a compiler that resides at the operating system level.

Also, the burden of the compiler itself and it's optimizations wouldn't be on BRL. Imagine the amount of time that would free up to do other things...

I know many disagree with me on this point, but XNA portability is just one of the scenarios that would be a step closer to possible under that situation. I know some also would disagree with the focus not being on compatibility with older machines (which is what targetting non-native code somewhat implies). To that, I'd say the future lies in the future, not the past.

There is currently no language that abstracts above those two targets (java and .Net). I'd say any language that can pull that off and generate binaries that target both of those platforms will gain a LOT of attention in the entire development community (not just the game development community)

It seems that I am obviously not the only one here who does not see BlitzMax as a game development language (only).

But still, I don't see the advantage of targeting the Java VM, unless you want to write slow and resource hungry desktop apps with a non-native/Swing-Look & Feel (just think Netbeans here). Java still sucks for desktop apps; it's a server platform and won't grow out of that niche anymore.

I also don't see a real advantage of targeting .NET either, unless you are only interested in Windows. Mono might be nice for GNU/Linux, but it sucks on OS X, and that is the only other accepted desktop platform besides Windows. No non-technical folks use GNU/Linux, and the geek market is very small compared to the consumer and corporate markets.

I'd rather like to see native support for some mobile platforms, especially OS X for iPhone/iPod Touch.

But if you are serious about any of this, your only option is to raise a good deal of money and buy BlitzMax from BRL and start your own company that markets, sells and develops BlitzMax as a serious and professional application development tool from then on.

I obviously haven't voiced my opinion then! ;-) I use BlitzMax solely for making applications/utilities - I'm not as much into making games, but MaxGUI is perfect for knocking up applications quickly and easily.


No - BlitzMax applications should be able to run by themselves with little or no framework other than the OS/Graphics API.


Neither do I - I DON'T LIKE .NET AT ALL! Pretty much for the same reason as above.


MaxGUI Mobile - I like it!


Something/body is needed to show the world BlitzMax and mark its place amongst the other Indie languages out there - only then will it get the respect it deserves.

Sooo.... no one has come up with a reason why OOP in Blitz is a problem, except CS_TBL, who said people replying to questions with OOP examples can be off-putting for beginners.

@CS_TBL- How come you have recently answered a question in the BlitzMax beginner's area with an example using a method. Isn't this exactly the sort of thing you were arguing is alienating newbies?

I'm with Winni on a few issues- I have no interest in Max executables requiring .net. An option to spit out java code would be a nice extra for creating web applications, but I wouldn't want it to be the default.

The other thing needed is to be told when there are unused variables around. Unused methods and types too would be even better.

That might have been true years ago, but it's certainly not the case anymore. JIT compiled Java programs run fast enough, especially on modern hardware, to execute at acceptable speeds.

One of my favorite IDEs is written in Java.
But the real concern here is games, right?

look here...
http://www.youtube.com/watch?v=at_4jBuwJ28

here...
http://youtube.com/watch?v=VOUpzzo5ykM&feature=related

or if you're interested in 2D, here...
http://www.groovyrobot.com/

and there are more demos out there if you are curious enough to search...

These examples are easily on par with something that could be created today with BlitzMax and have roughly the same dependencies (OpenGL, OpenAL, etc). If you could write those in Blitz, and have them target the Java compiler, you've arguably hit a large number of platforms above those that Blitz currently supports (including 64-bit, and mobile--though that would need some tweaking) At the same time, it puts the burden of native-code compiler support outside of BRL. If it went a step further to spit out .Net code, support could extend to Xbox, DirectX9/10 on windows and Zune. On top of that, the user wouldn't have to learn C# or Java to do it.

Java's interpretted origins have given it a bad rep. What many fail to realize is that JIT applications (both in java and .net) haven't been interpretted for years (.net never has been), and are executed as native code at runtime. The major difference is that it's compiled on the fly, and the code is usually optimized and scales to the state of the machine it's executed on. No pre-generated native code is going to ever be able to produce more or less code to make an application run efficiently (well, not without bloating the code with all the possible execution cases, anyway).



And why is that? I can't think of a single good reason in 2008 why this should be a requirement.

BlitzMax's module system itself is a framework that abstracts away from the underlying operating system. The only difference is that the modules get distributed with the app on an as-needed basis. While there is some benefits to this, you do distribute copies of shared libraries over and over. It would sort of be akin to shipping internet explorer with every document you create. The frameworks should be looked at in the same light (and already have by those that are behind the technology):

Just like IE, .Net is pre-installed on Vista. Java is pre-installed on linux and MacOS. Most mobile phones include Java (rumor has it, the next iPhone will have it as well. Android OS phones will definitely have it) Worrying about pre-requisites is a mindset that attempts to sympathize with a dying demographic. Is it a concern now? Sure, to a minor extent. But it's a concern that shrinks daily.

And there are ways of silently embedding the java compiler into your application in such a way that only your application will utilize it.

Besides, one could argue that getting the latest OpenGL driver for your PC's video configuration is usually magnitudes harder than getting the latest JVM or .Net framework. Your installer can tell your clients where they need to go and possibly even automate the process.

I'm not sure what you mean by one file. If you mean the source, a BlitzMax module is in one root folder, but it can have any number of source files in it, and indeed any number of folders off that root. If you mean the object, you don't have to have one big module compiling to one big chunk of object data. Modules can import other modules, so you can break the modules down into as little or as much as makes sense in any one module. This can even be built into a hierarchy, so you could have a game engine module which consists of several other modules, one of which is a 3d module, which itself consists of a camera module, a mesh module, a shader module, etc.

@Gabriel:
What you're describing sort of sounds like a "project" in Visual Studio-ese. As you probably know, projects build down to .dll's or .exe's. However, they are not limited to containing just representations of your source code. You can put whatever type of file you want in a project, and if you specify it to do so, it will embed the resource into the .dll or .exe.

Or maybe I'm not entirely sure what you're talking about, and if that's the case, I'll refrain from further comment to not risk saying something incorrect. :) I thought you were saying that you wanted a single file that contained more than just source in it.