The ‘Classic’ compiler in C#

First things first: I’d like to correct the wording in one of my previous post’s statements. I mentioned this “another compiler that didn’t turn out that good”. Some people are now under the impression that C# is to blame for the project in question being now in a frozen state. Maybe I phrased it poorly, but the fact that it was developed in C# at first, has little to do with its failure. The author clarified to me that he dropped C# and switched over to C++ just for the sake of re-writing, and not due to performance issues. Personally, I don’t buy that, but that doesn’t matter. What matters is that a lot of people are paying a lot of attention to what I actually say, and I should be more careful how to express my thoughts in this blog. So let me emphasize once and for all… the other compiler project was ‘successfully’ developed in C#, and later in C++, but is now paused for an undetermined time due to completely unrelated reasons. There. Case closed. He’s watching my blog very closely, though πŸ˜‰

And then onto other issues at hand. The new compiler (written in C#) is progressing nicely. In the beginning there’s naturally lots of plain setup to do just to get most of the needed entities created. It’ll get more interesting soon, though. For the past week, I’ve used approximately 4 to 6 hours almost every day after work to establish the new compiler solution. That’s a healthy 12-14 hours of programming a day πŸ˜‰ . Time flows easily when you listen to inspirational music. Currently, the compiler parses the command line arguments, initializes a build job, and invokes the lexer on the source file. Half of all token types are already recognized, and there’s also one dummy parser (which, for testing purposes, only prints all tokens to the console output). I expect to finish the lexical analysis on the remaining token types soon. And then I can start implementing the statement parsers – which ought to be interesting because I now have some new tools at my disposal, thanks to object oriented platform.

I decided to take a little different approach for error reporting. All old compilers shut down the process immediately after encountering the first compile error. This new design doesn’t do that, but the compiler creates a list of compile errors instead and prints them to the standard error stream. This allows Cool Developer editor to compose a neat listing the user can then iterate through and fix more issues at once before re-building. This will probably save time on trial-error, and thus enhance productivity. Basically, this concept requires the compiler to be able to recover from compile errors and simply continue the process from the next statement. Oh, architectural joy! In addition, the compiler now also supports warnings i.e. messages that don’t count as errors, but still hold information about problems in code. Warnings don’t cause the compilation to fail, but they too will be listed in Cool Developer’s user interface.

As a bonus, you’d call the CoolBasic Classic compiler from command line like this (subject to change):

cbccompiler mygame.cbc /out mygame.obj /def coolves.fw

You can optionally enable Finnish interface by adding /lang fi

Possible platform changes

We recently had a discussion at our regular DevTeam meeting about exploring other possibilities for a proper development platform (and for the record, that meeting was one of the longest so far). There is a number of reasons why we think we should migrate away from a certain programming language, and base our code upon a “more supported” platform. For example, when the Chipmunk physics library updated not so long ago, several problems emerged regarding cross-compiler generated code, and ultimately broke some compatibility. Now, one would expect that since it’s C it was standard enough to “just work” every time. In reality, however, our developers have had hard time with importing and invoking (consider SSE2 and dozens of compiler flags in the equation) the 3rd party libraries. We’ve got Chipmunk working in the current build, but there’s a high probability that it’ll break again in future coming library updates. All in all, fighting these kinds of problems is indeed quite frustrating (and uncalled for), especially when debugging these things is very difficult – if not impossible.

I think that procedural coding in general, an inadequate editor, a bit too simple tools, and a somewhat limited debugger will not serve our best interests in the long run. To me personally, it’s not too encouraging to open up our current development environment and start writing productive code anymore. I’m a professional C# developer, and this procedural coding (I once preferred) is becoming a mental burden for me. It has definitely affected my motivation in a negative way. I know I said a year ago that in order to create a fast and compact compiler, a procedural approach would be ideal. But I consider pleasant and powerful tools equally important because it enhances productivity of the programmer and maintainability of the project. I’m referring to Visual Studio (which in my opinion is the best IDE out there) as well as to Intellisense, refactoring, code analysis, unit testing, and other very powerful tools provided by it. After all, I think that if the compiler required a tad more memory and it took 2 seconds longer to build a game, it wouldn’t hurt too much (in a year the computers running the compiler are probably multiple times faster anyways).

So we’ve come to a point where we’re going to port our existing code over to C++ and C#. This will make a whole lot of new possibilities available to us: We can now harness the power of modern development environments, get more productive, and we no longer have to worry about the import files. We can trust that the generated ASM is correct and that using external libraries won’t conflict (that much, at least). There are pros and cons in object oriented design, but overall I’m confident that the marginal speed gain provided by procedural coding style isn’t going to outweigh anything. One of the most important things is that the developers are happy and get to work on something they enjoy.

The Cool VES game engine is going to be re-written in C++. This still enables us to inject ASM to where speed is critical. We’re also experimenting with a new multimedia library that ought to ease our job when implementing certain command sets in the future. We also continue developing Cool VES for both Windows and Linux.

I also mentioned C#. That’s for the CoolBasic Classic compiler! Now, this is quite interesting because there has been one project (that has nothing to do with us) I’m aware of, that attempted to write a compiler in C# about a year ago. It didn’t turn out that well, and currently the project in question is apparently frozen. One would think that this should be considered a warning example, but yet I’m willing to try doing the same thing because I really think it’s possible and quite doable. Yes, there are some serious challenges, and the architecture plays an exceptionally big role here. C# makes it possible to create a very high-level and sophisticated core for the compiler, and I’m very excited about it. Only a day after the meeting, I already had an initial architecture plan and a Visual Studio solution in place. Given that procedural model is seriously impacting my motivation, I actually believe I’ll get the job done faster now that I have good tools – even when it means I basically have to start over.

Many people associate C# to the Windows operating system. While it is true that C# is largely used to write software for the Microsoft .NET Framework, not everyone is aware that you can target programs written in C# to other platforms as well, like Linux. Just as Cool VES is intended to have both Windows and Linux versions, CoolBasic Classic compiler should also be available on Linux. I’ll be using Mono for that, but more information about that will be published at a later time.

If this becomes an epic fail, I can always revert back to the old compiler, although I highly doubt that. “I want to believe” πŸ™‚ . In fact, I should have known better when I made the decision of the development environment almost a year ago. I hope I get it right this time…

TLDR; We decided to start using more powerful development tools, and we’re all now more productive and happy.

Introducing the Cool Developer editor

Hello again. Guess what, we have another video to offer! This time we’ll demonstrate Cool Developer, our forthcoming code editor and development environment. If you didn’t know, Cool Developer is the very same editor you’ll end up writing CoolBasic Classic games with in the future, so I think the video material you’re about to see is going to be very interesting. This sneak-peek introduces the editor at a very early state, but it’s already working wonders and we thought it’s ready enough to be publically announced.

This video is narrated by Antti Kajanus, a DevTeam member who is also a professional programmer and an expert in various Microsoft technologies. He’s an ASP.NET MCPD, and currently actively working with Windows Presentation Foundation. He’s the main responsible for Cool Developer. You may want to check his blog for more information and interesting stories about software development at excitingcode.com.

The following video shows quite a few interesting things, including a very powerful layout/windowing system, a solution explorer, an editor control, and the ribbon. The icons and other graphics are by no means final. The intention is to show the basic concept of the new editor. Enjoy!

CB Comic #3

CB Comic #3

Introducing Astigma (DevTeam General Manager) and Drath (DevTeam Content Manager)

Framework Definition Files

The purpose
Ok, so I think it’s finally time to introduce something I’ve been working on for the past several weeks. This is actually one of the two “bigger” things that I referred to in my previous blog post. As I’ve been hinting a couple of times already, one of our strategies is to design our future coming game making tools in such a way that they’re as modular as possible. That is, we want the languages (such as CoolBasic Classic) to be separate from game engines (such as Cool VES) so that a language is merely a tool to write programs and the user can choose the target framework that best suits his/her needs. This also dictates that language compilers should not be directly dependent from the target execution system (read Virtual Machine). CoolBasic Classic, as a language, thus doesn’t really know about the functions and constants or any other type of symbols that are available in, say, Cool VES game engine. For example, unless explicitly specified, you couldn’t call LoadObject or PlaySound from CoolBasic Classic source, unless you wrote those functions yourself.

So you have to tell somehow to CoolBasic Classic compiler that these functions exist and how to invoke them. What happens under the hood, is that instead of executing CoolBasic source, a game engine (Cool VES) procedure shall be invoked. This is where the Framework Definition Files come in handy. As a part of Cool VES installation, this file is provided. The definition file is passed to the compiler during build operation. It contains a list of function and constant symbols that will get imported to the compiler’s symbol table to begin with. In this way, the compiler is able to recognize those services provided by the target framework, in our case Cool VES game engine.

There are two types of definition files: one is XML and the other is binary. They both host the exact same information about symbols. The XML format is intended for easy reading, and it can be consumed by 3rd party applications. Also, Cool Developer editor reads symbol listings from the XML file so it can highlight the code properly. However, parsing XML can be a bit slowish, and doing so every time we want to build and run our game will be an overkill, simply put. Luckily, the binary format is designed for fast reading and parsing, containing offsets for fast file seeking. The data is stored there as a structured tree so that full scope info is retained. We are planning to publish the binary format specifications (yes, a public document) at some point too, but this information is, of course, subject to change.

The editor application
Needless to say, we needed an editor to create and maintain these definition files. So I created a neat application for that. It’s an internal tool that the DevTeam uses, thus it’s not available to public. This hasn’t prevented it ending up being a quality piece of software, though, and I’ve actually put a bit more time on it than I originally planned. But that just makes a point, eh? We drive for quality! Quality takes time, but in the end, it’ll be worth it. This is how the editor looks:

Cool Framework Definition Editor 0.9

It’s been written in C# (.NET framework 4.0), and that cool dark appearance (something like that will be in Cool Developer’s theme collection, too) is the Expression Dark theme, from Microsoft (and it’s also available for free at codeplex.com).

The video
As a bonus, I decided to try something new, and managed to conjure up something I think can be considered a video. That’s right, I made my first video ever, and put it on YouTube! I have absolutely zero skill and experience in video recording, editing, encoding, and presentation in general. It’s narrated in english (which is not my primary language), and I found out the hard way just exactly how difficult making a video like this can be. Despite careful planning and preparation, I found it surprisingly hard to not begin to stutter midway or how to keep your speech fluent without any moments of disturbing silence. Before the actual presentation, I actually wrote a 2,300 word transcript, but as soon as I got started with the presentation, I noticed I actually had no time to read anything (despite I’d learned half of it by heart). So I ended up improvising it all to the end.

Making the video took me all evening, and I learned how to zoom the screen only after uploading it on YouTube. All in all, I’m pleased to the outcome, but now I know how to do it better next time. Enjoy this 15 minute long demonstration (I recommend watching it in 720p, and yes I know it’s still blurry):

There’s also another video coming, stay tuned!

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