PATRIA 3D Engine – General Overview

Reading Time: 2 minutes

This is the first of a series of articles which intend to document the PATRIA 3D engine, an OpenGL based framework I have developed during the last 2 years with my Team, the Team Novasoft.

The engine was born by an idea I kept in my mind since years and that I was able to put in practice in the development of our first game using this engine, Fantasy Racing.

Our engine is not ever near the flexibility of holy monsters such as UDK or Unity but it is ours, it served a lot to build our own experience and it is flexible enough for our needs.

In particular, the engine aims to be 100% cross platform on at least the following platforms:


– Android (2,3, and ICS)

– Windows


– Linux

The engine is completely written in pure C language with no additional libraries than standard memory manager and i/o routines (for desktop versions).

The usage of a pure C solution gave to me the ability to compile the engine on a multitude of systems and architectures and therefore make the engine itself portable on different platforms.

The PATRIA 3D engine offers the ability to be integrated "as it is" on any supported platform thanks to the development of a compatibility "interface" layer which covers all the language-environment specific interfaces.




The main idea behind the PATRIA3D Engine development was to create as much possible a portable engine not linked to any specific technology except than OpenGL, standard memory libraries and I/O libraries. This represents the core of the engine.

The engine does not talk directly to the HW obviously, for obvious reasons the dialog with the HW occurs using the different drivers of the extensions we need to use, one example for all, the OpenGL driver.



25.000 Downloads on Fantasy Racing!

Reading Time: 1 minute

 We passed the 25.000 downloads with Fantasy Racing just yesterday.

I have to admit that it is a real satisfaction and I feel very proud of what my friends and I have been to achieve in this "free time" adventure.

The game has a real potentials, there are chinese publishers that are trying to take the distribution rights for it. It is quite funny to see their proposals for something, we already know in our hearth, we will never let go since it is part of us, it is inside our bones.


Go Fantasy Racing, GO! Go Team Novasoft!


Some very good news about our Fantasy Racing Game

Reading Time: 1 minute

 I am very happy to see our newest game, Fantasy Racing, receiving excellent feedbacks on Internet sites.


The Game is going very well in terms of downloads considering that we have no advertisements campaigns on going and we are not actively following the game on forums/sites/communities online.


We found out that the game was rated 16th on the global racing Android games on this site:

Besides, it  was appraised to be on the top 5 racing games for MicroMaxFunbook device:

And it got a quite positive review on Mobile Modder website


It is a real satisfaction for us to see people which appreciate our efforts on our game.


To close this post, we have reached more than 21.000 downloads for our title, congratulations team novasoft!

Android and HW differences

Reading Time: 2 minutes

Since the release of the first game on the Android Market I have faced the usual problems on the HW differences of the different Android devices on the market.


I think this is the actual limitation of the Android platform, a lack in the HW standards.



This limitation forces every developer to perform endless sessions of quality testing on a multitude of devices that ofter represent a serious limitation for and indie team.


Not all the people of starting teams can afford to have tens of devices for testing and, even if they can, no one can guarantee that the application won’t crash on a specific sub version of the HW or a specific version of Android.


As if it was not enough the presence of a multitude of custom Roms, custom access levels (root access), anti virus and anti spy-wares make the situation out of control and almost impossible to be handled by simple human beings.


Besides, if you decide to go for a custom code written in C, eventually using the Android NDK, things gets harder and harder.


Just to report an example of this, when we released the version 1.7 of Fantasy Racing, we started received bad reviews (four one star in one day, terrible!) and we didn’t know how to react.

In the comments our users reported things like "always crashes" or "does not start" while on our devices the game was rock solid and very stable.


We realized that all the users reporting the errors were running the game either on Galaxy SII or Galaxy Note which are 2 very common devices in the Android market.

We started digging around and we found many forums talking about bugs specific for these devices. Bugs were pointing to ADMOB compatibility or the soundpool bug. We released fixes for these problems but apparently nothing changed, we continued to receive bad reviews from our users.


We decided then to procure some devices having the same specs and we found out that on a Galaxy SII of a friend of ours, the game went very smoothly while on a Galaxy SII of another friend it constantly crashed.


To cut a long story short, we found out that the problem was depending on our PATRIA3D Engine which used to ask the GPU to draw an "not existing" Vertex Buffer Object in some game conditions and that the GPU on these devices (Mali 400) raised an error blocking the game.


The same problem didn’t happen on our testing devices using different GPU families such as PowerVR, Adreno or NVidia.


In simple words, the problem was caused by a bug in our code but we had different behaviors depending on the GPU installed on the devices (though I think it is mostly related to the OpenGL driver implementation of the device).


We have now fixed the problem and the game is rock solid on those devices but unfortunately the bad reviews remains like a stain we cannot remove.


We still cannot explain why on same Galaxy S2 devices the game worked fine but start thinking about them as mysteries of the Android World.



[ITA] Rilascio Fantasy Racing – Post Mortem Report

Reading Time: 7 minutes


Ciao a tutti

vi presento il titolo appena rilasciato dal mio team amatoriale, il team novasoft.

Il nome del gioco e’ Fantasy Racing.

E’ stato pubblicato Venerdi 17 2012, nel market android:…t.racegame

Tecnicamente il gioco e’ basato su di un framework che noi amiamo chiamare PATRIA 3D engine, totalmente proprietario e scritto in Ansi C puro. Il nome e’ dovuto al fatto che quando abbiamo iniziato a svilupparlo erano in corso i festeggiamenti per il 150 anniversario della nostra nazione. Ecco il motivo del nome PATRIA.

Alcuni cenni su PATRIA

Il motore in questione ha le seguenti caratteristiche (al momento, anche se in continua lavorazione):

– Supporta pienamente OpenGL ES 2.0

– E’ completamente compilabile in qualsiasi ambiente desktop (Windows, Mac e Linux) e mobile (IOS e Android)

– Supporta vari formati di immagini per il texturing

– Supporta shaders standard GLSL con un framework di caricamento e compilazione molto interessante tra cui l’embedding degli shaders stessi al fine di proteggerli da un eventuale intrusione nel package applicativo.

– Supporta caricamento di modelli da formato OBJ e da un formato proprietario .patria3D che viene ottenuto attraverso un tool di conversione proprietario

– Nel gioco fantasy racing si e’ implementato un map editor basato su fogli di calcolo cosi che chiunque potesse editarli (funzione non aperta al pubblico).

– Supporta il wrapping JNI per il supporto NDK

– Implementa un sistema di messaggi interno molto efficiente (per quanto possa esserlo un sistema di messaggi) al fine di rendere il motore pluggabile su diversi ambienti come Objective C e Java NDK, Linux, Windows o MAC

– Implementa un sistema molto basico di calcolo delle collisioni attraverso buonding boxes o multiple spheres per avere un approssimazione del volume del modello.

– Implementa vari effetti di esplosione particellare basati su CPU ed altri basati GPU su shaders nei casi piu tosti.

– Supporta l’integrazione con il WII mote per il testing su Desktop del prodotto

– Le funzioni matematiche del motore grafico come le manipolazioni di matrici e’ possibile delegarle a codice SIMD ARM NEON per ottimizzare drasticamente le prestazioni

– Implementa il picking di oggetti attraverso color picking con un framework di utilizzo semplicissimo a livello di programmazione.

– Implementa un algoritmo molto base e mal funzionate di ray casting per la selezione degli oggetti, al momento non usato

– Supporta merging delle meshes

– Supporta merging e batching automatico degli elementi statici dello scenario al fine di minimizzare le OpenGL Draw calls

– Supporta tecniche di color replacement e vertex manipulation sulle meshes caricate nell’engine

– Supporta cloning delle mesh

– Implementa un sistema di benchmarking interno per la valutazione delle prestazioni del motore come FPS, Draw per Frame, Triangles per Frame etc

– Supporta 3 livelli di dettaglio del motore al fine di rendere al meglio su diversi devices in base alla loro potenza. La scalabilita’ sarebbe possibile in modo dinamico anche se al momento non ho investito in materia.

Cenni sullo sviluppo

Ora, passando oltre gli aspetti puramente tecnici, vorrei riportarvi le mie esperienze in questa avventura da un punto di vista piu pratico.

Il nostro gruppo si e’ riunito un anno fa, per la precisione il 18 di Gennaio 2011.

Inizialmente era composto da 5 membri e non era stato composto per lo sviluppo di videogiochi ma per altre idee imprenditoriali. Dopo un pochino 2 membri hanno abbandonato un po per perdita di entusiasmo un po perche’ messi male nel loro assetto aziendale.

Siamo cosi rimasti in 3.

E’ composto da 2 programmatori (io e Bizio, spero si iscrivera’ presto) ed un modellatore 3D che si e’ anche occupato del level design (mio fratello).

In aggiunta, un mio ottimo amico si e’ prestato per le basi musicali del gioco (Grazie Max, spero ci sara’ un ritorno tangibile all’aiuto).

Il tutto e’ stato sviluppato di notte dopo orario di lavoro e durante i week ends in pure stile indie casalingo, ci manca solo il garage (in alternativa’ pero’ ho la cameretta di mio figlio dove programmo, tra winnie de poooh e macchinine).

Tutti e 3 i componenti del team hanno famiglia e figli (mio fratello ne ha 3 per darvi un idea).

L’avventura e’ nata ed e’ tuttora un tentativo di sondaggio del mercato piu che un tentativo imprenditoriale. Il modo in cui eventuali introiti saranno gestiti sono dettagli non rilevanti anche se non e’ stata la molla principale. Ringraziando la situazione non abbiamo problemi in tal senso.

Il framework 3D e’ stato interamente sviluppato da me partendo da fine Febbraio 2011 senza avere nessuna conoscenza di OpenGL o programmazione 3D in generale.

Avevo un ottimo background di programmazione di videogiochi di base che comincia circa 20 anni fa, ho scritto nella mia vita qualche milione di linee di codice in linguaggi di basso livello come C e ASM e sono appassionato da sempre di real time computing. Diciamo che questo e’ quello che mi ha aiutato di piu.

Il framework contiene al momento piu di 35.000 linee di codice C contando solo il motore e non il layer Java che sta sopra al momento.

Tutta la filiera produttiva e’ stata effettuata con SW free ed opensource come Eclipse, Valgrind (per il memory profiling), Blender, Inkscape, Gimp e tanti altri tools che ora non ricordo nemmeno piu di precisione.

Al momento il framework e’ solo agli albori per cui non offre ancora molte delle cose che vorremmo come antialiasing, postprocessing e altri effetti che sono nella do-queue.

Abbiamo intenzione ovviamente di migliorare PATRIA come tecnologia inserendo effetti grafici, migliorando le capacita’, le prestazioni e la programmabilita’. L’idea’ e’ quella di avere un framework the potremo utilizzare internamente per darci un buon engine, diverso dalla solita roba e che ci permetta di sviluppare le nostre idee in poco tempo.

Cosa e’ andato e cosa non e’ andato

Per quanto riguarda l’esperienza di implementazione stessa, posso dire quanto segue:

– Il non avere esperienza del mondo OpenGL e’ stato un problema marginale. Avevo gia una buona preparazione ai concetti base ed un ottima predisposizione matematica. Non avrei nemmeno osato diversamente.

– Il non avere esperienza di OpenGL e non conoscere nessuno che ne avesse mi ha costretto a fare tutto da solo. Ho investito tantissimo in libri come il red book, il blue book, l’orange book ed il gold book, Li ho letti e riletti 1000 volte fino alla nausea. E’ diventata la mia lettura preferita al bagno. Ho anche investito molto nei libri di GPU Gems, Game Gems e di matematica applicata al 3D.

– Il non avere esperienza di OpenGL mi ha causato mesi di ritardi, questo devo riconoscerlo. Questo perche’ inizialmente ho sviluppato in immediate mode, poi ho scoperto OpenGL ES 2.0 e le potenzialita’ degli shaders. Da li ho scoperto la necessita’ di gestione delle matrici in proprio e cosi via, ho cominciato a studiare le potenzialita’ di ottimizzazione del rendering, il batching e cosi viam si e’ aperto un mondo. Penso di avere buttato via tutto e rifatto tutto almeno 5 volte, almeno la componente di rendering del motore. Lo rifarei? Dalla A alla Z, e’ stata una esperienza incredibilmente eccitante. Non sarei riuscito a fare il tutto la notte dopo una giornata lavorativa molto impegnativa se non ci fosse stato l’amore in quello che facevo.

– Il supporto del mio ottimo amico bizio e’ stato tutto sulla componente Java. E’ stato fondamentale avere una persona che curasse l’aspetto mobile puro. Lui si e’ specializzato in tutto quello che non era game engine. Molto utile. Questo ha comunque comportato uno squilibrio molto gli effort di sviluppo verso il motore C ma questo era gia in programma e l’ho un pochino accusato.

– Tornando indietro riscriverei tutto come ho fatto, a prescindere dal risultato mi si e’ aperto un mondo di esperienze e sono sempre piu innamorato di questo mondo. Ho ampliato le mie conoscenze sul mondo della programmazione real time e mi sono fatto le ossa (tanto) sull’ambiente Eclipse che e’ usatissimo anche nel mio mondo principale.

– Ho imparato a dormire 4 ore per notte. Lo faccio ormai da 13 mesi, ho scoperto che e’ possibile ma con le dovute accortezze.

– Sono felice di non avere usato un engine gia fatto perche’ non mi avrebbe dato le stesse emozioni. Sto facendo questo per passione, i soldi non mi servono (non prendetela a male) ed i ricavati non andranno nelle mie tasche in quanto ho parecchi progetti non di lucro da portare avanti. Quello di cui sono felice e’ che il background acquisito in C, nel mondo GL e e nel mondo unix in generale e’ impagabile.

– L’imparare a modellare low poly e’ stato piuttosto difficile facendo le cose a livello amatoriale. Ancora non abbiamo raggiunto un livello buono in materia. Siamo fiduciosi che ci riusciremo, l’impegno c’e’.

– La mancanza di un grafico si e’ sentita. Abbiamo pero’ commissionato il lavoro del materiale del market, icona e campagna di promozione ad un illustratore molto bravo. Non saremmo mai riusciti da soli. Il costo e’ stato gestibile.

– Il concept del gioco non e’ ancora completamente quello che avevamo in testa anche se e’ completo. Non siamo riusciti a sviluppare il tutto in tempi decenti. Ci sara’ molta carne al fuoco aggiunta nei prossimi mesi (settimane spero). Il gioco e’ cmq giocabile ed a nostro avviso divertente con ben 15 livelli di gioco.

– L’effort e’ stato massacrante. Consiglio di non mettersi in queste avventure con una famiglia e figli se non si ha un ottima comprensione dal proprio partner. Non e’ stato un gioco da ragazzi, e’ stato un impegno serio.

– Sono molto soddisfatto di aver messo su un bel tech layer, spero di riuscire a riusare tutto come e’ nei miei programmi.


Tornando sul discorso prodotto, posso dire quanto segue:

– Abbiamo speso all’incirca 3.000 euro in tutto per:

– Devices di prova (il mondo Android ha bisogno di tanti devices per i testing)

– Libri

– Illustratore per la grafica del market e della campagna pubblicitaria.

– Campagna Pubblicitaria.

Ovviamente questa stima non considera il nostro tempo. Se dovessi calcolare il costo reale, ad esempio calcolando quanto guadagno l’ora per le ore che ci abbiamo lavorato sarebbe una cifra altissima, decine di volte di piu, meglio non pensarci (siamo in 3 dopotutto).

Modello di business

Il modello di business che abbiamo deciso di adottare e’ di seguito descritto.

Piattaforma Android (rilasciata oggi): Modello free + pubblicita’ da migrare ad un freemium puro. Per ora abbiamo tutto free ed i passaggi di advertisement basata su ADWHIRL. Nelle prossime settimane rilasceremo content a pagamento tra cui:

– Capitoli addizionali di gioco (0.99$ a capitolo)

– Rimozione AD (da quantificare)

– Pacchi di mappe aggiuntive (da verificare e quantificare)

Piattaforma IOS (da completare il porting): Modello a pagamento per tutto. Pensavamo a 0.79$. Se le cose su Android si dimostrano positive adotteremo il modello freemium anche la anche se vorrei prima consultarmi con gente che gia ha esperienza reale su quel mercato come ad esempio il sempre disponibile TheCrib.

Per ora i prezzi ed i tempi sono ancora da decidere quindi non prendeteli alla lettera.

Cosa ci aspettiamo

Una cosa sicuramente l’abbiamo gia ottenuta, abbiamo imparato tantissimo. Inoltre il non essersi esposti economicamente e socialmente a rischi ci permette di guardare la situazione con moltissima tranquillita’.

Le aspettative (o meglio speranze) ci sono, e ce ne sono moltissime nel nostro cuore. Essendo persone mature pero’ capiamo sia la situazione del mercato che la reale qualita’ del prodotto. Per questo capiamo benissimo che non ci arricchieremo con questo prodotto.

A noi basterebbe coprire le spese o creare le basi per sentirci appagati in questa avventura.

D’altro canto possiamo dire che noi ce l’abbiamo messa tutta. Siamo partiti un anno fa senza sapere nulla di Android e di OpenGL e ora stiamo con un prodotto nel market android basato su un framework 3D perfettamente funzionante e che regala emozioni mentre si gioca, diverte.

Certo, non sempre basta questo a fare un successo, vediamo casa succedera’, noi aspettiamo, ieri notte non abbiamo dormito ed oggi sara’ tutto il giorno dedicato al refresh del market android e delle statistiche di admob.

What is next?

Il porting ad Iphone e’ da completare, non credo cominceremo altri prodotti. Almeno per ora non ne abbiamo le forze e non possiamo stressare ulteriormente (senza introiti) le nostre famiglie.

Vedremo in base al risultato.


Se siete arrivati fin qui, avete avuto molta pazienza.

Grazie di cuore a tutti.

The love and hate for shared libraries

Reading Time: 2 minutes

 Since yesterday I have been playing around on the WII controller integration on my PATRIA 3D engine.


This is required in order to have a fully working accelerometer support for our games testing since it is quite an effort to perform real testings on the smartphones especially when you are still in the middle of the caos of code development.


I have been trying the libwiimote on my ubuntu 64 bit but unfortunately, for some reasons, it does not look like the best solution for me (thought the library is well done). In fact it has a lot of sleep/wait time in the implementation which cause the frame reate of the game Fantasy Racing to drop to 15/18 FPS on my laptop. It looks like that, if no input is made on the device, the wiimote_update function freezes my process.


I have then decided to go for libwiiuse and I find it fantastic though I have not yet completed the integration.

To cut a long story short, I have compiled the library, using the well done documentation, I have done all the required configuration steps in my eclipse environment but every time I have run a compiled program using the shared object library  I used to get this error message:


error while loading shared libraries: cannot open shared object file: No such file or directory


This problem has kiled me since I spent a lot of time looking for an explanation to the root causes of it.


After I while I thought…..holy crap Maurizio, can you be such a stupid? The new library is a shared library which links other shared libraries, let’s try to refresh the dynamic linker cache by running the command ldconfig

. And….it actually solved it. Lesson learnt, whenever you have problems linkind shared libraries, always remember to update the linker cache!!!

Fantasy Racing Alpha 6.0

Reading Time: 1 minute

 Since long time I was not publishing any news about the new title under development called "Fantasy Racing"

In the mean time our engine has evolved to version Alpha 6.0 which is, according to our internal consideration, one of the last versions being part of the alpha phase. Soon we intend to move to Beta – Release candidate versions.

The Game is almost complete, music is there, game interface is there, gameplay works fine, mobile devices integration works flawlesly.

We are finalizing the tuning of the engine in order to achieve a better frame rate on old devices but so far the results in that area are excellent as well.

We have an average of 55 FPS on a Galaxy TAB 7", 60 FPS on an Asus Transformer EEE PAD with NVIDIA tegra and results on other devices are amazing in terms of perfomances and compatibility levels.

The PATRIA 3D engine is starting to be a monster with many heads and its capabilities, considering the fact that has been developed only since few months are very good.


I am working on free time (ahahahhahah this is good, free time!) a complete matrix of the capabilities of the PATRIA 3D engine, I hope to be able soon to post it on this site and on the new upcoming PATRIA 3D official website.


At the moment, enjoy this video:





How to keep consistent 2D coordinates in a 3D world having different resolutions

Reading Time: 3 minutes

This document aims to document how to support 2D objects positions in a 3D engine supporting different resolutions and aspect ratios.   This is the solution I have currently adopted in our PATRIA 3D engine and it is not for sure the best solution available there.


In such conditions it is quite difficult to position objects that perfectly fit your scene such as the game’s HUD (for instance life icons, energy bars etc). I am sure there are multiple ways to achieve the wanted result but this is the way I have implemented in my PATRIA engine. Let’s take as an example the following HUD positioning in for the fantasy racing game based on the Team Novasoft’s PATRIA 3D engine.


Focusing our attention on the right side of the picture where the HUD is displayed:


We can easily understand tha the HUD is composed of 6 pictures, 5 pictures that diplay small stars (life in the game) and a pause button placed in the center.


In order to calculate the X game 3D coordinates of where the engine has to diplay the texture’s quad (2 triangles), some calculation is required as shown in the following code excerpt:


First, I calculate a base X coordinate called HUD_Life_Coordinate_X based on the window_width (in my initial case 800 pixels) and then I divide it by 2 (the negation is used for following code not in this picture).


Starting from that I start playing with trigonometric functions to have the starts moving in circle around the circle of the pause button. But this is just a fancy effect, not the core of the discussion.


Now, the problem starts here, I initially thought that calculating the coordinates based on screen’s widths would have been enough, I was wrong…..


I have started testing the application on different android devices and this is what I found out.


On Galaxy TAB device, having a resolution of 1024X600, different from the initial development environment which is 800X480, this is the result of the above solution:


On other resolutions such as the Asus Transformer (1280* 800) the problem is even worse, the HUD is not displayed at all.


  At this point I started guessing which was the best way to handle this situation.


  I initially thought that it was depending only on the X resolution of the screen but I was wrong, every attempt in that send failed.


  I have then focused my attention to the screen ratio which is used as well in the OpenGL view frustum configuration of my engine (I guess any engine does it btw).


  So, the question was, how can I calculate an X value so that the HUD is displayed correctly on any “valid” resolution?



My approach was the following:


  • Take a resolution as a base for the final calculation, in my case I took the 800X400 as base.

  • Calculate the aspect ratio of the standard resolution:


  • Calculate the Aspect ratio of the current device resolution.

  • Convert the base offset coordinate in the following way:




Where: ReferenceCoordinate is the coordinate you calculated during the design of your game based on default resolution.


CurrentRatio is the screen ratio of the current resolution. DefaultRatio is the ratio of your default resolution (in my case 800X480) Therefore, having said so, I have changed my code in the following way:

  • Defined a new standard value for the default resolution’s aspect ratio (this step is not mandatory but helps a lot in code usability)


  • Modify the previously shown procedure to calculate the coordinates of the object in the following way:

So, having applied this solution, achieves the wanted result:

Illustration 1: 800X480 (used my many devices such as Samsung Galaxy S, Motorola Defy etc)



Illustration 2: 1024X600 used by Samsung Galaxy TAB 7"



llustration 3: 1280X800 (used for instance my our Asus Transformer)

Profiling a C 3D engine using Valgrind

Reading Time: 2 minutes

 I recently faced some memory corruption problems on my PATRIA 3D engine which are quite painful to be solved.

Luckily I started using Valgrind, an opensource dynamic analysis tool which can debug the memory allocation of a typical C program.

Valgrind is free and can be downloaded at this URL.

The very interesting part of Valgrind is that you can run your compiled code (complied using debug symbols BTW) and see what is going on at memory allocation/read/write and deallocation level.

This is really what a C programmer would live to have always in his toolbox.


For instance, it is quite easy and straightforward to find memory access errors such as:

==8334== Invalid read of size 1

==8334==    at 0x4C29804: strlen (mc_replace_strmem.c:282)

==8334==    by 0x42FF06: PATRIA_Shaders_LoadAndCompile (PATRIA_Shaders.c:113)

==8334==    by 0x430D20: PATRIA_Shader_Load_Phong (PATRIA_Shaders.c:649)

==8334==    by 0x4137A4: Game_Menu_Engine_Init (CUBE_Game_Menu.c:3260)

==8334==    by 0x432657: main (main.c:244)




It is also quite reliable the function which identifies the conditional jumps in the program which are based on uninitialized values such as:

==8216== Conditional jump or move depends on uninitialised value(s)

==8216==    at 0x41761B: PATRIA_Draw_Scene (PATRIA_CUBE_Draw.c:1801)

==8216==    by 0x40D195: Game_Engine_DO (CUBE_Game_Logic.c:4563)

==8216==    by 0x50A93F7: glutMainLoop (glut_event.c:972)

==8216==    by 0x4326A8: main (main.c:267)

Valgrind allows you to identify the code line subject of the problem (in the last example the line 1801) and the exact file name where the line belongs to (PATRIA_CUBE_Draw.c).

As it is quite natural for a debugger like valgrind, it reports as well the call stack of the program:


– main

      – glutmainloop

             – Game_Engine_DO



I am very satisfied about this tool, it is free, well done and very realiable.


Good work guys.