QuestionS momentan. résolu

Bonjour.
J'ai quelques petites questions, et je... cherche des réponses... :hehe: :


-Comment créer une bordure autour de l'écrant de jeu qui soit dans la fenêtre du jeu mais pas dans le jeu (dans laquelle on peux cliquer, mais qui n'existe pas réelement dans le jeu...)?...

-Comment tester si une zone dans un sprite ou un background est remplie ou transparente?

-Je peux en non enregistré sauvegarder des images en .gif individuellement. Comment les enregistrer dans le même gif à la suite l'une de l'autre?...

-Je sauvegarde 100 données dans une .ini... Les coordonnées des salles visitées et non-visitées d'une carte de 10/10...
Donc: repeat(10){ repeat(10) { read(map[cx,cy]) } }...
Y-a-t'il des moyens pour faciliter/accèlérer/diminuer le temps de chargement, le nombre de données?...(Parce qu'avec plusieurs cartes...)


Je suis pas sûr qu'il y ai des réponses à toutes ces questions, mais ça m'arrangerai si oui...

1) bah, tu m'explique? tu veux qu'on puisse cliquer dessus mais qu'il n'y ai pas d'interaction?!?

2) ....pas possible à la base. Sinon : tu fait une surface de la taille du sprite, tu la remplie de blanc, tu affiche le sprite, puis tu fait un draw_get_pixel ou tu veux. si c'est blanc ; ton sprite/background est transparent à cet endroit.

Sinon pour les sprites, tu peux essayer de faire une détection de collision, mais c'est pas top.

3)Pas possible à la base dans game maker.

4)

for(X=0 ; X<10 ; X+=1){
for(Y=0 ; Y<10 ; Y+=1){
ini_write...(map[X,Y]);
}}

tu peux pas faire plus court

M@d_Doc a écrit:

for(X=0 ; X<10 ; X+=1){
for(Y=0 ; Y<10 ; Y+=1){
ini_write...(map[X,Y]);
}}

tu peux pas faire plus court

avec X++ et Y++ c'est plus court de 2 caractères

pour la bordure, tu fais un fond et tu places une view au milieu de l'écran, comme ca ca fait une bordure.
sinon je vois pas.

Les "for" sont plus rapides que les repeat?...
En tout cas, 100 données restent 100 données, merci.
(C'est donc pour ça les temps de sauvegarde hyper longs dans les jeux avec des cartes!)

Et le 2 et le 3, c'est dommage, mais bon.


Pour la bordure, je voulait une zone où si on clique, les objets savent qu'il y a un clique, mais que si ils sont sur la bordure et qu'on clique sur eux sur la bordure ils réagissent à "global mouse" mais pas à "mouse" (comme si on cliquait en dehors de la salle)...

C'est un peu compliqué, je pense que je vais me débrouiller avec un test pour la bordure et un draw... J'avait essayé avec une view in room plus grande que la view in screen mais c'était moyen...
(En fait c'est parce que dans mon jeu, le personnage se dirige vers la souris, et que les portes sont hors de la room, d'où la nécessité d'une bordure où cliquer.)

En tout cas merci de tes réponses rapides!

Edit: Vos réponses. (chuis lent à poster...)

Pour la bordure de view, je vais tester ce que tu proposes, Zebdal.

zebdal a écrit:

M@d_Doc a écrit:

for(X=0 ; X<10 ; X+=1){
for(Y=0 ; Y<10 ; Y+=1){
ini_write...(map[X,Y]);
}}

tu peux pas faire plus court

avec X++ et Y++ c'est plus court de 2 caractères

pour la bordure, tu fais un fond et tu places une view au milieu de l'écran, comme ca ca fait une bordure.
sinon je vois pas.

j'étais pas sur que les surchages d'opérateurs marchent en gml ^^ mais oui, c'est plus court ^^

Oui mais c'est aussi plus rapide?

Edit:
For plus rapide que Repeat?

zebdal a écrit:

avec X++ et Y++ c'est plus court de 2 caractères

mais en contrepartie ça ne marche pas

x++; ca ne marche pas? il me semblait l'avoir déja utilisé pourtant.

Pas en GML en tout cas :)

je plussoie, x++ ne marche pas en GML malheureusement ...

tout comme >> et << me semble il ...

On aurait dit la solution miracle, mais en fait... :gniah:

Bon, merci de vos réponses
Décidément je cherche dans a mauvaise direction...


Une dernière chose: for plus rapide que repeat?

La meilleure solution est de tester :

tu fais une boucle repeat dans step ou draw, puis tu regarde le fps (en mettant la room_speed à 99999).

ensuite tu fais la même boucle mais avec un for et tu regarde quel fps est le plus élevé

sachant que pour 100 itérations, la différence de temps entre les 2 méthodes est négligeable et surement l'ordre de millièmes de secondes.
si c'était pour un lancement de fusées, je comprendrais que tu veuilles parler de rapidité mais là, c'est complètement obsolète.
contente toi de faire de la bonne programmation avant de te lancer dans des trucs comme ca, c'est le genre de choses qu'on fait en bac+3 voire plus ^^.

zebdal a écrit:

sachant que pour 100 itérations, la différence de temps entre les 2 méthodes est négligeable et surement l'ordre de millièmes de secondes.
si c'était pour un lancement de fusées, je comprendrais que tu veuilles parler de rapidité mais là, c'est complètement obsolète.
contente toi de faire de la bonne programmation avant de te lancer dans des trucs comme ca, c'est le genre de choses qu'on fait en bac+3 voire plus ^^.

Je trouve pas que cela soit une bonne remarque. L'optimisation est quelque chose à laquelle il vaut mieux se mettre le plus tôt possible, sinon c'est très dur d'y revenir après.

Surtout que dans un jeu, quelques millièmes de secondes utilisés à un step par un code c'est pas grand chose, mais si tu code chaque step de chaque objet comme devant prendre quelques millières de secondes, dans un jeu avec beaucoup d'instances tu risque de te retrouver avec des steps extrêmements lents.

Après c'est sûr qu'il faut pas exagérer, mais c'était pour dire à ceux qui lirait ton message, que plus c'est optimisé mieux c'est, et dire, "on verra plus tard pour l'optimisation" c'est comme dire "on recodera le projet deux fois, une fois pour qu'il soit lent, et une autre fois pour qu'il soit rapide".

nicoulas a écrit:

La meilleure solution est de tester :
tu fais une boucle repeat dans step ou draw, puis tu regarde le fps (en mettant la room_speed à 99999).
ensuite tu fais la même boucle mais avec un for et tu regarde quel fps est le plus élevé

Sans doute la meilleure chose à faire. Et ce ne sont pas des informaticiens qui pourront me contredire.

Excuse moi si je pose une mauvaise question, mais penses tu vraiment qu'il y a une différence de codage entre l'instruction for et repeat. Bien sur, dans "for" il y a une initialisation et une incrémentation en argument mais si tu t'inquiètes pour ce genre de trucs tu peux continuer de suite parce que je ne crois même pas que l'on puisse parler de millième de seconde ici.

Tout au plus de micro seconde

Malax a écrit:

nicoulas a écrit:

La meilleure solution est de tester :
tu fais une boucle repeat dans step ou draw, puis tu regarde le fps (en mettant la room_speed à 99999).
ensuite tu fais la même boucle mais avec un for et tu regarde quel fps est le plus élevé

Sans doute la meilleure chose à faire. Et ce ne sont pas des informaticiens qui pourront me contredire.

Excuse moi si je pose une mauvaise question, mais penses tu vraiment qu'il y a une différence de codage entre l'instruction for et repeat. Bien sur, dans "for" il y a une initialisation et une incrémentation en argument mais si tu t'inquiètes pour ce genre de trucs tu peux continuer de suite parce que je ne crois même pas que l'on puisse parler de millième de seconde ici.

Tout au plus de micro seconde

Je n'avais que lu ce que disais Zebdal, mais en effet pour ce qui est de repeat et for, c'est sûr qu'il ne faut pas se poser de questions, les différentes construction d'un langage ne changent rien du tout. Ou alors ce n'est pas la peine d'utiliser un langage où il y aurait des différences notoires, en matière de rapidité entre un while, un for et un repeat ou un do until.

Sinon tu peux directement passer en ASM ou alors n'utiliser que les GOTO du C. lol

Malax a écrit:

Excuse moi si je pose une mauvaise question, mais penses tu vraiment qu'il y a une différence de codage entre l'instruction for et repeat.

Si c'est adressé à moi : c'est juste que red-error a posé la question donc je lui réponds

moi, je parlais à red-error.

Citation :

L'optimisation est quelque chose à laquelle il vaut mieux se mettre le plus tôt possible, sinon c'est très dur d'y revenir après.

c'est complètement faux.
Il faut d'abord savoir programmer, comprendre les concepts de la programmation avant de penser à une quelconque optimisation.
Ca ne sert à rien de passer son temps à optimiser un programme faux.
savoir programmer, c'est VITAL.

c'est pas pour rien que dans les livres de base sur la programmation, ils ne font même pas référence à l'optimisation.

Citation :

Après c'est sûr qu'il faut pas exagérer, mais c'était pour dire à ceux qui lirait ton message, que plus c'est optimisé mieux c'est, et dire, "on verra plus tard pour l'optimisation" c'est comme dire "on recodera le projet deux fois, une fois pour qu'il soit lent, et une autre fois pour qu'il soit rapide".

il y a optimisation et optimisation.
savoir si for ou repeat est plus rapide ce n'est absolument PAS vital, surtout pour 100 itérations.
il y a 30 steps par seconde je crois, si la différence est de l'ordre de 1 millième de seconde, ca n'affectera pas le jeu.
En plus, la différence de vitesse entre le for et le repeat peut varier en fonction du nombre de commandes que tu veux répeter, surtout si dans un for tu appliques des calculs relatifs à ta variable d'itération.
dans un cas, celà pourrait etre le for alors que dans un autre celà pourrait etre le repeat.
je pense que j'ai tout dit.

moi j'utilise tout le temps le for pour plusieurs raison:
_la clarté, je trouve que c'est vraiment plus visible
_le repeat n'existe pas dans tous les langages

zebdal a écrit:

Ca ne sert à rien de passer son temps à optimiser un programme faux.

Un programme 'faux' ? Ça n'a aucun sens.

zebdal a écrit:

savoir programmer, c'est VITAL.

Hm, peut être pas quand même ...

zebdal a écrit:

c'est pas pour rien que dans les livres de base sur la programmation, ils ne font même pas référence à l'optimisation.

Forcément, ils considèrent que tu as un pc ultra récent à 64 coeurs avec 128 Go de Ram, donc ils n'en parlent plus.

zebdal a écrit:

il y a optimisation et optimisation.

T'as lu ce qu'as écrit dam ? C'est exactement ce qu'il disait en fait ...

daminetreg a écrit:

Malax a écrit:

nicoulas a écrit:

La meilleure solution est de tester :
tu fais une boucle repeat dans step ou draw, puis tu regarde le fps (en mettant la room_speed à 99999).
ensuite tu fais la même boucle mais avec un for et tu regarde quel fps est le plus élevé

Sans doute la meilleure chose à faire. Et ce ne sont pas des informaticiens qui pourront me contredire.

Excuse moi si je pose une mauvaise question, mais penses tu vraiment qu'il y a une différence de codage entre l'instruction for et repeat. Bien sur, dans "for" il y a une initialisation et une incrémentation en argument mais si tu t'inquiètes pour ce genre de trucs tu peux continuer de suite parce que je ne crois même pas que l'on puisse parler de millième de seconde ici.

Tout au plus de micro seconde

Je n'avais que lu ce que disais Zebdal, mais en effet pour ce qui est de repeat et for, c'est sûr qu'il ne faut pas se poser de questions, les différentes construction d'un langage ne changent rien du tout. Ou alors ce n'est pas la peine d'utiliser un langage où il y aurait des différences notoires, en matière de rapidité entre un while, un for et un repeat ou un do until.

Sinon tu peux directement passer en ASM ou alors n'utiliser que les GOTO du C. lol

Ouf alors, parce que j'étais à 100% d'accords avec Zebdal pour coder sans réfléchir à "for" ou "repeat" et ça m'embêtait de passer pour le raleur ^^

Et dans GM, ce n'est pas en chipotant du code que l'on obtient des gains significatifs, mais plutôt en jouant sur les activations/désactivation intelligentes d'objets et de tuile (pour activer/désactiver les tuiles, on y arrive par des moyens détournés...). Le reste, c'est limite minuscule à coté. [dans le cas de ma démo 4, je suis passé de 55fps à 190fps avec ça(et j'aurais pu encore mieux faire)]

Citation :

Il faut d'abord savoir programmer, comprendre les concepts de la programmation avant de penser à une quelconque optimisation.

On part de la base qu'on sait programmer. Quelqu'un qui sait pas programmer ne peux de toute façon pas optimiser un truc qu'il ne comprends pas.

Citation :

Ca ne sert à rien de passer son temps à optimiser un programme faux.
savoir programmer, c'est VITAL.

... no comment ...

Citation :

c'est pas pour rien que dans les livres de base sur la programmation, ils ne font même pas référence à l'optimisation.

Ca mon cher, c'est parce que la plupart des livres de prog, c'est de la daube. de la vraie.

Citation :

En plus, la différence de vitesse entre le for et le repeat peut varier en fonction du nombre de commandes que tu veux répeter, surtout si dans un for tu appliques des calculs relatifs à ta variable d'itération.

c"est pour ça qu'on utilise un for, quand on a de toute façon besoin d'une variable d'itération lol


et moi je n'utilise pas repeat non plus.

for est plus rapide d'execution, repeat est plus rapide a écrire :oui:

Citation :

Un programme 'faux' ? Ça n'a aucun sens.

ne fais pas ton cogis, tu sais très bien que je voulais dire "un programme non valide".
(programme non valide = programme qui ne passe pas la compilation).

EDIT: "faire son cogis" signifie "reprendre sur tous les points".

Okok, mais de toute façon c'est sur qu'il faut savoir programmer avant d'optimiser, ça paraît logique.

Citation :

Ca mon cher, c'est parce que la plupart des livres de prog, c'est de la daube. de la vraie.

pour ca, je ne suis pas d'accord.
un bouquin tout seul n'est pas la meilleure méthode d'apprendre à programmer, c'est en pratiquant qu'on programme.
un bouquin sert juste d'aide pour cette pratique.
La plupart des bouquins sont assez bien rédigés.
La chose qui change entre chaque bouquin c'est la facon de chaque auteur a d'aborder les sujets.

Topaze22 a écrit:

Ouf alors, parce que j'étais à 100% d'accords avec Zebdal pour coder sans réfléchir à "for" ou "repeat" et ça m'embêtait de passer pour le raleur ^^

Toi raler, j'en ai pas le souvenir mais je t'ai à l'oeil

Je crois qu'on va s'arrêter là, le débat n'aura jamais de fin ^^

Merci pour ce débat enflammé, et désolé surtout de poser les mauvaises questions.
La base de la question faisait juste que certains avaient une préférence pour le "for" plustôt que le "repeat", et j'ai ma réponse (qui n'a finalement rien a voir avec le fps mais les "itérations" comme vous dites donc. ).

Et pour l'optimisation, c'était parce que ça prenait 1-2 secondes pour charger les 100 données...


Encore merci de vos réponses! :lng:
(Je vais plus en poser, moi, si ça pose un problème... :sarcastique: )

nan nan désolé si on c'est un peu énervé, c'est pas ta faute ^^
J'appelle ça un conflit d'idées entre deux programmeurs qui apparemment n'ont pas la même vision de la programmation lol.
Promis, je ne soulèverai plus de débat houleux si tu poses une question :p :p

Encore désolé red