Bon j´ai pas tout suivi je préviens, mais étant donné que tu veux faire un mario like donc tu scrolling horizontale, ton problème est au niveau du background si j´ai bien compris.

C´est simple tu as 2 solutions:

- Un background qui se répète: tu vas bouger le background de 10 tiles vers X par exemple et hop tu reviens au début mais en faites ca fera comme une suite. Ce sont des images avec des vue en 360° la fin de l´image se continue au début.

- ou alors un background fixe, que tu fixe à chaque frame, quand mario avancera, ton background bougera mais tout le reste oui (mario, les tiles, les monstres ...etc)

jojo___ j´ai l´impression que tu n´as pas très bien compris...
il faut centrer le background à la position x de mario, giganova dit qu´il faudra aussi prendre les coordonnées y de mario car si il saute, le background ne bougera pas.
et tu dis que pour la fonction sauter on a besoin du y oO lol :p
Giganova oui dans par ex super mario bros le background est mis juste à la position x de mario, pas à sa positon y, mais toi tu peux le faire pour ton jeu si tu veux ^^
tout dépend de tes goûts.

Bah si mario saute, le background il descendra non? je veux dire, que quand il reste immobile il voit par exemple un arbre (le bat) et quand il saute il verra ce meme arbre (le haut).
Enfin tu as surement trompé, j´ai mal compris ....

A_Genuis >> okay merci donc tu pense qu´une fonction background
avec une definition des coordonnées x par raport a mario et un y = 0
et d´une blitsurface de l´image devrait suffire

cette fonction(); étant incluse dans une boucle sdl_event ^^´
donc se répétant a chaque action..

jojo___ >> si c´est du scrolling ce sera l´écran qui monte et non le background qui descend ^^´

Ah ouai oups, me suis trompé xD

A_Genius > "Oui mais un mario-like c´est simplet, il n´y aura pas des millions de tile"

--> Mais meme s´il n´y a pas des millions de tiles, si tu bosses dans un tilemapping, en 2 divisions, tu es directement sur le tile ou tester la collision ! Donc tu n´as qu´une collision a tester !
Meme s´il n´y a pas des millions de tiles, a quoi sert de faire quelques dizaines, ou centaines de collisions, alors que tu peux n´en faire qu´un seul ?
Dans un tilemapping, on ne teste pas toutes les briques a chaque itérations ! C´est justement le principe du tilemapping : la régularité épargne les calculs !

Fvirtman >> je comprend ton principe, il suffit de de tester si la case n´est pas vide dans ce cas on renvoi les nouvelles coordonnées du mario (ça va beaucoup mieux a comprendre les explication de ce monsieur qu´il y a 3 ans xD)

Mais bon j´essai de comprendre ton code pour le lecture de la bitmap et du renvoi des tuiles en fonction de la couleur des pix.
Mais il y a plein d´importation d´autres fichier dans tout les sens ^^ (c´est flou pour moi..)

"sinon est-ce que cela peu gerer le scroll horizontal ? "
"j´ai peur qu´elle ne se déplace avec le perso"

Le philosophie de "promenade" que je te propose résoud tout a la fois :
Imagine un écran géant de 20 mètres de long, 20 mètres de large :
la dedans, tu dessine tout ton monde, et aussi ton perso : tu es dans un monde ABSOLU : les coordonnées du gars peuvent etre 10000, 5000
Donc quand tu déplaces le gars, tu bouges ses coordonnées.
et ensuite, une fois que tu veux afficher, tu définis le "fenetrage", c´est a dire que sur ton écran géant, tu mets un cadre, et tu dis que tu ne verras que ce qu´il y aura dans le cadre
Donc tu déplaces que le cadre. Et, comme ton perso bouge dans le repere absolu : il est indépendant du cadre : et ne "se déplacera pas avec le perso "
et poru faire un scrolling, finalement, tu déplaces juste le cadre !

Apres, pour le rendu, tu calcules la zone de tiles a afficher en fonction de la position du cadre, puis tu calcules la position de ton personnage en fonction de la position du cadre : une soustraction !
position_dans_l_ecran_perso.x = position_absolue_perso.x - position_cadre.x;
position_dans_l_ecran_perso.y = position_absolue_perso.y - position_cadre.y;

Bref, c´est un concept : tu travailles dans un "monde géant" et tu n´en affiches qu´une partie

Fvirtman Ah oui je n´y avais pas pensé...
Giganova Il faudrai faire une fonction qui teste les collisions dans la zone du mario...c´est pas si simple que ca un mario-like x)

Ouai enfin il vaudrait mieu approprier le monde et pas le faire trop grand non plus non? Parce que le gars qui fait un truc enorme alors que le joueur ne peut voir qu´une petite partie de tous ça ce serait un gachis non?

Je me trompe encore ? ^_^

"Ouai enfin il vaudrait mieu approprier le monde et pas le faire trop grand non plus non? Parce que le gars qui fait un truc enorme alors que le joueur ne peut voir qu´une petite partie de tous ça ce serait un gachis non?

Je me trompe encore ? ^_^"

Ben c´est lui qui choisis la grandeur du niveau...
Et il peut regler la grandeur du cadre au besoin.

Fvirtman Alors on fera comment pour dire "telle tile est à tel endroit" ? On devra utiliser un tableau ?

jojo____ > pas tout a fait d´accord
Un grand monde ne "coute" pas grand chose : juste la BMP porteuse (ou le fichier Texte porteur).
Dans la mesure ou dans un monde, c´est toujours les memes tiles qui sont placés de partout, ça ne coute pas plus cher a ce niveau la non plus

Un jeu comme Sonic, ou ça va a toute vitesse, il vaut mieux un monde bien grand pour pas que le joueur finisse en 30 secondes

Le TileMapping permet de faire des mondes géants sans que ça coute trop

A_Genius > "Alors on fera comment pour dire "telle tile est à tel endroit" "

Télécharge mon fichier "promenade" dans mon tuto §2.A.2, lance le, regarde la tete du "minimonde" puis regarde le fichier levels.bmp, ça va te sauter aux yeux
Tu peux meme t´amuser a modifier le fichier levels.bmp pour changer le monde.

sachant qu´un BMP (une image en général) c´est qu´un tableau 2D !

Oui tu as surement raison. Mais je pensait plutôt au gachis du travail et non de la mémoire du pc ou de la rapidité ;)

Je penser que travaillé super longtemps et précisément pour créer une partie de la map que le joueur ne verra même pas n´est peut etre pas géniale ;)

Ben en fait, oui, le mec qui dessine le level, il aura plus de boulot s´il fait un monde plus grand, bien sur

mais bon, ça ! apres, ça dépend si le gars veut qu´on finisse son jeu en 10 minutes, ou en plus longtemps

Fvirtman >> j´ai bien compris la philosophie tu cadre qui ne revoi sur l´écran d´ordinateur qu´une partie de la map générée par le fichier .bmp

pour des tiles de 16x16 une bmp de x indefini et y = 30px suffit non ?

si tu as des tiles de 16x16 pixels, et une image de level de 30*30 pixels, ça peut te couvrir 16*30 = 480 pixels de long, et pareil de haut

En fait, tu fais juste une multiplication : un pixel de l´image de level représente, a la sortie, un tile de 16x16

Moi je pense que 16x16 c´est trop petit ! mais apres, les gouts les couleurs

Ah oui tu utilises une image et tu fais une fonction qui analyse la couleur et tu la transformes en objet ^^
Merci de l´info :D

ui mé bn les tuiles que j´ai trouvé c des 16x16, pui c pr jouer en 640x480 max ^^´ mais bon je pens que je vais passer la reso en 320x240 comme ça me fera moins de boulot pour fer le level ^^´ un programmeur a une philo de feignasse, j´avoue je le suis un peu.

Sinon je cherche toujours la fonction pour renvoyer la couleur d´un pixel j´ai trouvé suface->format->BytePerPixel mais elle ne m´est d´aucune utilitée