Basilisk, I'm really impressed by what has been done with BlitzMax so far. What I'm wondering is, though, do you intend to stick with BlitzMax for as long as possible? What'd it take from a programming language for you to consider making the switch?

Quite simply it would take another programming language that so easily makes cross-platform compatible code. We really don't have the time or resources to make 4 distinct branches of code for Windows, MacOS-Intel, MacOS-PPC, and Linux. With BMax we can really make just one branch (with an few OS-specific compiler directives) and have a functional game for everyone. It is really quite amazing.

Since BlitzMax is a form of BASIC language, I think it is shunned by many programming purists, but I can say that kind of elitism is ridiculous. It all compiles into machine code. BlitzMax is a fully object-oriented language and can do anything C++ can do- in fact, if I want I can import C++ code chunks (if I prefer that structure) or Assembly (if I want additional speed). Some of the concerns regarding OpenGL rendering speed will eventually get addressed, but even now Book II looks to be fully compatible with hardware up to 5 years old, which covers 98% of our audience.

So yeah, for now we have no intention or desire to switch to any other language or development environment.

BW,

I think a lot of people believe that BASIC is still an interpreted or slow language. The original intent of Basic was to be a simple language that non-science students could learn to program a computer (BASIC as most of you know is an acroymn meaning Beginner's All-Symbolic Instruction Code).

Most of the languages ( late 50's early 60's) at the time were scientific (FORTRAN, Algol) or business (COBOL). None of these languages lended themselves to educating non-science majors to programming.

BASIC took the best parts from FORTRAN and Algol. But since it would be used for teaching purposes it was not a compiled language.

Compilers turn source code of the host language into machine language (the computer's native language). The entire program is turn into machine language at once. If there are errors, the errors are reported in a error listing and compiling stops. Take you error sheet and get all the bugs out and recompile. (COBOL was a good example).

Interpreters on the other hand change a line at a time of the source code into machine language. Checking for errors in each statement. If an error occurs, it would stop checking and point out the error. The person could correct the error right then and run the program again. (very good for teaching purposes).

The new modern BASICS all have compilers and some have both compilers and intrepreters. The compilers turn everything into machine code.

BlitzMAX may not be as efficient as C++ or as speedy as assembly, but as BW stated it allows his team to cross platform without having four sets of code specific to each platform. This makes development easier. You only have to worry about specific OS calls and BlitxMax supports OpenGL, which makes the graphics work easier.

Most of us will never notice the difference in speed. We get a great game on many platforms that we all can come to the forums and converse about. Works for me!

I am part of an indie game dev group. We develop in C++ and have only one branch because we use SDL and OpenGL. The library linking is a tad different for each operating system, but the code is identical (with just a few preprocessor directives). Maintaining a single branch in C++ is very doable, but I understand your desire to use Blitz.

We are concluding our first game project soon and will be moving to Ogre3D for what will hopefully become our premiere RPG.

The good news is that you were able to push out such a beautiful game using Blitz. I've always shunned BASIC for its syntax and design paradigms more than its performance, but those are just semantics. Lots of tools can be used to make great products.

Keep up the great work! I hope to save up the money to purchase Book 2 in the near future.

Well, http://www.freebasic.net/ has bindings for SDL, OpenGL and someone's also working on versions of the bindings for SFML too. Doesn't have Mac OS X support, unfortunately (think it does compile on BSD and Darwin though).

Wish someone could (or would) work on OGRE bindings for FreeBASIC, but that might require fundamental changes to the language (as OGRE is heavily C++). Might well see if I can do anything...

It's a shame that Blitz cannot produce 64-bit binaries yet. Can FreeBasic do that?

Right now, I can produce 64-bit Linux binaries and possibly 64-bit OSX binaries (the whole OSX universe confuses me). I use mingw32 in Windows, and as far as I can tell, there is an unfinished mingw64 project out there. What is the best way to produce 64-bit binaries in Windows right now? It just seems that everyone uses 32-bit binaries for convenience.

I have no idea. It might if you're prepared to put in some legwork (though, being Open Source, it'd be easier to adapt it for 64-bit then BlitzMax).

As for 64-bit binaries under Windows? Well, I hate to say this but you'd likely have to spend cash on Visual Studio. I'm pretty sure the commercial versions of 2010 can produce 64-bit binaries (as might 2008, but not so sure on that). And yeah, 32/64-bit compatibility is not quite there yet, so I'm sticking with 32-bit OSes for now.

I'd be interested in learning more about the setup/tools/software you use on each platform to compile your code. Whenever I dabble in C++ and try to figure out how to make a nice cross-platform pipeline, I end up more confused than when I started.

Confused howso?

Sure! I'd be willing to go over the details with you any time you'd like. C++ can be a pain to tame at first, but it's really a great language. We can either talk over messenger, or I can post a huge brain-spew right in this thread. Pick your poison.

Some of us would like to see what you come up with.

Just using SDL/OpenGL as your primary API cuts out 99% of platform-specific code you would otherwise have to write. Ogre3D is supposedly the same way, and we are analyzing that API for our next project.

My particular team uses Code::Blocks IDE because it runs on all major operating systems, and we can help each other set everything up properly. In our SVN, we keep a folder inside the source code called "project" that contains the OS-specific Code::Blocks project files. Those are separate because the library linking is unique for each operating system. (Windows links to "opengl32", Linux links to "GL", and OSX connects via "-framework OpenGL".) They also configure their respective include folders (each OS keeps them in different locations).

With just a little meta-data control, the C++ code is the same across the board. I program exclusively in Ubuntu; my buddy codes in Windows 7. We commit changes to the code, and everything works great in both locations. The only time we've had to write system-specific code is for those rare quirks that pop up (i.e. OSX apparently does not support window icons??). SDL itself is an adequate window manager.

Admittedly, we should be producing make files to handle the complex building across platforms, but we haven't taken the time to learn the make file format.