GT Turbo

Orion_ : question, si on veut developper sur jaguar et qu'on a besoin d'un graphiste, est-ce qu'on peut emprunter ceux de jagware ? Ils ne sont pas attitrés a Jagware !! Si tu en trouves un qui est d'accord, bien sur enfin actuellement le manque de graphistes limite le choix, sinon commence ton projet avec des graphes bidon et dès que tout est en place on devrait pouvoir trouver quelqu'un qui pourrait t'aider. GT Sans dessin !!

cts : Heu...petite requete pour le nouvo CMS: - une gestion de CVS (1 admin par projet, avec le droit d'autoriser d'autres personnes à faire des updates) Il y aura un truc comme cela, ou certaines parties de forum seront reservé juste a l'équipe de developpement concerné. cts : C'est prévu ? kiki l'héberge ? Le RaZ'moket pourra te donner plus de détails. GT Un petit peu au courant

SCPCD : C'est clair que de toute facon le probleme est resolu SCPCD and Jag CF Powa !!!! GT En réseau !!

cts : Bah, c'est le bug connu non ? C'est une bonne question, j'ai un doute, enfin dans tous les cas de figure, j'ai juste posté cela car je trouvais cela interressant, après de toute façon SCPCD nous a règler le problème......Alors perdre du temps la dessus, moi ce que j'en dis.... GT

Azrael : Orion_ > Si j'ai bien compris le concept de Jagware (GT, Raz, SCPCD et Fredifredo en sont à l'origine), c'est un lieu de rencontre de gens qui veulent à la base développer sur Jaguar. C'est une sorte de groupement de compétences qui adhère ou pas selon l'humeur, l'affinité ou l'ambition aux projets proposés par les participants. Je dirais que personne n'est "obligé" d'apposer le logo sur une production, mais dans la mesure ou ladite production n'aurait pas vu le jour sans la communauté je pense qu'il est fair-play de l'y apposer. La responsabilité de ces propos n'engage que moi, toute rectification des auteurs du site est la bienvenue (Eh les gars ! me laissez pas tomber !!!) Pour moi c'est ok, 100% d'accord avec Azrael, si tu as besoin de graphistes tu poses la question a ceux ci, pareil pour la musique, le code, les routines mathématiques, voire les idées etc... Pour la marque Jagware, c'est pareil que l'avis a Azrael, par contre juste une chose obligatoire, veuillez citez dans les credits toutes les personnes qui y ont participé par respect envers ceci, mais je penses que les personnes présentes ici le font automatiquement donc c'est tout bon. GT D'acord avec Azrael

Pourquoi cherche un bug qui est connu par quelqu'un d'autre ? En farfouillant ici : http://www.mo5.com/obsolete/67-dossier-anecdotes-atari.html et si on descend plus bas on trouve ceci : Oui et le son était fait au DSP et le pauvre devait aussi gérer le fameux réseau qui d'ailleurs était buggué au niveau de la FIFO HARD de la puce obligeant à capturer chaque octet sous peine de le perdre ! Rodolphe Czuba et Thierry Schembri connaissaient déjà le bug !!! GT Mort de rire !!

templeton : Du genre toi tu réalises tous les décors, toi tu fait les fxs, toi tu fais tous les sprites, etc... Effectivement cela est une solution, on attend le nouveau site et on regarde si on arrive a trouver de nouveaux graphistes et a voir qui veut faire quoi, après il reste plus qu'à !!!! GT

templeton : Bref ce qui prend le plus de temps dans un jeu c’est le graphisme ! Alors imagine une prod amateur avec un seul infographiste qui ne maîtrise pas tout les domaines… Ce qui me fait le plus peur, ca sera quand plusieurs graphistes travailleront sur le meme projet, la différence dans le style, cela fait ètre un superbe avantage comme un massacre, il va presque falloir un 'comité de graphistes' qui puissent soit synchroniser tous leurs styles, soit qu'il puisse dire ce style je peux celui la pas. Ca va ètre 'bien prise de tete'. GT Chez les codeurs (Ca va presque ètre le camps des glandeurs !)

Orion_ : et ça: http://www.cs.umu.se/~mat97jkn/tng/96kb_demo/ visiblement de la 3D d'atari et pas qu'en C, mais 68k/gpu/blitter C'est bon je me souviens de cette démo, elle était dispo sur le site de DHS. On a d'abord droit a un logo atari 'gouraudé' et ensuite un tunnel avec un scrolltext, par contre je me souviens pas qu'il y a avait du son. GT En train de me souvenir

templeton : Doom ce n'est pas de la 3d mais du raycasting. Excuser mon ignorance mais par raycasting, on désigne la simulation 3d par des artifices 2d (Zoom, déformation, etc...) ? GT Trop en retard sur les termes !!

Je viens de débarquer il ont fait la fête içi, j'ai l'impression de pas ètre passer ici depuis 1 mois !! Donc en clair, si on veut du jeu rapidement, on recrute une vingtaine de graphistes ou on fait rien que du jeu 3d !! Meme pas marrant !! lol !! (On est bien dans la m...... ) Orion_ question ? pourquoi 6 mégas ? tu penses qu'une chanson fait cette taille là ? Ensuite SCPCD a dit qu'on risque d'avoir un certain débit qui rendrait la chose possible, sinon on peut décompacter en temps réel, certaines personnes le font et le faisait déjà sur un ST, qui est moins puissant. donc qui va se coltiner la version Jag du jeu ? Hein qui ? GT plus là.......

Moi il me faut toujours deux eproms (Une pour Azrael, et l'autre pour ma console de secours), on regarde cela en privé. GT

Je reprends du service sur ce programme qui j'espère pourra bientot arriver a une fin de son developpement, je travaille sur le gestionnaire de modules (Lecture et sauvegarde), la gestion sera dynamique, vous pourrez charger et 'dégager' directement un module depuis le programme, il y aura pas besoin de tout relancer. Voili, voila pour les nouvelles. GT perdu dans ce paquet de ligne de code

Orion_ : par contre sans jag cd :/ Et la Jag CF t'en fais quoi ? Une bonne carte CF de 512 Mégas, une bonne routine de compactage, cela devrait suffire pour mettre quelque musiques sympas sur la Jag !!! Après il reste juste le petit soucis pour le tapis, mais on devrait réussir a règler ce probleme. GT

Vous croyez qu'un jeu comme 'bust a move' vaudrait le coup sur Jag ? GT En train de me poser la question

J'ai repris mon travail sur mon gestionnaire de liste (de sprites) et certaines questions apparaissent, surtout une. Pour celui ci j'ai donc trois niveaux (le fond meme (Back), les sprites au second niveaux, et les compteurs), quand vous appellez la routine de sprite il faut maintenant lui passer le niveau dans lequel votre sprite doit apparaitre, c'est normal. La ou c'est moins marrant, c'est quand faut le liquider, vous preferez indiquer vous meme dans quel niveau il se trouvait ou on le fait en automatique, cela est plus de question de vitesse qu'autre chose. Car indiquer le niveau cela réprésente une instruction (68000, Gpu ou Dsp), alors qu'en automatique c'est un peu plus long. C'est juste pour avoir un truc qui décoiffe. Enfin si on analyse, on a plus de chance de 'killer' un sprite qu'un fond ou qu'un compteur. donc je vais le mettre en mode manuel (pour l'automatique je ferais une seconde version), ce qu'on veut c'est que ca tourne en une Vbl après le reste !!! GT Rapide (Enfin j'espère !)

Orion_ : bon c'est approximatif hein ... donc en gros est-ce que c'est ça ? Pour ma part cela a l'air de coller, la seule chose, pour ceux qui veulent jouer les c.... c'est la flèche blitter-ram qui peut ètre dans le deux sens, cause lecture a partir de la ram et écriture en ram, mais bon c'est un détail, c'est du 'chipotage'. La seule personne qui pourra vraiment te confirmer la chose est toujours le meme : SCPCD. Orion_ : moi au depart j'etait pour le principe de dev suivant: -écran virtuel sur lequel on blitte tout avec le blitter -object liste avec un gros sprite qui represente notre écran virtuel -et on prune le tout sur la télé mais en relisant les caractéristique de l'object processor, ça peut etre très interessant de l'utiliser, vu qu'il a l'air rapide (2 pixels par cycle en 24/16bits, contre 1 pixel par cycle en 8bits ou moins) et qu'en plus il permet la transparence avec la couleur 0 (pour les sprites donc) ça permet de soulager le blitter et de gagner du temps je pense. Ta première idée est effectivement celle qui apparait dès que l'on pense a ceci, mais je me posais la question si dans certain cas de figure (Des trucs genre Doom) cela sera pas plus rapide de définir certains sprites et de jouer avec, par exemple un sprite pour le sol, un pour la partie principale et un pour le ciel ou plafond. Pour éviter dans certains cas de devoir redessiner alors qu'il n'y en a pas besoin. Mais bon cela reste toujours une idée, donc faut voir l'avis des autres et sinon ESSAIS. Orion_ : je vois pas trop encore comment gerer du scrolling en hardware (je pense pas que ça soit possible avec l'OP, donc au blitter ?) Cela dépend toujours de ceux que tu veux scroller, on va partir du premier cas un plan complet, effectivement on pourrait utiliser l'.O.P. en utilisant une technique assez spéciale sur la gestion mais vu que coté ram nous sommes limités a 2 mégas, la solution blitter est a encourager. Par contre la c'est un peu plus 'Funky', car ces malins d'Atari n'ont pas prévu certains cas de figure (Et pourtant cela a été pensé sur les blitters micros !), donc parfois un peu de bricolage ou de réflexion vont s'imposer. Exemple, si tu veux faire scroller tout l'écran vers le bas, d'un premier point de vue on aurait juste a recopier tout l'écran une ligne plus bas, ben... raté !! J'ai fait l'essais, la première ligne est recopié sur la seconde, mais après la seconde (Qui maintenant est la première !) sera recopié sur la troisième, en fin d'opération on arrive juste a recopier la première ligne sur tout l'écran. Donc je suis passé a tout recopier mais en partant de l'arrière, mais soit j'ai pas tout compris soit c'est impossible de tout recopier en un bloc en marche arrière (Ou ceux mais en pixel mode, qui est très très lent). Donc tu recopies lignes par ligne en partant d'en bas. Tant qu'on est dedans, le blitter marche en deux modes, le pixel mode et le phrase mode. Le pixel mode est plus pratique, car on peut travailler a l'ordre du pixel, par contre il est d'une lenteur maladive. Le phrase mode est ultra rapide mais permet que de travailler sur des phrases (8 octets) ce qui en 16 bits fait 4 pixels, donc scroll par pas de 4. J'ai commencé a travailler sur une technique utilisé dans les démos pour pouvoir faire du scroll par pas de 1 en phrase mode mais cela va manger de la ram. Donc ici aussi toute bonne idée est attendu a bras ouvert ? Orion_ : bref, je vais finir de lire la doc et je poserais d'autre question ici, si vous me le permettez ^^ Pose seulement !! GT En phrase mode P.S. : Je viens de revoir ton dessin encore une autre petite chose, tu peux utiliser le blitter pour recopier les codes Gpu et Dsp dans leur ram respective, pas qu'au 68000

Petit H.S : Fredifredo : GT a ça dans ses stocks ... ( il a d'ailleurs des choses qu'il ne soupçonne même pas sur son CD que je lui ai gravé ... il a tout mon DD jaguar moins 5 Mo ! ) Fredifredo si tu savais le temps qu'il me faudrait pour examiner tout ton CD, cela me mettrais encore un moi de retard dans les dents !! Et par exemple ce genre de convertisseur j'y mettrais un oeil seulement quand un moteur 3d sera dispo (Car cela m'étonnerais beaucoup que le format le plus pratique soi le meme que celui qu'Atari utilisait a l'époque !), pour l'instant cela m'arrange je peux travailler sur le reste. H.S. Clos GT

Orion_ : et dans le repertoire y'a un fichier .3ds Si je ne me trompes pas .3ds c'est l'extension de truc 3d sur PC ? Non ? Car faut savoir Atari fournissait un convertisseur pour convertir ces fichiers 3d en format pour leurs routines. GT En 2D !!

SCPD fait monter la pression !! On attend tous les détails de cette merveille !! GT

Ca fait toujours plaisir un codeur de plus !! Bienvenue !! GT

Fredifredo : même avec des images 256 couleurs ... C'est peut ètre a cause de cela, il faut plus de couleurs !! GT En train de sortir !!

Quelques détails supplémentaires, j'ai encore oublié de préciser que l'adresse de chargement de la routine doit ètre aligné sur un mot long (Donc multiple de 4) et que la routine meme ne fait que 300 octets, faites pas gaffe a la taille du fichier .o, Madmac rajoute pleins de trucs sans intèrets !!! La routine d'installtion ne recopie que le code meme. [english] Starcat has asked me for some details, and he has right my english doc is not very good, so some additionnal explanations : Unpack_adr is the adresse where the routine will be installed in ram (Gpu or Dsp ram) ($f03000, $f1b000 any adresse but must be long word aligned) When calling, if d0=0, the data will be unpacked and the routine will be finished only when unpacking was done. If d0<>0, the routine will come back immediatly, not when the Gpu or Dsp has finished, that means you can do something else during the depacking time (Calculating and unpacking in same time, loading data on CF and unpacking, etc...) Don't look on the .o file, the rout do only 300 bytes !!! (In .o file, you can find 'symboles' and a lot of other things, we don't need !!) The installation rout only copy the rout nothing else Do you have any questions ? Ask !! GT Turbo

C'est bon pour moi, je retournes a mes lignes de code, après trois jours a faire que manger (Beurk...... meme un petit gateau me ferait vomir ) je reprends du service !! GT Perdu dans mes lignes mais heureux de cela

J'ai presque fini de te mettre au propre la routine de compactage. GT Dessus