Discussion :

[matthieu637]

Bonjour,
je fais actuellement un rpg 2D vu de haut ( sans système de case par case ) et j'aimerais savoir comment définir les zones où le personnage ne peut pas accéder.

Le déplacement du personnage se fait par un changement de repère.

J'ai pensé mettre une grande image de fond pour la carte et une autre image avec les objets inaccessibles et dont les zones transparentes ( où on voit donc la première image ) seraient accessibles.

La seconde solution ( avec plein d'images dessinées les unes à côté des autres ) aurait été de vérifier à chaque instant où le personnage bouge si l'image où il arrive est accessible.


Avez-vous d'autres solutions? La première est-elle réalisable?

[matthieu637]

Problème résolu par la 1ère méthode et l'ajout d'une 3ème couche pour dessiner le personnage sous le haut des maisons et arbres.

[bouye]

Ta solution fonctionne en effet parfaitement.

Generalement et traditionnellement on utilise une image dediee, un masque en N&B ou en deux couleurs (voir BufferedImage.TYPE_BYTE_BINARY) qui defini les zones accessibles dans l'image de fond. Idem la plupart des sprites ont des masques qui leur sont associes pour definir les zones qui ne ne comptent pas pour les collisions (ex bidon : la cape du perso qui flotte au vent).

Egalement, de nos jours, tu peux te creer une editeur qui te permet de dessiner des formes geometriques sur le fond, de les stocker dans un fichier texte et ensuite d'utiliser l'interface Shape pour determiner si le perso peut aller dans ces zones ou pas. Ca a probablement le merite de bouffer moins de memoire qu'une image dediee.

[matthieu637]

Je me disais aussi que la RAM utilisé par l'application augmenté rapidement avec l'utilisation d'images dédiées.

Actuellement, lors d'un déplacement la méthode géodata() est appelé presque 500 fois par seconde pour analyser les points d'un ovale qui représente le socle du sprite et cherche si il y a de la couleur en ces points :

Code :

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

1
2
3
4
5
6
7
8
9
 
	public void geodata()
	{
		int rgb= bufferedImageInnaccessible.getRGB((int) xGeo,(int) yGeo);
		int rouge = (rgb >>16) & 0xFF;
		int vert = (rgb >> 8) & 0xFF;
		int bleu = rgb & 0xFF;
		if (rouge != 0 | vert != 0 | bleu != 0) {xPerso -= dx; yPerso -= dy; dx=0; dy=0;}
	}

Pourtant malgré ce nombre l'UC n'est pas fortement utilisé (2-3%) et les déplacements sont fluides.
Si il existe une solution qui prend moins de RAM, moins de calculs et tout aussi efficace je suis preneur.


Je dispose justement d'un Éditeur maison permettant de créer des cartes pour cette application. Avec l'interface Shape les déplacements seront-ils toujours aussi fluides, la RAM/UC sera-elle diminué ?

[bouye]

Justement quel type utilises-tu pour tes images masque ? Car TYPE_INT_RGB ou TYPE_INT_ARGB c'est quand meme 4 octets par pixel.

[matthieu637]

Le TYPE_INT_RGB.

Si j'augmente la taille de l'image ( 380 ko -> 980 ko ), la RAM utilisé par l'application passe de 200 mo vers 460 mo.

[dinobogan]

Le TYPE_INT_RGB.

Si j'augmente la taille de l'image ( 380 ko -> 980 ko ), la RAM utilisé par l'application passe de 200 mo vers 460 mo.

Pense aussi que le masque n'a pas besoin d'être aussi grand que l'image affichée (sauf si bien sûr tu veux de l'ultra-précis). Tu peux faire un ratio en divisant par deux. Donc le nombre de pixels de ton masque sera divisé par 4.

[bouye]

Et puis voir egalement du cote des TYPE_BYTE_* pour une autre division par 4...

[matthieu637]

Je vois merci.

Pour dessiner toute la carte vaut-il mieux avoir une seule image complète en mémoire ou alors avoir un fichier texte en mémoire et dessiner chaque image à part. Il ne faut pas non plus négliger les déplacements ( déplacer une grande image ou des centaines de petites? ).


Mais il y a tout de même quelque chose que je n'arrive pas à saisir :
pour une simple image de 389 ko la JVM utilise 35 mo juste pour la déclaration de l'image et pour son affichage (soit cent fois plus de place).

Code :

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

1
2
3
4
5
6
7
 
private Image im1 = new ImageIcon("image.png").getImage();
protected void paintComponent (Graphics g)
   {
super.paintComponent(g) ;
g.drawImage(im1,0,0,null);
   }

Mon code est-il incorrect?

[artscoop]

Salut,
Ben première chose concernant ton dernier post, ce n'est pas parce que l'image pèse 385ko sur disque qu'elle pèsera 385ko en mémoire.

Une image de 8000x1000 pixels peut peser 35Mo en mémoire et peser moins d'un méga sur disque (si PNG ou format compressé)

Deuxièmement, à part sur des maps fixes ou larges dessinées, si ton jeu est assez peu conséquent, pour des raisons de simplicité de gestion, de performance et de place en mémoire, vaut mieux découper ton fond en tiles et en étages.

Premier étage : Tu affiches le sol
Second étage : Tu affiches les objets au sol (ombre du personnage, etc)
Troisième étage : Tu affiches ton personnage et ensuite les objets s'élevant nécessairement autour de ton personnage...

La méthode doit être un peu modifiée mais je m'en étais déjà servi pour faire un petit jeu (pas terminé), et ça marchait TRÈS, TRÈS bien.

Pour la technique que tu utilises, oui c'est donc possible que 35Mo soient utilisés.
8192x1024 = 32Mo
Ajoutons un possible overhead de la VM Java, et on arrive vite à 35Mo.
Enfin je ne sais pas tout à fait comment ça marche.
Tu devrais faire le test de la mémoire prise sur un tout petit programme fait un iquement pour ça.

@+, (j'ai du mal à taper, y'a pas de curseur...)

[matthieu637]

Je vois merci.
J'ai une petite carte qui fait du 6000*2700 pixels. Sachant qu'avec il y a un masque en noir et blanc qui fait donc aussi du 6000*2700 (même si il utilise moins de RAM). Avec tout ça je monte à 370 mo sur l'application (pour un simple jeu 2D ).

Je dispose de mon propre créateur de carte, j'ai donc pensé qu'au lieu d'avoir une seule image en 6000*2700 pixel. Je ne fusionnerais pas les titles et à chaque tiles j'associerais deux tableaus de int ( les x et les y ) comme ça au lieu d'avoir 6000*2700 pixel enregistré en mémoire j'aurais seulement quelques pixels des images utilisées avec des tableaux de coordonnées pour les afficher.

De plus avec cette méthode je pourrais faire en sorte que le personnage puisse se déplacer derrière certains objets, car l'utilisation d'un masque pour bloqué le passage est pratique mais comment faire pour qu'on puisse toujours passer derrière un arbre? il faut découper le masque de l'arbre en deux et ensuite créer une 3eme couche à dessiner après le personnage (plus de travail, plus de ram utilisé, ...).

Alors que avec cette méthode vu que chaque objet sera attribué d'un couple de coordonnées je n'aurais qu'à regarde le "y" d'un objet pour savoir si je le dessiner avant ou après le personnage, se qui ne fait que simuler une 3ème couche alors qu'il n'en existe pas réellement.

Je souhaiterais donc savoir si avec cette méthode je gagnerais vraiment en RAM?
Je pense par contre que cela nécessitera plus de processus car dans le paintComponent je devrait faire défiler les tableaux, analyser si leur coordonnées appartiennes à l'écran, et faire peindre image/image au lieu d'en avoir une seule (le nombre d'image est tout de même de 2000~ mais avec seulement 40~ différente), soit au moins 2000 coordonnées à analyser toutes les 40 millisecondes (pour atteindre du 25 images/seconde comme l'œil ) durant un déplacement ... se qui n'est pas négligeable.
Vaut-il mieux dessiner toutes les tiles du sol même si elle ne sont pas afficher à l'écran? ou la méthode Graphics.drawImage fait encore plus de calcul qu'un if même si la zone n'est pas visible?

Enfin avez vous d'autres solutions plus pratique, moins couteuse pour gérer les collisions et les passages par derrière?

Je rappel que la vue est en perspective, à la Diablo II.

Merci à ceux qui auront la patience de me lire.

[billynirvana]

Je suis intéressé par discuter avec vous sur un des problèmes que je rencontre actuellement.

Je suis en train de coder un remake simple du jeu "bomber man" en full java et en 2D (pas de jogl ni truc du genre). La boucle principale d'affichage se contente d'imprimer à l'écran une image de fond, un ensemble d'images pour les murs, un ensemble d'images pour les bombes, bonus et bombers.

Quand mon personnage se déplace, ma gestion des collisions fait en sorte qu'il ne traverse pas les murs. Le code ressemble à ça:

Code :

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

1
2
3
Position positionActuelle = bomber.getPosition();
Position positionCalculee = bomber.nextPosition();
Si bomber.collides() { bomber.setPosition(PositionActuelle); }

Cependant, la vitesse de déplacement de mon bomber n'est pas fixe, elle dépend d'un paramètre "vitesse".

Mon problème est que si mon bomber se déplace trop vite, l'algorithme ci-dessus est insuffisant car le bomber restera trop éloigné du bord. Imaginons que le bomber est à 50 pixels d'un mur et que sa vitesse est de 55pixels/itération. Vous imaginez donc que mon bomber restera à 50pixels du mur et ça fait moche ^^.

L'idée est dans le cas où la positionCalculee du bomber aboutit à une collision, d'approcher au maximum le bomber du mur. Cependant, l'algorithme que j'ai utilisé ne me satisfait pas.

Avez-vous une astuce, un algorithme performant qui permette de résoudre ce problème?

Merci pour votre collaboration,

Kurt

[bouye]

Faire un calcul de position un peu plus complexe que la remise a la position precedente (ben oui parfois pas la peine de chercher plus loin que le bout de son nez).

[billynirvana]

Bien entendu, c'est ce que j'ai fait! Mais je trouve que mon algorithme n'est pas efficace. Je posterai son contenu ce soir car là je suis au taf!

L'algorithme utilisé fait intervenir la distance entre les deux objets!

Kurt