More BeOS Propaganda
Written by Serun
I was mowing our lawn when I got the idea for this article and I thought I would write it before I forgot all of my well-crafted points. This article is essentially going to be about BeOS, as usual. I'm going to go into my opinions of BeOS vs Windows from a programming stand-point and I will discuss some programming info/tips to get started programming BeOS.
Windows is a bloated OS that barely accomplishes the smallest of tasks within an acceptable time. This is an opinion of mine which is practically a fact, any system that is around for so long and never clears away the silt becomes bogged down and sluggish. Game level graphics are nearly impossible using the GDI and the DirectX API helps incredibly to alleviate this problem. The problem with DirectX is that it is also a hack, it was not put in the low-level design and therefore it's speed suffers, although it is not a large performance hit, it is still there. In BeOS on the other hand direct access to the screen buffer was built in at the ground floor and doesn't suffer the same problems that DirectDraw/DirectX does in this area.
Points on Programming on each OS
Windows is horrific to program for, it's large and bloated and to get what you want most of the time you have to work around things. Yes, it is possible to get things to work in Windows, I won't argue with that, I've seen some awesome stuff in Windows, but when I'm coding I want the OS to work for me and not against me like Windows does. I'm sure many of you are either screaching at the top of your lungs and mentally kicking my ass or are saying that I don't know what I'm talking about, but the point of the matter is that I do. The reason is because I started programming for Windows and DirectX about six to eight months before it caught on in the demoscene pretty much at all (even though it hasn't caught on fully, in a few more months, I don't think DOS demos will be made anymore), all I had to go on was the two of Denthor's windows tuts which only used DCs to get access to graphics and the Win32 page that Nix/TBL put up. Other than that there were a few DirectX papers to go on but most of them did not cover direct access to the screen buffer. I learned nearly everything from trial/error and I got up to doing some basic demo effects, did a game, and started another before my attention was snatched away to BeOS.
BeOS is pleasant to program for, the API is setup very nicely and is organized into diffrent chunks called 'kits' which cover diffrent aspects of programming, The whole API is setup heavily in a Object Oriented manner. There is an Application Kit, a Media Kit, a Game Kit (my favorite), a Network Kit, an OpenGLKit, a Translation Kit, etc. These kits are easy to use and function and connect to the rest of the system in a logical way. I have mainly dealt with the Game Kit and the Application Kit, therefore we are going to go into programming a basic app that gets fullscreen access to the screen easily. This brings us to the next section.
Basic BeOS Programming
If you want to start programming for BeOS it is really a good idea to look through the sample code that comes with the OS, look for some of the Be Newsletter articles, and maybe check out BeOS Central for some basic programming tutorials (they cover doing GUI related stuff). Also look to the Neo-Programmers Collective (featured on BeOS Central), they have source, tips, and articles for people new to BeOS and C/C++.
[Note - I have only had experience with the x86 side of BeOS, I have no experience with PPC and don't pretend to, everything here should apply to both x86 and PPC versions of BeOS though. Oh, also, I'm using r4.5 for this, it should also work with r4 and most likely the next few releases of BeOS too.]
In BeOS you start with your main function, this would be just like a standard C main function. Remember that you can make apps to run from Terminal (Bash shell), but to be able to receive messages and do all the good stuff you need to make a BApplication object. A BApplication is the base of BeOS apps and chances are most if not all apps you make will use it. It is important to note that you almost never use a BApplication directly, Infact I never have and I haven't seen anyone else do it either, you usually make a derived class.
BApplication has a method called Run() which starts the message loop, and when this is called the function ReadyToRun() is called, the BApplication version of this is empty but our class will start up everything from here. QuitRequested is another handy function, it is called whenever the Application receives a B_QUIT_REQUESTED message, which we can send ourselves from the application, or the system can issue, we will use this function to set a flag to let us know when to clean up.
OK, this is great that we have this Application class, but how are we going to use it? all we have to do in the main function is create an object of it, the Run() function will be called from our derived classes constructor, and therefore, our ReadyToRun() will also be called. Neat huh!
Okay, so we have an app now, but this is worthless without direct access to the screen. To do this easily we are going to use a BWindowScreen, it is a class that will bypass the App Server (what draws all the GUI) allowing full acess to the screen. There is another class called BDirectWindow, it allows you to have acess to a frame buffer but also allows you to switch between a window and fullscreen, the problem is it becomes more complicated than I'm willing to go into in this article, maybe next time. The BWindowScreen is exactly what we want, again we are going to use a derived class.
In our constructor we will initialize all of our variables, create a semaphore which will allow us to to control who has access to our rendering thread and call the BWindowScreen function Show() which makes our Window take focus, and take over the whole screen. BWindowScreen's make use of a function called ScreenConnected( bool ) which is called with 'true' when the WindowScreen has just connected to the Screen and with 'false' right as it is about to lose its connection to the Screen (ScreenConnected is called with 'true' when Show() is called). We have to make our own version of this in our derived class. Ours will create the rendering thread if it hasn't already been made and get a pointer to the frame buffer when ScreenConnected is called with 'true'. When ScreenConnected is called with 'false' we will halt the rendering thread, and in the case that we are quitting, we will cleanup permanently. After we create the thread in ScreenConnected, the threads' function is called which calls our Render function, and this is where all of our drawing takes place. The render function is where all the good stuff is going to occur. If you were to look at all this you most likely think that programming for BeOS is just as hard as programming for Windows but after you get these small things setup, everything is really compact and simple. Besides being simple after its setup, the programs are also smaller than windows programs in general.
[Note - I used the BeIDE to compile this. To compile the sample code, you must make sure that libbe.so and libgame.so are added to the project. To get the program down in size, make sure that in the linker options that you check 'strip all symbols' and 'strip local symbols'. If you have problems mail me.]
I started to write another part for this article which was going to go into doing graphics in 16 bit color, but I've decided to wait until next time and not try and cram all the information into this article before the due date. I only have about five days left before all the articles are due so I want to make sure that all the info in here as well as the source code is polished (Did I do a good job?). Anyways, if you need to do some 16 bit graphics stuff in BeOS right away check out the source code, it has some basic graphics functions like PutPixel and Clear although these versions are meant for teaching purposes and not for speed. If you have any problems, questions or comments email me, I'll be happy to help you out in anyway I can.