Not to downplay his achievement - I'm sure making the game was a lot of work either way ... but implementing it in Basic doesn't seem especially praiseworthy.
Also, yeah, I use the big ugly eye-burning white-on-blue screen. You can see a photo of the development box here: https://twitter.com/manfightdragon/status/319786194395357185
It's cool that you put constraints on yourself by using the BASIC syntax, but it's really dishonest to pretend this is being built in classic QBASIC and leverage it for press without making any distinction between the tools you're using and the tools people actually had available to them in QBASIC.
Quote from the PC World article, that is supposedly from you: "It would show that even old, abandoned tools and the most basic pieces of software can still be put in the hands of someone who wants to create their dream and result in beautiful things happening."
This to me suggests that your goal is to show that actual QBASIC, the abandoned programming tool from the DOS era, can be used to build cool games. A noble goal. Using QB64 and SDL and a bunch of modern tools, however, does very little to achieve that goal.
Maybe this is just nit-picking, but QBASIC is a very specific name - the name of a particular BASIC interpreter that came with versions of DOS. You could have easily been more general and said you were building the game in BASIC, and been completely accurate, but then I suppose that wouldn't have gotten you an article on PC World.
And to give some context, I have in the past encountered people who were ACTUALLY building cool modern games in QBASIC. They did this by writing commands out to disk from their QBASIC game and then running windows apps to do the work of talking to libraries in order to do MIDI playback or read from game controllers. This, at least, counted as using QBASIC, and was quite a feat of engineering - even if those games weren't pure QBASIC.
The game looks cool, though!
Also you're not compiling anything. It's all interpreted at run time (which is why performance is dog slow).
Often at the time, you could write some code using the free QBASIC which came with MS-DOS and then decide that you need to purchase one of those other programs to compile it prior to distributing it as a standalone executable.
Also, I went to download QB64 and compile a very basic app then opened that inside a hex editor to see if the it was just a standalone exe interpreter with the .bas attached as a resource (a bit like how self extracting zip files work) and appears that QB64 does genuinely compile the code.
So I stand corrected on both the old and new instances of QBasic.
There is some strange stuff inside the QB64 generated exe though. References to automation.whatismyip.com (stranger still, that sub-domain isn't DNSed).
QB64 is definitely a Window app that's written to look like it's running in DOS though. There's even a character map compiled into the exe so that the fonts look native to DOS. It also looked quite fun, so I can see the appeal of using QB64 for personal projects.
$ whois automation.whatismyip.com | head
Whois Server Version 2.0
Domain names in the .com and .net domains can now be registered
with many different competing registrars. Go to http://www.internic.net
for detailed information.
No match for "AUTOMATION.WHATISMYIP.COM".
>>> Last update of whois database: Wed, 17 Apr 2013 10:58:41 UTC <<<
It's pretty common for compilers for niche languages to statically link the runtime library by default. Many think it eases distribution.
1. it's statically compiling in libraries for APIs that aren't even being used (again, I know this is pretty common as well - it was more said as a side issue since I was already on the topic of it's runtime). But most importantly:
2. because automation.whatismyip.com DOES NOT EXIST. The API is broken because it calls a non-existent sub-domain name. The sub-domain has no DNS record. It does not ping nor curl because it's completely imaginary....and so on. (sorry for the flippancy of the post, but this is now the 3rd time I'm having to reiterate myself so I just want to be clear that everyone understands my point)
It reminds me a bit of the freepascal project. Beautiful compiler, tons of extensions (including generics: http://wiki.freepascal.org/Generics), graphical RAD IDE (Lazarus) ... yet relatively few people use it because C++ does all of that and more. Ultimately, I guess syntactic preference isn't really enough of a justification for yet another compiled imperative OOP language...
As a side note, QBasic does support line numbers - albeit for legacy reasons and not recommended syntax. And some dialects of BASIC did support functions - though the syntax was awkward so I usually just used GOSUB / RETURN when I needed procedures with no return values.
If I'm honest, I feel the same way as the aforementioned poster. Writing any modern game in QBasic is akin to A-Team style engineering (building a rocket launcher out of an old shoe and some duct-tape). QB64, however, is basically just like any other modern scripting language. The former would require massive hacking and "outside the box" thinking to build even the basics of the game engine; where as the latter is just Python written in the syntax of BASIC.
That all said, I can't blame him for misleading people a little (whether that's intentional or just dumb journalists not understanding the distinction between QBasic and QB64) as making a project visible can be as hard as the actual development process. So at least he's hard work will see some reward. Plus he's offered to release the source because of public interest - which is quite honorable.
> QB64, however, is basically just like any other modern scripting language.
QB64 is not a scripting language. It compiles the QBasic language (with a few extensions) to C++ and passes it on to gcc. It seems like you're making a lot of assumptions about QB64 when you could instead be looking for facts.
But the BASIC dialect that QB64 compiles is more than just QBasic in much the same way that QBasic was an advance on QuickBasic/BASIC.
I'm not familiar with PyPy (from a developers perspective) so I can't comment on that comparison.
> QB64 is not a scripting language.
I didn't say it was. What I said was that it's LIKE a scripting language. And the context of that (which you've kindly cropped out thus distorting the point I was making) was in terms of the way how the language is extended via additional libraries (eg Perl libraries can be Perl modules or bootstrapped from C++ - and QB64 libraries have that same 'feel' to them) and the nature of the language (it compiles to byte code rather than machine code†, the relatively limited scope of the language without the C++ libraries and it's performance, etc).
† It's also mentioning here that most scripting languages compile these days too, it's just that few offer a standalone ELF / PE with the runtime included (there's a limited need for the latter unless it's a niche language).
Just to be clear, saying something is LIKE something else is a comparison, it's not the same as saying something IS something else. And the very nature of comparisons is that there will be elements of the comparison which are not equivalent (which is why comparisons rarely work in arguments as the opponents will focus in the differences rather than the similarities)
> It compiles the QBasic language (with a few extensions) to C++ and passes it on to gcc. It seems like you're making a lot of assumptions about QB64 when you could instead be looking for facts.
I've played around in QB64, compiled and decompiled binaries in it and browsed it's source. Where else would you suggest I "be looking for facts"?
The QBasic language is almost exactly the same as QuickBASIC 4.5. Every version of any Basic that Microsoft release had advances over previous ones. Furthermore, modern additions to the standard library hardly constitute a language change.
> I didn't say it was. What I said was that it's LIKE a scripting language.
You're right; I read into that too much. Though I still contend QB64 is no more like a scripting language than QB45 was. I didn't mean to imply that scripting languages cannot be compiled or that all interpreted languages are scripting languages. In my mind, something is a scripting language if it's primarily used for (read: makes easy) at least one of two purposes: automation or extension. Of course, nobody agrees on what constitutes a scripting language just like nobody agrees on what constitutes anything in programming.
> I've played around in QB64, compiled and decompiled binaries in it and browsed it's source. Where else would you suggest I "be looking for facts"?
Those are good places to look. Documentation is also a good place. I don't mean to be spewing condescending crap, but a lot of the comments in this thread seriously irked me. It's a problem with programming as a field that many (maybe even most) terms are ambiguous or nebulously defined.
A lie? QB64 IS a QuickBasic derivative. It's no more a lie than saying Scheme and using Guile, or Lisp and using Clojure.
It's not like he said QuickBasic but used C++.
Apparently QB64 can directly access C header files as well as Windows DLLs [1], although I don't think the author used any external modules. The source is described as being a solid monolithic block of 12k lines worth of BASIC, which in and of itself is fairly throwback-worthy.
[1] http://en.wikipedia.org/wiki/QB64
edit : checked an old QBASIC manual to confirm whether or not multidimensional arrays (2+) were supported
DIM cube(3,5,4)If I get on Steam, I'll be able to use the DLL features to implement SteamWorks API