Forum Liberty Basic France
• Index
Salut salut !
Je viens poser une petite question aux experts =)
Comment bouger l'arrière plan d'une scène ? Je m'explique :
Si on utilise comme dans beaucoup de jeu actuel un monde ouvert, la carte se charge automatiquement lorsque l'on se déplace. Si on fait 100 mètres a droit, le personnage ne va pas se rapprocher de la bordure de la fenêtre de droite mais restera au milieu et c'est la carte qui se décallera de 100 mètre vers la gauche.
Pour ma part je ne sais utiliser que 2 techniques pour obtenir cette solution :
- Utiliser dawnbmp avec des coordonées X et Y qui sont modifiable. On "re déssine" donc l'image à chaque incrément de pas. L'inconvéniant c'est que ca se cumule sur la mémoire donc ca devient très vite inutilisable ....il existe bien une solution pour nétoyer la mémoire "cls" mais le temps de faire cela et de re dessiner l'image, on a un "blanc" qui rend la scène épileptique assez rapidement ....
- Utiliser le drawsprites .... Technique de bidouilleur, on fait un sprite gigantesque que l'on met en arrière plan. Il suffit de modifier les coordonées X et Y et d'utiliser drawsprites à chaque incrément de pas. Le problème ici c'est les performance du code ... le sprite étant gigantesque, si on veut avoir une image fluide il faut faire 1 drawsprite par pas de mouvement et on constate très rapidement un ralentissement horible du code (aussi horrible que mon orthograf
) ....
D'ou ma question : Connaissez vous une autre méthode pour faire un déplacement de cet arrière plan sans ce cela soit un gouffre à ressource ou un moyen de déclencher de crise d'épilespsie chez le spectateur ? Ou un moyen d'afficher le fond d'écran en fixe mais que la fenêtre se déplace ?
Merci à ceux qui vont se casser quelques neurones (si possible une explication avec bout de code ca sera sympa XD)
Edité par atomose Le 12/07/2020 à 14h59
Je viens poser une petite question aux experts =)
Comment bouger l'arrière plan d'une scène ? Je m'explique :
Si on utilise comme dans beaucoup de jeu actuel un monde ouvert, la carte se charge automatiquement lorsque l'on se déplace. Si on fait 100 mètres a droit, le personnage ne va pas se rapprocher de la bordure de la fenêtre de droite mais restera au milieu et c'est la carte qui se décallera de 100 mètre vers la gauche.
Pour ma part je ne sais utiliser que 2 techniques pour obtenir cette solution :
- Utiliser dawnbmp avec des coordonées X et Y qui sont modifiable. On "re déssine" donc l'image à chaque incrément de pas. L'inconvéniant c'est que ca se cumule sur la mémoire donc ca devient très vite inutilisable ....il existe bien une solution pour nétoyer la mémoire "cls" mais le temps de faire cela et de re dessiner l'image, on a un "blanc" qui rend la scène épileptique assez rapidement ....
- Utiliser le drawsprites .... Technique de bidouilleur, on fait un sprite gigantesque que l'on met en arrière plan. Il suffit de modifier les coordonées X et Y et d'utiliser drawsprites à chaque incrément de pas. Le problème ici c'est les performance du code ... le sprite étant gigantesque, si on veut avoir une image fluide il faut faire 1 drawsprite par pas de mouvement et on constate très rapidement un ralentissement horible du code (aussi horrible que mon orthograf
) ....D'ou ma question : Connaissez vous une autre méthode pour faire un déplacement de cet arrière plan sans ce cela soit un gouffre à ressource ou un moyen de déclencher de crise d'épilespsie chez le spectateur ? Ou un moyen d'afficher le fond d'écran en fixe mais que la fenêtre se déplace ?
Merci à ceux qui vont se casser quelques neurones (si possible une explication avec bout de code ca sera sympa XD)
Edité par atomose Le 12/07/2020 à 14h59
Perso, j'utilise la première solution avec un bmp plus grand que la fenêtre
Je crois que pour soulager la mémoire, c'est: #handle.ext, "discard".
Si tu fais ce dont tu parle, le personnage va marcher sur place.. Est-ce bien judicieux ?
Ce système est à utiliser quand le joueur est le personnage (vision oculaire, le paysage se déplace).
Bon, on peut toujours désynchroniser le personnage de l'avance carte; mais dans un cas ça doit donner l'impression que le personnage rame, et dans l'autre ça demande de très grandes cartes.
Je crois que pour soulager la mémoire, c'est: #handle.ext, "discard".
Si tu fais ce dont tu parle, le personnage va marcher sur place.. Est-ce bien judicieux ?
Ce système est à utiliser quand le joueur est le personnage (vision oculaire, le paysage se déplace).
Bon, on peut toujours désynchroniser le personnage de l'avance carte; mais dans un cas ça doit donner l'impression que le personnage rame, et dans l'autre ça demande de très grandes cartes.
____________________
Roro
Roro
Oui le personnage ne marche pas et fait du sur-place mais c'est dans le cas ou la carte bouge. Ce n'est pas possible de bouger la fenêtre graphique ou de bouger l'image de fond sans avoir à la remettre a chaque fois ?
j'ai deja vu plusieurs fois "discard" mais jamais su l'utiliser XD je vais voir ce que ca donne =). merci du conseil
j'ai deja vu plusieurs fois "discard" mais jamais su l'utiliser XD je vais voir ce que ca donne =). merci du conseil
Citation:
Bah non, si tu bouge l'image, tu change d'image; le changement de bmp est relativement discret, quel est le problème ?
Ce n'est pas possible de bouger la fenêtre graphique ou de bouger l'image de fond sans avoir à la remettre a chaque fois ?
Bah non, si tu bouge l'image, tu change d'image; le changement de bmp est relativement discret, quel est le problème ?
____________________
Roro
Roro
relativement oui et non.... si tu redessine tu as un blanc entre les deux images (pour les grosses images). discard efface bien la mémoire jessai de maitriser ca pour voir si ca peut faire l'affaire 
EDIT : autre question bête : il n'est pas possible d'afficher qu'une partie définie de l'image en question ?
Edité par atomose Le 12/07/2020 à 21h28
EDIT : autre question bête : il n'est pas possible d'afficher qu'une partie définie de l'image en question ?
Edité par atomose Le 12/07/2020 à 21h28
Citation:
Oui, c'est possible.
Il n'y a pas de blanc au changement de bmp; ce que tu peux vérifier en commutant deux bmp de même lumière couleurs et contraste
il n'est pas possible d'afficher qu'une partie définie de l'image en question ?
Oui, c'est possible.
Il n'y a pas de blanc au changement de bmp; ce que tu peux vérifier en commutant deux bmp de même lumière couleurs et contraste
____________________
Roro
Roro
Et comment c possible ? XD
(Syntaxe pour sélectionner une partie de l'image a afficher)
(Syntaxe pour sélectionner une partie de l'image a afficher)
Citation:
Evidemment il ne faut pas fermer le bmp, aller faire trente six choses et afficher en revenant, si on introduit de la latence, forcément ça se voit.
Citation:
Ah non, mais tu n'y es pas du tout; si tu veux modifier une partie de bmp il faut que tu ai en fichier le bout modifié et tu le sur-imprime. Et là encore il n'y a pas de blanc.
J'ai commencé un flipper sur ce principe les bumpers marchent très bien.
Il n'y a pas de blanc au changement de bmp;
Evidemment il ne faut pas fermer le bmp, aller faire trente six choses et afficher en revenant, si on introduit de la latence, forcément ça se voit.
Citation:
Et comment c possible ? XD
(Syntaxe pour sélectionner une partie de l'image a afficher)
(Syntaxe pour sélectionner une partie de l'image a afficher)
Ah non, mais tu n'y es pas du tout; si tu veux modifier une partie de bmp il faut que tu ai en fichier le bout modifié et tu le sur-imprime. Et là encore il n'y a pas de blanc.
J'ai commencé un flipper sur ce principe les bumpers marchent très bien.
____________________
Roro
Roro
• Index
1 Utilisateur en ligne : 0 Administrateur, 0 Modérateur, 0 Membre et 1 Visiteur
Utilisateur en ligne : Aucun membre connecté
Utilisateur en ligne : Aucun membre connecté
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie