Toutes mes réponses sur les forums
-
Oui mais la décompression du code en ram va te faire perdre du temps, donc le gain en espace memoire sera converti en perte de vitesse. Le grand classique!
Tu fais ta décompression à l’avance, petit à petit, exactement comme lorsque dans la version ‘moteur’ tu générais ton sprite compilé à l’avance, petit à petit, tant que tu avais des cycles dispo par 1 50iè de seconde, pour que ton frame rate ne chute pas.
Perso je trouve ça très jouable.
Je ne vois aucune preuve que ça ne fonctionnerait pas très bien.Je l’ai dit déjà : il faut une gestion fine de ce qui risque de devoir être prochainement affiché, au fur et à mesure de ta progression dans le jeu, pour avoir le sprite compilé dispo au moment où il faudra afficher ce sprite.
En permanence en mémoire tu n’as que les sprites compilés de ce qui sert tout le temps ( ton personnage, les tirs, les explosions, les ennemis communs, les éléments communs de décor ). oui c’est mon avis aussi.
Il y a une autre solution, si on veut éviter d’avoir un moteur dans le jeu qui génére les sprites compilés.
Ce serait de compresser le code de ces sprites compilés.
Ca devrait se compresser très bien, car
° on utilise quasi toujours les mêmes instructions( LDR, STR, LDMIA, STMIA, STMIB, STMDB, ADD, MOV )
° il n’y a pas besoin d’avoir de tests dans le code de ces sprites compilés, hors chaque instruction ARM est conditionnelle, et le champs dans l’instruction qui détermine l’exécution conditionnelle prend déjà 4 bits sur les 32 bits de l’instruction. En fait cette méthode de « sprite en code » (sprite compilé) ne marche que pour des pixels chunky ou alors sur un seul bitplan bref n’a pas trop d’intérêt sur Amiga classic…
Tu peut faire un move 32 bits et écrire 4 pixels dans la partie solide du sprite ?
Tu ne peux pas faire un MOV avec n’importe quelle valeur 32 bits, puisque l’instruction est codée sur 32 bits, comme toutes les instructions de l’ARM.
Ce que tu feras c’est que tu chargeras avec une seule instruction LDMIA, jusqu’à 12 registres, et là tu pourras faire tes STR si tu veux écrire 4 pixels.
Mais en aucun cas tu ne feras une répétition de STR pour écrire un segment.
Tu utiliseras STMIA destination!,{liste de registres}et attention on n’opère que sur des adresses multiples de 4 avec LDM et STM (*), et STR aussi, ça oblige à avoir 4 codes, et 4 copies du contenu du sprite, shifté à chaque fois de 1 pixel.
LDRB et STRB eux opèrent sur n’importe quelle adresse.
Vous comprenez mieux j’imagine pourquoi il faut avoir un moteur qui crée à loisir le sprite compilé quand il va y en avoir besoin, puis libère son espace jusqu’à la prochaine fois où on aura besoin de lui.
On ne garde en permanence en mémoire qu’une copie du sprite.
Les seuls sprites compilés en permanence en mémoire vont être ceux qui reviennent tout le temps à l’écran.(*) les 2 instructions ignorent les 2 bits de poids faible de l’adresse utilisée
@ Modulo
Suis nase ce soir mais je te réponds.
Enespérant ne pas écrire n’importe nawak.
Toutes les instructions sur l’ARM prennent 4 octets ( ça aide pour générer du code )Quand tu plottes un pixel ( donc 1 octet en mode 256 couleurs ), tu peux avoir un offset en pré incrémentation ou post incrémentation dans l’instruction, et le coût est de 0 cycle si c’est une constante.
Mettre ! fait que l’incrémentation avec l’offset reste en sortie d’opération.
Cette valeur peut aller de -4096 à + 4096.
Ca prend 0 cycle supplémentaire tout ça.
Ecrire 1 octet avec STRB coûte 4 cycles.
Reprenons l’exemple de l’étoile qui ressemble à + et fait 3×3
Pour l’afficher :
on va dire que R14 est l’adresse mémoire en haut à gauche du rectangle dans lequel est est inscrite.
Disons aussi qu’elle est monochrome, de couleur 255.
Ca donnera, en mode 320 x 256 256 couleursmov r0,#255 ; 1 cycle
strb r0,[r14,#1]! ; 4 cycles
strb r0,[r14,#320-1]! ; 4 cycles
strb r0,[r14,#1]! ; 4 cycles
strb r0,[r14,#1] ; 4 cycles
strb r0,[r14,#320] ; 4 cyclesmov 0,#32*1024*1024 ; 1 cycle
ldr pc,[0,#-4) ; 4 + 4 cycles si je ne dis pas de conneries32 octets pour un truc qui fait 3*3 soit 9 octets, et encore 9 octets pour son masque, soit 18 octets, ça ne semble pas terrible. ( je ne prend pas en compte la taille du code utilisant la méthode générique d’affichage, puisqu’elle va servir pour tous les affichages )
Certes.
Sauf que si ton rectangle ne fait pas 3×3 mais 64×64 parce que tu as plusieurs étoiles et tu en as une en haut à gauche et une bien en bas à droite, ça change la donne.
Imagine que tu en as 10 là-dedans
Le code ci dessus *10 prendra 24*10 + 2*4 = 248 octets ( s’il n’y a jamais plus de 4096 octets d’écart entre le bas d’une étoile, et le haut de la suivante )
Ton sprite lui qui fait 64×64 prend 4096 octets, et encore 4096 octets pour son masque.A noter que STRB est la pire des instructions car elle prend 4 cycles.
STM ( écriture multi registres ) prend 4 cycles sur le 1er registre de la liste de transfert, puis 1 cycle pour chaque registre suivant, donc pour l’Archie plus un sprite est gros, et plus il est plein, plus le ratio pixels transférés par cycle est élevé.
Tous les registres sont 32 bits, pour rappel.Je n’ai pas pris en compte le coût pour la routine appelante de faire
mov #0,32*1024*1024
str pc,[0,#-4] ; le program counter vaut adresse courante + 8 à cause du pipeline de l’ARM
ldr pc, addresse de la routine d’affichagej’espère ne pas avoir écrit trop n’importe quoi
Pas pratique de rédiger là.Je mets toujours mes variables à 32*1024*1024 – qqchose, j’expliquerai pourquoi si vous voulez.
Je ne penses pas avoir vu la réponse dans ce thread mais comment est organisé la mémoire vidéo de l’archi ? c’est un genre de chunky ou c’est du bitplane à la Amiga ?
Tout est chunky.
Si tu veux faire des tests voici les gfx de Battle Squadron, il y a aussi d’autres jeux.
http://amiga.lychesis.net/game/BattleSquadron.htmlMerci pour le lien.
Je pourrais déjà piquer une des animations d’explosions, pour l’explosion des boules ( en réadaptant les couleurs avec mon choix de 16 couleurs ) quelle est la différence d’occupation mémoire entre une routine «boucle + data» classique, et la version générée (unrolled) ?
je n’avais pas répondu
la différence est très importante, mais l’idée c’est d’avoir ton générateur de sprites compilés dans ton jeu, pour appeler la génération du sprite compilé au moment opportun, puis libérer la mémoire quand tu n’as plus besoin de ce sprite compilé.
Ensuite, bien comprendre que si tu as un sprite avec beaucoup de vide,tu peux avoir un sprite compilé qui va prendre moins de place que ce sprite là, car le sprite compilé ne traite que le plein, pas le vide.
Au final pas évident de donner un chiffre, comme ça.
Ca va être du cas par cas.Prenons un cas extrême.
Imagine tu as une animation d’étoiles, en forme de croix, disons çette forme :
+
3 pixels de haut et 3 de large
et tu en as un nuage de 4 ou 5,
tout ça dans une animation qui va tenir dans une succession de rectangles 32×32
ben là en sprites compilés non seulement c’est plus rapide pour les afficher que la méthode classique,
mais ça prendra aussi nettement moins de place.Je pousse le trait exprès, par soucis de pédagogie.
Rappel : pas besoin de masque avec les sprites compilés, ça fait un sacré gain de place.
Ni vide ( je simplifie, il y en a quand même un peu au niveau des bords des segments horizontaux composant le sprite), ni masque. Laurent, le guitariste de Grospixels, aime les Archimedes dans cet article bien fourni de 2001 (comme le temps passe … ) :
https://www.grospixels.com/site/acorn.php
note: écoutez leurs remixs également, ils sont géniaux.
🙂
Regarde qui il remercie tout en bas 🙂EDIT : il y a des erreurs dans l’article :
Archimedes A3000-A3010 : CPU ARM3 à 16 Mhz. L’unité centrale n’est plus séparée du clavier, comme sur les ST et Amiga. C’est le dernier de la gamme à porter le nom d’Archimedes.et le A5000 c’est 8 Mo max, c’est le A540 qui peut monter à 16
S’il ne fallait avoir qu’un Archimedes ça serait lequel?
Je dirais un A5000 car il a un ARM3, et tu peux l’overclocker jusqu’à 42 Mhz, et le bus mémoire à 12 Mhz, tu peux l’overclocker si tu utilises des upgrades 4 Mo avec des chips RAM modernes rapides qui existent maintenant ( j’ai financé le projet ).
http://chrisacorns.computinghistory.org.uk/Computers/A5000.html#A5000
Il peut avoir 8 Mo et cette extension mémoire est encore fabriquée et distribuée par cje micros.
Ca fait une sacrée bécane, au final.
13,5 MIPS si ARM3 à 25 Mhz
17 MIPS si ARM3 à 33 Mhz
à 42 Mhz pour le prix du changement d’un oscillateur, on doit être autour de 20-21 MIPS hé hé hé
et si en plus on overclocke le bus mémoire de 12 à 16 Mhz … wow Ca fait partie des montages que je devrais réaliser mais j’ai la flemme, ce sera pour cet hiver.
https://stardot.org.uk/forums/viewtopic.php?f=16&t=17832 Bon je sais que ca a été dit et redit plusieurs fois dans le sujet, mais une vidéo qui compare un A3010 sorti en 1992 (???) à un Amiga (500) qui n’était même plus fabriqué en 1991…
Exact.
Ca rend la vidéo encore plus nulle, en effet. Shaun Hollingworth vient de publier un commentaire dansla vidéo dégueulasse que Dan a fait pour descendre l’Archimedes par rapport à l’Amiga :
Shaun Hollingworth
il y a 1 minute
Pacmania on the Archie was the only version to have proper width ghosts lol. The ones on the Amiga were limited due to the hardware sprite sizes etc, and the ST was the same due to the 68000 speed limitations. But the Archie flew along.
If I’d known at the time how to hack the VIDC chip to product a full screen game I would definately had done that, as we did with a football game much later.
Given it was only the second game I had worked on it was wonderful. A couple of us were going to a seminar at Acorn, and I took a pre-production copy of Pacmania with me. There were wide open mouths from people – with a comment from one of the Acorn engineers saying « Hmmm… I guess you must be writing to the screen directly? Am I right? » 🙂
Lemmings was ported from the ST and Amiga versions (not the pc version), for which we were given the 68000 assembler source code by DMA design. The fact that the 68000 was big endian caused a few problems at first, because we used all their map data directly. Also the program flow which sometimes jumped around quite a bit, eventually returning with a RTS from somewhere or other, at various places was really awkward because of the link register subroutine call method. So we used a macro « BSR » which did « stmfd r13!,{r15} / movnv R0,r0 / B <branch off to subroutine destination> and I got called out by someone who had disassembled the program at Cambridge university, posting his comments entitled « Poor Lemmings Coding » about this in a news group for me using that call macro. But it worked tremendously well for our purposes! It got used quite a lot at times, with the link method used for calls which had a single return path. The Pacmania arcade conversions were originally written by me for the other platforms, so I knew exactly how the program flowed in all cases, so the link method was always used there. Tu comptes lâcher ton code source ? Ou tu préfères le garder ?
Je compte mettre sur Pouet le programme BASIC que j’utilise : le source ASM commenté est dedans.
Il y aura aussi le fichier excel dont je me suis servi pour écrire les sprites compilés, et d’autres feuilles répertorient les variables utilisées et leurs emplacements.
Qui sait, cela suscitera peut-être des vocations.
Titan voulait peut-être coder sur Archimedes.
Le groupe m’a fait membre(*), après avoir vu mon projet SOTB-like, ils m’ont invité à les rejoindre sur Discord, mais n’étant pas du tout antifa alors que le groupe l’est, ça a clashé et mon ‘membership’ n’a duré qu’une journée, ou 2.Que quiconque pompe ce qui lui plaît, ça m’ira très bien, du moment qu’il y a de nouvelles productions sur la machine.
(*) j’ai toutes les preuves évidemment.
Je pense juste que Dan ne connais pas assez l’Archimedes du coup il prend des raccourcis. C’est le même problème avec l’Amstrad qui était sous exploité et on voit aujourd’hui que l’on peut faire de très bon jeux avec.
Si tu ne connais pas une machine tu ne l’utilises pas pour faire un comparatif avec la machine que tu chéris ( Amiga ).
C’est comme si de mon côté je faisais un comparatif Next auquel je ne connais rien avec l’Archimedes.
C’est juste nul.
On ne fait pas ça quand on prétend offrir des vidéos de qualité.A minima Dan aurait pu passer sur le forum Acorn stardot pour poser des questions, avoir des infos etc etc …
Ou au moins faire une recherche sur Youtube …
Mais non, il n’a pas agi ainsi.
Dan n’a donc pas bossé, il savait déjà ce qu’il voulait dire de l’Archie face à l’Amiga.
C’est la preuve qu’il n’a fait preuve d’aucune objectivité, et par conséquence cette vidéo est honteuse. Avec le dual playfield il affiche 70 bobs de 28×28
http://www.powerprograms.nl/amiga/dpl-fastbobs.html
Après en aga on pourrait ajouter 80 sprites de 32×32 (320/32 et 256/32).Dans quelle résolution ?
@Zarchos: Il ne reste plus beaucoup de lignes noires en bas de l’écran. Le temps d’une frame est plein à 99%
Et oui, c’est bien le but : utiliser au maximum ce dont je dispose pour afficher le maximum d’éléments.
Un bon cycle est un cycle utilisé ha ha ha.
