[Index Software] Coin des développeurs :]

[Bubu]

j'ai intégré le son dans mon projet.
Maintenant on peut lire de la musique et jouer des bruitages.
Mais, c'est du code qui date, mais par chance, pas obsolète.
La seule chose que j'ai changée, c'est que j'ai encapsulé la priorité et fixé le nombre maximal de bruitages simultanés.(32)
Voici le code :

Code : Tout sélectionner

package com.niviz;

import android.content.Context;
import android.media.AudioAttributes;
import android.media.MediaPlayer;
import android.media.SoundPool;

public class SoundPlayer {

    private final SoundPool soundPool;
    private final Context context;
    private float effectsVolume;
    private static MediaPlayer mediaPlayer;

    public SoundPlayer(Context context) {
        this.context = context;
        AudioAttributes attributes = new AudioAttributes.Builder()
                .setUsage(AudioAttributes.USAGE_GAME)
                .setContentType(AudioAttributes.CONTENT_TYPE_SONIFICATION)
                .build();
        soundPool = new SoundPool.Builder()
                .setAudioAttributes(attributes)
                .setMaxStreams(32)
                .build();

        effectsVolume = 1.0f;
    }

    public int loadEffect(int resourceId) {
        return soundPool.load(context, resourceId, 1);
    }

    public void setMusicVolume(float volume) {
        if (mediaPlayer != null)
            mediaPlayer.setVolume(volume, volume);
    }

    public void setEffectsVolume(float effectsVolume) {
        this.effectsVolume = effectsVolume;
    }

    public void playEffect(int id, float volume, float pitch) {
        soundPool.play(id, volume * effectsVolume, volume * effectsVolume, 1, 0, pitch);
    }

    public void playMusic(int resourceId, float volume, boolean isLooping) {
        if (mediaPlayer != null) {
            mediaPlayer.stop();
            mediaPlayer.release();
        }

        mediaPlayer = MediaPlayer.create(context, resourceId);
        mediaPlayer.setVolume(volume, volume);
        mediaPlayer.setLooping(isLooping);
        mediaPlayer.start();
    }

    public void stopMusic() {
        if (mediaPlayer != null) {
            mediaPlayer.stop();
            mediaPlayer.release();
            mediaPlayer = null;
        }
    }

    public void pauseEffects() {
        soundPool.autoPause();
    }

    public void resumeEffects() {
        soundPool.autoResume();
    }

    public void stopEffect(int id) {
        soundPool.stop(id);
    }

    public void unloadEffect(int id) {
        soundPool.unload(id);
    }

    public void releaseEffects() {
        soundPool.release();
    }
}

[seul]

J'admire la technique, même si je connais très peu dans le domaine.

[Bubu]

J'admire la technique, même si je connais très peu dans le domaine.

Pour l'instant, il n'y a rien de difficile et pour le son, j'utilise des classes toutes faites, je n'ai fait que les regrouper ensemble.

Là où ça va être compliqué, c'est quand il faudra gérer les différents rendus tout en les affichant du plus lointain au plus proche.
Il n'y aura plus de notion de sprite batches, ou du moins pour l'utilisateur.
Car en fonction du rendu, il faudra utiliser plusieurs shaders et plusieurs textures cibles de rendu, et donc plusieurs sprite batches.
J'y réfléchis, mais ça s'arrête là, je n'ai pas encore les idées suffisamment claires pour coder ça.

[seul]

J'admire la technique, même si je connais très peu dans le domaine.

Pour l'instant, il n'y a rien de difficile et pour le son, j'utilise des classes toutes faites, je n'ai fait que les regrouper ensemble.

Là où ça va être compliqué, c'est quand il faudra gérer les différents rendus tout en les affichant du plus lointain au plus proche.
Il n'y aura plus de notion de sprite batches, ou du moins pour l'utilisateur.
Car en fonction du rendu, il faudra utiliser plusieurs shaders et plusieurs textures cibles de rendu, et donc plusieurs sprite batches.
J'y réfléchis, mais ça s'arrête là, je n'ai pas encore les idées suffisamment claires pour coder ça.

Parfois il faut juste attendre et tu retrouveras tes idées après.

[Bubu]

J'admire la technique, même si je connais très peu dans le domaine.

Pour l'instant, il n'y a rien de difficile et pour le son, j'utilise des classes toutes faites, je n'ai fait que les regrouper ensemble.

Là où ça va être compliqué, c'est quand il faudra gérer les différents rendus tout en les affichant du plus lointain au plus proche.
Il n'y aura plus de notion de sprite batches, ou du moins pour l'utilisateur.
Car en fonction du rendu, il faudra utiliser plusieurs shaders et plusieurs textures cibles de rendu, et donc plusieurs sprite batches.
J'y réfléchis, mais ça s'arrête là, je n'ai pas encore les idées suffisamment claires pour coder ça.

Parfois il faut juste attendre et tu retrouveras tes idées après.

Ma priorité reste l'affichage du plus lointain au plus proche.
Même si cela a un impact clair au niveau performances.
Car il faudra utiliser différents shaders, et différentes textures cibles.

Je fais appel à vous : quels sont vos rendus préférés :

-color map. C'est le plus commun. On affiche les textures telles qu'elles.
-grey scale : On affiche les textures en niveaux de gris. (Je fais au plus simple : je fais la moyenne du rouge, du vert, et du bleu et je laisse l'alpha inchangé)
-emissive : C'est un mélange spécial en alpha blending : on additionne la couleur de fond avec la couleur à afficher. Si on fait ça bien, on utilise un flou gaussien pour faire un halo.
-normal mapping : il faut la normale par pixel, codée dans la normal map. Et il faut une map qui code la brillance et une autre qui ne contient que les couleurs brutes, sans calcul d'éclairage.

Je poste un fragment shader possible utilisé pour le normal mapping en 2D:
Mais comme vu sans doute, j'utilise une seule texture qui code tout
Normalement, il faut au moins 2 textures différentes au minimum.
Mais si on veut gérer les effets de lumière il faut une autre texture en niveaux de gris pour la coder correctement.

Je précise que ce code n'est pas universel, au contraire il est très spécifique. C'est juste pour illustrer. (Il permet de gérer 2 lumières et c'est fixe, et il y a des paramètres en dur dans le code, mais j’espère que ça peut donner des idées.)

Code : Tout sélectionner

precision mediump float;

varying vec2 oTexCoord;
varying vec4 oColor;

uniform sampler2D sampler;
uniform vec3 light1Dir;
uniform vec3 light2Dir;

void main() {
	vec4 color = texture2D(sampler, oTexCoord) * oColor;
	vec3 normal = normalize(2.0 * texture2D(sampler, oTexCoord  + vec2(2.0 / 3.0, 0.0)).xyz - 1.0);
	float shininessFactor = texture2D(sampler, oTexCoord  + vec2(1.0 / 3.0, 0.0)).x;

	normalize(light1Dir);
	normalize(light2Dir);
	
	float dotP1 = dot(light1Dir, normal);
	float dotShininess1 = dot(normal, normalize(light1Dir + vec3(0, 0, 1)));
	float shininess1 = clamp(pow(dotShininess1, 100.0), 0.0, 1.0);

	float dotP2 = dot(light2Dir, normal);
	float dotShininess2 = dot(normal, normalize(light2Dir + vec3(0, 0, 1)));
	float shininess2 = clamp(pow(dotShininess2, 100.0), 0.0, 1.0);

	gl_FragColor = vec4(color.xyz * max(dotP1, 0.35) * 0.5 + 0.5 * shininessFactor * shininess1 + color.xyz * max(dotP2, 0.35) * 0.5 + 0.5 * shininessFactor * shininess2 + 0.3, color.a);
}

J'ai beau réfléchir, mais je ne vois que ces rendus comme étant indispensables, mais peut-être aurez-vous plus d'imagination que moi !

J'en profite pour vous poster la texture qui va avec, qui m'a permis de faire du normal mapping en 2D:
De gauche à droite : la color map (couleurs brutes), la map de brillance et la normal map.
Mais en général, ou du moins pour les jeux, ils utilisent 3 textures différentes et les shaders qui vont avec.

[Bubu]

Réponse à la personne qui se demandait ce qu'était un intérêt spécifique.
C'est envahissant, et on ne peut pas s'en débarrasser, et c'est l'inverse d'une phobie.
Pour le dire clairement, c'est obsessionnel.

Au contraire, on en redemande.

[Tugdual]

Jujutsu (jj) - quand Google réinvente Git :

• en mode ninja...

Extrait :

Le principe de Jujutsu tient en une phrase : votre répertoire de travail EST un commit. Poh Poh Poh !!

Fini l’index, fini le staging area, fini les acrobaties pour synchroniser vos modifications. À chaque fois que vous sauvegardez un fichier, jj crée automatiquement un nouveau commit avec un hash différent, mais conserve un “change ID” stable qui survit aux réécritures. C’est complètement fou et pourtant ça marche.

[...]

Évidemment, Jujutsu reste expérimental. L’écosystème est plus petit, les intégrations IDE limitées (bien qu’il y ait déjà des extensions VSCode et Vim), et la terminologie différente demande un temps d’adaptation. Mais pour ceux qui cherchent une approche plus intuitive du contrôle de version, ça vaut franchement le détour.

[...]

Bref, vous l’aurez compris, jj ne remplace pas Git dans l’immédiat . Il le sublime en gardant la compatibilité totale. C’est une approche intelligente qui permet d’adopter progressivement un workflow plus fluide sans perturber les équipes de dev.

[Tugdual]

Le vibe coding gagne du terrain, un tiers des développeurs seniors :

• affirment que plus de la moitié du code qu'ils livrent est généré par l'IA...

Extrait :

L'enquête menée en juillet 2025 par Fastly auprès de 791 développeurs a révélé une différence notable dans la quantité de code généré par l'IA qui est mis en production. Environ un tiers des développeurs seniors (plus de 10 ans d'expérience) déclarent que plus de la moitié du code qu'ils livrent est généré par l'IA, soit près de deux fois et demie le taux déclaré par les développeurs juniors (0 à 2 ans d'expérience), qui est de 13 %.

Pour de nombreuses personnes, le codage est synonyme de précision. Il s'agit de dire à un ordinateur ce qu'il doit faire et de faire en sorte que l'ordinateur exécute ces actions de manière exacte, précise et répétée. Avec l'essor d'outils d'IA tels que ChatGPT, il est désormais possible de décrire un programme en langage naturel (français par exemple) et de demander au modèle d'IA de le traduire en code fonctionnel sans jamais comprendre comment le code fonctionne.

Andrej Karpathy, ancien chercheur d'OpenAI, a récemment donné un nom à cette pratique, le « vibe coding », qui gagne du terrain dans les milieux technologiques (Google a même déclaré générer 25 % de son code par IA). Selon cette approche, le développeur ne révise ni ne modifie le code, mais utilise uniquement des outils et les résultats d'exécution pour l'évaluer et demande au LLM d'apporter des améliorations. Contrairement au codage assisté par l'IA ou à la programmation en binôme traditionnels, le développeur humain évite d'examiner le code, accepte les compléments suggérés par l'IA sans révision humaine et se concentre davantage sur l'expérimentation itérative que sur l'exactitude ou la structure du code.

[Tugdual]

Brian Kernighan, co-créateur d'Unix, s'exprime après avoir testé le langage Rust :

• « je ne pense pas qu'il va remplacer C tout de suite »...

Extrait :

Brian Kernighan a trouvé son expérience avec Rust « pénible ». Selon lui, les mécanismes imposés par Rust pour garantir la sécurité mémoire sont trop lourds, surtout dans un programme où la gestion de la mémoire n’était pas un problème majeur. Il décrit son unique essai comme « une douleur », et juge l’écosystème du langage — avec ses crates, sa complexité et la lenteur de la compilation — comme « incompréhensiblement vaste et lent ».

« Ohhh, Rust », a déclaré Brian Kernighan, sous les rires du public. « Je n'ai écrit qu'un seul programme en Rust, vous devez donc prendre tout cela avec beaucoup de recul. Et j'ai trouvé cela pénible. Je n'arrivais tout simplement pas à comprendre les mécanismes nécessaires pour assurer la sécurité de la mémoire, dans un programme où la mémoire n'était même pas un problème ! ». Sa plus grande critique semble concerner ses performances de Rust.

[Bubu]

Brian Kernighan, co-créateur d'Unix, s'exprime après avoir testé le langage Rust :

• « je ne pense pas qu'il va remplacer C tout de suite »...

Extrait :

Brian Kernighan a trouvé son expérience avec Rust « pénible ». Selon lui, les mécanismes imposés par Rust pour garantir la sécurité mémoire sont trop lourds, surtout dans un programme où la gestion de la mémoire n’était pas un problème majeur. Il décrit son unique essai comme « une douleur », et juge l’écosystème du langage — avec ses crates, sa complexité et la lenteur de la compilation — comme « incompréhensiblement vaste et lent ».

« Ohhh, Rust », a déclaré Brian Kernighan, sous les rires du public. « Je n'ai écrit qu'un seul programme en Rust, vous devez donc prendre tout cela avec beaucoup de recul. Et j'ai trouvé cela pénible. Je n'arrivais tout simplement pas à comprendre les mécanismes nécessaires pour assurer la sécurité de la mémoire, dans un programme où la mémoire n'était même pas un problème ! ». Sa plus grande critique semble concerner ses performances de Rust.

...et il y a encore pire : le SmallTalk. Inventé sur le coup d'un pari par un groupe de chercheurs tellement focalisés sur la théorie qu'ils en ont oublié le côté pratique.
La réponse pour répliquer quand on critique ce langage : Oui mais tout est objet.
Bien-sur que c'est vrai. Une classe est un objet elle-même, mais du coup c'est la poule avant l’œuf ou l'inverse ?
Puisque pour créer une instance d'objet, il faut bien sa classe. Mais une classe est elle-même un objet.
Pour rigoler : qui à pondu le premier œuf alors que les poules, n'éxistatient pas !
Même le code est objet. Par exemple on peut stocker du code dans une variable.
Mais la seule fois où j'ai rencontrée des obsédés du SmallTalk, c'est a la fac.
Dans le milieu professionnel, où du moins pour ceux qui place la performance de leur code comme prioritaire, c'est pas la peine.
Tant pis, on compile le code pour plusieurs plateformes à la fois. Le même code que l'on utilise quelque soit la plateforme. (A part la pomme pourrie qui persiste à rester coincée dans son coin et qui utilise comme le langage par défaut pour mobile l'Objectif C.)

Que ce soit pour Android (l'OS de Google), ou iPhone (l'OS de Apple), on peut programmer également en C++.
Mais à mon avis, ça doit forcément nécessiter un portage.

[Bubu]

Ben je subis une grosse déception : le multi render targeting que l'on apelle MRT, pour simplifier, n'existe toujours pars pour OpenGLES 2.0.
Le MRT.
L'objectif est de créer 3 textures, (la color map, la light map et la normal map) en même temps.

[Bubu]

Tout ce qui me motive encore, c'est d’améliorer ce qu'ont fait les autres.
C'est à dire de présenter un moteur d'affichage digne de ce nom et de moteur de jeu 2D. C'est tout. Mais c'est énorme.
La première chose c'est de savoir afficher des zones (plus tard fenètres). Une zone est dessous donc n'est pas prioritaire.

[Hydrean]

Tu travailles en Indé ?

[Bubu]

Tu travailles en Indé ?

Merci pour ta réponse. Mais oui, je code et publie en indé.
Je tiens ce projet sans contraintes extérieures, c'est pour le plaisir.
Donc mes sources sont libres et open-source.

Maintenant la difficulté va être de générer un rendu parfait, quelle que soit la profondeur exigée du rendu.
De base, j'utilise l'alpha blending classique, mais if faudra gérer l'émissive blending, qui consiste simplement à additionner au fond la nouvelle couleur.
Je vais être obligé de transformer la texture cible finale, en simple texture comme une autre.
Mon système d'AABB me permettra de générer et utiliser de manière optimale les différents rendus.

Tout va se jouer dans la méthode draw() :
(Déjà de base, ils seront triés du plus lointain au plus proche, et le reste en dépendra)
Il faudra énumérer les sprites en fonction de leur type de rendu. Si on a par exemple 100 sprites qui utilisent un seul rendu et qui se suivent, on les affichera grâce à un seul draw call.
En faisant comme je le pense pour l'instant, il n'y aura besoin que deux 2 shaders (rendus) différents, mais le normal mapping risque de mettre le bazar.

Ce qui me motive à persister dans cette façon de faire, c'est qu'on pourrait avoir une interface android plus intéressante, et des jeux bien plus attractifs bien sur.

[Tugdual]

Microsoft libère enfin :

• le code source du BASIC 6502...

Extrait :

Tapez “STORD0” dans un vieil émulateur Commodore et regardez ce qui se passe. Non, ce n’est pas une commande documentée mais bien un Easter egg planqué dans Microsoft BASIC depuis 1977.

Et si je vous parle de ça, c’est parce que j’ai une bonne nouvelle. En effet, Microsoft vient de libérer le code source de ce BASIC 6502 historique sous licence MIT. Quarante-sept ans après sa création donc, on peut enfin fouiller dans les entrailles du programme qui a fait tourner des millions de machines mythiques de l’ère 8-bits. Et croyez-moi, c’est une mine d’or pour comprendre comment deux jeunes de 20 ans ont posé les fondations de ce qui deviendrait plus tard, le plus gros empire logiciel de la planète.

[...]

Ce qui est fou, c’est quand même de réaliser que ce petit bout de code a généré une industrie de plusieurs trilliards de dollars. Sans ce BASIC 6502, pas de Commodore 64 (la machine la plus vendue de l’histoire), pas d’Apple II tel qu’on le connaît, pas de génération de programmeurs formés dans les années 80. Microsoft aurait peut-être mis la clé sous la porte sans ces revenus initiaux et l’histoire de l’informatique personnelle aurait été complètement différente.

[...]

Alors oui, c’est juste du vieux code. Mais c’est LE vieux code. Celui qui a permis à une génération entière de découvrir la programmation. Celui qui a transformé Microsoft de startup dans un garage en empire mondial. Celui qui cache encore, 47 ans plus tard, des Easter eggs et des secrets.