Blitz Basic Worklog

Finally, you can now create executables!

· 8/8/2000

Hmm, not a lot to report, but I'm kind of bored so thought I'd write some stuff anyways...

Perhaps the major thing to note is that Blitz now has a simple debugger. It provides a combined call-stack/variable-watch tree control you can inspect while your program is stopped or tracing. Nothing too fancy, but I'm already finding it useful myself.

There's a fair bit of pressure on at the moment to add Windows GUI support to Blitz. Fair enough, as many of the AmiBlitz users got into Blitz for it's Amiga GUI support. These are also the people showing the most interest in Blitz at the moment, so I find this totally understandable.

However, GUI support for Blitz is not my immediate goal. Ideally, I'd rather get a decent library system into Blitz and let someone else tackle this! At the moment, my goals for Blitz are still cool 3D and a solid library system.

· 29/7/2000

Wow, what a day! I've finally solved 2 major problems within the space of about 8 hours!

First up, people have been reporting speed problems - ie: Blitz progs were running very slowly in certain graphics modes. The problem appears to be that not just different video cards, but different display modes have different capabilities. This had kind of occured to me, but I couldn't think of a way to determine which display modes were the problem ones. Anyway, there is, and it turns out to be ridiculously simple. VERY MUCH my fault, but when you're trying to debug something on a machine 2000 miles away it's easy to panic!!!!!

Secondly, Blitz now works under Win2000! I have finally taken the plunge and installed the beast - still using Win98 for development though - and was incredibly happy to find Blitz was just 1 fix away from working 100% Woohoo!

· 27/7/2000

Sorry about the lack of updates, but it's been a fairly uninteresting 'fix-lots-of-bugs' period. This is, of course, a good thing, but doesn't make for terribly gripping reading.

I have received lots of 'put this in' requests, but am trying fairly hard to stick to my primary goal of making Blitz solid and bug-free. While I'm under no illusions about releasing Blitz with NO bugs in it, I'd like to minimize problems as much as possible. However, some feature requests are very sensible - revealing a distinct lack of foresight on my part - and have been implemented. I'm not going to mess with language features too much from here on in - at least not until BlitzPro time - but new, simple commands are no problem.

People have been knocking together some quite nice demos too - check out the examples page. Unfortunately, executables aren't available yet so you'll just have to stare at the code and wonder...

· 21/7/2000

Well, it's been an incredibly nerve-racking couple of days. For reasons totally unclear to me, one of the MFC methods decided to start behaving completely differently. The problem appeared after installing the latest 3DFX driver (worst installer I've ever seen), and boy was it scary. After installing the driver, I started Blitz up and was mildly(!) surprised to find that all the demo programs appeared completely garbled in the editor. On top of that, NOTHING would compile. Two days later I had finally tracked the problem down to the GetLine() method - it just appears to work totally differently than it used to. I guess the 3DFX driver must have installed an MFC dll that works differently - I'm just amazed at how differently it works! Anyway, the problem is fixed, and I've had confirmation of the problem via the experts exchange site.

Reading the docs for the GetLine() method I can see that it could work either way but, like DirectX, the docs are extremely vague, consisting of only a few sentences.

I also threw together a 'Firepaint' demo. This simply generates explosions when the mousebutton is held down, but looks very cool! It also makes for a good speed test, with hundreds of particles flying all over the place.

With the GetLine() problem out of the way, things are starting to look very finished. Look out for a demo soon!

· 16/7/2000

Yet another discussion group started! There were lots of requests to move things over to e-groups, so it is done. I think you have to register or something, but it looks pretty groovy. Go here.

Had a bit of a relax today and when on a minor 'coffee-crawl' around Auckland. Did manage to put in saving of window-size/general preferences, though.

I've been hammering Blitz quite a bit lately, and it's looking really solid. No crashes so far, although some of the error messages are a bit confusing - must fix. However, as with anything PC-related the real test is how well it works on EVERYONE's machine. Hopefully, the beta release in a few weeks will uncover any of the nastier problems.

There are still a few memory leaks, but I'm pretty sure I know where they're at.

· 15/7/2000

Well, I've been putting this off in the hope I would gradually change my mind about it, but that hasn't happened so here we go: The DirectX rant:

DirectX really, really sucks! Why?

• Amazingly convoluted and downright 'weird' API. Although this can be said of pretty much the whole Win32 API, they seem to have gone to extra lengths with DirectX.
• Slow. Ok, it's pretty hard to beat hardware accelerated Blits, 3D etc, but whenever the software has to do anything it seems to ALWAYS be better to write your own, naive version. Examples? Clipper objects - clip 'em yourself for a non-trivial speed boost. Transformations? Ditto. A hacked up for...next matrix multiply goes faster. Direct3DSound? I have no idea what they did to this, but doing your own doppler-shift/3d pan/fadeout effects on top of DirectSound is about 3X faster.
• Incredibly Non-deterministic. Basically, NOTHING in DirectX is guaranteed to actually work - EVERY call you make has to be checked to see if it succeeded! This places an incredible burden on the programmer, and is certainly unnecessary.
• Very poor documentation. There are a million 'gotchas' to watch out for in DirectX, very few of which are documented. Important topics like interaction with Windows are given about a paragraph, while whole chapters are devoted to non-DirectX stuff like 3D pipelines. Weird. Still, I get the feeling not even Microsoft know how DirectX works anymore. On the ONE occasion I've actually received a reply from directx@microsoft.com, they only had answers to 2 of my questions - one of which was useless, and the other just plain wrong.

It's really scary to think that the people responsible for this are subtly 'guiding' the development of PC gaming hardware - in the sense that it's now pretty much an 'AHAL' (abstract hardware abstraction layer!). Whatever junk they throw in to DX the hardware manufacturers are gonna feel obliged to implement. Yeuck.

· 12/7/2000

Spent the last few days tidying up lots of little problems and tweaking various commands. Almost all the menus are functional now!

I also started work on 'release' mode. This is where all the runtime checking is turned off and your code just FLIES! Up until now, every statement in the program was making a windows PeekMessage() call before it executed. This is disabled in release mode, and although the speed difference is noticable it's not as great as I thought it would be! Array checking goes in release mode too, so make sure your code's cool.

I'm yet to put in any serious work on runtime error checking. So far, I've been relying on windows exceptions to let me know when something's wrong, which work nicely but is a bit obscure. Most runtime errors result in an 'Illegal memory address' error message, which is not very useful. Got to get on to this...

All up, Blitz is starting to look very much like a decent package. Hopefully, the beta in early August is still a reality...

· 6/7/2000

A major clean up of the command set is just about finished. I got default parameters going for functions - within Blitz, too! - which slims the command set done quite a bit. Also put in a nice Select...Case...End Select, that works for ints, floats and strings, and allows multiple expressions per case.

ResizeImage and RotateImage went in very sweetly. As they're intended for creating pre-calculated images, and not for real-time use, I could afford to do something a bit tricky, so put in bilinear filtering. The end result is scaled, rotated images that are very smooth. It's even possible to rotate by less than a pixel, but still notice the rotation! I took a huge sprite, rotated it through a tiny arc, and you can definitely notice it swaying. Or so I've convinced myself...

I also put in a very cheesy console mode, basically so people (myself included) can mess around with various non-graphical commands. It's not meant to be used seriously, but it at least gives Blitz simple Print/Input capabilities. I'm eventually going to convert all the (non-C++) filesystem stuff over to Posix too, meaning the 'core' of Blitz should be buildable on quite a few platforms...

Check out the commands page - most of the major stuff is now in.

· 30/6/2000

Well, it's been a slow but rewarding couple of days. Pixel perfect collisions are finally happening, after much scratching of head and general 'humm'ing and 'hahh'ing. Actually, it felt a bit like a return to the old Amiga days - stuffing around with shifting and last-word-masks - but the results are worth it. Could also be a good candiate for assemblerizing. Still, it ALWAYS pays to see what kind of asm VC has produced as it's often very, very good.

I also put in DirectMusic support. It's a huge package, and feels a little like overkill just for the sake of letting people play music files. I don't think it plays anything but Midi, either - the docs are a bit vague on this (and that, and that...). It would probably pay to put in support for good-old winmm.lib too, as I think this is more flexible. Still, there's a lot in DirectMusic that someone with a more musically inclined brain would probably understand, so it could make good fodder for BlitzPro library writers.

Also reduced(?) constant expression trees in preparation for a 'Const' variable type and default function arguments. Up until now, an expression like 'a=100-50' would have generated code for the subtraction. But no more! I really want to get default function args in ASAP, as the library command set is looking pretty bloated at the moment.

· 27/6/2000

Whew, just knocked off about 30 BASIC commands! Mainly string handling and fileio stuff - not much fun, but working in C++ made it about 100 times more bearable than it was in the bad-old 68000 days! God, I'm glad I'm over assembler, but still have a huge respect for the guys out there still hacking (in the REAL sense of the word).

Animating images are in, and pretty simple to use. LoadAnimImage just grabs a sequence of cells from a .bmp and DrawAnimImage is used to draw a cell. Animating images and normal images are really just the same thing, except normal images have only one frame. I may actually drop DrawAnimImage and use an ImageFrame command instead to prevent the number of Image commands balooning. On the other, hand I don't like 'state' stuff very much...

Only 3 serious things I have yet to do with Images. ResizeImage, RotateImage and some kind of pixel-perfect collision routine. I know of no PC hardware that allows for collision checking like the good old AmiBlitter, so I'll probably have to create bitmask images for collision purposes. Not too major, just messy...

I've also replaced the 'commands' section of this page with a link to an automatically generated document that reflects exactly the commands present in Blitz.

· 24/6/2000

There comes a point in any project where you suddenly feel like, 'wow, this is starting to look like something cool'. It's usually triggered by some minor addition, and is usually a total surprise. In games, it's quite often the addition of a title page. It happened the other day with Blitz, and it was caused by simply adding a 'compiling progress' meter. Suddenly, it felt like I was using a real piece of software...weird.

Emboldened by this small step for Mark-kind, I got back into the IDE and added a whole bunch of trivial stuff. The difference is amazing, and Blitz is starting to 'feel' really, really good! True to form, I'm not quite doing the IDE the 'proper' way (ie MFC MDI app). This is partly because reading MS documentation is too much like real work, and partly because I just like to do things differrently! Anyway, it gives Blitz a certain unique feeling that I am well pleased with.

I added a whole bunch of sound commands the other day. DirectX is pretty good in this department, once you've got your head around the WAVEFORMATEX structure. Anyway, sounds are playing happily away and all is good.

Also added my own 'new' and 'delete' operators for debugging . I'd been using Visual C's DEBUG_NEW up until now but, like so much of Microsoft's stuff, you spend a LOT of time trawling through endless docs looking for a tiny feature before saying to yourself 'This is crazy. I could do this myself in half an hour'. So I did. The upshot is I have a very nice memory leak detector built in to Blitz, and have been hitting in mercilessly.

· 20/6/2000

There is now a BlitzPC discussion group, where people can put forward Blitz ideas and just generally shoot-the-breeze!

· 15/6/2000

Another highly successful day! I had decided today was gonna be a big 'fix all the memory leaks' day, and expected it to be a long, drawn out hassle. Fortunately, it wasn't, and by midday I was twiddling my thumbs looking for something else to do. I decided it was time to have a go at generating some stand-along executable code - something I've been putting off until the program format had stabalized a bit. A few hours later and it was all go - spacies at the click of a button! This is very cool, as I can now start sending out some executables to people and suss out compatibility issues.

· 14/6/2000

Wow, long time without an update. I've been working madly away and am happy to say that Blitz is coming along very, very nicely. Floating point is in (except for one tiny problem), NewTypes are happening, and I've written a little Space Invaders!

The NewTypes thing has been implemented very differently from the original Blitz. For starters, everything is now a pointer. To create an instance of a NewType (an 'object'), you use the 'New' operator. To get rid of an instance, you use 'Delete'. All New'd object are maintained in a global list, giving you quick 'n' easy access to all objects of a particular type. For example, here's how my space invaders code updates the aliens:

for a.Alien=Each Alien
UpdateAlien( a )
next


You can achieve the same thing manually:

a.Alien=First Alien
while a<>Null
UpdateAlien( a )
a=Next( a )
Wend


Other cool things: you can Delete an object, but still use Next or Prev on it. Deleting an object will automatically force all pointers to it to 'Null'. You can delete all instances of a Type with 'Delete Each' - great for end of level clean-up, and it's nice to know all those objects really are deleted.

Best of all, the horrible aliens() current object thing from AmiBlitz is no more.

This system is not quite ideal. Objects are maintained in only one list, although it's no problem to manually create your own lists C-style. In my experience this isn't too much of an issue, particularly with games, but might bug people who want more flexibility. I will probably explore mulitple lists at a later time, but right now I'm very happy with this set up as a core memory management system. Other stuff can be layered on top.

I've also been playing with the idea of allowing objects to specify states, maybe like this:

NewType Alien
var x,y
state active,angry,happy end newtype


for a.Alien=Each Alien[ angry And active ] ...

Enormously useful for games, but we'll see...

Other things I've been up to:

• Array bounds checking is in.
• Temporaries cleaned up at function exit.
• Major sexification of code.

On the topic of functions, It's looking like Gosub might have to bite the dust in Blitz - too much of a headache to implement cleanly. It would also simplify things to throw out Goto as well, but I'd probably end up with a bunch of angry Basic programmers out for my blood. Besides, I like having it in there just to piss off the purists.

· 23/5/2000

Yay! Back into some real programming! Finally put in some decent register spilling, which seems to be working well. The actual spilling code isn't too hard, but Intel's instruction set makes for some 'interesting' problems. In particular, certain instructions need their operands in particular registers - eg: divide requires the divisor to be in EAX:EDX; bit shift instructions require the shift amount to be in ECX. But it's making a pretty good attempt to ensure these requirements are met, thus causing fewer spills.

This has really been a lead-up to putting in floating point, which I am starting on right now...

· 22/5/2000

Woah, sorry about the lack of updates but it's been a week in Windows HELL! I learnt a lot more about DirectX and MFC than I'd really like to know, but it's all been fairly productive. Your code can now be run in either 'debug' or 'execute' mode. Debug mode copies it's output to a window, and allows you to stop/step through the code. Execute mode runs full-screen, but you can only pause or continue execution. Not entirely what I was after, but a good compromise.

Syntax hilighting now in, although my color scheme leaves a lot to be desired! It's not very fast at the moment, but fast enough. I'll probably soup this up a bit later - the initial coloring when a file is first loaded is a bit slow.

· 12/5/2000

Put in forward referencing for functions, and functions returning values - hurrah! You can also forward reference arrays and simple vars, but I may take this out. It's probably time to put in some floating point - a bit of a hassle due to x86 FP being stack based. In fact, a complete overhaul of the register allocator - which doesn't even spill yet! - is probably in order.

· 11/5/2000

Spent some time changing the runtime/debugger interface. The IDE and runtime are designed to run in separate threads. Before, some of the runtime thread code was in the IDE project, which I wasn't too happy with. Now all the runtime thread code is in the runtime project - much nicer.

Also implemented the 3 graphic modes the runtime can execute in - stand-alone, fast-windowed and slow-windowed. Stand-alone is full screen/full speed mode. Fast-windowed simulates double buffering by using 2 offscreen videomem buffers, while slow-windowed uses one offscreen video buffer and 2 offscreen system buffers. Slow-windowed is mainly for graphics cards without much videomem, or projects which consume a lot of videomem. However, windowed mode will probably always consume more memory than stand-alone, so it's probably a good idea to make sure the IDE can handle only having a stand-alone mode.