[Index Software] Coin des développeurs :]

[Bubu]

L'état mourir est déclenché si Mario lui tombe dessus.
Les deux états aller vers la droite 1 et 2 (animation quand il avance) sont juste enchainés en fonction du temps.
Pareil pour la gauche.
Et ainsi de suite.

C'est pas quand il touche un mur?

Quand il touche un mur, il change de direction.
La succession droite1 droite2 devient gauche1 gauche2, et vice-versa.

J'implémente ça souvent en utilisant des enum pour les différents états.
Et je gère chaque état dans un switch

Là, ça pourrait être, si je ne me trompe pas.

EtatChampignon {droite1, droite2, gauche1, gauche2, tomber, mourir}

switch (etatChampignon) {
cas droite1 :
si collision, gauche1
sinon droite2 après un délai
avancer un peu vers la droite.
s'il est hors champ, le réinitialiser en position et état
si vide en dessous, état tomber

cas droite2 :
si collision, gauche2
sinon droite1 après un délai
avancer un peu vers la droite.
s'il est hors champ, le réinitialiser en position et état
si vide en dessous, état tomber

cas gauche1 :
cas gauche 2 :
l'inverse respectif de droite1 et droite2

cas tomber :
baisser verticalement un peu.
si hors de l'écran, réinitialiser position et état.

cas mourir :
retourner le sprite, et baisser verticalement.
s'il sort de l'écran, supprimer l'automate
}

quelque soit l'état courant, si Mario détecte une collision avec lui vers le bas, mettre état mourir
quelque soit l'état courant, si Mario détecte une collision avec lui sur les cotés ou vers le haut, Mario passe en état mourir, ce qui déclenche la fin de la partie.
(L'état initial dépend de sa position relative à celle de Mario, pour qu'il s'en rapproche)

Les changements de position sont proportionnels au temps écoulé depuis la dernière frame. (Codés sous forme de vitesse, et parfois d'accélération)

Après c'est approximatif, hein, c'est plus pour donner l'idée qu'autre chose, car tomber il y a 4 états aussi. Car il continue d'avancer en tombant et à être animé. (Entre autres que j'oublie surement)

Après on pourrait aussi faire un automate pour changer les sprites, et un autre pour changer le comportement.

Ensuite il faut paramétrer l'automate. Régler ses vitesses, ses accélérations et ses délais d'attente.

[Benoit]

On mesure le temps écoulé. Parfois jusqu'à la nanoseconde près, mais dans les jeux, la milliseconde est largement suffisamment précise.

Je ne crois pas qu'ils vont compter les cycles processeurs (seul moyen d etre precis a la nano) dans les jeux en general.
En tout cas j'espere.

[Bubu]

On mesure le temps écoulé. Parfois jusqu'à la nanoseconde près, mais dans les jeux, la milliseconde est largement suffisamment précise.

Je ne crois pas qu'ils vont compter les cycles processeurs (seul moyen d etre precis a la nano) dans les jeux en general.
En tout cas j'espere.

Non non .
Il y a des fonctions toutes faites pour ça.
De souvenir, en C++ sous Windows il y a deux fonctions pour ça.
Une précise à la nanoseconde, une autre à la milliseconde.

Sous Java, il y a System.currentTimeMillis(). Par des différences on déduit le temps écoulé.
Elle renvoie un entier (long), exprimé en millisecondes.

Code C++ pour Windows :
______________________________________________________________________________________________

#pragma once

class Chrono
{
protected:
double t;

double getTime()
{
__int64 count,freq;
QueryPerformanceCounter((LARGE_INTEGER *)&count);
QueryPerformanceFrequency((LARGE_INTEGER *)&freq);
return double(count)/double(freq);
}

public:
Chrono(void)
{
reset();
}

void reset(const double time=0.0)
{
t=getTime()-time;
}

double time()
{
return getTime()-t;
}

~Chrono(void)
{}
};
____________________________________________________________________________________________________________
Ce code est précis au cycle processeur près.
Par contre j'aurais dû typer count et freq directement LARGE_INTEGER au lieu de faire un cast. (Dynamique en plus .... )

[Benoit]

Puisqu'on est sur le fil des devs. il y a un moyen d'installer des packages python offine avec pip ou conda ? (en les telechargeant a la main).

J'ai affaire a un proxy tres peu cooperatif qui refuse de faire passer les requetes. (Et je dois livrer un truc a un dizaine d'utilisateurs derriere le proxy).

[philigram]

J'ai travaillé sur des jeux dans les années 2000. Il n'y a pas eu que la programmation séquentielle d'utilisée.
Quand j'ai commencé, dans les années 90, les développeurs codaient encore en assembleur. Ce fut difficile de les déloger et de les faire passer rien qu'en C.

Au départ, les codeurs, féru d'asm, continuaient à coder en utilisant malgré tout les nouvelles fonctionnalités de processeurs. Ils ont été assez vite dégouté de constater que leur code était moins performant que le simple compilateur C.
A l'arrivée de C++, des Thread, ils ont découvert qu'on pouvait développer autrement. On a pas mal utilisé la programmation multi-thread surtout sur des jeux d'aventure.

On a développé en événementiel. Des objets (personnages par exemple ou voitures) pouvaient être de objets au sens programmation objet.
Certains communiqués via des sockets, ou simplement par mémoire partagée.

Au début, j'ai travaillé sur un jeu de bagnole et là c'était une seule boucle infinie. Au début ce fut compliqué car les modèles étaient trop lourds et entre 2 frames pas moyen de caser les calculs, surtout que la 3D était gérer par logiciel (facettes, texturage, ombres ...). Il a fallu alléger pour éviter les saccades.
Le problème, et je râlais pour cela, est qu'on développé sur les machines dernières générations. Ainsi il fallait prévoir des modes dégradé car pas mal de joueurs n'avaient pas le matos suffisant.

[Bubu]

Le multi-tâche est essentiel dans les jeux, c'est clair.
Mais en général, ce n'est pas pour avoir plusieurs choses en même temps qui bougent, évoluent.

Les tâches sont trop simples et rapides à ce niveau, et au contraire on perdrait en performances à cause des mécanismes de synchronisation (mutexes, sémaphores et sections critiques).
C'est en général réservé aux taches lourdes et parallélisables. Comme des tris d'entités du fond vers le premier plan pour le rendu transparent (translucide en fait), ou des choses comme ça. Ce n'est qu'un exemple.


On ne s'en sert pas pour les choses visibles et simples qui se passent en même temps, en parallèle. C'est un paradoxe.
En entrée de rendu de frame, on a le temps écoulé, et on avance pas à pas tous les automates en fonction de ce temps.
C'est beaucoup plus performant que de passer par l'ordonnanceur système, s'il y en a un (!)

EDIT :
Mais rien n'empêche d'utiliser le multi-tâche pour mettre à jour les automates en parallèle, mais par groupes.
On peut regarder combien il y a de processeurs (de cœurs) et diviser le groupe d'automates en autant qu'il y a de cœurs, et de mettre à jour chaque groupe sur un cœur différent.

[Bubu]

Il ne faut pas prendre cet exemple personnel pour un conseil
Dans notre jeu, tout est fait dans un seul thread.

A part le chargement, l'appli et OpenGL. Un thread pour chaque. De toute façon je n'ai pas le choix. C'est l'architecture même d'Android qui décide.

Pendant que l'appli se charge, j'affiche une simple animation en parallèle.
Et au contraire, je gère toutes les interactions de l'appli sur le thread de rendu.
Comme ça je n'ai pas de problème de synchronisation de threads.
Et c'est recommandé.

Mais le jeu, juste lui, est géré par un seul thread.
Que ce soient les animations décoratives, ou le cœur du jeu, c'est le même thread qui fait tout, le thread de rendu.
Quand un événement est créé dans l'appli, je l’exécute sur le thread de rendu.

[Tugdual]

Même chez Apple, ça ronchonne sur les open-space :

• Apple Park : certains employés d'Apple ne seraient pas ravis de l'option open space ...

[arius]

Même chez Apple, ça ronchonne sur les open-space :

• Apple Park : certains employés d'Apple ne seraient pas ravis de l'option open space ...

Je ne comprends vraiment pas pourquoi

[Bubu]

C'est une mode les open-spaces il faut croire.
Ils s'imaginent quoi ?
Entendre les autres palabrer, entendre les cliquetis de leurs claviers, va augmenter notre créativité ou productivité ? Sérieusement ?
Vive les bureaux fermés.
Au moins on décide avec qui, et quand communiquer.
Sinon, on se croirait dans un réfectoire ! Ou à spéculer en bourse.

N'importe nawak !

[philigram]

La raison des openspace est uniquement économique. Ça revient moins cher au m2. On installe plsu de monde au m2 et c'est plus souple, et donc demande moins de frais logistique.
Après le génie de nos élites est de persuader les plus influençables, les jeunes sortie de l'école, que cela fait djeun, sympa, conviviable et que ça booste la créativité tout en fluidifiant la communication.
Pour avoir travailler en openspace, c'est tout le contraire. On finit par mettre un casque, NTs et autistes, ou déconner si il y a une bonne ambiance.
Alors certaines boites, on trouver le truc : mettre le responsable aussi en openspace.
Et chacun finit par espionner l'autre.

[Bubu]

Ils devraient peut-être laisser les bureaux indépendants, mais favoriser les communications pendant les pauses,
en créant un "Café" ou l'on peut se rejoindre.
Dire : Tiens gros, j'ai une idée, on se retrouve au café dans 5 minutes ?

[Bubu]

Même chez Apple, ça ronchonne sur les open-space :

• Apple Park : certains employés d'Apple ne seraient pas ravis de l'option open space ...

Les open-spaces, pour les développeurs,
c'est comme
Les batteries, pour les poules pondeuses.

[arius]

Même chez Apple, ça ronchonne sur les open-space :

• Apple Park : certains employés d'Apple ne seraient pas ravis de l'option open space ...

Les open-spaces, pour les développeurs,
c'est comme
Les batteries, pour les poules pondeuses.

ça dure plus longtemps?

[Bubu]

Bah quand elles ne peuvent plus pondre, on les fout à la casse. (Cuisses de poules etc). Ils recyclent.
Pour les développeurs, s'ils ne sont plus assez productifs, c'est pareil : on les fout à la casse (au chômage). Ils recyclent.