Arkanoid - Page 15

Pourquoi faire du triple buffering?

Parce que si tu tournes à 70 fps, ça risque de ralentir pas mal ton moteur de faire de la copie à chaque fois... (typiquement, presque 25% du proc puisque les routines de gray qui font 1 plan à 90 fps bouffent un peu moins de 20% de 10 MHz sur une HW2, donc 2 plans à 70 fps vont bouffer 30% des 10 MHz qui vont te rester sur les deux HW).

Je vois. Tu me conseil quoi à part le tripple buffering? Au fait je ne tourne plus à 70 fps mais à 60 fps et c'est variable de 55 à 65 fps.

Le triple buffering, aussi Qu'est-ce que tu verrais d'autres?

Lol, rien d'autre.

Bon j'ai réalisé les animations des briques et ça rend bien, par contre y a pas un moyen de rendre l'écran un peu plus stable car quand le niveau est affiché l'écran est assez foncé et quand les briques disparaissent petit à petit l'écran s'éclaircie. GrayAdjust peut être utile dans ce cas?

De plus quand le scrolling est en action, tout ce qui est foncé à tendance à ce cacher facilement avec le blanc et le gris clair.

Ben oui, c'est les risques du scrolling On peut pas dire que t'avais pas été prévenu.

lol, ça n'a aucun rapport avec le scrolling les problèmes que je vient de citer.
Y a peu être des améliorations à fournir.

Je ne parle pas des discussions récentes, je parle des tous premiers posts où je trouvais que faire un scrolling pour un casse-brique, c'est se faire chier pour pas grand chose et que ça va surtout pas être très pratique...

Bien rattrapé.

J'ai déjà fait une tentative qui a échoué, l'écran est trop petit donc j'ai fait avec du scrolling et j'ai pensais comment le réaliser. Ca sera vraiment plus pratique que tu ne le pense et très jouable. (je rappel que le scrolling suivant x est presque inexistant et que les briques ne commenceront pas près de la raquette et de plus le scrolling suivant y laissera le temps de récuprer la bille...

Bien rattrapé.

...

Ca sera vraiment plus pratique que tu ne le pense et très jouable. (je rappel que le scrolling suivant x est presque inexistant et que les briques ne commenceront pas près de la raquette et de plus le scrolling suivant y laissera le temps de récuprer la bille...

Pas sur 89... Et tu oublies le cas où il y a plusieurs billes.

Mais le cas où il y a plusieurs bille l'écran ne scrollera pas sauf avec la raquette.

le fait que l'ecran soit ombre vient en partie du scrolling...

Je dirais qu'il ne devient pas sombre, c'est la partie sombre qui ce confondent avec les parties claire.

Au fait TIMad tu procede comment pour faire varier la vitesse de la bille?

bein tu rajoutes un vecteur vitesse

Je ne demande pas ça, je veux juste savoir si tu fais par l'intermédiaire d'une interruption ou tu cherche le coefficient que tu met devant cos et sin pour ta fonction de mise à jours de la positiion de la bille.

bein ca me semble pas tres compliqué, il te faut une unité de temps, donc une synchronisation.
apres le reste si tu vois pas..

Le problème c'est que je veux éviter d'utiliser une interruption et trouver un moyen d'avoir une fonction qui me donne des cooefficient correct.

Théroqiuement je ne peux mettre à jours que 60 fois par seconde les positions des billes et ce dans la boucle principal donc il faut que je trouve le moyen qu'une fonction me donne le coefficient correct et met à jours la positions des billes.

Si la vitesse est de 60 le coefficient pendant 60 passages sera à 1
Si la vitesse est de 120 le coefficient pendant 60 passages sera à 2
Si la vitesse est de 180 le coefficient pendant 60 passages sera à 3

Reste les intermédiares.

J'ai donc pensé à réaliser un compteur qui s'incrémente de 60/speed*32768. Si lors d'une mise à jours de positions de billes il est inférieur à 32768 alors le coeffcient sera de compteur/32768 sinon le compteur sera soustrait de 32768 et le coefficient sera de 1.

Et mince ça fonctionne à moitié de temps en temps j'obtient de coeefficent énorme de 10.

tu utilises deja une int pour les gray c quand meme pas compliqué de faire un hack des gray pour te servir de sa synchronisation (suffit d'externalisé une var si mes souvenir sont bon)

lol, suffit juste de rediriger l'auto int 1.

Mais faire ça dans une interruption si source de bugs énorme pour mon programme, imagine que je détecte une collisions puis vient l'interruption qui change le coefficient de vitesse de la bille puis je revient à la detection de collision qui devient fausse. J'ai déjà essayé et ça bug horriblement, les collisions ne sont plus respecté.

Et quand je pose ce genre de question c'est que j'ai déjà essayé avant de poser la question.

geogeo
: Reste les intermédiares.

Tu fais comme dans PolySnd (ou plutôt comme je t'ai dit de faire pour PolySnd, parce que ce n'est pas toi qui as trouvé et ça se voit ). C'est exactement le même problème, avec exactement la même solution.

pt1 on entend vraiment n'importe quoi...

Tu fais comme dans PolySnd (ou plutôt comme je t'ai dit de faire pour PolySnd, parce que ce n'est pas toi qui as trouvé et ça se voit ). C'est exactement le même problème, avec exactement la même solution.

C'est ce que je fais Kevin mais ce n'est pas parfait, je vais trouver le problème et le corriger.

Enfin corrigé et enfin de compte j'ai pris l'auto int n°1!

J'ai changé le premier décors car il passe vraiment pas. J'ai ajouté une fonction de modification de la vitesse de la bille, les Billes auront un sprite unique de taille unique.
J'ai ajouté les gestions des briques en acier et leur animations. Et enfin ajouté le sprite de scores à droite.

Hum, il faut scroller pour voir son score ?

oué
(mais il a pas voulu comprendre quand je lui ait dit que c'était pas un bon systeme...)

c'est n'importe quoi surtout, l'interet du scrolling est totalement artificiel ds ce cas là

Hum, il faut scroller pour voir son score ?

OK alors donne moi une meilleur idée.

oué (mais il a pas voulu comprendre quand je lui ait dit que c'était pas un bon systeme...)

Tu verrais quoi????