Zerosquare

Those last few days, I started playing with audio again.

 

First thing : apparently, Atari eventually realized something was wrong. The left/right channels swapping bug is actually documented in the later versions of the documentation (I used the scans from Tyrant, which are the most recent version I know about - the JagRef revision 8 PDF is actually an older version). Well... "documented" is a strong word. They removed the timing diagrams, added alternate definitions of the registers called L_DAC and R_DAC, and some text saying "Note that these registers have right and left swapped on purpose". You didn't think Atari would have admitted they'd made a mistake, did you ?

 

It seems the mistake was discovered quite early, because definitions for L_DAC and R_DAC can be found in Jaguar.inc files dating back to 1993, and they are correct (L_DAC = $F1A14C and R_DAC = $F1A148).

Note that the definitions of L_I2S/R_I2S, LTXD/RTXD and LRXD/RRXD have not been changed. So if you don't want your channels to be swapped, you should use L_DAC and R_DAC instead of those.

 

Another related and interesting question : which register should be written first, L_DAC or R_DAC ? The Atari sample code writes to R_DAC first. I tried both, and it doesn't seem to make any difference.

 

So this part of the puzzle looks pretty clear now.

 

But there's still something strange about the SMODE register. Atari sample code enables the interrupt on the falling edge of Word Strobe. Before, I thought they got it wrong, and that it should be set to the rising edge instead.

But it appears that it depends on the sample rate. For low sample rates, the channels are in-phase with the rising edge setting, and out of phase by one sample with the falling edge setting. For high sample rates, it works the other way ! So back to square one...

The Jaguar is definitely a mysterious animal

 

(by the way, if you think a delay of one sample between two audio channels is negligible, check this article. Sony had a similar bug in some of their MiniDisc players, and it can indeed cause problems.)

C' est quoi une grille avec de tiles?

Ça consiste à construire un décor en assemblant des "blocs" de graphismes sur une grille, comme ceci :

 

En gros, ça ressemble à un passage du jeu blazing star (3:50)

Je cherche simplement à comprendre comment ils ont fait.

Ça peut être un scroll à parallaxe classique (plusieurs plans superposés qu'on fait défiler à des vitesses différentes pour simuler la profondeur -- le plus proche est celui qui avance le plus vite), mais ça m'étonnerait parce qu'il faudrait une grande quantité de plans pour avoir un effet de cette qualité, à en juger par la vidéo. Je pense plutôt que c'est une animation précalculée d'une dizaine ou d'une vingtaine d'images, vu que le fond se répète régulièrement. Ça utilise beaucoup de mémoire, mais sur Neo-Geo les cartouches sont justement énormes...

 

I converted the files to binary (using a program written in 5 minutes ^^), and all of them display fine using the tool I posted yesterday. CRY15 and RGB15 files also work when using mixed-mode. So maybe there's something wrong with your display code, or your assembler is somehow generating junk...

 

Here are the files in binary form if it's useful : space.zip

Un shoot est-il plus simple verticalement ou horizontalement (cette dernière est ma préférence)?

Sur Jaguar, la difficulté est équivalente.

 

par exemple de la fumée qui s' échappe des cheminées, 'est l' ensemble du plan qui est animé, un peu comme un sprite géant, ou bien c' est des éléments superposés?

Sur ce point, tu peux faire quasiment ce que tu veux : un plan unique, une grille avec des tiles, un plan fixe + des sprites par dessus pour les endroits qui sont animés... Grosso modo, tu peux considérer que tu as un nombre de sprites illimité (dans la limite du raisonnable !), avec les tailles, positions et ordre de superposition que tu veux.

 

SuperFly DX (un jeu amateur sorti récemment) est un bon exemple de ce qu'il est possible de faire :

(ça commence à 1:00).

 

 

Autre chose, vu que je travail aussi en 3D, si j' élabore un décors en 3D, avec une caméra qui suit la progression sur une trajectoire linéaire, ça doit être inclu comme une "video" de fond, ou alors une 3D gérable par la console?

Sans aller jusqu' du radiant silver gun, juste un plan qui propose un effet de profondeur, comme pulsar (je crois) sur neo.

Là j'avoue que je n'ai pas trop saisi... la vidéo en temps que tel tu peux oublier, il n'y aura jamais assez d'espace mémoire pour la stocker. Pour ce qui est de la 3D, je ne vois pas trop ce à quoi tu fais référence. Tu aurais un exemple (une vidéo, idéalement) ?

Here's a quickly-made viewer / converter for CRY, RGB16 and mixed-mode pictures : view_jag.zip

Check readme.txt inside the archive to see how it is used.

Seb : I never used mixed mode, sorry.

Just tried Zeros convertors and they work great THANKS!

You're welcome

 

SebRmv : to view CRY pictures on a PC, there's JagView, but it displays the colors slightly wrongly (so it's not a good tool for debugging). If I can find some time, I'll make a PC viewer for CRY files.

 

Sounds like a fun idea

 

Here's a fixed version which should handle transparency correctly :

bmp_cry.zip

Usage is : bmp_cry input_file.bmp output_file.cry

 

Only uncompressed 24-bit BMP files are supported.

Lines in the output file directly follow each other (in other words, they're not padded to an integer number of phrases).

 

And here's a version without the dithering :

bmp_cry_nodither.zip

Never mind, it's working fine now

And here are my photos : http://zerosquare.free.fr/ac_2010/.

 

Photos/videos from other people can be found in the first post of this topic.

Also, neither your or zerosquare's convertors handle RGB 0,0,0 (black) correctly (for transparecny) - yours outputs $0001, and Zero's output's $something01 (can't remember) - a search and replace with $0000 fixes this but it's a bit of a pain.

I know about that bug, and it's even mentioned in the mail I sent you

 

Basically it's because my converter uses dithering (Floyd-Steinberg, to be exact) to avoid color banding artifacts, so perfect accuracy is not guaranteed. I added a special case to fix the transparency issue in my (unreleased) RGB16 converter, but I didn't backport it to the CRY one. I'll do it as soon as I can

 

(I thought that SebRmv's converter handled it and worked fine, that's why I didn't release mine).

 

Further note - *both* your convertors *always* get the first word in the file wrong (pixel 0,0).

 

eg, give it a pure black bitmap, and the entire file will contain a single repeating word, with the first word +1 intensity.

Strange. This one is an unknown bug. I'll look into it.

 

Hope this helps.

It sure does

And here are the screenshots.

 

Black Hole by Fadest :

 

Dragibug Attack by Matmook :

 

And the new C.V.S.D title screen :

Nice

 

Is the website supposed to be ready yet ? All I see is a static picture...

Merci Pocket (rien à voir avec Silicium?)

C'est pas le même que celui de Silicium en effet, même s'ils sont collectionneurs tous les deux

 

Don't forget Xerus too

 

Since it seems that some of us are tired of pressing buttons again and again, here's something to help : a Jaguar pad autofire mod.

 

It includes a potentiometer to choose the fire rate, and an optional switch to disable the autofire mode. The autofire only affects the B button ; other buttons work normally.

 

The mod can either be installed inside a Jaguar pad, or built as an external pass-through box, for those who don't want to modify their controllers.

 

Warning : this has not been tested yet, as I don't have all the components. The topic will be updated once I get time to actually buy what's needed and build a prototype.

 

Here's a preliminary schematic :

 

Feel free to comment

Well done

Nah, your's fine too

Joyeux anniversaire

Thanks to overridex, a Linux version is now available

See the post above for details.

Merci!^^

 

J' ai pas trop regarder à quoi correspond la jagcf, mais je suppose que ça va grandement améliorer les possibilités de la jaguar.

Ca risque de relancer un peu plus la scène homebrew du coup, non?

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)

 

Je risque donc de venir vous embêter plus souvent, vous poser des questions techniques.

 

Pas de souci, on est là pour ça

Concept rigolo, et j'aime bien le style du dessin

 

640X480 demande un effort de programmation supplémentaire ou c' est juste un problème de taille mémoire?

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

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 :

Quelles seraient les résolutions idéales pour un shoot vertical? (en pixels)

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.

 

-Peut-on facilement inclure 2/3 niveaux de plans ayant chacun un défilement différent?

Oui, aucun souci.

 

-Un sprite peut-il être composé en 2 partie? Une partie animée à "taille fixe" et une autre à "taille variable"?

En gros, le sprite du jouer pourrait grossir de plusieurs fois sa taille et ainsi perdre de sa vitesse de maniement exponentiellement.

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.