Infos sur la Vampire
-
C’est génial de faciliter la vie aux développeurs dès la conception du hardware! (enfin de la programmation du FPGA )Bravo la team Apollo! 🙂
merci flype
rajoute nous des coprocesseurs hard pour manipuler des millier de sprint de 1 pixel de côté à 1025 de côté et une centaine de scroling de 1 pixel à 3200 pixel de longue et largeur 🙂
je reve déjà de toutes les convertions des jeux de la neo geo et logiciel facile à utiliser pour modifier les decors et les objets en plus en les rajoutantaie, ça pique un peu les yeux…
Only amiga makes it possible
XTR Games
Magic Productions
tilde@cyb0rg Un peu beaucoup oui 🙂
@Receptor
Je ne développe pas le core, c’est Gunnar V.B. et quelques autres. Pour ma part, je suis principalement testeur, je teste le core en faisant des suites de tests en ASM ou en C, et je programme ensuite quelques trucs pour le plaisir et pour la communauté.A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.Hello
>des coprocesseurs hard pour manipuler des milliers de sprites
J’ai rien lu la dessus : ça semble pas prévu
A mon avis il vaudrait mieux une fonction (nouvelle) de l’OS Vampire, hyper optimisée ASM+AMMX qui tracerait les sprites/tiles plutôt que de laisser les devs faire chacun le propre code de traçage plus ou moins bon
En plus ça masquerait les éventuelles évolutions du CPU ou de l’AMMX puisque seule cette fonction les taperait directement, ça permettrait aussi aux nouveaux progs de tourner sur les anciens Amiga classics en leur ajoutant aussi une version soft de cette fonctionQQue chose comme la fonction graphics->CompositeTags de l’OS4 qui gère le tracage avec transparence/rotation/redimensionnement en 15/16/24/32 bits
(Je peut d’ailleurs offrir les sources de mon PatchCompositeTags à la Team Vampire si ils s’engagent à ne jamais les diffuser)
Alain
hello flype ok pas de souci 😉
salut thellier
Oui cela aurait été super si ont pouvait ce pencher sur un tel hard sprint ou objet, imaginer la faciliter de créer des jeux sans ce soucier de développer constamment sont moteur de jeux tout serait en hard pour faciliter le développement du jeux lui même cela serait un gain de temps considérable. et pas de ralentissent suivent ce que fait le programme.Excusez moi des fautes
Amigaouf, enlève ton masque, on t’a reconnu !
Non mais le Bescherelle est de rigueur pour vous deux ^^
voila 🙂
Oui c’est plus ou moins le plan, et en effet, çà masquerait le code AMMX, on explore cette voie depuis quelques temps à différents niveaux. Quant au PatchCompositeTags, c’est super sympa 🙂 on peut en reparler un peu plus tard avec grand plaisir.
L’intégration dans le hard de trop de (bonnes) choses n’est pas (toujours) une bonne idée. D’abord, çà prend de la place, beaucoup de place dans le FPGA, et doit donc être très sérieusement pensé; ensuite le couple CPU/SIMD (AC68080/AMMX) est déjà très flexible et rapide et permet d’implémenter de manière plus flexible des fonctionnalités. La clef réside dans une (ou plusieurs) librarie bien conçue, qui s’occupe des tâches ingrates pour le codeur (et surtout plus fiables).
A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.Y’a déjà picasso96 ou / et SDL et même la graphic.library du système qui existent pour tracer des tas de sprites (enfin c’est plutôt des tiles en fait mais dans le principe …)
A mon avis c’est bien plus intéressant de développer des versions optimisées des libs et des drivers existants que de s’emmerder a réinventer la roue. En plus ça permets au passage d’en faire profiter aussi les programmes déjà existants qui les utilisent.C’est exactement là (ces libs) que nous faisons nos expériences, entre autres. Concernant la graphics.library c’est délicat, le code est propriétaire et cossu, faudrait que çà bouge de ce coté là (libération de l’OS3.x), il y a aussi Aros68k (qui tourne bof bof, la task force aros va devoir faire des miracles pour le rendre utilisable sur autre chose qu’un cpu x68 ou arm), ou EmuTOS/FreeMiNT (qui tourne super), donc il faut penser ‘large’, idéalement les routines de tracé devraient être OS-independant, mais ce n’est pas si simple. Bref, soyez certain que de notre coté les options sont étudiées, pour faciliter la vie des développeurs; à terme.
A part çà, un nouveau membre nous a rejoint il y a quelques jours, il travaille sur une (vraie) conversion de
Ghouls and GhostSuper Ghouls and Ghost :Ce que vous voyez là c’est le moteur du jeu, cross compilé depuis le PC du développeur, avec GCC 2.95.3 x86 pour m68k, ensuite le binaire est lancé sur la vampire depuis un dossier partagé (via Envoy).
A600 Rev 1.5 + Vampire 600 V2-128.
A1200 Rev 1D4 + Blizzard 1230 III/50Mhz + 68882 + 256MB @ 50ns.
- Le sujet ‘Infos sur la Vampire’ est fermé à de nouvelles réponses.
› Forums › AmigaOS, MorphOS et AROS › Matériel › Infos sur la Vampire