Managed inheritance

One of the coolest new features of CoolBasic V3 will be classes and their inheritance. In this blog entry, I’m not going into details nor will I summary exactly what aspects belong to it in CoolBasic’s case (I’ll leave that for later), but I’d like to share some conclusions on how to perserve data integrity through inheritance.

CoolBasic will support perfect hierchical inheritance of multiple classes. As in Visual Basic .NET, there will be “Me” and “MyBase” keywords which point to the current class and the parent class the current class was derived from. By default, overloaded functions between the derived and parent classes reference primarily to “local scope”. In order to specifically call the parent class’ functions “MyBase” keyword must be used in conjunction with the member access operator, for example “MyBase.MyFunction()”.

ChaosBasic (read more at CoolBasic forums) introduced a syntax which allowed multiple inheritances when a new class is created. Parent classes were separated by commas such as: “Class OpacityCow Inherits Cow, OpacityObject”. Now the question is… where does MyBase point to? How do you access the parents’ constructors? There’s obviously a design flaw with this concept, so I decided not to implement multiple inheritances in this way. Instead, much more coherent way to approach this problem, would be to only allow one inheritance per class. If the programmer wished to link multiple classes via inheritance it’d needed to be done like a->b, b->c.

In VB.NET, C#, and Java access is resticted to the direct base class to prevent inconsistencies in an object’s state. That’s why MyBase.MyBase does not exist. Some languages, however, do give access to traversing underlying classes… i.e. “::”. I haven’t decided yet whether or not I should allow this. For those who are interested in knowing more about the pros and cons of grand parent reference, I recommend visiting

This “safety net” applies to class constructors as well; CoolBasic V3 will force you to call the parent’s constructor in the derived class’ constructor. This ensures that all constructors are called when a new instance is created which in turn will result in complete and “well-formed” class instance.

Comment parsing

A few things about source code comments worth mentioning. First of all, both singleline comments and multiline comments will still exist in V3. Comments will be written pretty much the same way they’re written in C (and the related) languages. That is, singleline comments beginning with double slashes “//”, and multiline comments introduced as block that starts with “/*” and ends with “*/”. No more remstart/remend.

For now, multiline comments are stripped already in the file reading pass, and not in the lexical phase (singleline comments are handled here, though). I thought it’d be more efficient in terms of compilation time if lines that wouldn’t be processed anyway, were ignored completely instead of going through the normal tokenization. Due to this, comment ending and starting can’t occurr within a logical line. Obviously this would be easily fixed, but it’s extra work and some code recycling – which is rarely a good thing. This means that the “/*” and “*/” must be on their respective lines alone in a similar manner to how remstart and remend currently work. It may require some time to get used to this, but as it stands now, my decision is justifiable.

Images and the blind

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.

The Dragon Book

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 😉

Assembly Summer 2008

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!

AeroGlass Candy

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.

Designing the new Website

Due to the incident with webhotel I decided to change hosts and move the domain and the entire website to a new provider. After being absent for almost 3 years, I also feel that the current CoolBasic website is simply put, quite awful; Its look is outdated beyond all hope, and in fact its inner stucture collects dust in all essence – something that is completely left out of the current trends and CSS-based styling standards.

Also, CoolBasic V3 has its very own theme now (of which I will not elaborate just yet), so I decided to create a new website that is a little more appealing to a certain degree. The new website framework is already complete and looking good, but until CoolBasic V3 launch I don’t want to release the site since it would ruin the surprise (by its theme). Although the visio I’m having right now is just brilliant (*cough*) I really think that CoolBasic V3 should be released not until its Beta stage, and as a whole. Meaning that the Beta, website, manual and all other related things will just pop up during one night, and the users would wake to a beautiful morning 🙂

That being said, a placeholder website is needed. The current one really sucks (what have I been thinking while doing that?!), so I also took the effort and conjured up a little website for the current CoolBasic (2.x -generation). It’ll remain in effect until the massive Beta-launch takes place and the actual website will be introduced. Both websites, the placeholder and the final site, will be bilingual i.e. available in both english and finnish.

So far, the final website passes the strict HTML 4.01 validation.

Copyright © All Rights Reserved · Green Hope Theme by Sivan & schiy · Proudly powered by WordPress