This demo shows up the GUI system of my old project "Unrelated Framework". This GUI has been programmed from scratch and makes use of both via software and GPU rendering. In this case, the demo makes use of OpenGL for the rendering. The GUI implements the most important widgets, like buttons, text boxes, form windows, tab strips, list views and menus. In this demo, you can find a some window in a desktop background, with tabs and text boxes. You can minimize and maximize the windows, click on the option buttons, write some text and test the popup menu. The rotating images belong to deferred contexts which are drawn into drawables that are presented inside the GUI's windows.

Currently, I'm re-implementing all the GUI into my new project "TextureMind Framework", which is more advanced and accurate than in the past. For instance, in this demo the text is drawn with bitmap fonts precalculated inside one or more textures, while in the modern TextureMind framework all the fonts are automatically generated by the engine. In particular, the new framework can use both bitmap and outline fonts, if supported by the graphics device (currently, I'm working to implement path rendering and outline fonts in Vulkan). Another difference with the past is the material system: in the past, everything was made to be rendered with simple image patterns, while in the modern engine I have implemented a full and complex material system made by visual expression nodes and program shaders (where available). However, the old demo has been programmed 15 years ago, which is amazing considering the complessity of the features that I'm still trying to port in the modern framework.

Post link

When you create a game, you need to consider the target framerate of your application: it will affect the entire dynamic of the physics engine and all the choices that will make the game playable. However, given the big heterogeneity of modern graphics cards with different types of monitors, the target frame rate may not be available on all configurations. It's therefore necessary that the target frame rate is scaled adequately to make the graphics equally fluid and to not affect the gameplay dynamics.

The demo presents one of the existing solutions for solving this type of problem, based on the frame adaptation with linear interpolation for the trajectory correction. In practice, the application frame rate is the vsync frame rate, while the target frame rate is used to calculate deltaT. A linear interpolation of the trajectories is used to bridge the gap between the target frame rate and the vsync frame rate, generating frames that do not exist to reach the vsync frame rate. As consequence, the F1 option is smoother than the F2 option.

Post link

If you like tetris, you are going to enjoy this demo. Basically, it is a bot to solve tetris that I programmed many years ago. In this case, the only technique considered by the AI to put pieces into the line is the "hard drop", so horizonal movers and T.spin are not supported.

You can interact with the interface and decide to change the decision. If you keep the "space" key pressed, the AI will solve the tetris in your place, trying to not be defeated by the level complexity. You can also have fun trying to complicate the scenario, the AI will try to solve the level in the best way possible. This demo exists because in the past I wanted to implement a bot (like GemFinder) to automatically solve tetris games. Then, I was occupied with my current job and I abandoned it.

Post link

Post link

This is an old demo that I created in the past during the development of an isometric engine for a PC porting of the snes game Equinox. The project was commissioned to me by a person that wanted to port this particular game to the pc world and then he abandoned it for lack of money. The graphics look very similar to the snes title, I remember that I did a pretty good job with the porting.

This demo was also part of an old framework to create video games that I developed in the past. The engine doesn't make use of 3D rendering or GPU, it's entirely via software. There was an original idea implemented to handle isometric occlusion with the simple blit algorithm, without implementing any variant (infact, the algorithm could work with simple BitBlt function call). As you can see, you can play only two rooms with collision detection, you can run, jump and hit enemies. Even if you have only two rooms, the engine was capable to handle the entire game. It's a shame that the project has been abandoned.

Post link

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.

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

This time it was a little bit harder. As you can see in this video, my engine can generate in real time very complex textures with the maximum detail at the maximum speed possible.

Each texture is generated in real time at the frame rate showed on the top-left corner of the window (the "generation" label).

- Lumps (512x512, 200 objs, 16 bpp, 345 FPS)
- Blobs (512x512, 16 bpp, 107 FPS)
- Perlin noise (512x512, 8 octaves, 16 bpp, 115 FPS)

Also, the normal map and the bump mapping are calculated in real time. I used 16 bit per pixel to have more precision when I get the normal map (for more informations check my High Static Range video). Precision and speed of this engine are awesome. The final result can loop in all horizontal and vertical directions.

CPU: Intel 2 QuadCore 2333 Mhz; RAM: 4 GB DDRII 800Mhz

©2009 Gianpaolo Ingegneri

This demo shows a new feature about the texture generation engine implemented in my Unrelated Framework. The normalmap used by bump mapping is calculated on the base of an heightmap generated with two different methods: Low Static Range and High Static Range. The enviroment bump mapping shows the difference in quality between the two ranges.

The first range uses only 8 bits per pixel that is too low to represent a continuous surface like the sphere generated in this example and as result we can see many rings on the surface during the light effect. On the contrary, an high range of 16 bits per pixel is perfect to have a light effect on a continuous surface infact we don't have any kind of imperfection. I could use the famous High Dynamic Range to generate the height map, but in my opinion it could be too expensive for the use of memory and the lack of speed (32 bits floating point per pixel, or 16 bits half-float has continuous conversions because cpu doesn't support it).

©2009 Gianpaolo Ingegneri

This is a demo about drawing loop textures with a picture tube technique. The blit functions of my engine can write an alpha source image to a destination buffer preserving the alpha channel information. This technique is useful to design alpha textures and to make some background effect as shown in the picture.

©2008 Gianpaolo Ingegneri

Finally I've released what I hope will be the first in a long series of demonstrations about the potentiality of my Unrelated Framework. This demo shows some graphic effects to demonstrate the enormous flexibility of the blit engine. Strictly coded via software, it can run on lowend configurations with an excellent frame rate.

There is a custom font format very useful for future development on platforms where there is no freetype support or to resolve the annoying problem that you cannot use the true type hinting informations without a specific license. Moreover, my engine includes other effects like alpha blending, complex bitmap fonts and bump mapping. There is no use of graphics card because all the drawing algorithms have been reprogrammed from scratch by myself and the image buffer is displayed in fullscreen using the basic gdi functions of the operating system. However, in the architecture of my framework you can overload all the via software drawing functions with the graphic card functions of the other famous api like opengl or direct3d.

©2008 Gianpaolo Ingegneri