https://forum.mariouniversalis.fr/
Hein ? Je comprends rien, de quoi tu parles là ?Link275 a écrit :Il suffit de placer les 2 pages de sprites dans le dossier Graphics/Characters/.
Si les dégâts sont trop aléatoires dans plusieurs jeux RPG Maker, c'est probablement parce qu'on ne peut pas les choisir.Link275 a écrit :Et puis je trouve (comme beaucoup de RPG faits sous RPG Maker XP) que les dégâts infligés et reçus sont trop aléatoires.
Si elle fonctionne pas tu peux pas dire qu'elle est un FAIL.Moon Mario a écrit :Moon Mario a écrit :Une démo était attendue depuis longtemps (33 pages) et une fois qu'elle est là elle ne marche pas. T'imagines pas à quel point c'est frustrant, c'est pour ça que j'ai utilisé le mot Fail. De plus il manque masse de choses dans cette démo : Les graphismes Mario, les fichiers RGSS, ce qui démontre qu'elle a été bâclée.
J'ai lu la conversation et j'ai compris ce que Moon Mario voulait dire. Si il a bel et bien le droit de dire que la démo est un fail. Ce que tu ne comprends pas c'est qu'il ne critique pas la partie jeu, mais l'acte en lui même. Il a dit comme quoi c'était un fail de sortir une démo qu'il fallait trafiquer pour pouvoir jouer, il l'a dit sur ce ton là, parce qu'il voulait vraiment s'y essayer et qu'il a été frustré de ne pas pouvoir le faire. Tu comprends ou tu comprends pas ?Si elle fonctionne pas tu peux pas dire qu'elle est un FAIL.
Et c'est ça que je trouve bizarre. MarioKartDS a pu terminer le jeu jusqu'au bout, pourquoi pas les autres, même avec les graphismes ?Agent BOO a écrit :Mais pour la démo qui ne fonctionne pas, je ne crois pas que ce soit volontaire. Surtout qu'il y a quand même des personnes qui peuvent y jouer.
Enfin !ARC8Games a écrit :Il a dit comme quoi c'était un fail de sortir une démo qu'il fallait trafiquer pour pouvoir jouer, il l'a dit sur ce ton là, parce qu'il voulait vraiment s'y essayer et qu'il a été frustré de ne pas pouvoir le faire.
)Probablement parce qu'il faut télécharger un quelconque fichier et que MarioKartDS était le seul à l'avoir fait.Marioshi a écrit :Et c'est ça que je trouve bizarre. MarioKartDS a pu terminer le jeu jusqu'au bout, pourquoi pas les autres, même avec les graphismes ?
Perso je préfère une démo en retard mais de bonne qualité que vite fait et de mauvaise qualité. Que je sache, on ne te demandait pas de travailler plus vite pour autant. Noter que je n'ai JAMAIS dit que la démo était de mauvaise qualité.Marioshi a écrit :Enfin !
C'est parce qu'on me demandait tout le temps la démo que j'ai fait toutes ces erreurs.
D'accord, mais QUEL fichier ?Probablement parce qu'il faut télécharger un quelconque fichier et que MarioKartDS était le seul à l'avoir fait.
Regarde un peu les pages précédentes. On ne cessait pas de mes stresser, t'aurais aimé être à ma place ? Quand Ian aura la démo, j'améliorerai celle là et je la ressortirai.Perso je préfère une démo en retard mais de bonne qualité que vite fait et de mauvaise qualité. Que je sache, on ne te demandait pas de travailler plus vite pour autant.
Je ne parlais pas de toi.Noter que je n'ai JAMAIS dit que la démo était de mauvaise qualité.
Si on ne sait pas faire une animation en combat, on ne peut pas mettre des tilsets de combats... Quand on saura, on les testera.Doc Goomba a écrit :Et pour la dernière fois, est ce que mes tileset passe !!!
Ça j'en sais rien. Peut-être que MairoKartDS saura lequel.Marioshi a écrit :D'accord, mais QUEL fichier ?
Ah ok parce que ça te stressait tout ça ? Ben désolé alors.Marioshi a écrit :Regarde un peu les pages précédentes. On ne cessait pas de mes stresser, t'aurais aimé être à ma place ?
Je sais. Je disais juste ça pour qu'on ne tire pas de fausse conclusion de ce que j'ai dit.Marioshi a écrit :Je ne parlais pas de toi.
Wikipédia a écrit :DLL signifie Dynamic Link Library, ou en français Bibliothèque de liens dynamiques, dans le cadre du Système d'exploitation Windows. Traditionnellement, le nom de ces fichiers se termine par l'extension « .dll ». Une DLL peut contenir du code ou des ressources qui sont alors rendus disponibles à d'autres applications.
Le code contenu dans une DLL n'est chargé qu'une seule fois en mémoire. Ainsi, lorsqu'un processus tente de charger une DLL qui est déjà en mémoire, le code existant est mappé dans la mémoire du programme sans qu'un second chargement soit nécessaire, gagnant de la place en RAM. Lorsque tous les processus qui exploitaient une DLL se sont terminés, suivant le type de la bibliothèque et les paramètres Windows, l'espace mémoire qui lui était attribué peut être libéré ou non modifié afin que les prochains programmes hôtes n'aient pas à réeffectuer l'opération de chargement.
Une DLL peut être liée statiquement ou dynamiquement à un programme. Dans le premier cas, le programme déclare explicitement avoir besoin d'une fonction contenue dans une bibliothèque et la résolution de liens est effectuée par l'éditeur de lien au moment de la phase de compilation du programme. Le programme inclut alors dans sa structure binaire la liste des bibliothèques nécessaires à son bon fonctionnement dans sa "table des exportations" (export table). Le chargeur de programmes de Windows vérifie alors lors de l'exécution du programme que toutes les DLL requises sont disponibles, et si ce n'est pas le cas, stoppe le chargement en affichant un message indiquant que des dépendances nécessaires à l'exécutable n'ont pu être trouvées. Dans le second cas, c'est le programme qui demande explicitement le chargement d'une bibliothèque durant son exécution à l'aide de l'API LoadLibrary afin d'obtenir un pointeur sur la fonction désirée. Cette dernière approche est plus pénible car elle nécessite un effort plus important de la part du programmeur, mais elle permet d'une part de ne pas empêcher l'exécution d'un programme lié à une bibliothèque dont l'existence sur le système hôte n'est pas certaine, d'autre part constitue parfois le seul moyen d'accéder à des fonctions qui ne sont pas déclarées dans les fichiers d'interface fournis par l'éditeur et qui sont donc à considérer comme "non documentées".[c]
Des langages comme C, C++ ou Delphi sont aptes à créer des DLL qui peuvent être exploitées par d'autres programmes. De nombreux outils de développement qui proposent des bibliothèques d'exécution à l'instar des MFC ou de la VCL de Borland proposent soit une liaison statique (intégration directe du code dans l'exécutable) soit une liaison dynamique (la bibliothèque est alors à distribuer sous forme de DLL).
L'utilisation de DLL permet de mettre à disposition du code et de rendre modulaire l'architecture d'une application. La mise à jour de celle-ci peut également se faire en remplaçant uniquement les DLL obsolètes. Néanmoins, l'utilisation de plusieurs versions concurrentes de DLL est problématique sous Windows et conduit à certaines incompatibilités regroupées sous le terme DLL Hell.
Les DLL sont recherchées dans le répertoire courant, puis dans les répertoires inclus dans la variable d'environnement path comme c:\windows et c:\windows\system32.DLL signifie Dynamic Link Library, ou en français Bibliothèque de liens dynamiques, dans le cadre du Système d'exploitation Windows. Traditionnellement, le nom de ces fichiers se termine par l'extension « .dll ». Une DLL peut contenir du code ou des ressources qui sont alors rendus disponibles à d'autres applications.
Le code contenu dans une DLL n'est chargé qu'une seule fois en mémoire. Ainsi, lorsqu'un processus tente de charger une DLL qui est déjà en mémoire, le code existant est mappé dans la mémoire du programme sans qu'un second chargement soit nécessaire, gagnant de la place en RAM. Lorsque tous les processus qui exploitaient une DLL se sont terminés, suivant le type de la bibliothèque et les paramètres Windows, l'espace mémoire qui lui était attribué peut être libéré ou non modifié afin que les prochains programmes hôtes n'aient pas à réeffectuer l'opération de chargement.
Une DLL peut être liée statiquement ou dynamiquement à un programme. Dans le premier cas, le programme déclare explicitement avoir besoin d'une fonction contenue dans une bibliothèque et la résolution de liens est effectuée par l'éditeur de lien au moment de la phase de compilation du programme. Le programme inclut alors dans sa structure binaire la liste des bibliothèques nécessaires à son bon fonctionnement dans sa "table des exportations" (export table). Le chargeur de programmes de Windows vérifie alors lors de l'exécution du programme que toutes les DLL requises sont disponibles, et si ce n'est pas le cas, stoppe le chargement en affichant un message indiquant que des dépendances nécessaires à l'exécutable n'ont pu être trouvées. Dans le second cas, c'est le programme qui demande explicitement le chargement d'une bibliothèque durant son exécution à l'aide de l'API LoadLibrary afin d'obtenir un pointeur sur la fonction désirée. Cette dernière approche est plus pénible car elle nécessite un effort plus important de la part du programmeur, mais elle permet d'une part de ne pas empêcher l'exécution d'un programme lié à une bibliothèque dont l'existence sur le système hôte n'est pas certaine, d'autre part constitue parfois le seul moyen d'accéder à des fonctions qui ne sont pas déclarées dans les fichiers d'interface fournis par l'éditeur et qui sont donc à considérer comme "non documentées".[c]
Des langages comme C, C++ ou Delphi sont aptes à créer des DLL qui peuvent être exploitées par d'autres programmes. De nombreux outils de développement qui proposent des bibliothèques d'exécution à l'instar des MFC ou de la VCL de Borland proposent soit une liaison statique (intégration directe du code dans l'exécutable) soit une liaison dynamique (la bibliothèque est alors à distribuer sous forme de DLL).
L'utilisation de DLL permet de mettre à disposition du code et de rendre modulaire l'architecture d'une application. La mise à jour de celle-ci peut également se faire en remplaçant uniquement les DLL obsolètes. Néanmoins, l'utilisation de plusieurs versions concurrentes de DLL est problématique sous Windows et conduit à certaines incompatibilités regroupées sous le terme DLL Hell.
Les DLL sont recherchées dans le répertoire courant, puis dans les répertoires inclus dans la variable d'environnement path comme c:\windows et c:\windows\system32.
Y a pas besoin de trafiquer la démo pour qu'elle fonctionne, enfin ! Il faut juste mettre ces deux fichiers-là :Il a dit comme quoi c'était un fail de sortir une démo qu'il fallait trafiquer pour pouvoir jouer
Sinon j'aime bien le scénario, mais je pense qu'ajouter un système de sauvegarde automatique ne serait pas mal. Et puis je trouve (comme beaucoup de RPG faits sous RPG Maker XP) que les dégâts infligés et reçus sont trop aléatoires.
Link275 a écrit : Pour que votre démo fonctionne correctement, placez ces deux fichers (à télécharger en utilisant Enregistrer la cible du lien sous) :
http://mariouniversalis.no-ip.org/Forum ... hp?id=1213
http://mariouniversalis.no-ip.org/Forum ... hp?id=1214
A l'adress "Mario_et_pikachu_rpg_3_\Graphics\Characters".