Blitzmax - A gaming language?

I'm just curious why Blitzmax has a reputation for game design when it has very basic graphics support and pretty much nothing built in related to actual game programming. (Sorry, a 2d image draw and collision detection doesn't qualify as a full out game design language.)

Take out the 2d graphics, audio support and you pretty much have C++ without the syntax bs.

I enjoy programming with the language, but I don't see why it has a repuation for game design when you can actually code anything you want with the language.

Be glad you can actually code (almost) anything you like with it.

I think its reputation for game design is due to the ease of use. Really, setting up your screen, loading images, rotating/scaling and drawing them is a hell lot of easier with BlitzMax than it is with C++ and a random library (have you ever looked into SDL or OpenGL?)

BlitzMax is, without the media libraries pretty much like C and C++. That's true. But BlitzMax comes with libraries that do support media and thus can be considered as a game design tool.

PHP, Python or Perl without all their great additional modules are pretty much the same as well. Though they're all used for different purposes. But all of the have modules as well that allow you to program a game in them.

I'm truly happy that BlitzMax is this flexible, although I wished it was a *bit* more flexible and C++ like.

I think it should be considered a game design language since it has media functions working right out of the box without a lot of hassle to get it to work. Which makes programming games much more productive.

To be honest, I think BlitzMax has a closer resemblance to C# than C++!

Porting C# code to Max is waaayyy easier than shifting C++ over, I find anyway!

Dabz

Because that's what Blitz products have always been about.

If someone would make an ideal gfx/sound lib for C#, and I mean: as simple as BMax gfx commands, no overhead, no bs, would C# then be as easy or practical as BMax?

C# inherently has overhead due to the .NET runtimes. Since you already have that overhead, you might as well use XNA with C#.

Blitzbasic WAS very game focused, it allowed you to do a lot quickly and simply. Mark, having written a number of mainstream games had a very good idea of what a games programmer needed and tried to deliver it in the simplest, fastest and most accessable way. This was done very sucessfully.

Blitz 3D captilised on this and managed to mix together a lot of gaming power in a very simple and accessable package. It also provided a lot of functionality "out of the box" which is what a lot of people where looking for at the time. A lot of people had written off being able to write 3D games as too complicated and difficult. Blitz 3D changed that, it was during this time that Blitz gained it's (PC) reputation as THE gaming basic even with very little marketing.

However the product was never really developed in later years and was tied down by its own strucuture and methods, some short comings where never really satifactorily solved (collisons, shaders, DX7 base etc.). All the while other game development systems clawed back the gap Blitz 3D originally opened up and then eventually supersceded Blitz 3D.

Blitzmax was a lot more ambitious than Blitz 3D and much more open, however I've always felt it lost a LOT of what made it attractive in the first place: ease of use, simplicity, deliver a big payload to the user.

Development on BlitzMax seems to have slowed for a long while so many next generation features that where originally anticipated have not arrived. So Blitzmax is now a bit of a strange offering in that it doesn't have the features of C#, C++, Java but doesn't have the attractive features of Blitzbasic or Blitz 3D either. TBH I'm not sure what the current design goal of Blitzmax is, I don't think anyone really knows for sure.

Darakheart

The big advantage of BMax is that you don't have to use all the new gimmicks. Go without Superstrict, without advanced types, without event-driven structures, and have everything an Int or Float etc. and you're back to the older Blitzes, but with those few nice extra bits such as incbin, OGL gfx etc.

Moar liek Diet C++

In my opinion:

-To compare it to C/C++ mean you have never used them. Its nothing like it. You have a similar structure and classes and methods of some sort in all oop capable languages, even modern ¨BASICs¨ like BlitzMax.

-Max is a general purpose language but it also has 2D graphics built in using 3DHW acceleration and has a much more powerful set of 2D commands than B3d. It has built in sound support so yes its a ¨games/multimedia¨ language too in its present state. It is ¨a proper language with an optional engine(s)¨. It is not an ¨engine with a built in script compiler¨. Which is much better for a variety of reasons.

-When Max -eventually- gets its 3D module and inevitably 3D sound then yes, it will be a 3D game creator too.

BMax to me is like some handy graphics and sound libraries wrapped with a simple OOP Basic-like language. This makes it fast to make games. I used to use the Allegro library with C++, it was neat.

BlitzMax (the language, not the libraries) is a general purpose programming language, and isn't any more a gaming language than C++, C#, or Java. Personally, I think BRL's strength was never the language - the Blitz language was actually quite inferior and tedious to code in compared to something like C. Now with BlitzMax, BRL is competing directly with free languages like C#, and unfortunately it's a losing battle. C# is far far superior to BlitzMax in speed, features, ease of use (IMO), available tools, etc. - not surprising considering huge teams at Microsoft are working on C#, and one or maybe two or three people are working on BlitzMax. If BRL is to compete, I think they should focus on what they did best - making 3D game SDKs - and open Max3D to C#, C++, etc.

Exactly, so now we have the best of -both- worlds, a dedicated game language by default (with its own 2D and sound system(+soon 3d with max3d)) -OR- it can be used as a general purpose one because modules can be added, changed or removed for the more advanced use.

For people to say ¨I wont use any advanced features like oop, so they shouldn´t exist is ludicrous¨ JUST DONT USE THEM. If you want B3D, simply use it as B3D.

Take the same away from b3d or dbp and there is not much left either. Anyway Max´s 2D is fast and has more than enough features for some great 2D games.

The main difference is that BlitzMAX doesn't really have any libraries that let you code anything BUT games in it, which is probably why most people see it as a hobbist/game language. No persistence framework, no regular expressions, no XML support, no multithreading, no proper unit test framework, no deployment tools, and so on.

Try writing a distributed webservice using BlitzMAX. Sure you can do it, but it would be more a matter of "proving FlameDuck wrong" than "practical application", and doing it in C# would be several orders of magnitude easier, and given the lack of multithreading in BlitzMAX, it would also perform much, much better.

Sure. But if you're going to be writing a ton of boilerplate code to get all your usual C++ libraries working in BlitzMAX, there's a certain point where you might as well write the whole thing in C++ anyway, or just skip right to C#.

True, however, my point was merely; that once it has a full deck of cards including 3D, most will never have to mess about as almost everything they will be included in the native stuff.

That's just it. It's a language, not a game engine. This language makes it easier to get a game up and running, but it's certainly not going to provide you with high-level feature sets as a dedicated game engine.

All of those libraries you say that are missing... Don't you know who Brucey is? Most of the type of modules you mentioned are there now. Both Perl, PHP (and I think Python as well) have these kind of modules as well, also created by the community.

What's the difference? The less bloated the language (like PHP is imo) the better. BMX is in it's core pretty clean. The modular nature of it is great and the default modules are fine as they are. Keeping it clean and minimalistic.

The reason for this is that most people confuse BlitzMax with DarkBasic, when it actually is a more efficient alternative to CPP.

Now you're just being silly, Mr Duck.

How is it more efficient than C++?

Probably it is quicker to knock out crap in BlitzMax as it is to knock out crap in C++ :-)


I would have to agree.

Well, yeah. it is.
Thats the whole point in using an engine module. It gives whatever language you are using just that, a dedicated, standard command set and handles all the ´under the hood´ processing thus adding to and changing your ´language´ into the engine´s language by adding those ¨feature sets¨.
Take away all the graphics(engine) commands away from B3D or DBP and you would be left with a rather compact and featureless version of BASIC too so i dont really see your point.

Unless of course you want some lame creategame() function.

Usually the "Blitzmax is game-oriented" crap comes when people complain about MaxGUI, in any other case, the statement is pretty silly all together when you discover 3rd party modules.



Really? You have plenty of modules (wrapped or not) that remove those ugly limitations, but there really isn't any OFFICIAL 'blitzmax' (blitzmax != Brucey [Wish it did]) libraries that really extend blitzmax' usage.
Many of us are not even working on games, but how many freaking modules did we have to install, or make ourselves to get anywhere doing anything else?
Take into account the amount of other modules that required wrapping and then licence fees on release.

so

No wrapping required, c++ has plenty of free ide's (Minus the fee for blitz products), and since it has been around, it already has a million libraries for pretty much any use, along with multithreading and the rest of the crap that's whined about by us.
The only thing making blitzmax 'efficient' is the simplified libraries that can already be met outside the blitz world.

Blitzmax is basically a language of wrapped functions. What makes you think throwing together some simplified libraries for c++ won't make things just as easy (and more flexible)?

I mean the coding process is much more efficient in BMX, not the code execution. Compare the sources for win32maxgui (C++) and win32maxguiex (BMX). The BMX version is much simpler and easier to edit, yet they do the same exact thing.

I don't really care about any of BMX's default libraries. Most of them are very basic and lack important functionality, like the sound module has no 3D spatialization. I think the cross-platform attempt of the modules compromises their features, and it all seems like a huge drag for one person to maintain.

I am more interested in BMX the language. I'd be happier if BMX added multithreading and dropped all the default libraries, since I usually replace them with third-party libs from SourceForge. I mean, just about every kind of library already exists as a C++ lib that can be easily imported, so why keep reinventing the wheel? What Mark should do is send modules of different libraries to the authors, to be included in the distribution. When Khronos releases an OpenGL3 header, they should include a BMX module with it.

Outsourcing MaxGUI was a good move. It doesn't make sense for Mark to be wasting time writing modules when they usually get replaced by something better. He's the only person who can tend to the BMX core, and I wish he would stick to that.

Regarding Max3D, I don't worry about competition, because our primary market is C++ programmers, and about half our BMX users only bought BMX after getting our engine. So I would like to think my opinion is unbiased.

Well it's good that we've proved beyond all reasonable doubt that BlitzMax is no good for developing games. That will make it much easier for everyone to explain why they haven't written any.

A module is a module, and modules really extend a language.

Then again I have only written one half-finished game in Blitzmax so I don't know much about it. ;)

So true.

But i'm coming to the conclusion (again and again) that we are re-inventing the same debate that gathers no production, over and over and over.

We are topic terrorists trying to get some attention from an ignorant government =P

Sure.

Indeed. So after nearly three years, BlitzMAX is (mostly) delivering about the same subset of features as .Net and Java have done out of the box for ages. Providing you happen to know they even exist.

Sure. Let's see. Brucey, Gabriel, Leadwerks, and Grey Alien. Out of these 4, 3 provide extended functionality exclusively for games. Yeah. It's such a mystery why BlitzMAX is perceived as a games language.

Not really. I openly acknowledge that you've contributed more to making BlitzMAX a powerful and useful language than pretty much anyone else. However my original statement still stands. Your efforts, as awe inspiring as they are, still amount to little more than "catching up to everyone else".

Amen.

And anyone who is using blitzmax for blitz3d, is using the wrong language. Minib3d, as good as it is, still isn't as good as the blitz3d commands.

Hell i've tried out blitzmax. And i can see where it would be a great language to use. But not as a replacement for blitz3d, in it's current state, IMO.

I hope that was sarcasm, because besides all the games ready written and being written you're dead wrong. I suspect most like myself are waiting for Max3D and using the time to learn something else until then(in my case bm+irrlicht). Its slow going though because irrlicht is not B3D-like so requires re-learning from scratch.

"I think its reputation for game design is due to the ease of use. Really, setting up your screen, loading images, rotating/scaling and drawing them is a hell lot of easier with BlitzMax than it is with C++ and a random library (have you ever looked into SDL or OpenGL?)"

I have to admit, this is very true. It's nice not having to worry about the low level code to handle all that. But in reality, that just saves an initial research trial and error period.

Don't get me wrong, I really like Blitzmax, but I'm starting to wonder where this language is going? It's not really a game design language, it's not really an application devlopment language, it's somewhere between basic and C#, etc, etc.

I'm on the Bmax bandwagon for now for 2 reasons only. It runs on Vista and it allows me to compile a mac/linux version. ;)

It's not really a game design language, it's not really an application devlopment language

A poor marketing strategy ? maybe

The amount of money I've made from Blitz-created games would seem to indicate otherwise.

Basically I think IMHO its because its better suited at creating games than anything else.

What GFK and Edz said. To think otherwise is just... wrong.

its because its better suited at creating games than anything

Which one ?
BMAX or Blitz3d ?
Everybody here, likes blitz3d .
As far as money is concerned I have my personal theory
Blitz is good , no question, but ,even more important, Blitzers are realistic people
do you attend other game engine forums , on a regular basis?
They alwayes speak of special effects ( shader and all those stuff)
They dream to develop AAA games
That's why (some) Blitzers make money (and find good paid jobs..see Gray Alien) while the others spend money

-Which what ?
-BlitzMax for new projects.
-Agreed, however things have moved on, its DX7, windows only and aparently impossible to update so now i am putting it in the place i hold the spectrum, amiga and other things i loved dearly but are no longer practical to me. Now i am looking forward to the day BlitzMax is a complete suite if it doesnt come to pass i will begrudgingly find something else.
-I would say so.
yes
-Many will, most wont. Personally i dont care about AAA or SFX other than it would be nice to do all those things i wished the hardware could handle in B3D (shadows, bump/normal maps etc) but platform independent.
-Im not complaining. I recently sent all my money on an 6 bed apartment if that counts (with a view to renting out half of it). Blitz paid the 15% deposit and a few holidays.
I am not full time though, wish i was but it is too bigger gamble to take.

Not me. It still doesn't work on the TabletPC. Also, what D4NM4N said.

First of all, since you don't know what he's making, you can't say for sure it's a "good paid job" [sic]. Secondly some (most?) of us already have jobs that pay well. Thirdly even an entry level Visual Basic programmer is likely to make more money 9-5ing it than practically everyone here.

So if it's all about the money, you're definitely in the wrong game.

GFK - "The amount of money I've made from Blitz-created games would seem to indicate otherwise."

Nice! Do you have a link to those games?

So.. everything has to be official for it to matter?

MGE, before you get over-excited (and not to be unfair to or belittle GFK who has genuinely worked extremly hard to be very sucessful (if not in fact THE most sucessful person),with his Blitz Creations), based on the hours worked and annual salary he would have made more money just working at Mc Donald's.

Due to the lack of any real progress on the Blitz front for a while some people are just more interested in point scoring than anything else.

Without a "full-feature" official offering BlitzMax is crippled and compares poorly to "mainstream" languages. There are some diehards that still believe that "one day" their time will come but I don't think it will. Blitz was the latest and greatest thing, but that time was some while ago.

Darkheart

@Plash

I think you missed something.
Blitzmax on its own can't really do much without 3rd party additions.



What ever do you mean? Xylvan made millions!

It would seem the only people who make money in this field are the ones that take their time, and don't jump the gun in hopes from desperation to prove something. This must be the case with Fairway Solitare, Tank Universal [becoming], and whatever it is that GFK published (???).

What's stopping the user from installing those 3rd party additions?

@Flameduck

What part of Blitz3D doesn't work on your tablet PC? Mine works and I'm running XP Tablet Edition. You do have to turn off advanced text services but that's about it. Oh and the debugger doesn't work but I don't really use it anyway.

Blitz3d was a gaming language. I'd say Bmax was a pretty generic programing language with a few useful built in shortcuts. Without a 3D renderer and more game oriented methods it's not comparable to something like B3D for actual game dev. More like C# like a few others have said. In some ways easier to use, only with lousy debugging tools and limited official IDE.

All of it.

Exactly.

Sometimes i'm wondering if the indie/game dev or programming scene generally is kind of different to other markets because people are always complaining (including me) or if it's really a segment were things are mostly not in a shape you would like it to be and you're fighting with uncompleted or somehow not satisfying components. Maybe it's due to that it's so much technology driven and so you're likely always playing catching up.

By the way i don't like Blitz3D, i wouldn't be here if there wasn't BlitzMax. My personal small heaven with BlitzMax would be a few enhancements on the programming side (arrays, lists), a real debugger, mutlithreading support, a reasonable physics engine well integrated (also for the 2d part), a 3d engine which supports those features which are important on a wide range of cards and all this working crossplatfrom oh and ongoing steady worklog updates. ;O)

How was B3D any more a gaming language than BlitzMAX+3DMod (especially the native one when it finally comes out)
Im guessing you have missed the millions of posts/worklog discussions about the WIP Max3D (and MiniB3D in the meantime).
I wish people would stop saying its like C/C++/c#, syntactically ITS NOTHING REMOTELY LIKE C.
It is BASIC. Evolved "Blitz-basic" in fact.
Its sooo much easier to use, in fact it can be used in a very similar way to B3D with auto variable declarations, non oop procedural code, you can even use horrid "gotos" if thats your bag!
I agree about the debugger needing some work but the latest release of the IDE is much better than B3Ds native one.

Here's something I wrote out recently. The way I see it, BMX will drastically cut down your development and maintainence time/costs, which boils down to more money for you per unit work. The only disadvantage it has is no multithreading support.

			C++		BMX		C#		DirectX10		OpenGL3

Platforms		All		All		Windows		Windows Vista		All
Speed of Development	Slow		Fast		Fast		-			-
Multithreading		Yes		No		Yes		-			-
Works with OpenGL	Yes		Yes		Yes
Works with DX		Yes		No		Yes

BMX ???

More or less agree. It'll cut down your initial development cost, so your time to market. For a game, good on you. For an application you plan to offer ongoing support for, maintenance is going to be much more cumbersome than with C# or Java, due in part to shortcomings in the language, and partly due to lack of tools.

So yeah. Game language.

Maybe Leadwerks meant 'Works with DX9'? In this case there is not an official support.

I really don't understand the topic of this thread 'Blitzmax - A gaming language?'. Is ASM a gaming language? or C++?
I think it's not the language itself, but the tools that come with it: if you have a 3d editor/world editor - 3d format converter and so on...is quite easy to define the 'language' a 'gaming language'.
If Bmax+MaxGUI comes with a GUI editor can be considered an 'application language'?

True.

So you're saying, take out the graphics, sound, collison detection (and don't forget easy joystick and keyboard input, built in lists), i.e. All the things that make game writing less of a chore, and you have C++? What do you have if you take all of those things away from Torque, ClickTeam <insert your favourite game creation tool here>?

Um. No. :-p

However MaxGUI is advertised as being used for both games and applications.

Blitzmax supports directX if the module supports directX eg. irrlicht.core or B3Dsdk.
The native stuff is OGL. (I think thats what he means)

Yes it is, there's "if then else", while loops, functions, switch statements, constants, variables. All these high level procedural/functional/object oriented languages (C++, PHP, Perl, Javascript, Blitz Basic, Blitz Max etc etc) share a lot in their syntaxes. Learn one and you know them all, save for a few details and working experience. Like "oh I know Select, how do I do that in this language, oh I see it's called Switch". No big difference. Or "oh here I use { and } instead of Begin and End". Again only a small lexical difference, same syntax.

So you are saying EVERY language is just like C... WTF :S

Seriously, i know what you are trying to say, but no, as far as syntax goes, bmax -IS- modern BASIC, not C, not C++, not pascal not java, not python.
(C & C++ are classed as 'middle level' languages, not high level because of the need for direct unconditional memory access and lack of GC for starters)

Nothing. The fact is that blitzmax comes as-is without support for anything truly useful AS IS.

As Flameduck said:



None without the additions from the users. The users seem to be supplying everything, like a P2P language. This is only because mark doesn't support his own products that everyone else has to do everything. Yet no one complains about that, only about the things we CANNOT do because it is closed source.




Switch MaxGUI with wxMax, and you have an application language =P

MaxGUI is a complete waste of time and money if you're trying to write tools/applications. And its still fairly useless for games. But mark wanted to re-invent that wheel too.

Yes, I think they're all like C.. especially when I'm standing a few meters from the screen. ;)

Conversely, it takes me just as long not to produce anything with BMax as it would with C++. ;o)

I find it funny how everyone thinks this "max3D" will actually surface anytime soon, and choose to use it in an argument defending Blitzmax....

3rd party support is only as good as the supporter for it. Once they find something better to do, the support is gone.

Mark switches gears very frequently. He did great with B3D, but I fear Darkheart is correct, his time is now over as he has lost the potential market he 'had'.

Those of you waiting for Max3D, have a long wait ahead of you which will most likely end in your giving up on 3d games all together. The rest of us (those with an ounce of common sense in us) have moved on to languages and tools that actually deliver on a consistent basis. I give B3D props on what I used it for however it was very short lived in comparison to the amount I can do with currently supported languages/tools such as C#, Unity, and so on.

Regardless of how many worklogs Mark posts hyping the would-be D4NM4N's, I highly doubt we will see the final product.

I agree. I used Blitz3D not for the language, but for the easy to use 3D engine. I bought BlitzMax not for the language, but for the promise that Max3D was coming within a year. And that was many, many years ago.

I've abandoned BlitzMax and moved on to C++ / other engines for a few reasons, but mainly because Max3D was promised but never released. Compared to other languages BlitzMax simply can't compete, so without something that sets it apart from the rest like a 3D engine, it's close to useless for me.

Why use BlitzMax when I can use C#/C++ with tons of libraries instantly available, and language features BlitzMax may never have? I know some people are scared of C/C++ because they see C/C++ code importing libraries into BlitzMax, and it looks cryptic, but they don't realize that it's messy simply because it's trying to make C/C++ code available in BlitzMax. Using C/C++ libraries in C/C++ is extremely easy, once you know how.

Know that for sure do you? I dont mind the wait, and i am actually using c++ for certain projects just now, but it is a hell of a learning curve, even if i was fully proficient in c++ i would still prefer blitzmax as it is so much cleaner, its quicker to produce stuff and will return with the interest in full force when it finally comes out. I have not lost anything in fact i have gained something in the process.
So thanks Mark for taking your time.

No. Assembly is a Second Generation Language, C++ is a Third Generation Language, and BltizMAX is essentially a Fourth Generation Language for games.

No big difference between Switch (you can only switch on constants, and in some cases only integer constants) and Select (you can switch on boolean expressions)? I beg to differ!

The idea that "every language is basically C" is so absurd it's hard to refute, largely because of Poe's Law, and me thinking you're being secretly ironic.

No, I don't. That's why I used a probability clause like this "which will most likely".


Well, it's good that your positive (even if it's based from delusion).


What process? The process of Mark switching gears? Or the process of Blitzmax being incomplete? I fail to see what process your speaking of here that you have gained from? Waiting for something that, by reputation, will take years for release (if at all) is not a process. You using C++ in the mean time just to switch gears yourself if/when Max3D rears it head is not a process nor is it a gain you can chalk up to Max3d.

"Because my car broke down I had to walk 50 miles to work today, so in reality I gained something, and I really must thank my mechanic, as without that walk, I would have never broken my ankle allowing me to take the next 4 months off on disability".


And this argument I am really getting sick of hearing. ITS COMMON THOUGHT THAT A STITCH IN TIME SAVES NINE!!!! Believe it or not, many of us here know (just being programmers) that it's better to take your time doing something and do it right than to just do it fast. Saying "Well I for one am glad he is taking his sweet time, cause I want it done right". Newsflash for those using that worn out old argument that everyone believes anyway: He isn't taking his time to do it right, he is playing with shaders, experimenting with other engines, playing video games, drinking beer, sitting on his arse, and then thinking of other products to make when he looses inspiration.

Yeah, sure, some of you will think that the previous sentence was meant as a cut on Mark. But it is not! Mark, like anyone else, is only human. He has other things to do, and other ambitions to persue. I would highly doubt anyone stating that he works on max3d 8 hours a day, 40 hours a week (specially after seeing his worklogs and his demos and screenshots). Like any other programmer, he goes on inspiration (what am I inspired on today). Max3D, in my opinion, would have little to no inspirational value. Why? Because here he is, with this overwhelming task of creating a 3d engine for a cross platform solution. He has to keep it up-to-date so that by the time it is released, it isn't obsolete, and he has to keep it feature rich. This boils down to thousands of lines of code that has been written before by hundreds of other 3d engine developers. It's not ground breaking, its not original, and in no way is writing vector functions inspirational (specially testing the modules and what not). He's going to get bored (as we have seen), he's going to play with other stuff (as we have seen) and he is going to constantly be questioning his direction (as we have seen).

So sit in your delusional little world. Stay positive; I'll give you my address so when the day comes you can drive by my house and give me a huge "I told you so" followed by the traditional pelvic thrust. And me, being that guy that loves to be proved wrong when it comes to things such as this, will get on my knees and worship you for the statistic breaker you are! But above all forgive those of us who are prone to following a curve, who can see where the interpolated point lies, and have the ability to switch gears ourselves without relying on those who are sitting on their laurels.

:-)

Cheers to that

Wow.

Im not in any delusions. If max3D fails to materialize i will (regretably) simply stick with C++ and/or Bmax+Irrlicht. Still i dont see your problem with people staying positive.
I have faith that BRL will deliver... eventually.

Oh and PS, last time my car broke down and i had to walk a few miles, i actually solved several of my problems by using the 'time out' and nice cross country walk to think clearly.

So next move is BlitzMax++, open source, and Mark disbands BRL??

What switch gear? All of you who have apparently abandoned BlitzMax or Blitz3D are still sitting in General Discussion moaning about BlitzMax or Max3D, or Blitz3D2 or whatever it is you feel aggrieved about. I gotta tell ya, for a bunch of people who have moved on, y'all don't move much.

Yes, I was a little bit ironic, but I was responding to the idea that languages like C/C++ and BlitzMax are "not even remotely" similar. On certain levels such languages are quite similar.

Tinky Winky's Law doesn't help a lot, either.

No truer words have ever been spoken on this forum.

All languages are similar to a certain extent.

All languages end up as assembly, enough said?

No, they end up as machine code. ;)

Lol same-same but readable ;D

@foppy. All modern languages are similar. They all have a -slightly- similar structure, a set of universal "programming rules" to follow (plus a whole load of their own). These days there is usually an oop option expected to all languages be they incarnations of BASIC, C, Pascal or Larrys Language of Love.
Thats where the relationship pretty much ENDS. (I would even compare it more to Pascal before i would compare it to C)

Nicely said. (although i object slightly to the 'all of you' part :P)

I still own all of the BRL products. I am fully welcome to come back and check on progress. It would be a stupid move (financially) to ignore the possibility that Blitzmax can become a viable 3d solution for I have nothing against Blitzmax as a language (in fact I see a lot of potential there) however making a general observation using past and present data doesn't mean that I hate BRL or any of it's products.

But just for you Gabriel, here's a little tid-bit of info. Chances are that there are many individuals that have done far more with B3D in respect to financial return than GFK and Grey Alien. The small fact that we are bound by NDA's and the matter that in some cases we don't do the whole project from start to finish (we aren't the designers, we aren't the artists, we have a piece of the pie we must complete) kinda keeps us on low key with what we actually accomplish. Because we don't advertise in our signatures every product we have made (or worked on) or every dollar we have taken in doesn't mean we are going no where.

But to touch again on my point above, just because I have moved on from BRL products doesn't mean I wouldn't come back if I saw financial gain in doing such. At this point, I see no Max3D ever surfacing (well, within the next 2 years) so for me, and those who have too many contracted projects on their plate, I must look elsewhere for my solutions which maximize my time to profit ratio. I can't submit estimates of labor in terms of "dependent on when Max3D arrives" or "depending on 3rd party support aspirations".

So it all boils down to the all mighty dollar for me, or so dictates the cable company, the water company, the electric company, and my childrens' birthday gifts and their extra circular activities. Sure, I can claim it is all for hobby, however you don't see me using a Betamax in the name of "It's only a hobby, leave me alone". If I don't have some way of falling back on it (even in the slightest), then it's pointless to pursue. Blitmax, as it stands, is pointless to pursue. So sure, the rest of you can wait, and again I'll gladly receive my "I told you so" from all of you when Max3D happens.

There's a few different markets here:

-The Blitz3D users who are stupid to understand BlitzMax, and want Blitz3D2 with integer handles and a completely procedural interface. This is probably where BRL has made the most money in the past.

-The language-focused people who own businesses and want BlitzMax to keep developing. Mark could charge $1000 for multithreading support, and we would pay it, happily.

-The Max3D faithful, who have no knowledge of what Max3D might be like, but will buy it as soon as it is available, based on their god experience with Blitz3D.

I'm right on the edge of switching to C#, but if I do that, I should switch to DX10, because C# is Windows-only. C++ would still be a terrible move, I think, because it would kill productivity, even after I was completely familiar with it. We are so darn productive as it is right now!

I think in the future we're either going to be C#/DirectX or BlitzMax/OpenGL. If we had some way of doing multithreading it would be much easier of a choice. I am missing out on opportunities with Intel right now because I can only program a single-threaded app. More importantly, our renderer is CPU-limited. Determining the object visibility set is what takes the most time, and that is something that can be easily parallelized.

Wow..thank you.

I actually agree in a way, although I'd attribute it to laziness. Many Blitz3D users complain about the "complexity" of BlitzMax OOP syntax and other advanced features when they don't even bother to try it. OOP and other features can be extremely beneficial to productivity, it would truly be "stupid" not to at least try to learn it and find out what all this talk of "object oriented programming", "garbage collection", etc. is about. (although unfortunately BlitzMax is crippled compared to C#, in it's memory leak prone garbage collection technique, etc., so C# would be the best place to start [and continue, IMO])

C# is great. C++ is probably necessary if you want to be at the very forefront though. There are somethings you just can't do as fast with a managed language.

Not important but I don't really understand this either.
Bmax natively supports OGL (1.1? 1.2?) *and* DX7 doesn't it? I don't need any extra modules to use D3D7Max2D or glmax2d.
What am I missing?

I think he meant you have no direct access to the DirectX API. But you do have to the OpenGL API. Correct me if I'm wrong though.

Maybe (i did not know there was a DX module included) but the defaults are OGL as far as i know.
I use it with irrlicht at the moment so its not relevant to me anyway.

BlitzMax 'natively' supports Direct3D7 and Direct3D9 (though it is incomplete) in the same way it 'natively' supports OpenGL.

Htbaa, you do have direct access.
D4NM4N, BRL.DXGraphics.

GFK - "The amount of money I've made from Blitz-created games would seem to indicate otherwise."

I'd love to see some of your work GFK!

I mean programming the DX10 API, not some crappy 2D DX7 commands.

I haven't seen too many bug reports of memory leaks. Those that are often turn out not to be a leak more a misunderstanding how GC runs.
Oh.. although you didn't cite that as a disadvantage? I am a bit surprised nobody has created a DX8/DX9/DX10 interface though. I wonder if there's a market for it?

OK. Thanks for correcting me Khomy Prime :-). I wonder why only direct access to the OpenGL command set is being mentioned on the BlitzMax product page, and not DirectX.

BlitzMax is mainly about the fun and doing some prototyping. I kind of get the same feelings when starting up AsmOne. :O) For making money other tools are suited better, at least for my current work.

Oh and C# isn't Windows only.

Buzzword
Powerboat Racing
Par Fore (so sorry about the box-art - nothing to do with me)
Tennis Ace

There's more (Hole in One, Double Top, Operation Overkill, Arcade Chess, Maxx GP, Maxx Trucks, Arcade Bowling) but I don't like any of those. Some were developed from start to finish in around a month and let's just say that they aren't what they could have been.

Hole in One was OK - well, Flameduck liked it, but it doesn't seem to be on sale any more since its nearly eight years old now.

Old screenshot of my current project.

Gfk: Idigicon arent selling stuff that dont work on Vista anymore, I contacted them about Space Combat (a game I called WarZone but they changed the name for some reason or other) and they said they were testing everything with Vista and those that dont work wont appear on the catalogue.

I thought Double Top was OK as well. Is it possible I got it in some 'Choose 3 titles deal' when buying B3D?
<edit> If so, then I chose it over about 100 other titles.
I think I got some horse racing game as well plus one other.

He's talking about circular references, where two objects isolated from the main program reference each other and remain in memory. I think what it came down to is eliminating circular references would have slowed down the GC. I don't think it is a big deal.

I didn't like the GC at first, but I don't mind it now, and if you need you can always write your own Free() method, which I do for complex objects that have to be manually freed.

The only "big deal" is the multithreading stuff. It's not that I have to have it right now, and can't live without it. It's just the fact it is extremely unlikely to ever happen. :( Even PureBasic has support for multiple threads, but I guess Mark lost interest in compilers. No plans for development when a language is already marginally behind = dead language.

I always write my own 'free' routines, comes from coding in C/C++ where everything has to be coded.

Yeah they had it in a few promotions so that's entirely possible.

True, but that defeats much of the purpose of garbage collection. Garbage collection was intended so you could simply set "object = null;" and forget about it, rather than perform some sort of delete operation on it to ensure that it doesn't cause a memory leak. When you start writing "Free()" functions, you might as well throw away the garbage collector and free everything manually again. At least then the way you delete an object would be consistent ("delete object;").

And eliminating circular references is definitely a good practice, but in many algorithms they're almost avoidable (unless you want to sacrifice performance). Circular references happen, not only on purpose, but often when you don't even plan or think about it, forcing you to debug your code to track down the memory leak (which can be even more frustrating than a memory leak in C/C++).

Excactly..

Gfk- Impressive line up! Thanks for the links. :)

What kind of objects can you possibly have where you can just set the variable to null, besides very simple objects? All the objects in my engine are referenced by a list that is a field of the world class, as well as the child entities, parent entity, and anything else that might use it.

It seems like if you want GC for anything else than simple math classes, you are hard-coding too much in your app. I can't even use GC for textures because I store them in a map sorted by file path, so they each only get loaded once.

GC is pretty useless unless you are writing a very simple program, or only relying on it for simple things like math objects. I don't mind it either way, and I am not going to complain about it, but I could go with or without it and it wouldn't make any difference. Even if circular references were detected I would still have to free everything manually. So to me it is just wasted CPU cycles, for most things. But it is nice for my vec3, vec4 mat4, aabb, etc. classes.

Demo of Gfk's Hole In One here.

Heck with Vista, that demo doesn't even work on XP due to DEP issues.

Depending on which version of Blitz3D you have, the demo source code shipped with the Idigicon (physical product) version. You can probably just compile it with the latest Blitz3D and get one that works on both Vista and XP.

And yes it's still a pretty cool game. It has just the level of golf game complexity that I care for.

Windows XP didn't even exist when I started writing Hole in One. Plus, the game was released ages before DEP came along.

I found some screenshots via google. Very nice looking game.

I could be wrong, since I don't use C# every day, but I've written a few prototype apps and code with it, and all my classes (even some fairly complex custom communication protocols) have always been deletable by setting to null.

Remember - if the garbage collector is fully functional and will actually reliably delete anything that is no longer referenced, all you really have to do is null all references to the object, and it will simply disappear. All objects owned by that class will be deleted too, unless something else references them.

For example, a Entity object, might contain a reference to a Mesh object (vertex/index data), a Material object, a few Vector3's (position, scale), etc. Usually you'll keep a list of used Entity's in your main loop or something, and they'll get rendered, etc. To delete an entity, simply removing it from your list will cause it to be no longer referenced, and therefore the Entity, along with some of it's sub-objects, to be deleted. If the Material object or Mesh object was used somewhere else, it will remain in memory thanks to the garbage collector.

That's how I see it, at least. Like I say I may be wrong because I'm not very experienced with GC coding.

John J,
I'm confused, earlier you claimed the bmax GC is memory leak prone and then right above you describe C#'s(which you seem to be happy with).... are you claiming thatis not how the bmax system works? the blitz GC works just fine... it's not any more prone to *programmer created* leaks than what you just described.

Entities are referenced by any children they have, and any entities they are parented to. So at the very minimum there are three references to any entity, plus whatever other complexities might be present. So a manual Free() method is necessary. There are very few cases when manually freeing an object isn't necessary.

Um. No.

If I create the parent object it and make it a global, it has one reference.
If I then create a field/child object on that parent, it has one reference. The parent still has one reference.
If I add a global reference to the child, it now has two references. If I then Null the parent, it has none, and will be GC'd.
Once the parent is GC'd, the child will have one reference, the global...

I thought it was easy to understand how object referencing works. I guess I was wrong?

BMax determines object lifecycle by reference counters when doing GC.
I believe Python does it this way too (or at least it used to)

.Net languages like C# determines object lifecycle by "reachability".

The difference here is that when you're determining garbage collection eligibility by counting references, there's a window of inaccuracy if you have circular references involved (a circular reference will not allow the reference count to reach zero without special handling)

"Reachability" actually keeps track of any references that are "alive". And therefore, circular references can exist and are collected when all objects in the chain are alienated and de-referenced.

Note that this is handled pretty well for anything that's an "instanced" item such as an object or struct. However, things such as event delegates typically have to be cleaned up manually if the object that publishes it doesn't die simultaneously with the subscriber.


Correct. When an object goes out of scope (either by exiting a method/object in which it lives) or by setting it to null, it's no longer "reachable"

All entities have a link to the world for fast iteration.

In fact, all extended entities, like a mesh, have their own link, so that I can quickly iterate through meshes. Plus they have links to scene graph nodes and a million other things.

The way you are thinking of OO and fast rendering don't really work together.

Yes it is. The BlitzMAX GC simply counts references. The .Net and Java GC walk the stack. The BlitzMAX way of doing it is marginally faster (when you're in a single threaded environment) but prone to memory leaks with objects that use cyclic references.

Walking an array is not faster than walking a tree.

It is if most of the objects in the tree are not of the type you are looking for. Let's say you have a "controller" entity that has to be updated every time the physics are updated. You obviously can't iterate through the whole entity tree to find those controller entities, so you need to have them stored directly in a list for fast access.

The more I think about it, GC is generally a bad idea because the few times it works automatically, it is based around dynamic allocation. Static allocation is much faster. Now I like some of the convenience of GC, but I wish it could be turned off for some (most) classes.

Now if BMX had a callback for when the refcount changed, or a way to access the ref count, I could do some neat things with it.

Choosing the wrong data model, is not in itself an argument against automatic garbage collection.

How would you go about handling the example I gave?

In my opinion it's not true "garbage collection" if it leaves memory leaks, as is the case with BlitzMax's implementation (reference counting) with circular references.

Leadwerks: Your example of a child node having a reference to it's parent and to all it's subchildren is true, but I think that's what weak references are for - for example, the "parent" reference would be a weak reference, so to remove a child node (and all it's children), simply remove it from it's parent node's list of children.

But I think you're right that most of the time (with fairly complex systems) you need a Free() function anyway, but I'm not sure. If this is the case, then garbage collection is utterly useless (to me, at least) - manually deleting objects would not only be just as easy, but more predictable and consistent - at least you ALWAYS know how to delete something in C++ - "delete object;" - the constructor will activate and reliably delete the object as you requested.

Can't you turn off GC?
<edit> or put better : GC mode can be switched off. Would that help?

Try GCSuspend() to stop garbage collection if ya dont want it

You must add a GCResume() somewhere apparently as they have to be nested. There is also GCMemAlloced() to get the amount of ram taken by the collector.

GCSetMode( mode ) where mode is 1 for automatic and 2 for manual collection with GCCollect()

No. Unless I'm mistaken, there's no "delete" in BlitzMax. The only other way to delete data in BlitzMax is to use garbage collection.

Good point.

Static allocation has a lot of side effects that lend to bad OO design and can make your app a memory hog. They also create other challenges for multi-threading (which, of course isn't an issue with BMax currently). If you have a lot of meshes, static allocation is going to consume a lot of your system resources, and those aren't let go even when they're not in use. With static allocation, you have to make a guess up front about what your memory consumption is going to be.

Sometimes you can get away with that. I'd guess more often than not, you probably shouldn't.

I think you're confusing what is meant by "static allocation" here. First of all, no game engine where things are managed dynamically can be truly 100% statically allocated. Even if you pre-allocate slots for all your entities, meshes, etc., you still have to implement some sort of dynamic allocation within your static system anyway.

What he means by "static allocation" is this: In C++, every object instance does not need to be dynamically allocated - for example your Entity class can contain Vector3 objects, Quaternion objects, etc., which are all "baked" into the Entity's memory block, rather than allocated individually. In other words when you create a "new Entity()", it requires one dynamic allocation, rather than ten.

Of course you're going to be doing dynamic allocation / deallocation in C++, but compared to BlitzMax/C#/GC languages, there's usually much much less (although it's up to the programmer).

Ah. I see what you're saying.

You can do that in C# too. If you declare something in a static variable, even if it's normally allocated dynamically, it will not be garbage collected until the application terminates.

This still creates challenges for multi-threaded applications though. The performance you gain by allocating the memory statically is lost when you have to repeatedly lock/unlock the context for a thread's read/write operations.

I think you're still misunderstanding. In C++ the default behavior when you add a member variable to a class, it becomes a part of the class's block of memory. For example:

class Entity {
    Vector3 position;     //position value (as a rotation)
    Quaternion rotation;  //rotation value (a quaternion)
    //etc.
};

Vector3 and Quaternion, while being classes themselves, are not individually allocated. Internally, when you make a "new Entity()", it allocates a block of memory large enough for all it's contained data, so the Vector3, Quaternion, etc. instances it contains are allocated at the same time the Entity class is. Similarly, when you delete the Entity, the Vector3 and Quaternion destructors are called, then the entire memory block of Entity is deallocated in a single step.

This way if your Vector3 class takes 12 bytes, your Quaternion takes 16 bytes, etc., then creating an instance of the above Entity class performs one allocation of 28 bytes total. In BlitzMax, it would perform 3 allocations, one of 8 bytes (two 32-bit memory pointers to the position/rotation values), one of 12 bytes, and one of 16 bytes. BlitzMax/C#'s method is slower (3x the allocations in this case) and more memory consuming (36 bytes instead of 28 in this case), and this is a particularly "tame" example.

This has no negative effect on multi-threaded apps as far as I know. You're thinking of global variables.

Ok.. NOW I understand. You're right. I was thinking "globally". In C#, static and "global" are practically synonymous.

You can get *similar* behavior to what you're talking about in C# a couple of different ways. Not exactly, mind you, but similar...

One way is to make sure that Entity, Vector3 and Quaternion are stack-bound objects (which means they have to exist as structs rather than classes). In .Net, the stack's memory is self managed and is not ever GC'ed. Once they are popped, they are gone in one swipe like you mentioned above. Of course, making those objects as structs will limit you in other ways, so this wouldn't be something you could realistically adopt in all circumstances.

Another method is to design your class so that it is GC'ed as efficiently as possible when it's finally destroyed.

To use your example (assuming Vector3 and Quaternion are classes with default constructors):

[Code]
public class Entity {
public Vector3 position = new Vector3();
public Quaternion rotation = new Quaternion();
}
[/code]

When Entity is created by the client code, the child objects Vector3 and Quaternion are created right away. This ensures the objects live next to each other in the heap which allows the GC to remove it in a singular chunk (rather than having to defragment the heap to find all the children that belong to a particular object)

Better yet, mix and match when you can to reduce reference-type objects. If possible, make Vector3 and Quaternion structs. They will be popped from the stack, and Entity will be a single reference to destroy upon GC.

By the way...
For the record, I don't believe managed code is in any way the ideal choice for developing a bleeding edge "game engine".

C++ will always out-perform C# or BlitzMax where it counts most in something like that.

The forte of languages such as C# and Blitzmax are the rapid development and ease of debugging and refactoring when it's acting as a simplified "glue language" layer between native C++/Assembler compiled code. For a "game" consuming "game engine" api's, this is probably good enough 98% of the time.

Even in XNA, C# isn't doing all the difficult, processor intensive operations. It's calling the appropriate DirectX methods (which are undoubtedly unmanaged native C++/Assembler compiled code APIs)

As processors get more powerful, and as developers see the benefit of sacrificing some clock cycles for service oriented and rapid development methodologies, managed code might find it's way up the chain someday.

So... comments such as "Garbage collection is useless" are a little too generalized. Useless for purposes of a game engine, perhaps. Maybe not so much for a client application that sits downstream.

The reality is, and I don't care if you're a game developer or a data base developer... time is money. And your boss (whether it's a manager or the end user community that buys your product) will want your application faster than you can deliver it. The trick is to choose the right tools for the job when that time comes: C++/Assembler for the high performance engine, C#/Blitz/Python/Boo/whatever for the game that glues it altogether.

Considering how many unique "script engines" (Domain Specific Language if you're using a snotty academic term) are baked right into game engines, I'd say that's a proven concept.

Not always. C++ is not faster by default, and as CPU's evolve to embrace visualization and parallelism, C++ will be outperformed by more advanced languages (like Erlang), better suited for that kind of architecture.

The only reason C++ has been around for this long is because CPU's really haven't evolved (just gotten smaller and faster) since the late 70's. But we're hitting the wall now, and we need to find new and imaginative ways to get more computational power, and in the long run, C++ isn't going to cut it. C++ is the new assembly.

It may be a reason, but it's certainly not the only one.


I'm sure it will be obsolete eventually, I just don't see that happening soon, at least not for game engine development. I think C++ will remain at the core of many high performance engines for a while. Maybe in 4 or 5 years.


True, no language is faster by default, but some are inherently more compatible with CPU-friendly optimizations. The fact that Visual C++ exceeds the speed of almost any other language/compiler (including C) proves this. But the fact that Visual C# occasionally exceeds the speed of some slow C++ compilers like GCC also proves that C# might have a fighting chance to compete against C++ as a high performance language in the future (possibly), but I'll wait until the time comes before making assumptions and staking too much time and effort on it.

I'm hopeful that the "easier" languages like C# will win out over C++ over time, but doubtful.

One thing I am noticing is that the average C++ coder is stupider than the average BMX coder. Not in terms of what they can put out, but in terms of their understanding of things.

Riiiight....

The same can be said for ANY language.

>>The fact that Visual C++ exceeds the speed of almost any other language/compiler (including C) proves this.<<

PowerBasic kick ass C++ big time speed regarding..

Naughty Alien: Faster than the latest Microsoft Visual C++ compiler with speed optimizations enabled? Somehow I doubt it. But please, show me where you get that info and if you're right, I'll be surprised.

..initial info came from their web site, and out of pure curiosity me and friend of mine (C++ lover) use to create some float point calculus progys to see what will be time out for both..for latest VC++version i cant say because he didnt use that by time we use to play with..however, try to download trial version of Powerbasic and see for yourself..every single thing we use to run as a test, it was at least 2 times faster than C++..I dont know why but maybe its because Bob Zale use to write Powerbasic compiler purely in Assembly..I dont know, but its damn fast and small exe..

..ihh..this code

x## = 1
y## = 1.000001
t! = Timer
For i& = 1 To 100000000
x## = x## * y##
Next
t! = Timer - t!

7 seconds in B3D
.984 seconds delphi
.1036 seconds Powerbasic

tested just now

I bet you were running in Debug mode, which is usually 5x+ slower than Release mode. Anyway, I'll try that example you gave in C++ and see how fast it is.

Here's how fast your example runs in MS Visual C++ 2005 with full speed optimizations on my old, slow 2.2 GHz AMD Athlon64:

.0203 seconds.

I've run multiple tests, and it usually takes 203 milliseconds, but averages at around 200 because sometimes it's faster. That's 5 times faster than PowerBasic, although I would have to run the powerbasic version on my PC to compare accurately (where can I get a demo?)

In debug mode (without optimizations), it runs reallly slow, around .1200 seconds (similar to your powerbasic time).

Here's the source code:

#include <stdio.h>
#include <time.h>

void main()
{
#ifdef _DEBUG
	printf("WARNING: You are running in debug mode! Results will be extremely slow!\n");
#endif

	double x = 1;
	const double y = 1.000001;

	unsigned long t = clock();
	for (unsigned long i = 1; i <= 100000000; ++i) {
		x *= y;
	}
	t = clock() - t;

	printf("Time: %d milliseconds    %f\n", t, x);

	getchar();
}

..your test rig is faster..ill try later on other machine (2.8Ghz) and let ya know..best way is to download trial and try..

Where can I get the trial? The only "PowerBasic" website I can find looks like it's from the early '90s and only has MS-DOS downloads.

P.S. If you want to try comparing C++ to PowerBasic on your computer, just make sure you're running in Release mode and that you have all the optimizations enabled (optimize for speed, favor speed over size, enable whole program optimization, etc.) If you want I can send you a .zip with all you need to compile it with one click if you have Visual C++ (the free version works just as good).

BTW, this is a very bad way to test it - it's too simple. A more realistic test would have to be much more complex and test multiple areas of the language.

You sure make a lot of over-generalized statements. Not everything is so black and white.


Your average "VB" developer is afraid of terse syntax.

Your average Blitzmax developer is deathly afraid of object oriented concepts.

Your average Java developer is overly thorough because the syntax forces you to declare every exception. (ok, that's not entirely true anymore, but the average ones don' t know this...)

Your average C# developer is a VB, Java or C++ convert, with all of their baggage to go with it.

Average should probably be replaced with "inexperienced"

"Inexperienced" C++ developers are typically very performance centric in their design. Often sacrificing readability, maintainability, scalability, and sometimes stability to acheive it.

Any seasoned developer, C++ or otherwise, will know that squirlly brackets have never killed anyone, object oriented design isn't all that difficult to understand, and not every exception has to be trapped and handled a special way.

These same seasoned developers will also know that while performance is important, it's less of a priority than maintaining some other disciplines of software design. An application that runs very quickly, but crashes often, is going to be less embraced than an application that runs marginally slower and is more stable.

Some may disagree with me on this, but I've found that good performance isn't really measured in clock cycles. It's measured in "acceptable usability". What defines acceptable usability differs from application to application.


Well, there is such a thing as managed C++, so it's always possible that C++ as a language might still be able to create faster code (or at least comparable code) when that future occurs. Perhaps a more precise argument would be to compare managed vs. unmanaged.

That said, there might be some extreme situations where C++ could be outperformed by managed code even today.

Though this wasn't what you were referring to, JIT can give C# an edge in some areas of scalability. JIT compilation can analyze the current state of memory, cpu usage, and available processing, when emitting it's native code from IL. With native code C++ compilers, you're stuck with the native code that you built regardless of the environment.

That could conceivably give a managed code applications better or comparable performance to a C++ counterpart because it can adapt the actual runtime native code in a way that pre-generated native code can't.

But again, as I said, that would only be the case in an extreme condition.

There is a "Sieve of Eratosthenes" reference implementation (as-in all the different versions do the same amount of work, disregarding specific language optimizations, relying only on compiler performance) in pretty much every language you care to test on for just this kind of speed comparison.

Well said.

Very true!


IMO managed C++ is useless. It's like a version of C++ that's hacked to compile to .net - not only is it harder to use than plain C++, but it's just as slow as C#, so it's pointless (compared to C#).


Exactly. And for games, guess what acceptable usability is? For me it's 60 FPS+ on the target hardware, so if your game is simple, languages like C# should work fine. If it's very complex and uses advanced rendering techniques for special effects, highly detailed AI x 100, etc., C# may not be fast enough.

Lol, is 'squirlly brackets' the technical term for them?

In a time where Dual Core CPUs have become the norm and Quad Core CPUs are already entering the mass market, I think your 60 FPS+ benchmark can soon easily be passed even by purely interpreted languages, provided that the language allows you to use all cores and you can parallelize your code. And that is exactly where platforms like .NET, Java and also Python have always been very helpful and supportive.

The only relevant question is how productive your chosen programming language and frameworks are; everything else is what Tyler Durden in "Fight Club" said about self improvement. ;-)

I think we're a little way before that time yet, surely. I mean as far as the existing userbase goes.

There is no such thing as an "existing userbase". It's a myth. PC users are not (even marginally) homogeneous. About two years ago I bought an entry level POS Dell laptop. Even it has a Dual Core processor. I don't know who you think is going to be playing a very complex game, using advanced rendering techniques for special effects, and advanced AI, who doesn't at the very least have a computer better than an Inspiron 6400.

More to the point if we're dealing with the kind of complexity John is talking about it would be quite favorable of us to chose a language/platform combination, that's very scalable. Now C++ (as source code) is very scalable, as it runs on everything from the chip embedded in your washing machine, to Blue Gene supercomputers.

However a C++ compiled binary, is not nearly as scalable. Want proof? Easy. Go and dig out an old PC game. I chose MechCommander 2. I remember it ran pretty good on my computer way back then. Today I have a PC with 10 times the performance. My Riva TNT 2 is replaced by a Radeon X1650XT, my PIII 500 is replaced by a P4 3600, I have 4 GB of RAM, rather than 500 MB, I can't even guess how much more HD space I have, and the OS is now XP, rather than Windows 2000. Guess what? The game runs worse today, than it did back then.

With C++ you need to pick your target, and stick with it, come hell or high water. With .Net (or other JIT compiled languages) your performance will scale more linearly, as the target moves.

Now I'm not directly saying that one is better than the other, but depending on your time-to-market, and reliance on 3rd party software, there could be a significant paradigm shift during development. Case in point: Duke Nuke'em Forever. With C++ you really need to be ahead of the curve, with C# you can pace yourself, knowing that the busy folks at Microsoft will be doing all the catching up for you.

C'mon, you knew damned well what I meant by 'existing userbase': the multitude of PC owners who haven't yet upgraded to a multi-core CPU system.

I don't remember reading that's what MGE was aiming for, then again I did only scan this thread.

And how many people interested in 60 FPS+ games do you know who have -not- yet done that?

Sure, there still are hundreds of millions of PCs out there with outdated CPU power -- and most of them are standing in some corporate offices and are used for accounting, word processing or as surf boards for corporate Intranet software, meaning that they don't need any upgrading for the tasks that are being done with them.

However, that is not the market we were talking about. But even in the corporate market with 900 million low cost machines already in place, the paradigm shift to multi-core machines is already happening simply because you cannot buy single core machines anymore.

Developing for single core computer systems is developing for the past - or at best for today's cell phones, and even those already have 3D hardware acceleration and will soon have multiple CPU cores as well.

And while I'm at it, desktop computers in general will quickly become a relict of the past. The world is turning mobile, there are already more notebooks (nowadays all dual core) being sold than PCs and cell phones are increasingly gaining computing power as well, becoming the next generation of computing -- and gaming -- devices.

In that world, you will be much better off using scalable and portable programming platforms than using one that only optimizes for one target.

And that is why multi-threading and ARM CPU support would be much more important for BlitzMax than yet another fancy (or not so fancy) 3D engine.

Me, for one.

Says who? I don't remember MGE mentioning a specific market.

Wow, way to fly off on a tangent. Congrats.

Me. I have a fairly good video card, and an old but still fast enough single core CPU, and it plays everything ~2005 and before at far over 60 FPS. BTW, very few games even take advantage of multicore CPUs.

But I'm not arguing that multicore CPUs aren't the future. My point is that C++ is still the fastest language (provided you have a good compiler), nothing else.

As a coincedence, recently I also tried to run Mechwarrior 2 (Mercenaries). I remembered how I liked selecting configurations, and the atmosphere of the game. Being able to choose your own playing style (machine guns or lasers, or rockets etc.) But sadly as you say, it didn't run well, I believe there was no sound or something. (Plus I couldn't figure out the controls and lost interest again.)

One application for multicore processing that we could be taking advantage of right now is Newton Game Dynamics. When using thread-unsafe callbacks, Newton gains about a 90% performance boost per extra CPU core. Unfortunately since I have to lock the threads at the beginning of each BlitzMax callback, our performance gains on multicore CPUs are negligible.

There is loads that Blitz lacks as a language which would be nice if the powers that be got up and put in instead on resting on thier laurels.

Things like:
1) Multithreading - this in itself would give us a performance boost in certain situations.
2) Multicore processing - it would be nice if as has been suggested we could use up that extra processing power for other things rather than letting it go to waste why our games hog one core.

I think with those things in the language it would make it much more appealing to people who want to develop more applications than just games.

BlitzMax is and always has been meant as a gaming language, not an application development language. To not support multithreading in this era is, needless to say, a very very bad idea.

My guess is that on the performance ladder, C++ comes after C and Pascal which come after plain Assembler. However, I'm lucky - it doesn't have any relevance in my career, I simply don't need the fastest language around. ;-)

EdzUp, nobody keeps you from using BlitzMax for multi-processing today; you can launch multiple processes and manually implement a communication layer between the processes (e.g. through sockets). Multi-threading would implicitly take advantage of multiple processors when available, but unfortunately we don't have that option in BlitzMax.



Thanks for the flowers, big10p. Like all BlitzMax language-related threads, this one has also been off-topic after the first few posts already, so I just added my own version of "Carthago Delenda Est". Maybe I should put "BlitzMax needs multi-threading and ARM-support" in my signature.

No, C++ is actually faster than C (and certainly Pascal) in most benchmarks (although it depends highly on the compiler). C++ is less primitive in structure and allows the compiler more room for optimization.

Of course, assembler will always be the fastest because it's at the lowest level, but a common misconception is that the more advanced the language, the slower it has to be, which is not true (not any more, at least).


That's not practical - it would be much slower than multithreading, and be so difficult to implement that it would defeat the purpose.

The problem with multi-threaded applications is that they have to be written specifically for that type of processing.

And the problem with implementing it in BlitzMax is that I suspect this type of thing isn't an easy concept for it's core audience: the hobbiest and beginner. Multithreaded applications are notoriously difficult to debug and if not done correctly can be easily outperformed by a single threaded application.

Multi-threading can occur to a certain limited fashion today in BlitzMax. Nothing should stop API's from being written in C++ or some other language (and bound to Blitzmax) from doing multi-threaded operations behind an API's method call. One example is the Update() method present on most graphics APIs. Some of the processing of the object graphs in these situations could probably be threaded into sub-processes.

With my reference to "acceptable usability" above, the gain of doing multithreading in the Update of the core API might buy enough time in the loop to keep multithreading out of Blitzmax programs written in Blitzmax.

I also heard that Intel was working some black magic on a future processor that would some how allow single-threaded applications to utilize multiple cores/processors without putting the burden of determining context locks on the developer.


This is what I was talking about above. Not locking contexts when doing cross thread access is asking for trouble.

You might appear to get away with this if things stored in memory don't change very much, but running an app this way is very prone to race condition and unpredictable behavior if a critical shared resource changes on you at an inopportune moment.

Multi-threaded processes are ideally suited for long transactional operations with very limited dependence on shared resource. Or short transactional operations if the resource needs frequent access.

You can get away with shorter locks on a resource, but you have to make sure all dependent concurrent transactions are done with it's value before anything is allowed to update it.

In other words, you have to make these concurrent processes act as though they aren't.

There are certainly a few BlitzMax programmers that could handle these concepts. I'm not so sure about the rest of them. (That's not meant as an insult to anyone, by the way. Multithreading is simply difficult to implement correctly at any level of experience)

.Net does a pretty good job of making most objects thread safe at the expense of some minor memory overhead (Every object has a baked in locking context behind the scenes, and the CLR manages it for you if multiple threads are present. You can also hook into the context for custom transactions). If multithreading were done in Max, Microsoft's way of doing it is a pretty good model to follow to keep it simple. Unfortunately, I imagine the implementation behind the scenes in the core language wouldn't be a small task unless Mark has anticipated this implementation and has prepared for it.



Is multicore processing in the scope of applications? I was under the impression that the core/CPU a thread is assigned to was an OS-level operation.

That is not true, you only have to lock threads when writing to a variable all threads can access. Otherwise, you want to allow the threads to each just do their own thing independently.

There are some tasks, SOME tasks, not all tasks, that can be parallelized. These tend to be tasks that are already eating up a lot of CPU usage, because they repeat a lot, or process a large number of items. Your word processor won't run any faster as a multithreaded app, but your lightmapper, renderer, image processor, etc. will.

Actually what I said is true. You can get away with it if memory doesn't change much. But to avoid race conditions, you have to lock it transactionally. Sometimes that means you have to lock a variable even when you only intend to read it.

Take the following pseudo code into consideration using your logic... Assume a is some variable accessable by all threads.

lock resource a
a = 100
unlock resource a
AResult = Call SomeThreadedMethod() asynchronously as a thread
BResult = Call SomeThreadedMethod() asynchronously as a thread

SomeThreadedMethod(){
   local1 = 0
   do until a = 0

      local1 = local1 + 5
      local1 = local1 / a

      lock resource a
      a = a - 1
      unlock resource a   

   loop    

   return local1

}

The above code is prone to a "division by zero" exception even when "a" is being locked only during writes.

Thread#1 could enter the loop structure with a = 1 and Thread#2 can lock a and reduce it to zero at the same time. Since Thread#1 has gotten past the loop's condition, it's free to proceed to the local1 = local1 / a. It's not aware that another loop changed the value because a wasn't locked transactionally.

That's what I meant about unobvious side effects. At a glance, the code looks sound and even appears to be diligently following the multi-threading rules, but there is a slim window of opportunity that causes the application to crash.

This is just an example, but worse things could happen in a game engine. Suppose you see artifacts appear occasionally and it's caused by a non-transactional locking bug like I described above. It would be a hair-pulling bug to try to track down.

"BlitzMax is and always has been meant as a gaming language, not an application development language."

Why do you say that? I still don't see why anyone would think you could code a game easier or better in Blitzmax compared to langauge "x".

And for a noob coder, Blitzmax would be very hard to grasp.

Agree

Take Torque , for example
It provides :
Basic Game classes - Gameplay classes - Mission obects - Game Setup Scripting - GamePlay scripting etc

This is a true game language while Blitzmax is nothing else than a general purpose simplified OO programming language

The point is that a programming language must come with a 3d module

Maybe 5 years ago. Today we have things like Erlang and Stackless Python. Take your cue from languages that do it right, that's all you need to do to make multithreading accessible. Of course as long as you're working with archaic languages like C/C++, you're going to have to work with their limitations as well.

They were. Not anymore. Intel finally seem to have embraced the ideas of VLIW, and are moving all those expensive operations to the compiler, to reduce the costs of CPU dies. So not much good news for BlitzMAX.

Surely you jest? Microsofts way of doing it is only marginally better than stdC. Java, Erlang, Stackless Python, even Common Lisp all provide much, much cleaner and simpler ways of doing multithreading than the miserable BeginInvoke() bollocks you have to put up with in .Net.

Because of empirical experimentation. For the purpuse of making a game, compared to any other type of software, BlitzMAX provides pretty much the perfect balance or "acceptable usability" if you will, between an abstract easy to use language (mainly focusing on features relevant to games, that is none of the other things on my list that practically all "x" languages have) and a native performance-oriented compiler.

Compared to what? Seriously? And by "noob" coder do you mean someone entirely new to programming, or someone burdened with a couple of years of procedural indoctrination. Because if it's the former, and you're having a hard time understanding BlitzMAX, then maybe programming just isn't your thing. If it's the later, I'll cut you some slack because you're doing it wrong, and it'll click eventually.

Except for that annoying little fact that Torque isn't a language. It is at best a framework, albeit a poorly thought out one. If you're looking for a game framework to go along with you're game programming language, I hear Grey Alien is selling one. You might want to hurry tho' because he won't be for long.

Well I've programmed in a wide variety of programming languages over the last few decades, and to this day only a handful of them (of the top of my head AMOS/STOS, BlitzBasic/BlitzMAX, PureBasic and Dark Basic) are the only ones out of literally 1000's who have come with built-in drawing and collision detection functionality (which is only useful for games, and game-like applications) as part of the core language. So yeah. Games language.

And yet surprisingly few do. So I'm thinking your definition of programming language is slightly misaligned to the real world.

"Except for that annoying little fact that Torque isn't a language. "

Come on, what are you saying ?
Torque integrates also a scripting language which has been sepcifically designed to access the Torque game engine
You could use also C++ but for above reason it makes sense to use Torque programming language

"the only ones out d collision detection functionality (which is only useful for games, and game-like applications) "

Right, but this just proves that BlitzMax is an unfinished product

"So I'm thinking your definition of programming language is slightly misaligned to the real world."

No comment, just one of your usual useless and unpleasent comments

Eh?

Programming languages are'nt specific to 3D solutions, in fact, I'd dare to wager that across all the languages available to developers thoughout the world, the total amount of actual 'built' applications by these languages need a 3D interface will be tiny.



The thing that makes me laugh is that, yeah, BRL promised a 3D module, and I take it that people hung on to that word... But when you buy BlitzMax you know exactly what your getting, because it tells you right here:-

http://www.blitzbasic.com/Products/_index_.php

More notably:-


Create 2D Games for Windows, MacOS and Linux


And that to me, sums up BRL's product, nothing more, nothing less!

No mention of 3D, simply because Max3D may just be... Another product!

Dabz

EDITED: Added quote and bottom statement

Please friends
I think it is evident that the word " game " is missing
Please read

"The point is that a GAME programming language must come with a 3d module"

In my opinion it makes sense if the programming language is fully integrated with the engine, the level editor and the model editor
otherwise it is better to use a standard programming language

A stand alone game programming language is of little use

To you personally, but I hardly doubt that Gfk/Grey Alien and other actual 2D specific devs on this forum would agree.

Dabz

Of course it is just my opinion
Maybe Gfk/Grey Alien and others 2D devs are happy but I doubt that the thousand Blitz users ( me included ) have been waiting for years for a " 2D specific tool "

My initial reason for this thread was that the core language only has a small percent related to game coding and the rest could be suited for any type of development. So why does Blitzmax have a games only rep?

Don't get me wrong, years ago a language with built in 2d blit, alpha, page flipping, bitmap collision checking, would qualify as a state of the art 2d game language, but I think there needs to be more for it to qualify as a robust game design solution in 2008+.

I think the majority of peeps who use Blitzmax for game development is because you can also create a Mac build fairly easy. (Linux is just a novelty due to the small commercial game market.) And I'll be the first to admit that Blitzmax is the ideal choice if you want to design a 2d project, code once and deploy on Windows and Mac.

You asked the right question
You gave the right answer
170 posts later :)

lol.. :)

Well, the simple answer to that is that instead of waiting, people should of moved on. I know a few have already, good on them I say.

If you find your chasing a language that really doesnt suit your needs, that hardly is the languages fault. :)

Dabz

P.S. Nice discussion this! ;)

!?!?
blulsiht!

Why is a 2D game (or a board game for that matter) any less a 'game' than a 3D one..

im with D4NM4N on this one, there were games out WAAY before Wolfenstein brought us a 3d viewpoint that were 2d. As long as its entertaining and you have control over the character in it its a game (also its on a computer) :)

"Well, the simple answer to that is that instead of waiting, people should of moved on"


It is what I did, I moved on
However I would not argue if it had been made clear from the very beginning that BlixtMax was a 2d game tool only
The 3d module had been announced many times and it never came
Many people wasted plenty of time.
It is a not nice behaviour, in my opinion


"Bullshit
Why is a 2D game (or a board game for that matter) any less a 'game' than a 3D one"

For evident reasons

Well, there is nothing in the product description to say that, or that it is promised:

However, you seem to have forgotten the fact that it CAN be (and is being) used for 3D games by loads of people.

" Well, there is nothing in the product description to say that, or that it is promised: "

Would you seriously claim that most of Blitzers have not been waiting
( and some still are) for the 3d module ?
The description ?
I dont think that poor information, generally speaking, is a good excuse
I have never seen a roadmap, for example, correct me if I am wrong

"However, you seem to have forgotten fact that it can (and is) being used for 3D by loads of people."

Same as C\C++, C#, JAVA , Visual Basic, JavScript, phyton...what's the reason for having a new one ?

Choice?

I use BlitzMax as my "toolbox" of choice.
I could use any number of other ones, but I like BlitzMax.

Whether it has an official 3D module or not doesn't concern me in the least.

BlitzMax is just another programming language. What you do with it is entirely up to you.

What do I do with BlitzMax? Anything I want :-)

Congratulations. You managed to correctly identify Torque as a Game Engine. Here's a question though. Since there is also a Torque family product that caters exclusively to 2D games, and since a 3D module is a prerequisite to "games language", does that mean that Torque Game Builder doesn't qualify as a game language?

That's not a reason not to use C++, particularly since if you want to doing anything even remotely complex with any Torque product, C++ is your only recourse, as the scripting language isn't even Turing complete.

That's absurd. Which feature is missing from BlitzMAX that prevents you from making a game in it? I would say that the overwhelming evidence (at least a handful of very high profile commercial games developed in BlitzMAX by 3rd party developers) suggests otherwise.

Absolutely. And in BlitzMAX it is. So where's the problem? In fact it's so well integrated that (unlike Torque) you can't use it with any other language. At all. How's that for integration?

What you and supposedly 1000's of other people have been waiting for years for [sic] is irrelevant to the merits of BlitzMAX the language. That your hopes and dreams haven't materialized isn't BRL's fault, and I don't think it's fair to blame them.

What other development? Maybe this is a bad time to point it out, but working as a professional software developer, I have yet to see a project, that BlitzMAX is even remotely well suited for. You think BlitzMAX lacks a 3D engine to qualify as a game language (despite there being at least 3 perfectly capable 3D engines available for it). Well to write even the simplest of business applications BlitzMAX needs a hell of a lot more, and unlike with 3D engines, there's only really one option for anyone stupid enough to think using BlitzMAX for developing business applications is a good idea. Hire Brucey.

Fair enough. But we don't judge the merits of a programming language on what random people on the Internet believe. If you have empirical observations to support your claim, by all means present them. However the large amount of commercially successful games written in BlitzMAX (and the painful absence of any business applications what so ever) leads to a fairly straightforward conclusion. Even the numerous support tools developed for BlitzMAX (Blide etc.) are developed in something else. Clued up yet?

Well, there's your answer then.

Well you're obviously both wrong. Elite was the first video game ever. Then it was a quiet time for video games until Quake came along.

Well that's just rubbish. Dabhand already quoted you the relevant bit from the product page.

Like IT projects always materialize on schedule. By the way, I'm going to bookmark this thread, and in 10 years time when Max3D does show up, I'm going to come back and mock you. Some more.

Well it took longer than I'd thought before this thread turned from a discussion about BlitzMAX merits as a games programming language to whining about Max3D.

Not evident to someone not on drugs. Please do elaborate.

To claim that the majority of the Blitz community is a bunch of childish whining hatemongers, with nothing better to do than sit around on their hands all day, and post angry bile on the Blitz forums, seems to be charitably arrogant, considering games like Fairway Solitaire and Eschalon: Book I are making a killing.

Make up for its shortcomings? Sorry, couldn't resist. :o>

Just my two cent:
C/C++ --> Applications are harder to mantain than with BlitzMax. Usually faster than BlitzMax, but BlitzMax is 'fast' enough.
C# --> Requieres a runtime and it is not still really 100% mac or Linux compatible as mono is not mature and silverlight doesn't support all the C# framework core functionality.
JAVA --> Terrible syntax (IMHO) and also requieres a runtime framework to run. Not as fast as C#, so BlitzMax wins again
Visual Basic .net --> Same problems as C# with the addition of natively suported late binding, wich can make applications very slow compared to BlitzMax or C#
Visual Basic 6 --> Nasty com arquitecture, not really OO and it has to deal with the iDispatch for everything... Slow and not cross platform, also requieres a runtime
JavaScript --> Nice toy. Nothing more

No not at all, i am "waiting" myself. However I am not doing nothing, i am using the break from blitz to do some design work, graphics stuff, and learn some other programming skills incase it never materializes.
I do not see the 3D module mark is writing as the SAME product as BlitzMAX. I do expect it to be symbiant with it of course and I would not be surprised to see a combination product of the two sold together as a single package eventually (as the next "Blitz3D").

I certainly never thought that i was -promised- a 3D module just because i bought Bmax, but I assumed that -something- native would come out eventually to replace B3D that could be used with it.

I also expect it to have its own price tag which i wont mind paying at all.

Whats the point in having any of them anyway?, why dont we all get the old assembler out? Personally I would say its a matter of taste, ease of use and familiarity/similarity with previous blitz languages.

"Congratulations. You managed to correctly identify Torque as a Game Engine"

Unfortunatly I can not congratulate with you
You have not yet managed to identify that Torque supplies a built_in scripting language
Unless you dont see any difference between Torque and , for example, C4 or other engines which use pure C++

" Right, but this just proves that BlitzMax is an unfinished product
That's absurd."

You claimed that BlitzMax is not just a programming language since it provides also a 2d collision detection
Right, I repeat
However why not also a 3d collision detection ?
If you dont like the word "unfinished " let say " extremely basic " then
Hurrah ...for some 2d features , in the year 2008 ! come on

"For evident reasons
Please do elaborate."

From an accademic point of view , ok , a 2d game is a game but I dont suppose that in the 21th century a good 2d tool should be considered something at the state of art


"What you and supposedly 1000's of other people have been waiting for years for [sic] is irrelevant "

You have a peculiar idea of businees
A company should keep informed his clients of future developments
Particulary when his clients are expecting some features
Unless you want to deny that the 3d module has been strongly demanded and expected by the comunity

Many other engines pubblish a roadmap
It is not a must , of course, but definitly a serious businees behaviour

Honestly I quitted with Blitz some years ago, when I realized that the 3d module will never come
ok maybe in 10 years it comes, I hope you were joking
If the comunity has been advised in due time that the BlizMax project is over and no major features should be expected than it is ok
Otherwise I remain of my opinion


Ziggy

You are the only one who provided a serious explanation, thanks
While accepting your points, I remain of the opinion that these advantages do not justify the long time for the development of a brand new programming language
It was better to adapt a commercial one and to focus on the 3d module , same as all the other new game engines did

Where do people get the idea BlitzMax is 2D? The version of BlitzMax that I have is pure 3D and all 2D is emulated via 3D methods.

No it wasnt, there are loads of games before that that were 2d. You just happen to pick Elite because of its 3d viewpoint, yes thats good for the 3d argument but I was just pointing out that you dont need 3d to clarify itself as a game.

I did a google search for "first 3d game", funny to see discussions like this

http://forums.gametrailers.com/showthread.php?t=306519

where some people seem to believe a Super Nintendo game (Starfox) to be the first 3d game. (Not to mention "Mario 64"...) Haha.. amazing how people just bring up the same wrong examples again and again even after much older games (Battle Zone) have already been mentioned. Oh well sorry for this interruption. ;)

Sure I did. I also managed to identify it as "mostly worthless" and language wise, much inferior to BlitzMAX. Besides Torque is disqualified as a game language, as Torque Game Builder contains the exact same scripting language, but fails to meet your "3D Engine" criteria. So yeah.

Erm, because it doesn't have an official 3D engine yet?

Well that's nice. However the topic wasn't "Why is BlitzMAX considered a state-of-the-art 3D engine", the answer to which, I'm sure is blatantly obvious to anyone who's been reading this long.

Oh really? You're the one suggesting that a finished product (BlitzMAX) should not have been released for x years, because it was short one 3D engine? Are you from China or Cuba perhaps, since you have such a ludicrously poor understanding of capitalism?

Let me tell you why Marks idea was absolutely brilliant. Momentum. When you release a new product, it needs to achieve market penetration to become successful. BlitzMAX has some momentum now, and it's taken quite a while. When Max3D comes out, it can piggy back onto this existing market penetration. Everyone is always bashing BRL because they don't do enough marketing. Well one of BFG's biggest titles, which has been featured on two prominent games related webcomics, just happens to be written in BlitzMAX. How's that for brilliant marketing strategy! What's the biggest 3rd party game made in Torque? Really? How do you like them apples?

Not at all. Unfortunately demands and expectations of customers amount to nothing in a capitalistic society. Now since the community has been demanding a 3D engine for BlitzMAX, since the dawn of time, and since in the mean time at least 5 alternatives have materialized (three wrappers who did exactly what you suggested Mark should do [one for Ogre3D, one for TrueVision3D, one for irrlicht], and two ground up alternatives [Leadwerks and MiniB3D]). Now understand this. A capitalist market is simplistically driven by many forces, two of these are supply, and demand. Now since the supply for a 3D engine has grown exponentially, from "none" to "at least 5" and the demand has remained "mostly constant", that doesn't give Mark any incentive at all to hurry up with Max3D. Now if you'd all just bought TV3D those 3 years ago, Max3D would have been out ages ago. Like it or not, competition drives the market. No competition, no incentive for companies to improve.

Really? Show me one serious company that does that? Then show me one whose roadmap wasn't just smoke and mirrors when push came to shove. Yeah. Pretty much. The only reason company "a" releases a roadmap, is because they need to have a bigger ePenis than company "b" who also has a roadmap. Competition. It really is that simple.

I call Poe!

There is plenty of competition for 3D engines, BRL just doesn't seem to be motivated to compete any more.

There were promises around the time BlitzMax was released that BRL was working on the "next gen" version of the Blitz3D engine (Max3D), and that was exciting, because Blitz3D, in it's time, was a very competitive engine (compared to other engines), and I think we all expected a similarly excellent engine.

Well, so far, nothing has come (from BRL), and even a few third-party 3D engines have been written (from scratch) since then and BRL still isn't even sure what direction to begin with Max3D.

You're right, competition drives the market. Unfortunately BRL doesn't even seem to be competing any more, and maybe for good reason. There are so many amazing modern engines out there today (some for free), so maybe they feel like it's useless to compete in the same area. I know it wouldn't stop me (I'm a competitive type), but maybe not for BRL (aka. Mark Sibly - is there anyone else?)

http://www.bnl.gov/bnlweb/history/higinbotham.asp

now thats old :D, imagine if computers were still that big.

" Torque is disqualified as a game language "

For your information I dont like Torque either
However you did not grasp my point, right or wrong it may be.

I meant that a true GAME programming language is possible only for the so called authoring systems, whereas the programming language, the level editors and the model editor are merged in one only unit
Otherwise the programming language and the game engine are sinply two separate layers
In other words a stand alone game programming language does not exist except for a few minor features
Having said that, I am not blaming BlitzMax but I can not but notice that it is supported by a small company while its competitors are industrial giants

" Erm, because it doesn't have an official 3D engine yet? "

So, it is an unfinished product , as I previously said :)

" Unfortunately demands and expectations of customers amount to nothing in a capitalistic society. "

I dont know what is your job bur for sure you are not in the marketing of technical products.
By the way it is my job
My main clients, distributors, agents will shoot me down if I would not be open to discuss about future developments
Obviously some information are confidential but clients that invest money and time in my products has the right to be assured that my company is willing to support them also in the future

"Really? Show me one serious company that does that? Then show me one whose roadmap wasn't just smoke and mirrors "

C4
3DGS
NeoAxis
Unity
3DStudio
Leadwerks
......

"Where do people get the idea BlitzMax is 2D? The version of BlitzMax that I have is pure 3D and all 2D is emulated via 3D methods."

Phew! Glad to hear that, I need to load and animate a 3D model in Blitzmax to go with my game I'm working on, which native Blitzmax command will do that for me? I can't find it in the docs. Thanks.

how about LoadAnimMesh? why care if it's native or not? the 2 things that makes LoadAnimMesh different from LoadImage is who wrote it and how you get it... This was the very point of the modularity of bmax over b3d.

even when max3d comes it should not satisfy this thread's demands because it will be just *another* 3d engine among the many that already exist for bmax

Nope. Like I said, they don't have to compete because they have frenzied customers, buying into brand loyalty like it was the last day of the brand loyalty sale.

They don't have any competition, because in spite of the (by now) ridiculous amounts of 3D solutions that integrate flawlessly into BlitzMAX, people are still demanding Max3D. That is not competition (in capitalistic terms, it's actually more akin to a monopoly).

Sure. That's not what you said tho'. You said a true game programming language needed a 3D engine.

Except BRL is a New Zealand company, and by Kiwi standards it's actually a pretty big company.

No. Because Max3D is a separate product (much like MaxGUI).

No. I'm a software developer.

Sure. But they pay for the privilege. How much do you charge an hour?

No, There isnt one.

Its 2D only as far as the -product itself- goes (although you can access openGL directly :/ ).
When it finally gets released Max3D (a separate but native product) will undoubtedly have a loadmesh command of some sort.

However in the meantime theres:
-LoadAnimMesh() from Si's B3D (easy to use, its almost like using B3D)
-LoadAnimMesh() from B3Ds SDK (this effectively IS b3D and is windows only which are reasons why it did not prove so popular imo)
-ib3d_LoadAnimMesh() From gmans Irrlicht.b3d mod (Not a complete b3d commandset but can be used with irrlicht.core below)
-smgr.getMesh() from gmans irrlicht.core mod (You need to know irrlicht to use this)

-and many others.

Take your pick.

Please do not spread disinfo about BMax. It only adds fuel to the fires the troublemakers keep setting.

1. All 2D in BMax is emulated via 3D methods.
2. OpenGL commands are built into BMax and the only limit on the 3D engine/game of your dreams is your programming knowledge.

There really seems to be a lot of people who are expecting there to be native 3D commands in a 2D Programming (Game) language. The odd thing about it is (other than not being interested in 3D) I am put off by the 3D modules and wrappers for Bmax and I haven't even bothered to check them out.
My brain is screaming that they're slow, not complete, difficult to use when I have no real evidence to support that.
.
Like most things if I gave them a go they'd prove not to be as difficult as I feared. If I had a goal in using 3D I'd know which matched my needs or whether I had to look at another language.
.
I tried to find out why I have these preconceptions.
MiniB3D - Must be lacking in features as it has 'Mini' in the title.
Irrlicht - Even the name makes me think 'complicated'.
B3D SDK - A system taken and crowbarred into an SDK which can never perform as it did natively.
They are probably not any of these things but I am trying to understand why I, and maybe others, are not sold on the 3D add-ons for Bmax.
.
I still say with texture buffers, a better audio module and avi support Bmax would be the best 2D Game Language ever. It's pretty close already considering price, ease of use, flexibility, function, extendability and power.

Why? its true, it is 2D only as far as the actual 'engine/interface' goes, regardless of weather it is rendered by 3D.
You can use OGL itself (edited above) but that cannot be classed as a 3D engine can it. (which is what alberto and others are talking about)

A common misconception. MiniB3D is -almost- complete. I agree, it is a belittling name, personally would have renamed it XB3D or GLB3D.

Compared to b3d yes it is complicated. But quite wrappable (like gman started to do with irr.b3d)

Well, thats the $100 question, this is why Max3D would be a hit. Unfortunately, its still w.i.p.

No its not. You can prove it by looking at the source code for the modules.

That is odd, the nehe tutorials work pretty good for me in BMax and I have 3D objects moving around the screen and have an animated MD2 running around the screen. I know nothing about 3D and if an old codger like me can look at the tutorials and use BMax's native 3D commands (OpenGL is a 3D rendering API, afterall), I am not sure why the youngsters are having problems.

I am guessing what those continually whining for Max3D are after is a point and click 3D game maker as these folks are obviously against putting an ounce of effort into their own work or games. I guess it is much easier to blame Mark and BRL for your failures in life than accept responsibility for your own actions and shortcomings.

MaxB3D?
I wonder if it was called Max3D would people say "Great! The Bmax 3D module is available and it's brilliant" or are people holding out for a higher end solution?
I know where Max2D is lacking and, for me, its outweighed by all the positives. For Max3D though it just seems the argument or basis of discontent is based on a broken promise (perceived or otherwise).

Yes it is.
OPENGL is not an engine! Yes Max has lots of '3d stuff' built in there - MiniB3D as far as i know is completely written in blitzmax for a start. However, while you *can* access '3D functions', that is not what we were talking about, making my original statement completely true.

As far as people comming to Max, it IS just 2D, its even described as a 2D gamemaker language. Why? because there is no native SIMPLE 3D command set and refined engine. People want a managed engine, not the framework at its most unrefined level.

It doesnt really bother me, i like BlitzMax and i use irrlicht but it would be nice to have a new native engine, a "modern b3d module" so to speak. Irrlicht is cool, but it can be a little much sometimes.
-I sure as hell dont want to go messing about with the bare api.

nobody said it is

Python is a games programming language.

Python is great for making snake games I suppose, hahaha.. haha... .... :(

Great so we agree that BlitzMax does not include a 3D engine module and is sold AS a "2D games language" which it is. -for the time being at least (I was not talking about weather its capable of '3D')

Glad we cleared that up :P

Problem is, people who are programmers will adapt. Those that know only blitzbasic will be put off by anything less than a native, familiar command set, so as far as those guys are concerned Bmax is 2D only.


Lol, I wonder what is the forum record for titanic threads?

Or Civilization 4 or Half-Life 2.

Exactly.

Python is a programming language, just like BlitzMax is a programming language.

It's what you add to the language via extensions/modules/libraries/etc that give it the ability to do more.

Hehe I was just making a silly joke. ;) I was thinking maybe someone would reply "no, Cobra is better for that". ;)

anything started by xylvian ;)

and yes any programming lingo can write any program you should desire as long as all the relevant bits are available or can be coded

just because bMAX doesnt have 3D out of the box like blitz3D doesnt mean it CANT do 3D
or that b3D lacks windows widgets doesnt prevent you from making a tool or application that isnt game related

its a programming language with a game programming history
its not SEUCK or the 3D game maker or the early click and play releases
you can make an internet browser in bmax, just try doing that in SEUCK, nigh on impossible as its not a lingo but a game making tool

Never said it did. Just said it isn't a 2D product, which is true even though some in this thread are assuming BMax is 2D out of ignorance.

Out of the box, Blitzmax can do 3D as good as it can do a Windows gui application. Which is one of the reasons I like it so much. It really isn't a "langauge X" at all. Hence the reason for this thread. ;) And sure you could code a 2d, 3d, game, engine, etc, in Blitzmax just as easy or hard as you could in any language.

hmmm...does the topic poster get to put google ads in? :) lol...

To me, having the native 3D commands in BMax is awesome. I can access OpenGL much easier than when I looked at using it with C++. For somebody with zero 3D experience, I have been able to get up and running with 3D in BMax purely using the native 3D commands.

Ah, but it -is- sold as one. By "native 3D commands" i assume you are refering to the opengl interface right? If so this isnt really unique to max.

I agree with that to a point, like people who rather have an engine with a built in 'script compiler' right? Although i would say ignorance is a little strong, i would have used mis-informed or mis-led.
The reason most see it as '2D only' is this; It does not have any 3D half way point for people who want it. Take the 2D side, it has a 2D graphics engine within a managed environment, quite removed from using a lower level GL/DX api.
There is no 3D side like this in BMax, its either the complex and unrefined OGL interface at one end (any GP language can use this, it doesnt mean for example C or pascal -does- managed 3D either), and just a 2D language at the other. There is no middle or familiar ground there for most.
So you can see why people get put off it.

Personally i think its a great language, the fact that it is modular means you can load this, unload that or just use it as is. But i would prefer a familiar and native 3D module myself. But as i say i use irrlicht till that comes along.

@Foppy
Well don't. We're not here to have fun.
@GaryV Ohh good! Name them or point out the bit where they acted like an ignoramus. We can put them in a corner, stick a dunce's hat on them and flick ink pellets at their back.

Yes. But you're argueing semantics. If we consider the language to solely consist of reserved keywords, then you're absolutely right. However, there is a hell of a difference between what you can do with the Python core distribution, and the BlitzMAX one, and I think that's mainly what this topic is about.

As it stands Python comes almost with the exact opposite standard features that BlitzMAX does, so if you don't want to have too many 3rd party dependancies for your software, you would be better suited going with the language that, out-of-the-box, does most of the things you want to do. So for a game BlitzMAX would be an obvious choice over Python. Likewise for pretty much every other type of application, Python would be better suited than BlitzMAX.

At the risk of repeating myself, this is why BlitzMAX is perceived as a games language.

This thread is useless at this point, IMHO. Everything that is to be said on this topic has already been said.

It's getting hot here, I think this thread is nearing the center of the earth! We better stop.

Is this true? I know a few people have done well but how well-known is Bmax?
Anyway, I can't think of an area of Games Programming that Bmax can't be used for due to its extendability. I am slightly surprised that more game 'add-ons' haven't bubbled to the surface. Those that have been made (particle engines, map editors etc) have struggled simply because its such a small community. Most work and, for those that need improving, source code is often provided. I believe that many people just want it to work. I guess we have the two camps : It's a programming language VS It's a game engine. The first camp accept what Mark has given us and are happy to extend it, the second camp feel a bit let-down that its not easier.

Maybe because the GUI module that was released was half arsed and had loads of GUI bits missing.

Halflife2 was written in python!? :O

No, it was written in C++, although it probably uses Python for scripting.

FlameDuck has some serious misconceptions about scripting languages I think. Modern games (the underlying engine, at least) are usually written in C++, and levels are scripted with something like Python. This does NOT mean the game was written in Python! That would be as ignorant as saying "This house must be made out of paint, because I can't see the wood!"

I know, but it gives you something to do :-)


Surely there are "engines" out there where you simply have to provide a map, some models and 10 lines of logic to have your finished game? Perhaps that's what they want?
Where's the fun in that?

Why is there so much whining?
It's not like you have a day job supporting million year old legacy code...

My house is made of bricks.

Why do Americans insist on building houses out of wood? Don't you realise that if you build them out of bricks they won't blow away when it gets a bit windy? :)

this is why most other forums have pages
my page down button is breaking ;)

and puki hasnt said saussages or large yet (that i can recall) so everything that has been said on the subject HASNT

GfK: I was just using it for the analogy, of course. But to answer your question, nobody's "insisting" on anything. I'm sure the advantages/disadvantages of various build materials are considered when building a house, including strength, costs, etc. How much does it cost to buy a house (+land) where you live?

Tried pressing 'End' instead?
They start at around £60,000 at the moment.

too much (cambridge)
they insist on building town houses due to every town house being converted into bedsits ... now if they just made affordable studio flats people like me could move out of these town houses and 'families' could move in ... and it would mean i would stop living with the strange people (they might still live next door but i wouldnt have to share a bathroom and kitchen with em)

edit:
was joking bout page down but nope never tried till now (i normaly use the mouse but couldnt be bothered for some reason) thats another keyboard short cut im bound to forget

A man who lives with a skull on a stick called Mr Merrygrim thinks somebody is 'strange'? :D

Must be like One Flew Over the Cuckoo's Nest down your way!

60,000, for a full house + property?

This is getting off-topic though...

aye pot kettle :)

guy downstairs keeps starting convos with 'coincidentally' or finishing a convo he had with someone else ... ayt tis a mad magnet this house

i get paid by one of the mental health trust's yet it feels like im in an outpatines/day release ward some days

edit:

more for a shed this neck of the woods well they call them static caravans ;) a house is 5 balls + bonus might get you a deposit

That's what I am trying to understand. The original post from MGE suggests something is missing to make Bmax a Games Programming Language (). I wonder what *is* needed for a full out game design language? Physics? 3D module? Map Editors? Particle Editors? Game GUI? Sprite system? Game Framework? 2D Shadow system? These are all available although it'd also be nice to have a good camera system as well.
It can seem a bit disjointed as the implementations are different so is it the lack of these as native systems that is causing concern?

Full house, yep.

http://www.rightmove.co.uk <UK houses for sale.

Should prolly get back on-topic now.... not that I can remember what this thread is about any more :D

True.


lol

Well you're entitled to your opinion, but I think you have a serious misconception of what constitutes a game.

Actually that's exactly what it means. Case in point: Civilization 4 and Half-Life 2. While I'm perfectly aware that the underlying engine (Gamebryo and HL2 engine respectively) is written in C++, the actual games (that would be Civilization 4 and Half-Life 2) are written in Python. This includes more than simply "scripting the levels", and explains why "the community" can fix bugs in HL2 engine games (Vampire Bloodlines springs to mind) without actually having a HL2 engine license. Because you don't need it, because whatever is wrong with the game, is wrong in the Python script that represents it (unless it's an actual engine bug, in which case you have to wait until valve fixes it).

Well thanks for keeping me occupied then. :o>

Thankfully, not anymore. These days I write the soon-to-be legacy code, someone else is going to have to maintain in a million years. Muwahahahahah!

For real? For a proper house? I paid more than twice that for my apartment! Where is this? I'm moving!

Yeah that's what I was thinking. No way I'm moving to Cambridge.

A game is much more than the scripts built on top of it's engine. Take away that engine, and you have nothing. Take away the scripts, and you have nothing too. Neither can take full credit for the whole of the game, so you can't rightfully say the game (as a whole) was written in Python, just as I can't say the game (as a whole) was written in C++.

This demonstrates your flaw of logic perfectly:

You can say we're arguing over semantics, but in your own words: I think you have a serious misconception of what constitutes an actual game.

The engine that runs a game is every bit a part of the actual game, as your car engine is a part of your actual car.

Just because it's "under the hood" doesn't mean it's not there, and that you can pretend it doesn't exist, or doesn't matter, or is any less important to the "actual game" or "actual car".

Saying that a game's Python scripts are what makes the "actual" game is like saying your car's steering wheel and dashboard is the "actual" car.

Like blitz3d. It pretty much describes a b3d game. An engine written in c++ and a game written in the engine's unique compilable 'script' language.
I was more asking about HL2 game itself rather than the engine (i would have been very surprised if that was anything other than C/++/asm).

D4NM4N: The line between what is the "engine" and what belongs "scripted" varies greatly.

Blitz3D's "engine" is extremely minimal, almost to the point of being a simplified wrapper of DirectX. Most everything is done in the "script" of the Blitz language.

I personally don't know much about how the HL2 engine works, but I'd bet not only graphics, but pathfinding, physics, raytracing, particle effects, etc. are done in the C++ engine side. What's usually left to scripts are things like the HUD, controls, weapon behavior, high-level enemy AI, mission triggers and events, etc.

An "engine" is an API that abstracts the complicated OpenGL/DirectX/openAL/etc into commands suited for typical "game operations"

A script is a client of that API.

"That's what I am trying to understand. The original post from MGE suggests something is missing to make Bmax a Games Programming Language."

Correct. After playing with the language for a bit I've come to the conclusion that Blitzmax can do anything, so why the rep just for games? My answer to that question based on my research is because the majority of Blitzmax users are past Blitz product users, so they already have a heritage of game design from previous Blitz products. And the rest of the userbase learned of it as a tool to write once and deploy on Windows/Mac. As was the case for me. :)

Just because there is some seriously wicked add ons for "Feature X" doesn't mean you should advertise it as being "A Development Language for <Feature X>". Add a Brucey mod and it becomes a powerful gui system, add Grey Alien's Framework and it becomes a Casual Game Development Kit, etc, etc. But out of the box, it is neither one of those things. (That's why I personally like it.)

In my worthless opinion, Blitzmax is not a game design language any more than any other langauge. Like other langauges, Blitzmax has a nice collection of add ons that provide expanded functionality. Those that develop games in Blitzmax could probably develop the same game in any language.

Except the obvious lack of multithreading, making it practically useless for proper applications.

I think we are actually talking about the same thing, just with crossed wires. :D
The above things -are- the game. Things like physics, particles, physics, animators etc. are practically 'generic' for any game of that type.
For example i dont class the under-the-hood, hidden part of b3d that loads a mesh as part of my 'game' itself, its just there, part of the engine and not specific to my game code. I wouldnt say anything i wrote using Blitz was a mix of B3D scripting and C++, simply because b3D was written in c++.
After all the HL2 engine has been used for more than one game.
Of course, i understand what you are saying, as soon as any of it is linked in to the game, it is part of it.

Although i wouldnt really call Blitz3D's game engine 'minimal' as without it's engine functions theres very little left either. The entire 'language' is built -around- that engine. So the engine -IS- more or less B3D.

If by 'reputation' you mean people consider it is for games then that could be due to what people know about it.
It has got Blitz in the title. Blitz is often related to BlitzBasic (B2D/B3D). Lots of games have been created using Blitz software. Those that care often pay more attention to the language a game is written in than an application.

here here, well said :)

where, where? :p

There There!

300 pointless posts, c'mon we can do it.

I say it's minimal, because it's so simple (doesn't include particle code, physics integration, etc.), I had to write my own engine layer in Blitz3D when I made Blitz3D games, and implement my own scripts, etc. from Blitz3D.

The HL2 engine probably isn't as minimal, because somehow I doubt you could make a flight simulator, or a space combat game with it. It's locked into the FPS style levels and gameplay, because I'm sure a lot of that game code is done in the C++ engine. In other words, it's much more high-level than "CreateCube" and "PositionEntity".

Like I said, the line between the engine and the script varies greatly, and depending on the engine, you might be doing the entire game in script (leaving only the low-level graphics to the engine), or you might only customize some high level behavior in script (like AI, leaving the rest [controls, physics, missions, etc.] to C++).

True, lines are often too fine :) (eg, when does a script officially become a language? :/ )

I would still class anything that is common to more than one game (or code that is modular and potentially re-useable or multipurpose) as 'engine/framework code', rather than the actual 'game code'.
I guess its because i tend to be a very recycley-module, lots of files type person :)

Yes, that's what an engine is, basically. But just because it's recyclable doesn't mean it's any less of the actual game.

For example, I'm working on programming the game engine for our current project. It takes care of a lot of things, like loading planets (asynchronously) and stars, managing the coordinate system so floating point precision errors don't occur, managing planetary terrain LOD, atmospheric scattering, physics, shaders, etc.

You can't just swap out our engine for some generic thing (like Torque), keeping only the scripts - it wouldn't work. There's too much code embedded in the engine that relates to the game itself, like the assumption that spherical planets will be used (there is no flat terrain capability).

I guess I should put it this way: It's the engine that makes the game possible, and the scripts that define what the game does, within the limits of the engine. The more limiting the engine, the smaller part the script has in contributing towards the "actual" game. For a very flexible engine, it would probably be fair to say the script is where you write the "actual" game. But for a specialized game engine (and all are specialized, just to different degrees), the script is only a small part of the whole game.