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.
Friday, March 18, 2011
Tuesday, February 15, 2011
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.
Friday, January 28, 2011
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.
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.
Tuesday, January 04, 2011
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.
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.
Saturday, December 25, 2010
Mac development begins...
1. I just bought my first iMac top of the line (i7 2.9GHZ+SSD+8GB+1TB) which I am enjoying immensely.
2. I have ported my code over to XCode for the iPhone development.
3. I have updated my svn (under packages) with the latest components.
So I am back to work with a clear development path.
I have added support for inheritence+extensions for objects. For example: IOSView extends UIDisplay without UIDisplay being aware of IOSView. When UIDisplay calls pDisplay = CoreObjectNew(UIDisplayComponent) it creates not only an instance of UIDisplay but attaches to it also an instance of IOSView automatically. This allows IOSView to fill in the display buffer parameters without UIDisplay having to call IOSView. This is a great feature.
I am working on the basic components such as Timers, Pen events, Xml parsing and so on. This should take some time but components are being written quite quickly, so I will hope for the best.
Instead of uploading new zip files, I will from now on just refer to the latest SVN versions.
2. I have ported my code over to XCode for the iPhone development.
3. I have updated my svn (under packages) with the latest components.
So I am back to work with a clear development path.
I have added support for inheritence+extensions for objects. For example: IOSView extends UIDisplay without UIDisplay being aware of IOSView. When UIDisplay calls pDisplay = CoreObjectNew(UIDisplayComponent) it creates not only an instance of UIDisplay but attaches to it also an instance of IOSView automatically. This allows IOSView to fill in the display buffer parameters without UIDisplay having to call IOSView. This is a great feature.
I am working on the basic components such as Timers, Pen events, Xml parsing and so on. This should take some time but components are being written quite quickly, so I will hope for the best.
Instead of uploading new zip files, I will from now on just refer to the latest SVN versions.
Sunday, November 14, 2010
The means to the end is also important
I have been low on the radar because I have been working hard on the code instead of updating the blog but mostly because I didn't have anything to show.
I now do have a another snapshot of my code to show. While this is in no way Screens, it does preview the object storage with some example components.
I now support singleton components (components with only a single instance) and improved the overall design of how components are used. I also made it simpler to write a component as you can see in the attached code.
You can find the code here: http://www.box.net/shared/5blf9bqexc
About the multi-level assocation hierarchy, I removed that since not only did I find its use limited, but it was too complex for me to handle or explain to others, so I axed it. It was basically to allow each instance to have child instances while still being attached to the same object.
A few notes:
1. Allocation in chunks
It allocates objects per components in single allocations of 256 objects per component (apart from singleton components). It then re-uses allocations of the components. This reduces the problem of memory fragmentation.
2. Object limit
I currently have a maximum limit of about 65,000 objects. This is because I have an overhead of 32bits per objects which contains two 16bit references. However this implementation limit is encapsulated in CoreObject, so in the future this could be changed without an overhall on all the code.
3. Multi-instance support
You can attach multiple instances of the same component to a single object. This is how CoreNotify works where it just attaches each new notification to the same object and then uses CoreObjectCast to retrieve the next notification for message broadcast.
4. Simple component use
I have reduced the component overhead to a single public function that calls CoreObjectInit, a single typedef to define the object type and variable declaration in the header file of the component. The object can be any type, it can be an integer, character pointer, structure, union or anything fixed that C supports (it does not support non fixed character arrays since all objects must be of the same size per component).
I now do have a another snapshot of my code to show. While this is in no way Screens, it does preview the object storage with some example components.
I now support singleton components (components with only a single instance) and improved the overall design of how components are used. I also made it simpler to write a component as you can see in the attached code.
You can find the code here: http://www.box.net/shared/5blf9bqexc
About the multi-level assocation hierarchy, I removed that since not only did I find its use limited, but it was too complex for me to handle or explain to others, so I axed it. It was basically to allow each instance to have child instances while still being attached to the same object.
A few notes:
1. Allocation in chunks
It allocates objects per components in single allocations of 256 objects per component (apart from singleton components). It then re-uses allocations of the components. This reduces the problem of memory fragmentation.
2. Object limit
I currently have a maximum limit of about 65,000 objects. This is because I have an overhead of 32bits per objects which contains two 16bit references. However this implementation limit is encapsulated in CoreObject, so in the future this could be changed without an overhall on all the code.
3. Multi-instance support
You can attach multiple instances of the same component to a single object. This is how CoreNotify works where it just attaches each new notification to the same object and then uses CoreObjectCast to retrieve the next notification for message broadcast.
4. Simple component use
I have reduced the component overhead to a single public function that calls CoreObjectInit, a single typedef to define the object type and variable declaration in the header file of the component. The object can be any type, it can be an integer, character pointer, structure, union or anything fixed that C supports (it does not support non fixed character arrays since all objects must be of the same size per component).
Subscribe to:
Posts (Atom)