1770

iwannabear (./1769) :
non mais justement c'est pas de temps de reaction que je parle, pas dans le sens "tu reagis a un stimuli", mais de timing. tu peux tres bien mettre 0.1 secondes a reagir a un stimuli, mais c'est pas pour autant que t'aura une granularite de 0.1 secondes pour declencher un evenement 0.85 secondes precisement apres le dit stimuli. tu vois ce que je veux dire? ou declencher deux evenements tres proches l'un de l'autre (genre cliquer sur le bouton droit et gauche quasi-simultanement, a un intervalle extremement proche, style 0.02 secondes) ce n'est pas une question de vitesse de reaction a un evenement externe.
Ah ok, la vitesse d'enchaînement des actions ? Compris chef smile
http://www.humanbenchmark.com/tests/reactiontime/stats.php
trilove
(Quelle surprise, j'ai un temps de réaction de merde grin)
bon pour le coup de wow, je vois pas trop comment un fixed timestep changerait quoi que ce soit grin (et surtout, il y a tres fortement moyen que le serveur tourne deja en fixed timestep, a un framerate extremement bas, genre 20 fps) du point de vue du serveur
En fait le serveur n'a même rien à voir là dedans (énormément de trucs sont gérés côté client… le serveur ne vérifie même pas grand chose à ce que le client lui envoie…).
Disons que normalement, après avoir "téléporté" magiquement le personnage super bas par un calcul d'intervalle de temps très long, la moindre des choses serait de le remonter.
Si j'interprète bien ce que je vois, leur algorithme est à peu près "si joueur_py < niveau de l'eau alors joueur_vy = 0 et joueur_ay = 0" mais testé après le test de si le joueur est en dessous du décor. En fixed timestep tu ne peux jamais déplacer le joueur de plus de N unités, donc même cette implémentation simpliste ne peut jamais beaucoup t'éloigner de la surface de l'eau, contrairement à ce qui se passe en réalité sad
(Bon tu pourrais malgré tout quand même mourir dans les flaques d'eau mais ça je crois que c'est un peu normal grin)
avatar
Le scénario de notre univers a été rédigée par un bataillon de singes savants. Tout s'explique enfin.
T'as un problème ? Tu veux un bonbon ?
[CrystalMPQ] C# MPQ Library/Tools - [CrystalBoy] C# GB Emulator - [Monoxide] C# OSX library - M68k Opcodes

1771

Folco, lis ça: http://www.koonsolo.com/news/dewitters-gameloop/
[Edit] Loupé une page, je faisais référence à ./1740.
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

1772

iwannabeamaki (./1763) :
Bon, je réponds demain parceque j'ai pas le temps ce soir, mais rien qu'à lire ça :
Si tu fais un trop long saut, tu risques de traverser des objets sans collisions pas vrai ?

tu n'as manifestement jamais codé de jeu grin (si tu testes juste qu'à un instant T les objets sont en collision, tu risques effectivement d'en rater pas mal, framerate contrôlé ou pas)

Je connais, j'ai été des deux côtés de ce problème en jouant à Command & Conquer 2. Ce n'est que des années plus tard que je me suis dit que ça devait être pour cette raison que les missiles du Nod traversaient les murs Tempête de feu du GDI...

Pour éviter ça dans un truc à moi, j'avais eu l'idée de faire une détection plus poussée permettant de séparer une étape de calcul en deux (ou plus) si une collision était détectée au beau milieu. Par contre, je bossais sur une balle rebondissant sur le sol, donc c'était plus facile à vérifier qu'une collision entre deux objets...
avatar
Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.

1773

Le plus fiable reste quand même de considérer qu'une collision est un évènement dynamique. On ne teste pas si à T0 les objets A et B "sont en collision", puisque si par malheur d'une frame à l'autre ils se sont complètement traversés, on ne détectera rien. D'ailleurs on ne vérifierait pas une collision avec ce type de test, on vérifierait que les objets sont superposés, ce qui n'est pas tout à fait pareil. Il vaut mieux vérifier, par exemple, qu'entre T0 et T1 les objets se sont croisés, et là on est à peu près certain que du coup entre ces deux frames une collision a eu lieu (il ne reste plus qu'à calculer exactement à quel instant elle a eu lieu, mais on a toutes les valeurs nécessaires pour ça).

(du coup flemme de répondre à GC, de toutes façons c'est pas moi qui vais pouvoir ajouter qqchose à ce qu'a déjà dit iwannabear ^^)
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

1774

C'est précisément ce que je voulais dire. Mais dans mon raisonnement, une fois trouvé quand la collision a lieu, on fait les calculs sur le delta qui a mené à cette collision, puis sur le reste du delta (parce que la collision change ce qui se passe après, y compris les collisions futures).
avatar
Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.

1775

Pour Sonic j'avais dû mettre une vitesse maximale (en gros je faisais des calculs pour m'assurer que mes algos de collision étaient fiables à 16px/frame). Puis après on peut faire sauter la limite dans certains cas comme dans l'original (quand on va vraiment très vite) puis après on se retrouve dans des cas où on est coincé dans les décors, comme l'original grin
(Une autre solution aurait été de faire tourner 2x le moteur de collision par frame si la vitesse est très élevée)
avatar
Highway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

1776

Brunni (./1775) :
Pour Sonic j'avais dû mettre une vitesse maximale (en gros je faisais des calculs pour m'assurer que mes algos de collision étaient fiables à 16px/frame).

J'avai implémenté ça dans mon moteur. Puis un truc plus générique, en faisant les calculs pour les déplacements modulo 16 :
20 px de déplacement => un calcul pour le déplacement de 16 px, puis un second calcul pour un déplacement de 4 px.

J'ai peur de consommer fort en ressource avec une détection exacte : si j'ai un bloc de 16*16px, je devrais calculer si le segment de déplacement du perso (en fait, son vecteur de déplacement appliqué à sa position) vient intersecter un des 4 segments de mon bloc 16*16. C'est simple à faire en maths bien sûr, mais je ne sais pas comment optimiser pour ne pas calculer des intersections éventuelles avec des blocs de l'autre bout de la map qu'on ne risque absolument pas de traverser.

1777

Ya un truc que j'arrive pas à faire, bien que ça me paraisse tout con...

J'ai un objet O1 global au programme, qui contient un autre objet O2.

D'après valgrind, le destructeur de O1 est bien appelé à la sortie du programme, mais il n'appelle pas le destructeur de O2 (dixit valgrind aussi, je leak à ce niveau).
Comment faire ? Parait que saylemal d'appeler le destructeur d'un objet à la main, et pourtant ce fichu O2 faudrait bien qu'il soit détruit quelque part...

Evidemment, je pourrais n'avoir qu'un pointeur vers O2 dans O1, faire instancier et détruire O2 par le constructeur et destructeur de O1, mais ma méthode initiale ne marche pas du tout ?


---

tiens, je pense du coup que mon constructeur de O2 n'est pas appelé en fait, même si ça se voit pas dans le programme

1778

tu n'as rien à changer, ça devrait fonctionner comme ça. tu ad essayé de mettre un point d"arrêt dans les destructeurs de O1 et O2 pour voir s'ils sont bien appelés ? (plutôt que se baser sur les dires de Valgrind)
est ce que tu peux aussi poster un peu de code pour illustrer ?
avatar

1779

Je me souviens avoir mis un std::cout pour vérifier mon constructeur, il semblait appelé. Pas le destructeur, j'en suis certain. Je vais re-vérifier et poster du code. Merci bien. smile

1780

Attention, d'après les test que j'avais fait avec GDB il y a un moment, les points d'arrets dans les constructeurs et destructeurs ne fonctionnaient pas. Je ne sais pas si ça a été corrigé depuis
avatar

1781

Mais même un std::cout ne fonctionne pas ? En tout cas, il devrait m'afficher "pwet", il ne le fait pas, j'en conclue que mon destructeur n'est pas appelé.
Et en fait j'ai amalgamé deux cas dans mon exemple, ce n'est pas exactement ça mon problème. J'y reviendrai car je n'arrive pas à la solutionner...

ps : j'utilise GDB 7.2

1782

(GDB en ligne de commande ?? geek)

1783

ben quoi?

gdb binaire
run arg1 arg2
break main
run
continue
step
next
list
print

c'est quand même pas stallmanien.

1784

Non non, GDB via codeblocks grin

1785

cross

Devoir écrire step ou next pour avancer, c'est super pratique en effet \o/ (enfin c'est pas exclu qu'il y ait des raccourcis, mais bon grin)
Insight est quand même un peu plus sympa, non ? #modfus#

./1784 ahhh, quand même grin

1786

Y a des raccourcis (b pour un breakpoint, n pour next, c pour continue, etc.)
avatar
<<< Kernel Extremis©®™ >>> et Inventeur de la différence administratif/judiciaire ! (©Yoshi Noir)

<Vertyos> un poil plus mais elle suce bien quand même la mienne ^^
<Sabrina`> tinkiete flan c juste qu'ils sont jaloux que je te trouve aussi appétissant

1787

oui. Et insight sux par rapport à codeblocks.

1788

Folco (./1781) :
Mais même un std::cout ne fonctionne pas ? En tout cas, il devrait m'afficher "pwet", il ne le fait pas, j'en conclue que mon destructeur n'est pas appelé.
Non en effet c'était relatif à la remarque d'aze qui préconisait de mettre un point d'arrêt.
Une écriture sur std::cout devrait fonctionner sans problème.
avatar

1789

'tain mais vous vous prenez vraiment la tête pour faire vos jeux vous cheeky
unsigned short go_left(unsigned char powa)
{
        do
        {      if(can_mario_left())        mario.pos_x-- ;
                else                               return 0 ;
        } while(powa--) ;
        return 1 ;
}
après tu met en place un nb de pixel/seconde à ton perso, et on s'en tape du framerate, il doit bouger de 20px d'un coup bah tu fait go_left(20); et il la ratera pas la plateforme, même à 2 fps happy
et la le mec il le pécho par le bras et il lui dit '

1790

squalyl (./1787) :
oui. Et insight sux par rapport à codeblocks.
Je ne sais pas (mais bon, codeblocks c'est un IDE complet, non ?)

1791

r043v (./1789) :
tu mets en place un nb de pixel/seconde à ton perso, et on s'en tape du framerate, il doit bouger de 20px d'un coup bah tu fait go_left(20); et il la ratera pas la plateforme, même à 2 fps happy

Le problème, c'est qu'il est plus facile d'obtenir des frames que des secondes.
avatar
Maintenant j'ai la flemme de garder une signature à jour sur ce site. Je n'ai même plus ma chaîne Exec sous la main.

1792

bah forcément ca t'oblige à faire des calculs soit à chaque frame, soit si la précision n'est pas super importante, à chaque seconde par exemple, pour savoir ou tu en est et réadapter la vitesse en conséquence

par exemple, la ca recalcule la vitesse à chaque seconde, ce qui explique le coup de speed au démarrage ou les 'saccades' malgré le gros fps (surtout en full screen ou il change bc), bon après sur les vieux système comme win2k ou je l'ai développé il y avais moins de fps donc c'etais moins flagrant, mais ca ma permis de pouvoir faire augmenter la vitesse du bg et du perso de manière totalement indépendante du fps (haut et bas change la vitesse edit: espace met un sleep(1) donc te bloque vers les 60/65 fps)
et la le mec il le pécho par le bras et il lui dit '

1793

1kJL embarrassed
et la le mec il le pécho par le bras et il lui dit '

1794

si personne me répond je devrais me remettre un point de la loose :/

je pourrais peu être me le mettre en avatar ce serais plus simple embarrassed
et la le mec il le pécho par le bras et il lui dit '

1795

1796

(j'ai pas trop vu ou etait la question a laquelle t'attend une reponse en fait trifus)
avatar
HURRRR !

1797

1798

hehe

1799

trilove

non il n'y avais pas de question mais j'attendais du clash me disant 'put*in tu parle de contrôle du fps et ton truc est tellement pas con-trollé que je ne peu commencer à jouer xD'
et la le mec il le pécho par le bras et il lui dit '