This is old news (about a month), but due to the extraordinary nature of this issue, I decided to share it anyway. I received an interesting email from someone who’s completely blind. He told me that he couldn’t read the ASCII-table of the manual because it’s there as an image. Now that you think about it, there’s really no reason why the same table couldn’t be illustrated in text as well, and therefore be available to those few who are actually using special equipment to read information on “screen”. In today’s Windows world ASCII-tables are quite irrelevant apart from console applications, so the last 128 characters of the table weren’t even presented in their original DOS-symbols.

Funnily enough, most of the ASCII-tables you’ll find when you browse, for example, results of a Google search, are indeed images. Is it because it’s easier to generate the codes of each individual characters in a form of a table on some “canvas” and then simply screencapture it? Or is it just so much more work to write the HTML-table generation within the loop that iterates the character codes? Maybe we’re just lazy. Either way, I’ll make sure that the next ANSI-table within CoolBasic V3 manual is in pure text format.

I finally got my hands on the Bible of all compilers, The Dragon Book. Yep, it’s over 1,000 pages of pure knowledge and covers basically all one would ever want to know about how to make a high-end compiler for modern programming languages. The real name of this epic tome is “Compilers – principles, techniques, and tools”, but the reason why it’s called “The Dragon Book” derives from its cover illustration: There’s a dragon and a knight fighting each other. Inside, however, wall of 8pt text crits you for over 9,000! The books was originally written back in the 80’s, but the fresh second edition was published in 2006. This newer, updated version is the one I currently have.

Greedily I started munching the text, and to my surprise, I noticed that the described techniques are exactly how I’ve been writing the V3 compiler. Good. I probably won’t build the V3 compiler all by the guidelines of this book because there’s way too much information for me to handle at this point. But hey, I can always improve the compiler as I learn more and advance through this book. Mark Sibly (head programmer of Blitz 3D) once said, “When I was making my first compiler I couldn’t understand half the material (books) I had.” I can’t remember what the exact quote was, but you get the idea. I have a feeling that this book will serve me well in the future 😉

The annual summer party for coders, gamers, composers and artists took place again in Hartwall Arena, Helsinki Finland. 5,000 people was there! Although this time I decided not to purchase a computer ticket (a seat and a network spot reserved just for you) it was nice to be there again, after 3 years of break. The biggest reason to actually go visit the arena and not just sit home and watch all that from the Assembly-TV network stream, was that there were quite a few CoolBasic users with their desktops and laptops. I felt it’d be cool to go there and say hello face to face. So I did. Thanks to an “organized” topic on the CoolBasic forums, some real meets actually took place where members of community could talk and share thoughts in more “quiet” place. I myself missed all the meetings, but I heard afterwards that they were a success. I did, however, drop to say hello at the seats that were announced on the Assembly topic.

I probably said things I shouldn’t have, but the feeling and atmosphere was so amazing I guess I just accidentally slipped out some surprises about CoolBasic V3 I’d prefer not to ruin at this point just yet. However, now that I think of it, I hope I gave some hope to those who listened to me, that a new version is indeed in development and it’s going to bring a lot more to the table than the current CoolBasic version 2 (which is still at Beta, lol).

As I walked around the arena in darkness it wasn’t hard to spot these guys 🙂 I saw CoolBasic forums and editors open on their screens. I was flattered. It’s rewarding to see people actually using something that you’ve created. They even arranged a little competition of which I saw 4 CoolBasic entries (or they did it just because they knew I was coming to a visit, hehe). In addition, I saw a splendid graphical “demo” made in CoolBasic, covering some nice effects I’ve no idea how they’re carried out code-wise. This whole thing drove some new energy into me, and I feel encouraged to continue. I hear people thanking me for making tem what they are – without CoolBasic some people would never had started coding, and some of them are already growing out of the current CoolBasic due to its limitations. Those limitations I wish to lift in V3.

Again, Thank You!

I can’t help but keep liking Windows Vista AeroGlass UI. It’s simply amazing. Not an overkill, but impressive enough to get me thinking of it all the time I use Windows. That being said, I recently came across with this article in the MSDN magazine, where this effect was introduced in-depth. I found out that enabling this effect in Windows Forms was not so difficult a task after all. With a simple API, a programmer can enable the blur behind the window, extend the glassy client area, or change the color theme for a single window. All this got me pretty excited, so I thought why not give it a try and play with this little eye candy a bit.

Since it’s practically only about calling the Desktop Window Manager DLL (that ships with Windows Vista), achiving the effect would be easy and independant from the programming language used. I wrote a simple test application in VB.NET, and was pretty satisfied with the results. However, as the current plan stands, only the code editor in CoolBasic project would be written in .NET. All important tools, the engine and the libraries would be written in other languages such as VC++ 6.0 and PureBasic in order to establish as low software requirements for CoolBasic games and using CoolBasic development environment in general. So I tried to achieve the AeroGlass effect in PureBasic too (since it’s used to create some tools), and succeeded at it!

At that moment, I was on fire. Then I tried to apply this effect to one of my tools (Work In Progress, huss). That particular tool had some controls on its main Form. The glassy look worked fine on it, but as soon as you have labels, buttons or other controls, things get messy. The controls had opaque background color whereas their front color was transparent. Meaning that label texts, for instance, weren’t black but appeared in a carved manner. All control texts were difficult to read. Now the control background color isn’t really too much a problem as it’s easy to apply a transparent brush on them. However, fixing the foreground color proofed to be a lot trickier task.

It’s obviously a GDI-related problem: It ignores alpha data whereas DWM takes advantage of ARGB-encoded brushes. It’s possible to set the Form color manually with alpha value being zero, but that way the window transparency would be gone and that’d be completely against the purpose of the entire implementation of AeroGlass. The only solution to this would be to manually draw label texts with standard bitmap blitter – which supports alpha data. All this involve creating bitmaps using DC, in addition to some tricky code for event custom handling. You’d get a text effect similar to Windows Media Player (the Vista version), including the glow behind the text. But buttons and other controls would still render incorrectly. I’ve yet to figure out a fix for this.

AeroGlass could perhaps be applied to the new Editor, but not on the tools such as Auto Updater. I decided not to implement the effect for now.