[Index Software] Coin des développeurs :]

[lepton]

Ah ok... Dans mon esprit, ça servait à créer une zone protégée en mémoire. Mais ça n'a rien à voir avec les chaînes de caractères, en effet...

[Tugdual]

En langage C/C++, il n'y a pas de protections : c'est du bas-niveau, proche du matériel et de la mémoire, qu'on manipule quasi directement, en jouant avec des pointeurs. C'est concis, efficace, rapide, mais risqué, puisque très exposé au moindre relâchement du développeur. On peut néanmoins bénéficier de protections au travers de certaines bibliothèques, au détriment (plus ou moins, ça dépend des contextes) des performances.

[lepton]

En fait, en bon gros électronicien, je connais surtout le bas niveau. Ma seule expérience en C se limite à des bidouilles sur des PICs.
Ceci expliquant sûrement cela...

Dans une entreprise où j’ai travaillé avant, à une époque, les softs étaient écrits par des électroniciens purs et durs.
Puis la place des logiciels embarqués est devenue de plus en plus importante, et l’entreprise a embauché de "vrais" codeurs, informaticiens de formation.
Et là, quand ils ont mis le nez dans ce qui avait été écrit, est apparue chez eux l’expression dédaigneuse "coder comme un électronicien".
C'est-à-dire :
- Le maximum de choses dans le main().
- Le moins de fonctions possible. Ou alors des macros, histoire de bien remplir la flash.
- Pas de commentaires
- Des variables au rôle pas très clair, mais avec des noms faciles à retenir (A, B, C...)
- Parfois un asm { ... } surgissant de nulle part.

Un collègue a même déniché un fichier écrit en C avec un goto dedans. Il a dit que c'était la première fois de sa vie qu'il voyait ça.


Mais bon, ça marchait...

On en plaisantait (pas eux), mais il faut reconnaître qu’il n’y avait que celui qui avait écrit son code qui pouvait le maintenir...

[PaterFamilias]

En fait, en bon gros électronicien, je connais surtout le bas niveau. Ma seule expérience en C se limite à des bidouilles sur des PICs.
Ceci expliquant sûrement cela...

Marrant, ton spoiler ma rappelle mon deuxième job, quand ma boîte de l'époque (un constructeur automobile Français qui a deux marques Françaises) a commencé à avoir besoin d'informaticiens pour le soft embarqué, et qu'ils ont commencé à prendre des gars de la DSI (dont moi) pour industrialiser du code d'électronicien (qui, les pauvres, codaient comme ils pouvaient, sans avoir eu de vraie formation).
Je vous raconte pas le bazar politique (ce qui a fait que je n'ai d'ailleurs pas tenu longtemps, même si le job était très intéressant).

[Benoit]

En langage C/C++, il n'y a pas de protections : c'est du bas-niveau, proche du matériel et de la mémoire, qu'on manipule quasi directement, en jouant avec des pointeurs. C'est concis, efficace, rapide, mais risqué, puisque très exposé au moindre relâchement du développeur. On peut néanmoins bénéficier de protections au travers de certaines bibliothèques, au détriment (plus ou moins, ça dépend des contextes) des performances.

Il y a quand même moyen de faire des bibliothèques C/C++ compréhensibles et exploitables, y compris quand on est "électronicien".
Oui, je regarde dans votre direction Nvidia, quand les mecs de Google reprennent toutes vos librairies de zéro, c'est peut être "qu'il y a un problème" avec votre API.

[Bubu]

…Le problème sous-jacent, c'est qu'on ne donne pas d'adresse de fin …

En langage C, les chaînes de caractères sont qualifiées d'AZT : A Zéro Terminal.
Cela signifie qu'une chaîne de caractères se termine forcément par un code ASCII nul (pouvant aussi être représenté par '\0').

=======
Le langage C
Norme ANSI
2e édition

Brian W. Kernighan
Dennis M. Ritchie

ISBN 978-2-10-071577-0

…
Techniquement une constante de type chaîne est un tableau de caractères.
La représentation interne d'une chaîne se termine par un caractère nul '\0',
si bien qu'elle occupe en mémoire une position de plus que le nombre de caractères qui figurent entre guillemets.
Cette représentation implique que la longueur des chaînes est illimitée,
mais que les programmes doivent les lire entièrement pour déterminer leur longueur.
…

=======
Mais bon, pour aller un peu plus loin (qu'avec l'ASCII)
https://www.gnu.org/software/libc/manua ... Intro.html
https://www.gnu.org/software/libunistri ... troduction
etc…

Oui, mais libre à toi d'écraser le caractère nul, et d'agrandir la chaîne.
(Et de rajouter du code exécutable malicieux à cet endroit)


Pour malloc et free (langage C) :
malloc(taille en octets) alloue une zone de mémoire dans la RAM. Cela garantit qu'elle n'est pas utilisée ailleurs, au moment de l'allocation. (Et qu'elle ne sera pas utilisée non plus lors d'une prochaine allocation, à moins qu'elle ait été libérée entre temps).
free (adresse) libère l'allocation mémoire dont est précisée l'adresse de début.

Mais rien n'est guarantit en ce qui concerne l'accès, tant en lecture qu'en écriture de cette zone.

L'équivalent en C++, c'est les opérateurs new et delete.
Mais il existe en C++ des pointeurs intelligents. (Il y en a de 3 types). En fonction de la portée de l'objet.
Par contre, ils ne gèrent pas les références croisées.
Seuls les garbage collectors d'autres langages le font.

En C++, langage orienté objet, il faut être hyper rigoureux entre les allocations mémoires et leurs destructions.
Pour éviter les fuites mémoires.
C'est un peu simplifié grâce aux constructeurs et destructeurs. (On alloue tout dans le constructeur, on libère tout dans le destructeur... En gros)

La difficulté de la gestion mémoire dans le C et le C++, c'est de d'abord réfléchir à la portée de la ressource allouée. Et de prime abord savoir quand on en a besoin et quand on peut la libérer.

En Java, c'est un peu le cas aussi. Il faut éviter les allocations mémoires inutiles mais c'est seulement une question de performances. Mais les fuites mémoires, ça n'existe pas. En tout cas s'il y en a ce n'est pas la faute du développeur mais de la machine virtuelle Java.

[Bubu]

J'ai essayé.
De faire un jeu pour Android. Et d'en faire un revenu.
C'est un bide. Aucun téléchargement, aucune rémunération.
Je continue bêtement à enrichir l'API, gestion de texte international, rendu OpenGL dans des textures, afin de créer une UI.
Avec des textes, des boutons, des listes déroulantes. Mais je suis sans espoir. Je n'y crois plus.

Je crois que je vais reprendre des études.

Peut-être que la bonne place de ce sujet est "Juste pour geuler".

[Ixy]

Les jeux Android c'est un domaine très compétitif, il y a plein de bons jeux qui n'ont pas bcp de téléchargements. Ca te fait une expérience que tu pourras montrer.

[Bubu]

Les jeux Android c'est un domaine très compétitif, il y a plein de bons jeux qui n'ont pas bcp de téléchargements. Ca te fait une expérience que tu pourras montrer.

Merci Ixy ! Ça fait plaisir de t'entendre.
J'avais cru que tu avais lâché le forum, car ces derniers temps tu étais absent. Bon retour.

J'aimerais bien reprendre mes études dans le domaine des réseaux neuronaux. En Master. Mais j'ai d'énormes lacunes je crois.
De souvenir, en Math (j'étais en filière Math-Info), je me suis arrêté aux valeurs propres et vecteurs propres d'endomorphismes. (Diagonalisation).
Et en Analyse, aux séries.

J'ai peur d'être largué face à des éleves qui viennent de prépas.

Si je reprends mes études, j'irai vers Rennes.

As-tu un avis ?

[Manichéenne]

Je pense que tu as au moins montré que tu sais te fixer des objectifs, apprendre et avancer seul.
Du coup, est-ce que tu n'arriveras pas à combler tes lacunes de la même manière que tu as appris à développer un jeu Android ?

[Tugdual]

Ça t'a au moins permis de développer des compétences et un savoir-faire.

Tout ça pourra te resservir pour un autre développement...

[Bubu]

Je suis en train de travailler sur le rendu vers une texture (et non vers l'écran).
Cette texture sera plus tard rendue sur l'écran selon des paramètres.

C'est utile pour par exemple faire une liste déroulante :
On définit une image rectangulaire, dans laquelle on place tous les éléments graphiques horizontalement.

Sur l'écran ensuite, on place cette image rectangulaire correctement en fonction d'un marqueur de position horizontale, et tout le reste ensuite. (Par-dessus).

Tout fonctionne, sauf que :
L'image est rendue à l'envers.
C'est un problème dans la matrice de projection que j'utilise, qui utilise deux négations successive selon les axes y, et du coup le rendu dans la texture est tête-bêche.

Le problème c'est que pour l'instant j'arrive pas à corriger ce bug !!!

[Bubu]

Bon, c'est dégeulasse.
La seule solution que j'ai trouvé, est de donner une taille négative en y pour l'image de rendu. Render Target.

Donc j'ai crée un objet spécial, FrameBufferSpriteBatch hérité de l'objet SpriteBatch. Sa particularité, c'est d'inverser l'axe des y sur la texture.
Cela fonctionne, mais c'est moche.

[EDIT]
J'ai enfin réussi à afficher des images (sprites) correctement (et pas tête-bêche) dans une texture.
Du coup j'ai supprimé du projet l'objet FrameBufferSpriteBatch.
La différence ne tient que dans la matrice de projection utilisée pour ce rendu dans une texture.
J'ai à la main inversé le haut et le bas.
Donc l'API reste très simple.
On crée une texture cible. Avec taille à préciser.
On fait le rendu.
On restaure le rendu vers l'écran.
C'est tout.
(On peut utiliser la texture obtenue comme n'importe quelle autre pour un futur rendu vers l'écran).

[Bubu]

J'essaie de faire une API simple pour le rendu 2D.
Au début, on a une grille de sprites. Une ressource, une image, que vous devez fournir.
Vous apposez dessus un sprite batch. C'est fourni par mon API : vous devez simplement préciser combien il y a de sprites en largeur et en hauteur sur cette image.
Si votre image est un tableau en deux dimensions contenant les différentes images, c'est bon.
Mais mon système ne gère pas les images de tailles aléatoires. Il faut qu'elles soient dans un tableau 2D uniforme.

Ça peut paraître simpliste, mais ça permet de faire tous les Mario Bros.

Ensuite je permets de rendre (dessiner) chaque sprite, très rapidement, en utilisant les capacités de calcul de GPUs.(Il y a un GPU sur les téléphones aussi).

Un exemple de sprite batch :

game.png

L'avantage d'utiliser un GPU pour le rendu final, c'est de pouvoir faire des rotations, des mises à l'echelle (scaling), et des colorisations de sprites définis en niveau de gris.
Pour cela, on fait un peu de géométrie (rotations et scalings), et un fragment shader spécial (pour coloriser).
Le cycle pour chaque rendu (chaque frame):
Vider le sprite-batch
Ajouter tous les sprites avec leurs paramètres (coordonnées dans la grille, emplacement, taille, angle et éventuellement couleur).
Et rendre.

En un seul draw call, tous les sprites sont rendus. Au niveau performance c'est imbattable.

Mais tout cela ne concerne pas l'utilisateur final de l'API :

En initialisation :
Il charge sa texture.
Il met un spritebatch dessus.

En utilisation pour chaque frame :
il vide le spritebatch.
il y ajoute ses sprites.
il fait le rendu.

C'est tout.

[Ixy]

J'aimerais bien reprendre mes études dans le domaine des réseaux neuronaux. En Master. Mais j'ai d'énormes lacunes je crois.
De souvenir, en Math (j'étais en filière Math-Info), je me suis arrêté aux valeurs propres et vecteurs propres d'endomorphismes. (Diagonalisation).
Et en Analyse, aux séries.

J'ai peur d'être largué face à des éleves qui viennent de prépas.

Si je reprends mes études, j'irai vers Rennes.

As-tu un avis ?

Il faut regarder toutes les formations disponibles, comme il y a une grosse demande (des entreprises) il y en a peut-être qui exigent une formation pas trop poussée en maths (voir aussi formations big data).