-
Content count
2,138 -
Joined
-
Last visited
-
Days Won
5
Everything posted by Zerosquare
-
jeux amateurs: quelles limites graphiques? UP 04 juin
Zerosquare replied to gaban's topic in Graphism
On l'espère bien Pour plus d'infos sur la JagCF : ici (mais certaines infos sont un peu périmées, il faudrait qu'on remette ça à jour) Pas de souci, on est là pour ça -
jeux amateurs: quelles limites graphiques? UP 04 juin
Zerosquare replied to gaban's topic in Graphism
Concept rigolo, et j'aime bien le style du dessin -
jeux amateurs: quelles limites graphiques? UP 04 juin
Zerosquare replied to gaban's topic in Graphism
C'est plus complexe à programmer, les performances sont moins bonnes et ça demande 4 fois plus de RAM que le 320x240. Je pense que c'est pas une bonne idée pour commencer -
jeux amateurs: quelles limites graphiques? UP 04 juin
Zerosquare replied to gaban's topic in Graphism
Tu peux doubler la résolution horizontale pour avoir du 640x240, mais comme l'a dit Matmook, ça demande deux fois plus de RAM. Un autre truc casse-pieds, c'est que les pixels sont rectangulaires, donc ça complique le boulot des graphistes. D'ailleurs, je ne pense pas qu'il y ait de jeu officiel qui se serve de ce mode graphique, à part quelques-uns mais uniquement sur l'écran de titre, si j'ai bonne mémoire. On peut aussi doubler la résolution verticale pour obtenir du 320x480 (ou 640x480 si tu combines avec la technique précédente), mais c'est une bidouille non documentée (c'est un truc sur lequel j'ai travaillé, ce n'est pas complètement finalisé d'ailleurs), et ça a les mêmes inconvénients. Le HUD, c'est la zone qui contient les informations destinées au joueur : score, nombres de vies restantes, etc. Exemple : sur la version Jaguar de Raiden (qui a été critiquée pour avoir un HUD qui prend trop de place), c'est la partie droite de l'écran : -
jeux amateurs: quelles limites graphiques? UP 04 juin
Zerosquare replied to gaban's topic in Graphism
Une bonne base c'est 320x240, ou un peu plus si tu ne veux pas avoir de bordure noire en mode PAL. Pour un shoot vertical, tu peux choisir de mettre le HUD sur les côtés gauche et/ou droit, donc tu auras une zone d'action moins large. Mais c'est toi qui vois, si tu veux faire du plein écran, ça ne posera pas de problème de performance. Oui, aucun souci. Oui, les sprites sont zoomables. Par contre, si tu veux deux parties avec des niveaux de zoom différents, il faudra décomposer ton image en 2 sprites distincts. -
On s'est déjà parlé, mais bienvenue quand même PS : pour ton avatar : l'avatar et la photo personnelle sont deux choses distinctes. Si tu veux avoir un avatar affiché à gauche de tes messages, clique sur "Mes contrôles" dans la barre bleue en haut de la page, puis "Modifier mon avatar" à gauche (dans la section "Profil personnel").
-
jeux amateurs: quelles limites graphiques? UP 04 juin
Zerosquare replied to gaban's topic in Graphism
Ça c'est une question à poser aux graphistes, je ne sais pas trop comment ils font leur cuisine Pour de l'animation bitmap, ça n'a pas trop d'importance du moment que le résultat est une série d'images 2D (un strip, c'est ça ? j'ai un doute sur le terme) Pour le vectoriel, on n'en a encore jamais utilisé (dans Another World, ce sont les animations d'origine, rotoscopées à la main par Éric Chahi il y a un sacré bail), mais je sais qu'Orion_ (un des programmeurs d'ici) a déjà réussi à exporter des animations réalisées sous Flash pour les incorporer dans du code. Disons qu'à partir du moment où ton outil d'animation est capable de sortir une liste des coordonnées des sommets des polygones en fonction du temps, on peut se débrouiller. -
jeux amateurs: quelles limites graphiques? UP 04 juin
Zerosquare replied to gaban's topic in Graphism
Rien n'est sûr pour le moment, mais une sortie sur cartouche est potentiellement dans les cartons. C'est sûr Pourquoi pas. Ce qui nous manquait pour le moment c'est un graphiste qui fasse de l'animation vectorielle, mais vu que tu te proposes... -
jeux amateurs: quelles limites graphiques? UP 04 juin
Zerosquare replied to gaban's topic in Graphism
SCPCD et moi sommes ingénieurs en électronique et travaillons sur le projet JagCF (une extension pour la Jaguar qui ajoute un lecteur de carte Compact Flash, un processeur plus rapide et de la mémoire supplémentaire, entre autres). Disons qu'on a tout ce qu'il faut pour faire fabriquer une cartouche "sur mesure" sans difficulté Le souci, c'est qu'il y a un coût fixe pour la fabrication d'un PCB, indépendamment du nombre d'exemplaires commandés. Concrètement, ta cartouche unique va te coûter facilement 100€ ou plus ! (on peut baisser le prix en faisant fabriquer en Chine, mais la qualité n'est pas toujours au rendez-vous) Pour le portage d'Another World, c'est un peu particulier. Nous (j'ai un peu participé au projet, mais c'est SebRmv qui a fait 95% du boulot) sommes partis des sources des versions Atari et Amiga que l'auteur a généreusement accepté de nous fournir. Cependant SebRmv a préféré recoder quasi-intégralement le jeu plutôt que d'adapter le code existant. De plus, Another World avait été prévu à la base pour fonctionner sur des machines moins puissantes que la Jaguar. EDIT : SebRmv a répondu avant moi -
jeux amateurs: quelles limites graphiques? UP 04 juin
Zerosquare replied to gaban's topic in Graphism
Tout dépend Pour faire un jeu multiplateformes, le concevoir pour ça dès le départ facilite énormément les choses, surtout si la puissance des machines sur lesquelles le jeu doit tourner sont très différentes. Je m'explique : - il n'y a que deux langages de programmation supportés sur Jaguar : l'assembleur et le C, avec des restrictions pour ce dernier. Un jeu conçu en C "simple" sera beaucoup plus facile à adapter qu'un jeu en C++, C#, objective-C, etc. - l'accès au matériel se fera de façon complètement différente suivant la plateforme, donc il est intéressant de séparer dès le départ le code en modules raisonnablement indépendants (moteur de jeu, gestion graphique, gestion audio, gestion des contrôles...) - la mémoire disponible sera beaucoup plus limitée sur Jaguar - etc. On pourrait, mais il faut développer un PCB particulier pour ça, et le faire fabriquer. À moins d'être sûr d'en vendre une "grosse" quantité, l'addition risque d'être salée. Avec ceux que tu veux ! Il y a des outils pour convertir les formats d'images standards (BMP, PNG...), donc tu es totalement libre d'utiliser les outils qui te conviennent le mieux. Oui. Grosso modo, la place prise en mémoire par un graphique, c'est : largeur * hauteur * nombre de bits par pixel / 8. Après, on peut compresser les graphiques pour gagner de la place, mais il doivent être décompressés "manuellement" avant de les afficher. On peut utiliser soit de la compression sans pertes (LZ77, plus ou moins comme le PNG), ou de la compression à pertes (BPEG, qui ressemble au JPEG, avec les mêmes défaut visuels quand on compresse trop). Les formats supportés sont : - 1 bpp (2 couleurs), 2 bpp (4 couleurs), 4 bpp (16 couleurs) et 8 bpp (256 couleurs), avec une palette redéfinissable (mais qui est la même pour tous les sprites) - 16 bpp, soit en RGB 5:6:5, soit en CRY (format spécifique à la Jaguar, avec 256 teintes et 256 valeurs de luminosité) - 32 bpp dont 24 utilisés, c'est les 16 millions de couleurs "classiques". Mais on utilise rarement ce mode, car il consomme beaucoup de mémoire et diminue les performances. Des sprites différents peuvent avoir des formats différents, par exemple on peut avoir un fond en 65536 couleurs avec des sprites 256 couleurs par-dessus. Il n'y a pas de gestion du canal alpha, par contre la transparence "simple" est gérée (chaque pixel est soit 100% opaque, soit 100% transparent). Il est possible de créer quelques effets de lumière en utilisant le mode CRY, mais c'est assez limité. C'est une très bonne chose -
jeux amateurs: quelles limites graphiques? UP 04 juin
Zerosquare replied to gaban's topic in Graphism
Bienvenue ! Disons qu'en 2D c'est déjà pas évident comparé aux autres consoles, en 3D c'est encore pire (les moteurs 3D sont presque 100% logiciels car il y a très peu de support matériel, et les exemples fournis par Atari étaient plutôt nazes). Coup de chance pour toi, en tant que graphiste tu n'auras pas à te soucier de cette partie-là, surtout que sur ce forum on a davantage de programmeurs que de graphistes et de musiciens En fait, il y a plusieurs raisons : - dans la communauté de développement amateur sur Jaguar, on trouve une grosse proportion de programmeurs, mais (très) peu de graphistes. - vu la difficulté de développement, beaucoup de projets sont plus ou moins abandonnés avant la fin, et en général c'est la partie programmation qui est faite en premier - la machine peut techniquement afficher de très grands sprites 2D en 65536 ou 16 millions de couleurs, mais est malheureusement limitée par ses 2 Mo de RAM interne (partagée par tous les composants, il n'y a pas de mémoire vidéo ou audio dédiée), qui sont vite remplis dès qu'on commence à utiliser des graphiques de grande taille ou avec beaucoup de couleurs. De plus, pendant longtemps, la seule méthode de développement qui ne nécessitait de matériel coûteux consistait à stocker l'intégralité du programme et des données (graphisme et musique) dans la RAM de la console, ce qui réduisait les possibilités comparé aux jeux officiels sur cartouche qui disposaient de 2 ou 4 Mo supplémentaires ; si tu connais le Net Yaroze sur PS1, c'est grosso modo le même principe. - enfin, pour ne froisser personne, on va dire que "certains" ne se foulent pas trop Non, ce n'est pas plus compliqué d'animer un grand sprite qu'un petit. Pour les raisons qui font qu'on n'en voit pas plus souvent, voir la question précédente Je ne connaissais pas ce jeu. Mais en me basant sur la démo présente sur le site de l'éditeur, ça me semble raisonnable. ...et tu es loin d'être le seul ! Mais Atari n'a jamais été réputée pour la compétence de son management, et sur la fin ils ont enchaîné les bourdes... Pas de quoi -
SebRmv : maybe you could try running the COMMAND.COM shell from a MS-DOS or Windows 9x disk inside DOSBOX, instead of the integrated shell in DOSBOX. That should fix the problem with environment variables.
-
Have you tried using an environment variable to replace the arguments on the command line ? (I don't know if it works on DOSBOX)
-
AFAIK the only thing you have to do is to say you used the library in the credits, even if your game is commercial. Here's what SebRmv told me (actually I asked him about using C functions in ASM, but it must be the same) : - in an ASM source file, functions must be declared that way : .globl _myfunc if the C function name is myfunc - d0, d1, a0 and a1 can be modified ; other registers must be preserved - the return value is written into d0 - all arguments must be longwords - arguments are pushed on the stack, starting with the rightmost one ; the call is made using jsr ; the caller must adjust the stack pointer after the call For example : C : myfunc(a, 5); ASM : move.l #5, -(sp) move.l a, -(sp) jsr _myfunc addq.w #8, sp
-
(désolé, j'ai pas trouvé d'autre gâteau Resident Evil)
-
J'en doute
-
Congratulations for this awesome job
-
En général c'est du 320x240 ou approchant, éventuellement un peu plus pour couvrir la zone d'overscan des moniteurs.
-
Je trouve ça d'un très bon niveau, je pense que tes talents ne vont pas tarder à être mis à contribution