Discussion :

[otspot]

Bonjour

Dans le cadre d'un projet je dois programmer un mario like, mes questions (yen aura surement d'autres) portent sur le scrolling de l'arriere plan.

Pensez vous qu'il vaut mieux charger une seule et grande image qui contient tout le niveau ou vaut il mieux fait un meme background et le faire tourner en boucle?

Pour faire tourner en boule le background, quelle est selon vous la bonne méthode a suivre.

sachant que mes sprites sont des images 20*20, pour faire le scrolling, faut il en faire un de 1 pixel a chaque fois, ou a chaque fois qu'il faut faire du scrolling en faire un de 5 10 ou 20pixels. Quand j'en fais un de 1pixel a chaque fois, c'est très lent.

Merci pour votre aide

[fearyourself]

Normalement, il vaut mieux avoir une grande texture qu'on fait boucler

Donc c'est un mélange des deux propositions. On voit généralement une texture deux fois plus large que la fenêtre.


Pour la question de rapidité, cela ne devrait pas changer quelque chose. Tu as ta grande texture, tu fais le rendu. Je pense que toi, tu t'amuses à faire un rendu complexe du fond à chaque itération. Il faut faire un prérendu de l'arrière plan (ou le mettre dans un fichier) pour ne faire que le calcul au début du niveau et ensuite une seule copie par itération.

Jc

[bogoss91]

Pensez vous qu'il vaut mieux charger une seule et grande image qui contient tout le niveau

Si le niveau est très grand, t'aura besoin de garder une image très grande en mémoire, et ça devient problématique...

[otspot]

Oui, donc il faut prendre une image qui fait deux fois celle de l'écran (quelle en est l'interet?).
Et après, comment je fais pour boucler? Je comprend pas comment résoudre mon problème avec ta méthode.

Faut dire que en plus, la librairie graphique que je suis obligé d'utiliser manque de fonctions,
exp: pas de fcts pour selectionner une partie d'une image (donc exit les 100 sprites sur une meme image).
J'ai juste des fonctions pour charger une image et la coller en (x,y).


Merci

[otspot]

Bon, je viens de reprogrammer ma fonction, en suivant le tuto sur le scrolling avec sdl, et ca marche merci!!!

J'ai une autre question cependant, l'auteur fait un scrolling de 2pixels a chaque fois, dans un jeu de plateforme c'est un pixel a chaque fois ou plusieurs???

Merci

[Polyfructol]

Ça varie, et ça dépend de la vitesse du scrolling et des FPS.

D'ailleurs il vaut mieux penser en secondes : "scrolling de 100 pixel par seconde" plutôt que "10 pixels par frame"

[otspot]

Ça varie, et ça dépend de la vitesse du scrolling et des FPS.

D'ailleurs il vaut mieux penser en secondes : "scrolling de 100 pixel par seconde" plutôt que "10 pixels par frame"

Oui mais dans ce cas la, c'est pas le joueur qui controle le scrolling (en se deplacant), si????

Je fais pas le lien entre les secondes, et le deplacement, (en écrivant ces deux derniers mots, je viens de me rappeler que la vitesse c'est la derivée du deplacement par rapport au temps) mais je suppose que ce n'est pas ce que tu veux dire.

[bogoss91]

J'ai une autre question cependant, l'auteur fait un scrolling de 2pixels a chaque fois, dans un jeu de plateforme c'est un pixel a chaque fois ou plusieurs???

Merci

Ben ça dépend de l'impression que tu veux donner.

Si tu veux faire penser qu'il est loin (comme des lointaines montagnes), tu peux le faire bouger d'un pixel tous les 100 pixel que ton perso avance.

Par contre si tu veux faire penser qu'il est proche (comme un mur d'un donjon), tu peux le faire bouger d'un pixel tous les 10 pixel que ton perso franchis.

[Polyfructol]

Oui mais dans ce cas la, c'est pas le joueur qui controle le scrolling (en se deplacant), si????.

Si bien sûr, je tente aussi de développer un jeu de plateforme, et l'unité de vitesse de mon personnage est le pixel/seconde.

Un exemple simple, lors de la marche le perso se déplace à 100px/s.

En prérequis il faut pouvoir récupérer la durée du rendu de l'image.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
// Initialisation
float x = 0; // Position du joueur
float speed_x = 100; //vitesse
float delta; // Pour stocker le temps (en milliseconde)
// Il faut gérer l'accélération aussi, mais c'est pas obligatoire
// Sans accélération, il n'y a pas de transition entre la marche et l'arrêt
 
// Puis, à chaque boucle
temps_ancien = temps_actuel;
temps_actuel = get_time();
delta = (temps_actuel - temp_ancien) * 1000; // Récupération du temps de création de l'image, * 1000 pour l'avoir en seconde
 
if (marche_a_droite)
    x += speed_x * delta;
else if (marche_a_gauche)
    x -= speed_x * delta;

Alors prenons pour exemple que l'image ait mit 0.016 secondes pour se générer (environ 60 FPS).
x est donc incrémenté de 0.016 * 100 soit 1.6 pixel par image. Donc en 60 images, on aura avancé de 100 pixels. Si le rafraichissement avait était de 30FPS (sur une vielle machine), on aurait avancer de 3.2 px/s, au final on aurait parcouru la même distance sur la même durée.

Bon ça c'est pour le déplacement du personnage, sur les coordonnées de la map et non sur l'écran (logiquement le personnage reste dans la zone centrale de l'écran).

Ensuite pour le scrolling, on utilise une camera (elle correspond à la position de l'écran), qui va se déplacer sur la map, en fonction de la position du héro.
Par exemple, si le personnage a pour coordonnée x = 1500, la camera aura pour x_cam = 1000. Donc à l'écran, le personnage aura pour coordonné x_screen = 500 (que tu utilisera dans la fonction d'affichage).



(Une petite illustration qui j'espère aidera).

Bon voilà, y'a encore des choses à approfondir(gravité, y, accélération), mais en cherchant "scrolling" sur le net, tu devrais tomber sur des choses de ce genre.

Pour la vitesse du background, comme le dit bogoss91, tu peux la varier, moi elle correspond habituellement à 0.5 fois la vitesse du joueur.

[otspot]

Ok, je commence à comprendre mais il me faudra du temps pour digérer ca, et ensuite pour le programmer.

Mais j'ai encore une question, concernant l'affichage, je sais qu'il faudra afficher l'image à chaque passage dans la boucle , mais laquelle afficher? et a quelle moment? Je pars du principe que j'ai 4images pour chaque animation(marche par ex), comment faire pour ne pas avoir l'impression que mario a les jambes qui brulent si je change d'image a chaque fois. Peut etre que c'est ca la solution, ne pas changer l'image a chaque fois.

Polyfructol, t'en ai ou dans ton jeu??

Merci pour vos conseils.

[Polyfructol]

Salut otspot,

Mais j'ai encore une question, concernant l'affichage, je sais qu'il faudra afficher l'image à chaque passage dans la boucle , mais laquelle afficher? et a quelle moment?

Le plus classique est de faire un tableau qui contient toutes les images et leurs positions (en objet, je stocke les sprites dans un vector), et à chaque boucle de rendu il faudra tout simplement toutes les afficher (ou du moins toutes celles qui sont dans la zone de la camera).

Je pars du principe que j'ai 4images pour chaque animation(marche par ex), comment faire pour ne pas avoir l'impression que mario a les jambes qui brulent si je change d'image a chaque fois. Peut etre que c'est ca la solution, ne pas changer l'image a chaque fois.

Pour les animations, il faut gérer un timer, et, toutes les X ms, changer d'animation.

Polyfructol, t'en ai ou dans ton jeu??

J'en suis à recommencer tout à zero , la première démo que j'avais fait était plutôt un mélange de procédural et d'objet, codée à l'arrache, sorte d'expérimentation. Je refait tout au propre pour faire quelque chose de plus solide et plus évolutif, fini en mai je l'espère.

[Sixissor]

Un truc facile que tu pourrais faire c'est incrémenter ou décrémenter tes coordonnées de texture de l'arrière plan sur l'axe horizontal ou vertical, dépendant de tes déplacements, avec des bornes, dépendant de la taille de la map.
Ca pourrait faire un scrolling pas mal.

Ex:
glTexCoord2f(0 + i, 0); glVertex2i(-1, -1);
glTexCoord2f(0 + i, 1); glVertex2i(-1, 1);
glTexCoord2f(1 + i, 1); glVertex2i(1, 1);
glTexCoord2f(1 + i, 0); glVertex2i(1, -1);
i += 0.1;

Ou des choses dans ce style.

[otspot]

merci sixissor, mais le scrolling marche sans problème.

Une nouvelle question, je vous avais prévenu qu'il yen aura beaucoup, le SAUT, j'ai programmé un truc qui marche en utilisant les fonctions de la physique (jet de projectile), mais j'ai l'impression que ca donne un effet bizarre quand le joueur se met a se deplacer en plein saut.
Y'a t il une solution connue, ou je dois faire avec ce que j'ai.
Merci encore à tous

[Polyfructol]

En plein saut tu pourrais désactiver les déplacements horizontaux : méthode qui respecte la physique.

Ou alors

Lors du saut, tu met un plus faible coefficient pour les déplacement horizontaux : c'est la méthode que j'utilise, comme dans la plupart des jeux de plateforme. Cette méthode laisse une marge de manoeuvre au joueur pour gérer son saut.

[otspot]

c'est la solution que j'utilise, mais je trouve que ca rend pas très bien à l'écran, en tout cas l'effet est pourri comparé à beaucoup de mario like que j'ai vu.
Donc peut être qu'il ya une autre méthode

Et quant a desactiver le deplacement quand il saute, je suppose que tu rigolais

[Polyfructol]

Et quant a desactiver le deplacement quand il saute, je suppose que tu rigolais

Non pas tellement, parfois j'ai testé des jeux ou c'était le cas et alors la maniabilité changeait complètement (il fallait anticiper à l'avance chaque saut sinon c'était la mort).
C'est d'ailleurs un peu l'effet que ça me fait quand je joue à Super Mario Bros 1, où on a vraiment du mal à se déplacer en l'air.

Pour ton problème, tu dis que l'effet est pourri, c'est à dire ?

Parce que une fois ta méthode implémentée, il suffit juste de trouver les coefficients qui donnent une bonne maniabilité. (J'ai bien dû faire des centaines de changement de coeff pour trouver ce qui me fallait, d'où l'intérêt de stocker ces variables dans un fichiers hors-code).

[otspot]

Par effet pourri, je veux dire, que ce n'est vraiment pas le même effet que je retrouve dans un vrai mario, ou on a l'impression que le saut est vraiment naturel.

Je commence à douter de ma méthode, representer physiquement quelque chose de physiquement impossible c'est pas évident.

Moi j'utilise la fonction d'un tir de projectile, avec un angle de depart=PI/2 et après je lui donne la possibilité de se deplacer en changeant les coordonnées obtenues avec l'equation du tir.

Quelles sont les autres méthodes utilisées d'habitude.

Merci

[Polyfructol]

Le plus évident et réaliste pour gérer la physique est d'utiliser les lois de Newton. Avec le vecteur accélération, le vecteur vitesse, le poid, les frottements, et je sais plus quoi ^^.

Sur le sol ou en l'air le joueur est soumis à différentes forces, qui sont assez facilement modélisable.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
acceleration_y = -0.1f; // Chiffre au hasard, mais assez faible
 
if (saute) {
    vitesse_y = 10.0f; // Un nombre positif, pour que le perso monte
}
else if (en_l_air) {
    vitesse_y += acceleration_y * delta_temps;
}
else {
    vitesse_y = 0.0f;
}
 
y += vitesse_y * delta_temps;

Je suis pas un pro de la physique, mais de ce que je me souviens ça suffit à faire un saut assez réaliste.

Si tu veux plus de réponse au sujet de la physique, crées un post dans le forum physique, mais je pense que le saut (en 2D) a déjà dû y être évoqué.

[otspot]

A la base, après une recherche sur le forum j'était parti sur un truc qui ressemble à ton code, mais j'ai bloqué sur le deltatime, car le time.h ne gere que les secondes et le deltatime est en millisecondes.

J'ai besoin d'une précision tout de meme, pour se deplacer dans l'air, tu fais comment?? Juste un changement des coordonnées??

Mais je crois que je vais creer un sujet sur le forum physique.

Merci en tout cas, et si t'as un autre conseil, ca sera avec plaisir