Adding more file formats

As you can see in my 'screensos' source forge project, I have been very active over the last few months.

I have lately added support for png files in FilePng and xml files in FileXml.
I am adding a lot of formats to make use of them in various sub projects.

I have also done a lot of refactoring and tweaking of existing components.
I know that Screens is lacking a lot of documentation. Because I am still in the development stage, I am focusing on the development since the documentation can be added later. It does keep this project under the radar (which I can see just from the page views) but I am fine with that since its not in a usable form anyway at the moment.

Drawing text works

Drawing text now works very nicely.

I have a utility fontray_mk to take any MacOS font and convert it into a C file containing the font data. Then I can easily use any font by just compiling it and passing its buffer into DataFontrayDraw function.

I have uploaded the changes regularly to source forge (ScreensOS).

Font handling

Just uploaded last night the UtilFontray component that allows me to easily capture any MacOS font and store it as an embedded bitmap font format. I am now working on the code to draw the bitmap font format and then I will be complete for an initial drawing scenario of fills, frames, bitmaps and text.

Casting power

One of the great advantages in dynamic casting is that you can move between capabilities of any object with any one of its handles.

UIWindow * pWindow = UIWindowNew();
UIElement * pElement = UIElementCast(pWindow);
pWindow = UIWindowCast(pElement);

You can see how I can move from the element to the window to the element easily and safe.
This simplifies code a lot since I don't have to pass objects down the pipe.
Its a lot like a C++ dynamic_cast call but in ANSI C!

It makes the components that I have to write small and simple.

Power without a manual

I am waiting for september before I buy an iPad to allow my brother to draw graphics for the game.
In the meanwhile I am fixing code bugs, rewriting components and adding new components into the mix.

It is taking me a while to get used to the power of association relationships. Everyone is more or less used to inheritance and containment relationships. Association relationships is not used very much at all even in high level languages. So its not like I can use the web to find out what oppertunities are available for me. I have to find them out one at a time.

Component C Extensions

Using Extensions in Component C makes it so easy to have separation of concerns.


Here is code how to start a specific application component:

- (void)viewDidLoad {

    [super viewDidLoad];

    

    /* Link application to ios view */

    UIAppComponent->pExtension = IOSViewComponent;

    /* Link ios view to engine */

    IOSViewComponent->pExtension = MyGameComponent;

    /* Start the application and set up the view handle */

    self.view = (id) IOSViewHandle(IOSViewCast(UIAppStart()));

}

The second line links the IOS platform specific implementation to the application engine.

The third line links the game component to the IOS platform.

The fourth line starts the application and links the view to the controller.

Neither the application component or the game  are aware of the platform it is running on.

And the platform does not know what game is running.

This is a separation of concerns and allows me to port code to run on the mac and then run it on the simulator without having to modify the game code itself in any way.

Note that the application component creates the object and does not need to be passed the platform or game to run. It all works behind the scenes and that is the way it should be done.

Great Progress

Hi,

As you can see by my source forge status, I have working on the Screens components for quite a while. I am playing around with a simple game for the iPhone to test and write new components. I have finished an initial version of the application but I still lack some good graphics that I need to import before I can publish it to the AppStore. It was written using only Component C components. The game is really simple but I just wanted something to try out to test the AppStore process.

I have uploaded all the components to source forge anyway as I progress.

Event notifications

I have been active on my ScreensOS project. I did another refactoring of the components and made it simpler to understand and easier to send notifications.

To register for an event:

CoreEventRegister(pObject, CoreNodeComponent, CORE_NODE_EVENT_MOVE, MyMoveCallback);

To send an event:

CoreEventNotify(pObject, CoreNodeComponent, CORE_NODE_EVENT_MOVE);

The advantage of this design is that each message is unique per component. No need to have selectors or string hashes. Each component just defines an enum of messages either public or private.

You can also send asynchronous messages using CoreEventNotifyAsync which doubles as a timer delay if the delayInMilliseconds parameter is non zero.

Xml first alpha works

Great! FileXml parser works combined with FileChunk and FileToken.

However there is a bug in detaching objects when inside a destroy handler message. I will work on this bug next.

I gave it a simple xhtml file and it parsed it successfully. I will do some more tests on different xml files to know that I can move on to the next set of components.

You can find always the latest package of components at:
https://sourceforge.net/projects/screensos/files/

Component Handlers

I saw a problem lurking which was the callback design for components. There was no way to know when an object was being destroyed unless the component sent a notification. The component could know that its instance is being destroyed but attached objects could not know.

I met this problem in FileToken where it wanted to point to an attached FileChunk instance but would not know if the FileChunk instance was destroyed.

I made a system-wide change. Before, components implemented specific callbacks for constructor, destructor and shutdown scenarios. Now a single handler can be set for each component in its initialization. The handler can receive messages from any component. The constructor, destructor and shutdown scenarios are now sent by CoreObject as messages to the component handler. But now there is a new message CORE_OBJECT_MESSAGE_DETACH which is sent to all attached objects when a object is being detached from it. This will be used by FileToken to know when FileChunk is being detached.

You can find the latest code collection at:
http://sourceforge.net/projects/screensos/files/screensos/packages_002.zip/download

When I hit a milestone, I will add a zip to the source forge files.

Moving along

Things are moving along quite nicely.

1. FileChunk that divides files into chunks has been finished.
2. Rewrote CorePool to be a simpler design.
3. Fixed various bugs along the way

I work in a sequence where I write code without testing it and test it at a later date.
Because each component is small, its easier to debug and decide if to re-factor or not.

Next component I am writing is FileToken that uses FileChunk to parse text files into tokens
and after that I get to write FileXml using FileToken.

First package source collection

You can find a zipped collection of all the packaged components at:  https://sourceforge.net/projects/screensos/files/screensos/

Currently its labeled packages_001.zip

I also uploaded a simple 'author public domain' comment for each file to keep things license consistent.

I am currently working still on the FileXml component. It is taking a little longer than I expected but I am sure progress in the component will come along nicely.

Development in progress

You can find the latest code uploaded via SVN at:
http://screensos.svn.sourceforge.net/viewvc/screensos/

I know that it looks like Screens is not moving anywhere, but there is an actual strategy involved even if it is taking a long time.

Let's recap:
2002-2008 = Wanted an application middleware, researching which programming model to use
2009-2011 = Figured out a new programming model: ComponentC programming model.

In the last half year I have spent time writing components.
The components separate for the first alpha into 3 parts:

1. Core
Core components is the basic core components of the system. CoreObject was the hardest component to write since it represented the programming model for Screens. The other core components were mostly easy.

2. File
This is where I am now. Writing components to parse files including xml using the component oriented model. I just finished a first draft of the file token parser which I will be using now for the xml component.

3. UI
This is the most exciting set of components (after CoreObject) that I want to write. I have had some years of researching drawing models (such as top down drawing) which I want to use in this middleware.

Once I finish these basic set of components, I can start making the more visual demos I made before. There are high and low points in any project. Here I am programming a strong foundation for later on. Once I finish the foundation I will able to move much faster in the alpha and beta releases.

I currently run the code in the iPhone simulator where it deals with multi-touch points, drawing a bitmap for each point while filling the screen with a gradient. As components come by I integrate them and check them in the demo. I think I will have some interesting things to show once I pass the second UI component set.

Because I tended to tell my ideas before implementing them, I am going the other route where I write something and then tell you about it.

Eating at a buffet

I finally found how to explain the advantage of Component C objects.

Using Component C objects is like eating a buffet. You have a choice of different foods which you can pile onto your plate in any combination or order that you want.

Using traditional object oriented languages/frameworks is like eating at a restaurant. You have a choice of different meals, each with its own combination of ingredients.

Using fixed meals is easier to use when the choice is small. But it does not scale. There is a reason why sandwich fast food places allow you to choose your own combination. Having a list of pre-fixed combinations becomes messy when it grows more than a few dozen options.

Thats why object oriented examples always work. They are a small selection of classes in use which work great just like a menu with 5-10 items works great as well.

Its when you have to manipulate over 50 items that things become complicated. So then they are separated into categories. But then you get to a point when categories need to be broken down into sub categories. Very quickly things can get out of hand. A complex system may have 200 classes that a developer needs to manage.

Do you derive your class from A, B, C, D, E or the other 50 options. Or maybe you go for containment which defeats the whole purpose of common components since you do not want to have to expose every possible interface that you want to support.

With Component C components. Its a buffet. You only offer a choice but do not control the combination of those choices. If the developer wants to make an object (like a plate) and attach to it (like putting food on a plate) a node and window component, you have a window that can be stored in a hierarchy of other nodes.

While I only have around 20-30 components, the advantage looks small. Its when I reach over the 100 component count that things become interesting. Every component only cares about what it needs to provide a specific feature or part of a feature. The combinations are defined by their usage. It scales.

UIWindow does not have to deal with hierarchy. CoreNode deals with hierarchy. Its separation of concerns. Components stay small because I don't have to stuff every feature I ever need in the same component.

Objects need to support reference count. Instead of stuffing it into CoreObject, it is handled in a separate CoreRef component.

As applications grow bigger, they will need to move to the buffet model. Al a carte.
Just like users are getting tired of fixed 1000 channel selections and prefer to choose what they want instead of tuning to a fixed channel that airs the show they want at a specific time.

Updates committed

Just to let you know that the latest code has been uploaded into the ScreensOS repository.

Moving along

Hi,

Sorry that I am consistently late in my updates.

I have been writing loads of components such as CoreQueue, CoreState, CorePool.
I am expanding the components and fixing bugs as I find them in existing components.

My next component is FileXml which will manage xml in an object oriented fashion but will have a twist where the objects are allocated by the caller instead of by the component itself. The xml file will also only be partially processed as needed. This should allow to load huge xml files without having to have the memory overhead.

There is currently a bug I think in XCode 4.0 where I can't seem to save my password in the repository settings for my SVN repository. When I find out how to save the password, I will update the latest code.

Update

I have been working hard on the data bitray component. I finished writing a first version of DataBitrayPaint. I am now working on enhancing the component to be able to compress/decompress/paint from one source to another. This should take me so time to figure it out and keep it simple. I will update you when I am done.

DataBitray

Uploaded the bitmap handling component (which is endian independent thanks to FileBinary component) which reads bitmap files.

However the component I want to talk about is the DataBitray component (packages/data in SVN). It allows compression and decompression of pixel buffers with some nice features:
1. In-place compression/decompression - Because the compressed data is always smaller or equal to the original data, compression can be done in place. Decompression is done backwards which also allows it to be done in-place. This allows to save the number of buffers needed for compression/decompression.

2. No header overhead - The Bitray compression is based on RLE but without the header problem. Pixels of the same value are compressed into two integers. So one pixel is one pixel, two or more pixels of the same value are always 2 pixels wide.

3. Simple design - No complex hash arrays, it allows for great locality since no static variables are needed and because it does in-place compression/decompression it only requires the buffer itself to be in the cpu cache, not two buffers.

4. Small output - A display filled with a single color is 8 bytes long. If each row has a single color, it is 8 bytes multiplied by the number of rows. This works well for user interface elements since they tend to have pixels of the same value.

5. Small code - The entire DataBitray component is less than 150 lines of code including comments! Its easy to implement and easy to read.

I plan to write soon DataBitrayPaint which will allow to do the alpha-blending on the target buffer instead of just overwriting the buffer when decompressing the data. The step after that is writing a component to manage the data-bitray buffers for images, so they can be easily embedded into the application without relying on file i/o. The idea is to isolate platform dependencies and this will be one way to avoid a platform dependency for simple user interface images.

Writing components left and right

I have just uploaded another set of files to the screens soureforge svn.
Added many components such as UITouch to manage multiple touch points and FileBinary to parse binary files with a field specification.

My next component is FileBitmap to manage reading and writing bitmap files.

Overall I am happy with the accelerated coding of components which are being written quite quickly.
My favorite part of writing the Component C code is the simplicity of the code with a small number of lines per component which are totally encapsulated.