Improving Bmax

After reading this I wonder who is working on Bmax from BRL. I doubt whether the product is going to evolve much more officially so I wonder there'll come a time when the community improve the official modules as changes are unlikely to get overwritten as often (if at all).

Seeing Mark adding to his worklog and commenting stuff shows that he is reading this forum. I don't know if he is the only one at BRL, but at least the way bugs are handled should improve. The way the community commits to posted bugs (double checking bugs, posting comments and possible fixes etc...) is very good in my eyes, but BRL should be part of this. Well, fixes provided by the community went into BMax in the past (at least some), but most of them without a word...

I don't think its fair to assume that Mark reads every single thread on this forum. Does anybody?

Rather than assuming nobody is working on Blitzmax any more because a community member fixed something, how about entertaining the idea that they just missed the thread?

tonyg, I think one does not need to read this forum to get the disturbing feeling that the development of BlitzMax has been frozen. There are regular minor updates to the SVN repository, but there is nothing large going on for BlitzMax.

After the latest announcements, it became very obvious that the new 3D engine is the only priority for BRL. If that is not compatible with your own plans and strategy, you sooner or later will have to face some unattractive realities about BlitzMax as your tool of choice.

Is there something wrong with Blitzmax that you're waiting for a fix for?

I don't think BRL can win. If they work on Max3D, everybody moans that there's no Blitzmax 2D updates. If they release 2D updates, everybody nags for Max3D.

Uh-oh, this kind of thread is kind of like a way of killing off BlitzMax and rendering it `old`. As soon as we start to think of it as being undeveloped and having to support improvements ourselves that's the beginning of the end ;-D

That said you do have a point, there hasn't been a max update for a while and it doesn't look like Mark is adding much to the language now except for the whole 3D engine.

Yep, I think that's because there comes a time when there isn't anything more to be added. I'm sure the C++ purists will be along shortly to reel off a few ideas about what Blitzmax could do but doesn't [need to].

Grey Alien, Anawiki and several others are doing fine with Blitzmax as it is. Why isn't everybody else?

Totally agree, what BlitzMax needs now is a native 3D renderer for its own good.

Maybe we're not all making the same games ( or indeed making games at all ) that you, Grey Alien and Anawiki are. I wasn't aware that development should cease just because the three of you have what you need.


I'm hardly a C++ purist, more of a C++ hater in fact, and I can think of plenty of things which could be added, and would be a big help for me. Granted I'm not you, Grey Alien or Anawiki, so I possibly don't count.

There's always room for improvement...

I've generally found BRL very receptive of ideas and code-tweaks to BlitzMax.

I suppose the reason I come upon situations where a code-tweak is necessary (like recently for BRL.Audio), is that I tend to push BlitzMax in directions that perhaps Mark & co didn't originally see it heading. It is after all a games programming language, apparently, which sits nice for those that use it in its raw form. For everyone else, we can just keep pushing for improvements. They'll come :-)

@Gabriel, what would you like to see added?

I doubt BMax has seen it's last update. BMax is great as it is, but still has a few bugs, it would be nice to see them fixed officially at some point.

If I had to guess I would say BRL won't release an update until they have a decent amount of fixes done. Releasing an update which only fixes one or two minor things is a bit of a waste of time.

Gfk, Who is moaning?
If there's no development or bug fixes then I have had my £40-£50 worth but think BMAX2D could be so much more and wonder if anybody has considered giving the official modules an overhaul.

Well I'm sure I've said this on a few different threads already, but since you ask, I could personally benefit greatly from properties, weak references and access modifiers ( ones which really work ) and benefit somewhat from overloaded functions, overloaded operators and method pointers. I'd also really like interfaces although possibly you can fake interfaces already with the "new" reflection stuff which I really haven't looked at.

Oddly, I'd also like to see other features added which I wouldn't personally benefit from because I think the people using the language would benefit, and the language itself would benefit. The most standout of those features would be threading. As it stands right now, threading is a big, but forgiveable omission. In a couple of years from now, it's probably going to be a dealbreaker for most people who would want to use it at all, which very much puts a big dent in BlitzMax's shelf life.

I guess this is one of those threads again...

To make it short: I don't really care for 2D or 3D updates, because this whole game thing does not really appear on my radar screen. I care for the BlitzMax language itself and for stuff like multithreading, 64-bit support, extended and bug free(!) MaxGUI features (especially for the Mac), and an OS X iPhone port of the whole thing would be more than lovely.

Objective-C was not made for little Winni, but I am afraid that I have to admit defeat and finally start learning it.

But if I will get that new job next week or so, I will have to re-focus completely and dive into Java, Delphi, C# and C++ (it's a documentation job).

Well no. You can't usually win by throwing in the towel.

What? That's absurd! While there might come a time when you personally are satisfied with what it does, and provided you have no intention of growing as a developer (or at least, not growing any faster than BRL can keep up with) then sure eventually BlitzMAX will be "complete". But the idea that BlitzMAX can do everything other languages can do (and better) is simply wrong.

John Carmack, Tim Sweeny and several others are doing fine with C++ as it is. Why isn't everybody else? Surely even you see the logical fallacy of this "argument"?

What BlitzMAX needs is the ability to utilize hardware built in this century. What good is a "native" (whatever that means) 3D renderer going to be, if it only works well on hardware you can only buy at garage sales?

If you are not making games then BM is the wrong language for you anyway.

BM is officially (as stated by Skid and to my knowledge on the page as well) only supported for games.
So if you use it for other stuff it might work but if not its your problem.

I agree with that, and first priority.
But screw 3d, screw gui, and screw any other new/updated official modules. All that can be achieved by us, if it hasn't already.

Gui: wxWidgets. Spend an actual day at it, brilliant stuff.
3d: ........look around lol. There's already tons of great 3d engines out there that are far ahead of this 'max3d'. Reinvent the wheel a bit why dont we.
Ide: blide..

I think we need updates that we can't possibly make ourselves to blitz, instead of mark wasting his time on alternatives.


With all the 3rd party modules that have floated to the surface (especially and mainly by Brucey imho), i'm pretty sure that's not true. For the other blitz products maybe, unless you're getting at something else.

wxMax: It certainly is great stuff. But my main focus is on OS X, and wxMax does not give me Cocoa stuff like CoverFlow, or does it? The used wxWidgets implementation uses the now deprecated 32-bit Carbon API only.

"even" me? If you'd thrown such a condescending comment at me a year ago, I'd be giving you both barrels and heading for a one way ticket to Ban City now.

What gets me, is the sheer number of.... people who are still using a language they are clearly desperately unhappy with.

If its that bad, go and find something that isn't.

Right, and these are the choices for the unhappy ones:

Freelancers and folks aiming for an Enterprise-type career: Use Java.

Windows-only application developers: Use Visual C#.NET.

Mac-only application developers: Use Cocoa with Objective-C.

Web folks: Use Flash on the client and Java on the server.

Game engine developers: You already knew that C and C++ are your only real choices in this industry. Whoever is not writing "the next engine (TM)", can use any of the other choices mentioned above.

Maybe Java can be substituted with Python in many cases, it's up to you.

All that being said, can we now go back to asking for new features for BlitzMax, since we are using it because we LIKE it and would just love to do more with it than BRL put on its marketing list?

I really must read things a completely different way to yourself. What I read is that peope are so happy with Bmax and its openess that they want more.

BlitzMax has some really nice features. I can load files straight from zip archives, create a GUI app in a few lines of code, and sort any object in a binary TMap. It's going to be very painful giving that up and switching to C++, but I don't see any future with BlitzMax in the long run.

Agreed.

I haven't used BlitzMAX in ages. Not much point really. That doesn't mean I don't care about the language tho'. In fact if it were up to the task, it would be my language of choice, but there are simply too many things you need to work around to get even the simplest of things going. I mean having to rely on runtime reflection to ensure that a Class implements a given Interface? Having to use multiple processes and socket communication in order to spread the load of computationally intensive tasks? In 2008? Come on.

That would be a real loss to the community. This is about that guy who makes games that come in cereal boxes, isn't it.

Guido van Rossum and several others think that this is the right way to go -- and that "multithreading is evil": http://www.eecs.berkeley.edu/Pubs/TechRpts/2006/EECS-2006-1.pdf

Personally, I like using threads, especially in network and database GUI applications.

Well they're wrong. While I would agree that it might work for trivial amounts of data, or in a data-driven business application, insofar we're talking video games and their complex object hierarchies and real-time nature, the overhead of using sockets for data interchange quickly becomes so large as to cancel out the benefit of having multiple cores for calculations.

I know where using more than one thread makes sense for me. But it's interesting that especially for games this whole multicore/multithreading thing seems to be a royal pain:
http://interviews.teamxbox.com/xbox/2169/Epic-Games-Tim-Sweeney-Interview/p3/