Back in the day there were SVGA libraries (like aklib) that allowed high-resolution (like 1280x1024 modes) graphics; but even on contemporary GHz desktop processors it wasn't fast. Also sound systems using background daemons that relayed stuff to DirectSound (or FMOD, not entirely sure after all these years).
This seems to be written in QB64 using SDL with OpenGL surfaces.
You could link against native libraries. There were a handful of graphics libraries written in assembly that we used to do fast blitting and resolutions higher than 320x200.
Back in those days, drawing a pixel was just writing to the vga memory buffer, so it was pretty easy.
there were several libs, mostly shareware, that extended the list of supported resolutions with VESA & VGA-modeX ones. I used it a lot of times. Nice days.
"The game, at the moment, requires about 2.6GHz on a single core to run good. It's just about unacceptable for a game that looks like it was made in the 90s."
Wow.
I am really curious all the things he had to write himself to make this work. I presume he's basically written his own isometric game engine and map editor from scratch in QB, which is... impressive.
I kinda wish he'd ship the code with the game... I want to see it.
In QBASIC/QuickBASIC the IDE is not file-based. By default it only shows the content of the current sub routine, as opposed to the content of a file.
If you want to look at / edit a different subroutine you open the sub routine selection dialog and select the one you want which then becomes the currently displayed one.
In the same way, if you want to add a new subroutine to the program you open the subroutine creation dialog, give it a name and then the IDE automatically makes the newly created subroutine the currently displayed one. I.e. you are only ever looking at one subroutine at a time.
Sounds limiting to programmers used to modern IDEs where you usually look at multiple functions at once, but I remember it fondly. There is something to be said for completely focusing on one sub routine at a time and for the IDE presenting your program that way, while everything is actually stored in one big file.
Holy shit, that's really impressive for QBasic. That was my first language, and I remember drawing/moving basic shapes around the screen. My magnum opus was a ray-tracing demo.
How is this game distributed? If I remember correctly, QBasic was bundled with MS-DOS (from v6 onwards I believe) and wasn't able to produce EXE's. QuickBasic was a separate commercial version that was the able to produce .EXE's.
The original QuickBasic/QBasic could definitely generate standalone compiled EXEs using the Basic Compiler (BC.EXE). IIRC it wasn't included until QBasic 4.5 and was expanded further in QB7 (aka Basic Professional Development System).
QBasic was intended as a replacement for GW-BASIC. It was based on the earlier QuickBASIC 4.5 compiler but without QuickBASIC's compiler and linker elements.
So, from this, QBasic was not able to generate .EXE's.
If you used QBasic to learn to program as a kid (which I did) then you might be interested in AppGameKit[1]. I would recommend it, however I must mention that I've become used to OOP and it is difficult to go back to a language that doesn't have it. So I haven't dont anything serious with AGK yet. Though there are many who have.
Same - I remember being in elementary school, playing nibbles or gorillas and then poking around in the source, trying to figure out what it was doing.
Ditto. I got as far as doing some basic 3D graphics in it (rotating spheres and such), an Asteroids clone, and arpeggiating chords for "harmony" from the PC speaker, but nothing quite like this.
Then again, this was written in QB64, which can do things that would've been wildly impractical in QBasic itself.
i taught myself c by prototyping programs in qbasic and then converting them to c. nice language, and for their time, the integrated help files were some of the best i've seen.
Bingo. My computer as a kid wasn't even connected to the internet so those help files are the only way I would have learned. That, and breaking the few programs that were included with it.
I discovered recently one of my new neighbors just retired from MSFT and was one of the original members of the QBasic team. Considering how much time I spent as a kid learning on it, I was kind of star struck.
- QB64 provides a graphics API, a wrapper around SDL and OpenGL.
- QBasic isn't that quirky, and QB64 looks like it pretty massively expanded the language. QBasic itself allowed for struct types, a limited dynamic memory allocation, and the standard flow control structures.
The author apparently modified QB64's use of SDL/OpenGL to handle some scaling differently.
It's impressive as a solo game project and interesting for the nostalgic connections. I respect anyone who can get through a project like this on their own, but it just doesn't seem that unusual.
It seems like Unity really blew up around 2013. The first references that I can find to this game are from April 2013, so he'd likely been working on the engine for a long while before that.
And most of what I've played reach back before then too ;-) My point was that Unity's probably been used for "just" a few hundred games, mostly in the past 4 years.
And also I don't think he'd have chosen Unity either; he talks a lot in the post (or the forum, I forget which) about being very comfortable with QBasic and choosing it for his familiarity with the language.
