Category Archives: Programming

All that has to do with programming languages: news, frameworks, software and tutorials.

Why a team of developers should never waste time programming a new operating system

It may be obvious to many of you, but I saw teams of amateur developers dreaming the perfect operating system, starting from the idea that the contemporary operating systems (like Unix or Windows) are still far from being perfect. In particular, I remember an italian news group that was frequented by more than one developer that wanted to create his brand new operating system starting from scratch, programming it just by himself, so they gave me the inspiration to write this article, maybe it could be useful to avoid that the same disaster will ever happen again to someone else. Even if you are the superman of computer programming, today you cannot pursue the impossible dream of creating your own operating system without hurting yourself for precise technical reasons. I don't want to discuss here about the difficulties related to the creation of a new file system, virtual memory, inter-process communication, multithreading and so on, because my example is easier and more solid than that. I want to assume that you already have programmed a working kernel for that kind of operating system, a "minimum" set of drivers to make it run on your pc and that you are ready to share it with the entire world. Well, even in these ideal conditions, the main problem is with the companies that currently are using Windows or Linux and that should invest money to drop their operating systems / applications to use your operating system, the same for the hardware vendors that should write the specific drivers, the software houses, curstomers, professionals, video gamers and so on. Today there are so many hardware devices that is almost impossible to achieve the same performance that already existing and most proven operating systems have achievied in so many years of existence. It's not a matter of programming skills, it's a matter of "temporal gap". Even if you are so good to achieve the perfection on a single machine, you cannot be able to obtain the same stability on the wide range of existing personal computers, tablets, smart phones, sbc and all the devices mounting all the existing peripherals, because you won't have the money, credibility, reputation, experience, employees, followers, curtomers to do it. The situation in the past was sligtly different, Windows was created to run mainly on x86 family of processors, but there were other operating systems (like Amiga OS) that were projected to run on 680x0 family of processors, so the idea of operating system was more embedded to the small set of hardware that the vendors had to sell. Today it's totally different. If you want to create a valid operating system, you have to cover all the existing hardware produced at least in the past 20 years, or even if your main target is a single device, you cannot surpass the existing operating systems because they are already optimized to work better on the same device in terms of performance and power consumption. In conclusion, if you are having the crazy idea of creating your own operating system, just forget it because you are wasting your time and the opportunity to produce something really useful. You will never produce even an ounce of what is required today to run a modern application on modern hardware, with the same degree of portability and support in terms of graphics / audio / peripherals, and even if you do it, there are already more stable operating systems that are doing the same thing exactly when you are having the bad idea of doing it.

Targeting OpenGL is not so easy, don’t get confused by the documentation

I want to create this post to clarify once and for all how the OpenGL extensions mechanism works and the correct proceedings to target OpenGL versions. I named this article in this way because OpenGL are generally bad documented (or difficult to understand) and OpenGL.org wiki makes the things worse. For example, several people got confused by this page:

https://www.opengl.org/wiki/OpenGL_Extension#Core_Extensions

Targeting OpenGL 2.1

These are useful extensions when targeting GL 2.1 hardware. Note that many of the above extensions are also available, if the hardware is still being supported. These represent non-hardware extensions introduced after 2.1, or hardware features not exposed by 2.1's API. Most 2.1 hardware that is still being supported by its maker will provide these, given recent drivers.

And this document:

https://www.opengl.org/registry/specs/ARB/map_buffer_range.txt

"New Procedures and Functions

void *MapBufferRange( enum target, intptr offset, sizeiptr length,
bitfield access );

void FlushMappedBufferRange( enum target, intptr offset, sizeiptr length );

Issues

(1) Why don't the new tokens and entry points in this extension have
"ARB" suffixes like other ARB extensions?

RESOLVED: Unlike a normal ARB extension, this is a strict subset of functionality already approved in OpenGL 3.0. This extension exists only to support that functionality on older hardware that cannot implement a full OpenGL 3.0 driver. Since there are no possible behavior changes between the ARB extension and core features, source code compatibility is improved by not using suffixes on the extension."

so the question is:

- GL_ARB_map_buffer_range is a core extension or not?

Continue reading

How to parse gl.xml and produce your own loading library

In the previous article I emphasized the importance of not having a third-party loading library like glew because OpenGL is too complex and unpredictible. For example, if you want to implement a videogame with an average graphics and a large audience of users, probably OpenGL 2.1 is enough. At this point, you may need to load only that part of the library and make the right check of the extensions or just use the functions that have been promoted to the core of the current version. Remember that an extension is not guaranteed to be present on that version of OpenGL if it's not a core feature and this kind of extensions has been introduced after 3.0 to maintain the forward compatibility.

For instance, it's useful to check the extension GL_ARB_vertex_buffer_object only on OpenGL 1.4 (in that case you may want to use glBindBufferARB instead of glBindBuffer) but not on superior versions because it has been promoted to the core from the version 1.5 onward. The same applies to other versions of the core and extensions. If you target OpenGL 2.1, you have to be sure that the extensions tipically used by 2.1 applications have not been promoted to the latest OpenGL 4.5 version and to check the extenions on previous versions of the library, making sure to use the appropriate vendor prefix, like ARB. Even if with glew you can make this kind of check before using the loaded functions, I don't recommend it because glewInit() is going to load also parts that you don't want to use and you run the risk to understimate the importance of checking the capabilities.

Anyway, reading the OpenGL spec and add manually the required extensions is a time expensive job that you may don't have the time to do. Recently, the Khronos group has released an xml file where there is a detailed description of the extensions and the functions for every version of the library, it is also used to generate the gl.h and the glext.h header files with a script in Python. In the same way, you can program a script that parses the gl.xml file to generate your own loading library, making the appropriate check of the extensions and including only the part that you really need to load on your project. You can find the gl.xml file here:

Continue reading

Why loading libraries are dangerous to develop OpenGL applications

OpenGL is not so easy to use. The API exposes thousand of functions that are grouped into extensions and core features that you have to check for every single display driver release or the 3D application may not work. Since OpenGL is a graphics library used to program cool gfx effects without a serious knowledge of the underlying display driver, a large range of developers is tempted to use it regardless of the technical problems. For example, the functions are loaded "automagically" by an external loading library (like glew) and they are used to produce the desired effect, pretending that they are available everywhere. Of course this is totally wrong because OpenGL is scattered into dozens of extensions and core features that are linked to the "target" version that you want to support. Loading libraries like glew are dangerous because they try to load all the available OpenGL functions implemented by the display driver without making a proper check, giving you the illusion that the problem doesn't exist. The main problem with this approach is that you cannot develop a good OpenGL application without taking the following decision:

- How much OpenGL versions and extensions I have to support?

From this choice you can define the graphics aspect of the application and how to scale it to support a large range of display drivers, including the physical hardware and the driver supported by the virtual machines. For example, VirtualBox with guest addictions uses chromium 1.9 that comes with OpenGL 2.1 and GLSL 1.20, so your application won't start if you programmed it using OpenGL 4.5, or even worse you won't start also on graphics cards that support maximum the version 4.4 (that is very recent). For this reason, it's necessary to have a full awareness of the OpenGL scalability principles that must be applied to start on most of the available graphics cards, reducing or improving the graphics quality on the base of the available version that you decided to target. With this level of awareness, you will realize that you don't need any kind of loading library to use OpenGL, but only a good check of the available features, that you can program by yourself. Moreover, libraries like glew are the worst because they are implemented to replace the official gl.h and glext.h header files with a custom version anchored to the OpenGL version supported by that particular glew version.

Continue reading

How the deprecated OpenGL matrix model works

Even if nowadays everybody seems to drop OpenGL methods when they are deprecated on the core profile, it doesn't mean that you don't need to use them in compatibity profile or that you don't want to know how they work. I searched on the web to find more information on how the old and deprecated OpenGL matrices are implemented and I didn't find anything (except tutorials on how to use them!). My doubt was mainly about the operations order, because I needed to make a C++ implementation of them, maintaining the same exact behavior. I used OpenGL matrices In the past without worrying about how they were implemented, I had a precise idea but now I have to be 100% sure. Even if we know how to implement operations between matrices, the row-column product doesn't have the commutative property so the internal implementation can make the difference. At the end, my question is:

- What is the matrix row-column order and how the product is implemented on OpenGL?

Tired of finding pages saying how they are useless and deprecated now, I had to check by myself the Mesa source code to find what I was searching for:

P = A * B;

P[0] = A[0] * B[0] + A[4] * B[1] + A[8] * B[2] + A[12] * B[3];
P[4] = A[0] * B[4] + A[4] * B[5] + A[8] * B[6] + A[12] * B[7];
P[8] = A[0] * B[8] + A[4] * B[9] + A[8] * B[10] + A[12] * B[11];
P[12] = A[0] * B[12] + A[4] * B[13] + A[8] * B[14] + A[12] * B[15];

P[1] = A[1] * B[0] + A[5] * B[1] + A[9] * B[2] + A[13] * B[3];
P[5] = A[1] * B[4] + A[5] * B[5] + A[9] * B[6] + A[13] * B[7];
P[9] = A[1] * B[8] + A[5] * B[9] + A[9] * B[10] + A[13] * B[11];
P[13] = A[1] * B[12] + A[5] * B[13] + A[9] * B[14] + A[13] * B[15];

P[2] = A[2] * B[0] + A[6] * B[1] + A[10] * B[2] + A[14] * B[3];
P[6] = A[2] * B[4] + A[6] * B[5] + A[10] * B[6] + A[14] * B[7];
P[10] = A[2] * B[8] + A[6] * B[9] + A[10] * B[10] + A[14] * B[11];
P[14] = A[2] * B[12] + A[6] * B[13] + A[10] * B[14] + A[14] * B[15];

P[3] = A[3] * B[0] + A[7] * B[1] + A[11] * B[2] + A[15] * B[3];
P[7] = A[3] * B[4] + A[7] * B[5] + A[11] * B[6] + A[15] * B[7];
P[11] = A[3] * B[8] + A[7] * B[9] + A[11] * B[10] + A[15] * B[11];
P[15] = A[3] * B[12] + A[7] * B[13] + A[11] * B[14] + A[15] * B[15];

where A and B are 4x4 matrices and P is the result of the product. As you can see, this snippet clarifies how rows and columns are internally ordered and how the product is implemented. In conclusion, the OpenGL methods to modify the current matrix are implemented by Mesa in this way:

Continue reading

Do you want to work for NICE/Amazon? We are hiring!

Hi. Since NICE was acquired by Amazon I became part of the Amazon EC2 and its team in the world. Me and my collegues are working hard to improve our High Performance Computing and remote visualization technologies, which basically require advanced C/C++ programming skills and a deep knowledge of the OpenGL libraries. If you meet the requirements and want to be part of our world-class team, check our current offers here:

https://www.amazon.jobs/it/locations/asti-italy

In addition to the skills listed in the announcements, the candidate must make a moderate use of modern C++ features and third-party dependencies (e.g. the use of high-level frameworks like QT or boost is justified only if it brings real benefits to the project and not to skip programming). know how to manage device contexts, choose / set pixel formats / fbconfigs, destroy / create rendering contexts, set the default frame buffer or FBO as rendering target, use graphics commands to render frames with multiple contexts running on multiple threads, without performance issues. A good knowledge of Desktop OpenGL specifications (from 1.0 to 4.5), deprecation and compatibility mode is required (e.g. the candidate must know that some OpenGL functions can be taken with wgl / glXGetProcAddress instead of using blindly a loading library like glew). If you have concerns or questions, do not hesitate to contact me. Regards.

Develop in C# for mobile with Xamarin, now it’s free!

Recently Microsoft decided to include Xamarin into Visual Studio, also into the free version. This means that from now you can use the C# language with .NET / Monodevelop framework to develop crossplatform applications with the support not only for Windows, Linux and MacOSX, but also for Android and iOS!

Before this news, you had to pay for Xamarin, but now it's free (with certain conditions, visit xamarin.com). If you didn't want to pay for it, the only way you had to support mobile devices was to rely on existing frameworks, like Qt, Unity and Oxygine, or produce extra code with Android SDK and xCode. The problem is that all these solutions use different kind of languages. Qt and Oxigine are C++, Unity is a 3D engine that uses C# scripts,  Android SDK and xCode for iOS are mostly Java oriented. If you wanted to support multiple platforms before, you had to change your habits to adopt a solution (even if you didn't like it) to cover an high range of machines. Now you can continue to develop your project with Visual Studio in C# and then decide to convert part of your project to make a mobile app using the same framework, with a little bit of effort for the platform specific features. If you want to develop an app in short time and share it to the world, Xamarin will make your life easier.

Super Mario Bros for Amstrad CPC464

When i was a little kid I remember that i really wanted to create a Super Mario Bros game for the amstrad cpc 464. Now that I am 33 and I work as a software engineer I asked myself: why don't you make your old dream come true? :) Finally I found the time to create a demo with the famous first Level 1-1 of Super Mario Bro:

The horizontal hardware scrolling needs a double buffer in order to get an accuracy of 4 pixels. The demo runs on original Amstrad CPC 464 speed emulated by Caprice. It is pretty fast and can loop horizzontally for a limit of 512 16x16 tiles meanwhile the level 1-1 takes only 212 tiles. I readjusted the original smb graphics to fit a 256x192 Mode 1 with 4 colors. I really like the effect of the gray scale map mixed with the blue sky, like in the original NES game. This demo has been programmed with SDCC in C and Z80 assembly.

The next challenge is to make a playable demo. For now i'm trying to produce a game for the Amstrad CPC 464 with only 64 KB of memory, trying to store the entire game into the available memory to make it portable for the old cassette system. I'm using pucrunch for z80 with zrle algorithm to save a huge amount of memory. The compressed tileset is about 3.5 KB, the chars 5 KB, a single level 500 bytes. A single level uses only a subset of the available graphics, so i can make assumptions to save memory during the decompression. I estimated about 9 KB for compressed data with a single level and 10 KB for the decompressed ones. At this rate, i can make only 4 levels playable but maybe it's good for a first version of the game. I don't know if i can implement more optimizations to store the remaining 28 levels or if i have to switch to disk loading or just use 128 KB, I'm still evaluating. Another challenge is to program 1 pixel precision blitting algoritm to move the characters. Unfortunately, I'm pretty busy with my job so i have very little time to dedicate to my projects, so it will proceed slowly, but it's good to know that i will post updates on this website as soon as they will available for the public.

Warning: I created this project only to improve my programming skills and not for commercial purpose. The original design, concept and graphics of Super Mario Bros are owned by Nintendo and not by me.

CJS Framework – Work in progress

After a long research for the perfect crossplatfrom multitarget language i didn't find anything that satified my expectations. I wanted to create c++, c#, java and javascript projects around a set of basic classes, functionalities and serialization to import/export files in a custom format.

In a first evaluation, Haxe language with json seemed to be the perfect choise, but after using it i realized that the code produced for the languages of my interest is too heavy, bad indented and hard to reuse in the context of a specific project. That's because Haxe and the other multitarget languages are studied to produce a final result (i.e. a game) and not a source code that is easy to understand for the human reader or to include in other part of a wide project. For instance, if i create an Hello world example with haxe and convert it to c#, it will generates alot of useless .cs files in a well structured (and unreadable) project that you can build and run at first attempt, but that is barely readable and hard to reuse into other clean c# projects. If you are thinking of creating a library in haxe to include the source code into your projects, it's better if you change idea: the final result of your cpp, c#, java or javascript projects may end to a gigantic mess.

For this reason, I decided to create from scratch a new framework that is called CJS Framework, which stands for CppJavaScriptSharp Framework. It's mainly a full bridge between these four languages (but it's not improbable that it will support other languages in the future). The basic idea is very simple: make a set of classes that are useful in a project and a serialization system that easly load objects regardless of the used language. For instance, we can decide to take advantage of the .NET framework and produce an editor in C# to manipulate the maps of a game that will be programmed in javascript and it will run on facebook or the web browser. Or a server application in c++ that communicates in a binary format with a client application for html5 coded in javascript. The framework is projected to satify easly all these tasks and much more.

Continue reading

Unrelated Engine – Deferred Rendering and Antialiasing

I tried to implement the explicit multisample antialiasing and I got good results, but it's slow on a GeForce 9600GT. A scene of 110 fps became 45 fps with only four samples, just to point out the slow down. While I was jumping to the ceiling for the amazing image quality of a REAL antialiasing with deferred shading (not the fake crap called FXAA) I fell down to the floor after I seen the fps, what a shame.

UnrelatedEngine01

Anyway, I decided to change from a deferred shading to a deferred lighting model just to implement a good trick in order to use the classic multisample (that in my card can do pretty well also with 16 samples!) reading from the light accumulation buffer in the final step and writing the geometry to the screen with the antialiasing enabled. The result is a little weird, but you can fix it by using that crap fxaa on the light accumulation buffer which is smoother than the other image components. For example, I can use: a mipmapping or anisotropic filtering to eliminate the texture map aliasing, a FXAA to eliminate the light accumulation buffer aliasing and finally a MSAA to eliminate the geometry aliasing.

ps: I used the nanosuit model from this site: www.gfx-3d-model.com/2009/09/nanosuit-3d-model/

Unrelated Framework – Inclusion of OpenIL/DevIL

OpenIL is a library with very powerful image loading capabilities and I decided to include it in my framework. My standard can handle several image formats like the classic 8 bit RGB or more advanced  formats like 16 bit RGB or High Dynamic Range. The images are imported from file and used maintaining the original format (if it's possible).  For other feature check  OpenIL official web site (http://openil.sourceforge.net/)

Supports loading of:

* Windows Bitmap - .bmp
* Dr. Halo - .cut
* Multi-PCX - .dcx
* Dicom - .dicom, .dcm
* DirectDraw Surface - .dds
* OpenEXR - .exr
* Flexible Image Transport System - .fits, .fit
* Heavy Metal: FAKK 2 - .ftx
* Radiance High Dynamic - .hdr
* Macintosh icon - .icns
* Windows icon/cursor - .ico, .cur
* Interchange File Format - .iff
* Infinity Ward Image - .iwi
* Graphics Interchange Format - .gif
* Jpeg - .jpg, .jpe, .jpeg
* Jpeg 2000 - .jp2
* Interlaced Bitmap - .lbm
* Homeworld texture - .lif
* Half-Life Model - .mdl
* MPEG-1 Audio Layer 3 - .mp3
* Palette - .pal
* Kodak PhotoCD - .pcd
* ZSoft PCX - .pcx
* Softimage PIC - .pic
* Portable Network Graphics - .png
* Portable Anymap - .pbm, .pgm, .pnm, .pnm
* Alias | Wavefront - .pix
* Adobe PhotoShop - .psd
* PaintShop Pro - .psp
* Pixar - .pxr
* Raw data - .raw
* Homeworld 2 Texture - .rot
* Silicon Graphics - .sgi, .bw, .rgb, .rgba
* Creative Assembly Texture - .texture
* Truevision Targa - .tga
* Tagged Image File Format - .tif
* Gamecube Texture - .tpl
* Unreal Texture - .utx
* Quake 2 Texture - .wal
* Valve Texture Format - .vtf
* HD Photo - .wdp, .hdp
* X Pixel Map - .xpm
* Doom graphics

Supports saving of:

* Windows Bitmap - .bmp
* DirectDraw Surface - .dds
* OpenEXR - .exr
* C-style Header - .h
* Radiance High Dynamic - .hdr
* Jpeg - .jpg
* Jpeg 2000 - .jp2
* Palette - .pal
* ZSoft PCX - .pcx
* Portable Network Graphics - .png
* Portable Anymap - .pbm, .pgm, .pnm, .pnm
* Adobe PhotoShop - .psd
* Raw data - .raw
* Silicon Graphics - .sgi, .bw, .rgb, .rgba
* Truevision Targa - .tga
* Tagged Image File Format - .tif
* Valve Texture Format - .vtf

This is an example of how it works in my framework:

C_Image *newImage = new C_Image();
//load from file
newImage->ImportFormFile("test.jpg");
newImage->ImportFormFile(UF_FILE_JPG, "test.jpg");
//export to file
newImage->ExportToFile(UF_FILE_HDR, "test.hdr");
//set file format jpeg compression
newImage->SetFileFormat(UF_FileFormat_JPG(50)); //the image will be saved in my format with a jpeg quality of 50
newImage->SaveToFile("test.img");

Gianpaolo Ingegneri
Copyright @ 2010 – All right reserved

Unrelated Framework – Inclusion of ZLib

The Unrelated Framework got support for ziv-lempel compression of data using ZLib. The classes can be compressed in memory, loaded and saved with few rows of code and without limits. For example:

//this works only with resources like images, fonts, sounds, etc...
C_Image *newImage = new C_Image();
newImage->ImportFromFile("test.tga"); //load image from file
newImage->SetFileFormat(UF_FileFormat_Zip(6)); //set a zip file format of 6th level
newImage->SaveToFile("test.img"); //save the zipped resource on file, simple isn't it?

//if you want to load...
newImage->LoadFromFile("test.img"); //the system understands that it was zipped
newImage->SetFileFormat(NULL); //set it NULL if you don't want the zip compression in the future

or

//this can be used for every kind of object

C_Image *newImage= new C_Image();
newImage->ImportFromFile("test.tga"); //load image from file
C_Object_Zip *objZip = new C_Object_Zip(); //init a zip container
objZip->CompressObject(newImage, 6); //compress the image object
objZip->SaveToFile("test.zob"); //save the zipped object on file
delete newImage;

//if you want to load...
objZip->LoadFromFile("test.zob"); //load the zipped object from file
newImage = (C_Image *)objZip->UncompressObject(); //get the uncompressed object
delete objZip; //delete and free the zip object memory

Gianpaolo Ingegneri
Copyright @ 2010 – All right reserved

Unrelated Framework – Gui and Gui Editor

Finally I completed the GUI of my framework. The best feature is that the Gui can work in two modes: via software or using the OpenGL. It's  very helpful for cross platform compatibility, for video games or other OpenGL purpose.

GuiEditor01

The Gui is in his first version but it has all the widgets necessary to create professional applications. An interesting feature is that you don't need to program a single row of code to create particular interfaces: with the Gui Editor you can easily project all kind of professional interfaces and load them in your program using few functions. You don't need to code the widgets to make them work properly.  In this way you can save hours of programming.

There is a full list of widgets implemented:

- Button
- Radio button
- CheckBox
- Form
- Frame Window
- FrameBox
- PictureBox
- ScrollBar
- Scroll space
- TextBox
- ComboBox
- Menu
- ListView
- TreeView
- ToolBar
- Image button
- Graphic Api Viewer

Of course the GUI was coded in C++, it's object oriented and it's an integrative part of my Unrelated Framework.

Gianpaolo Ingegneri
Copyright @ 2010 – All right reserved

Ultra Fast Interpolation (via software)

In general, interpolation is a method used to construct a range of values from a set of data points. In digital image computing there are several methods of interpolation to improve the aspect of a transformed image but there is a problem: all of them are too slow to work via software in real time. Infact, we can see fast interpolations in 3d games only because they are performed via hardware by the graphic card (infact in the past it was very difficult to see an interpolation performed in real time).  However, interpolation is usefull  not only for 3d engines but they are an important part of digital image computing so there is a real need to develop a method to make it faster, expecially if you have to work with a large amount of images at the same time. For this reason I have programmed from scratch a set of  optimized algorithms of interpolation that are definite as in the past... but 100 times faster! The only limitation is that they can be used only for scale trasform but numerically they are perfect and faster at the same time.

UltraFastInterpolation

Moreover, they are useful to generate procedural images in real time, like textures, that can be used in 3d engine or in some paint softwares where you cannot have a 3d card to speed up all the stuff. In this demo you can see the high performaces of different algorithms with images of 16 bit per pixel. To make sure that my interpolation is numerically perfect, I have included also the calculus of the normal map and the bump mapping effect. With biquadratic interpolation you will obtain a still perfect scaled bump map because the normal map calculus is derivative and the biquadratic is a second order reconstruction filter.

There are the performances on my computer:

Zoom 1x (on a 512x512 image)

- Nearest: 400 fps - Bilinear: 270 fps - Biquadratic: 80 fps

Zoom 4x (on a 512x512 image)

- Nearest: 965 fps - Bilinear: 780 fps - Biquadratic: 245 fps

Zoom 16x (on a 512x512 image)

- Nearest: 1405 fps - Bilinear: 1165 fps - Biquadratic: 390 fps

As you can see, the speed of the algorithm is directly proportional to the size of the zoom, however it is very fast also at the minimum size of 1x. This condition is very useful if you have to resize images or to generate textures with a large amount of stretched layers, like perlin noise. CPU: Intel 2 QuadCore 2333 Mhz; RAM: 4 GB DDRII 800Mhz

Gianpaolo Ingegneri
Copyright @ 2010 – All right reserved

Unrelated Framework – Abandoned

The project started from a small framework that I coded for the Amiga 1200. Now the project is much more advanced and it has been developed for many years on pc/windows platforms. In the past it was called Ultimate Framework but there were already several frameworks with the same name and I decided to rename it to Unrelated Framework .

Some features:

- Programmed entirely in C++
- Serialization of Classes
- Cross-platform design
- New image format for digital image processing

- New surface format for computer graphics
- New format for multi channel textures (color, alpha, bump, normals, z-buffer …)
- Algorithms studied to work also via software
- Proprietary format for bitmap fonts
- Powerful procedural generator of textures, static and animated
- Wrapper of OpenGL, OpenCV, OpenEXR, FreeType, etc…
- Flexible GUI studied to work via software and via hardware

This framework is still work in progress and I used it to produce many of the software that you can see in this site.

Gianpaolo Ingegneri
Copyright @ 2011 - All right reserved