Zerosquare

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").

Ç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.

Il sortira uniquement sur cd ou éventuellement sur cartouche?

Rien n'est sûr pour le moment, mais une sortie sur cartouche est potentiellement dans les cartons.

 

100€ pour une cartouche unique, ça me semble raisonnable. c’ est un peu comme quand je fais imprimer mes illustrations, ou qu’ elles se retrouvent sur une carte. C’ est quand même très grisant d’ avoir son boulot concrétisé dans ses mains!

C'est sûr

 

Pour en revenir à another world, j’ avais vu il y a longtemps un makking of, et ce qui me reste en mémoire, c’ est le principe de graphismes vectoriels, qui permettaient de restreindre les dépenses en ressources mémoire. Un tel système ne s’ est pas revu depuis flashback (si je ne m’ abuse). Pourquoi ne pas s’ en servir sur jaguar, ou même l’ améliorer? Another world tenait sur 2 disquettes et tourner sur des machines moins puissantes, avec un même traité, on pourrait peut-être gagner en détails?

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...

Concernant la cartouche, vu que mon ami développe et réalise des cartes mères pour diverses applications, au pire, en réaliser un exemplaire peut être jouable, si l’ on s’ appuie sur une cartouche déjà existante.

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)

 

Ah oui, another world est maintenant adapté sur jaguar, il sont partis d’ une version existante si je crois avoir compris.

La conversion est donc plus facilement envisageable qu’ une création pure et dure?

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

Par contre, réaliser un jeu sur cartouche, si on passe les sources à l’ un d’ entre vous, c’ est faisable?

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.

 

A-t’ on la possibilité d’ augmenter la taille de la ram si la cartouche possède une puce dédiée, à l’ instar de la super FX sur super nintendo?

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 quels genre de logiciels et quels formats peut-on réaliser des graphismes pour jaguar?

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.

 

Des graphismes monochromes prendraient donc moins de mémoire que des graphismes colorés?

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é.

 

Encore des questions, désolé, mais j’ ai une idée en tête, avec une mise en scène précise et simple, qui me semble tout à fait réalisable.

C'est une très bonne chose

Bienvenue !

 

-La jaguar me semble une machine techniquement taillée pour des jeux 2D arcade, mais elle traine une réputation d' architecture très difficile à programmer: est-ce plus souple si l' on se contente d' un jeu entièrement en 2D ou c' est la même chose en 3D?

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 navigant sur les différents sites de bidouilleurs jaguar, j' ai pu constaté que la plupart des programmes "homebrew" étaient très limités graphiquement (loin de moi l' idée de dénigré leur travail, je compare par rapport aux possibilités théorique de la machine) alors je me demande si c' est dû à la difficulté de programmer des graphismes plus détaillés, ou c' est uniquement par choix pratique?

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

 

-si je veux réaliser par exemple un sprite animé qui avance dans un décors, est-ce que la difficulté de programmation augmente en fonction de la résolution, sans dépasser les limites standards? Car sinon, pourquoi les jeux homebrew ne possèdent pas en général des éléments graphiques plus détaillés, plus grands?

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

 

-Un jeu comme "canabalt" peut-il être réalisable sur jaguar?

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.

 

Voilà, je me pose beaucoup de question, car il me semble que le potentiel de la machine est bien là. Quand je vois certains projets officiels qui furent abandonnés et qui pourtant auraient pu en faire une machine plus exceptionnelle, je reste perplexe.

...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...

 

Merci pour votre patience!

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.

Here's a cartridge dumping tool I wrote. It can be used to backup your Jaguar games for various uses : playing in emulators, preserving betas versions and prototypes, etc.

 

It's pretty slow, but very reliable, as there are multiple checks done to be sure that the data isn't corrupted.

As well as standard cartridges, Atari Flash carts are supported too.

 

Requirements :

- a PC running Windows (95, 98, 2000, XP or Vista : it doesn't matter. Windows 7 not tested, but it probably works too.)

- a BJL cable connected to a standard (not USB or PCI/PC Card/ExpressCard) parallel port

- a way to upload a Jaguar program with a game cartridge inserted (currently, the only option is a BJL-modded Jaguar)

 

See the included text file for more detailed instructions.

 

For programmers, the sources are included. Unfortunately, they're in French and almost without comments, as they from an older project which wasn't supposed to be publicly released.

 

Planned future developments :

- adding support for PCI/PC Card/ExpressCard parallel ports

- adding Linux support

- adding backup/restore features for the cartridge's EEPROM contents (used for saving states, hiscore lists, etc.)

- adding backup/restore features for the Memory Track

 

bjl_dump.zip

 

overridex has been kind enough to port it to Linux :

bjl_dump_linux.zip

Thanks to him !

The next version will be unified and work with both OSes.

Have you tried using an environment variable to replace the arguments on the command line ?

(I don't know if it works on DOSBOX)

And maybe just as important, is there any license or limitation connected to using the remover's lib with C on the Jag?

AFAIK the only thing you have to do is to say you used the library in the credits, even if your game is commercial.

 

Also can somebody tell me how C and asm code can pass parameters to each other in case I want to put parts of my own asm code in a c program?

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

Great

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

Good job !

Un peu de gâteau fluo pour notre ami Stabylo ?

 

Joyeux anniversaire !

Once again (and two days late, sorry), happy birthday kskunk !

Today is not his birthday, he explained it here