Logicielsmoto.com

Nous sommes le 28 Mar 2024, 10:11

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 168 messages ]  Aller à la page 1, 2, 3, 4, 5 ... 12  Suivante
Auteur Message
MessagePosté: 25 Juil 2020, 15:44 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Bonjour

J'ai vu ya 6 mois qu'il existait un standard du Jeu d'arcade qui a été porté sur tous les ordinateur 8 bits (C64, ZX Spectum, Atari 8bits, MSX, Amstrad (avec une version commerciale baclée), et sur Amiga, Atari ST et sur Atari Falcon (via l'émulation de la NES) et pas sur Thomson (alors que c'est largement faisable)

Donc voici le code Basic que j'utilise pour le traitement POKE des pxl en bm16c

Code:
4 REM console ,,,,3
5 print CHR$(&h1b)+CHR$(&h5e)
7 screen 0,0,0: lmax = 20 :cls
39 rem boxf (20,0)-(120,60),9
40 RAM = &h4000
41 dim bubble%(128)
42 for i=0 to 63: read bubble%(i):next
43 for i=0 to 15 : C= bubble%(4*i+1): D= bubble%(4*i+3) : GOSUB 200
46 for k=0 to 7 : ADR = RAM+40*i+4*k :A=PEEK(ADR) : B = peek (ADR+1):POKE ADR,(FILTREA AND A) + (C AND (not FILTREA)) :  POKE ADR+1,(FILTREB AND B) + (D AND (not FILTREB))
47 next : next :  i=peek(&hE7C3): i=(i OR 1): poke(&he7c3),i
50 for i=0 to 15 :C= bubble%(4*i): D= bubble%(4*i+2) : GOSUB 200
53 for k=0 to 7 : ADR = RAM+40*i+4*k :A=PEEK(ADR) : B = peek (ADR+1):POKE ADR,(FILTREA AND A) + (C AND (not FILTREA)) :  POKE ADR+1,(FILTREB AND B) + (D AND (not FILTREB))
54 next : next :  i=peek(&hE7C3): i=(i OR 1): poke(&he7c3),i
70 a$=inkey$: if a$="" goto 70
71 color 3,4
72 END
100 REM Data BUBBLE GAUCHE1
101 DATA 255,243,255,255, 255,51,255,255
102 DATA 242,34,51,255 ,34,34,35,255
103 DATA 114,114,47,255, 2,7,35,63
104 DATA 2,7,34,63, 2,7,50,255
105 DATA 2,7,50,63, 114,119,2,63
106 DATA 7,0,37,255, 34,34,37,95
107 DATA 7,114,37,82, 7,119,34,50
108 DATA 87,85,34,34, 87,85,82,47
200 IF (C AND 240) = 240 then FILTREA= 240 ELSE FILTREA = 0
201 IF (C AND 15) = 15 then FILTREA= FILTREA+15
202 IF (D AND 240) = 240 then FILTREB= 240 ELSE FILTREB = 0
203 IF (D AND 15) = 15 then FILTREB= FILTREB+15
204 RETURN


Ce qui donne ça
Image
Mais quand on enlève le commentaire de la ligne 39, quo'n utilise donc BOXF, on obtient ça
Image
Je ne sais pas pourquoi BOXF produit cet effet, c'est comme si la RAMB n'était plus gérée pour les pxl en bmp16c!

Donc c'est un des projets de jeu que j'ai sous Thomson. Il est très populaire et très prenant, mais vu qu'il y a 100 niveaux... Je me contenterais d'en créer un, peut-être une dizaine...

J'ai fait pas mal de tests en Basic pour le PSET (et en Pascal Base) pour voir les vitesses d'affichage, Pascal Base compilé est 10 fois plus rapide en gros.
J'ai donc aussi testé avec des Poke, plus compliqué à gérer parce qu'il faut tenir compte de la RAMA et RAMB... Mais pas en Pascal, je le fais ce WE.

Alors avez vous deviné de quel jeu il s'agit ?
Côté graphisme, je pense qu'un utilitaire permettant de créer des sprites 16c serait le bienvenu. Quelqu'un connait ça sous Thomson ?

Sinon j'ai d'autres projets de jeux dont des tests pour le monde de super Mario Bros... j'ai une idée de comment gérer les tiles et optimiser les affichage de tiles en vitesse, d'ailleurs le code que j'ai inscrit ci dessus donne une idée, notamment pour gérer LA TRASPARENCE en utilisant la couleur 15.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 25 Juil 2020, 18:01 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Pour le jeu c'est probablement bubble-bobble. Ca fait des années que je me disais de le porter sur thomson.. mais le courage et moi ca fait 2 (surtout que j'ai pas le code source pour commencer.)

Pour le BOXF, je pense qu'il laisse $A7C0/$E7C3 sur une banque écran qui n'est pas celle attendue.

Perso pour les sprites, je le ferais en ASM appelé depuis le basic. C'est très facile et bougrement efficace. A la limite au lieu du basic, un appel à une routine écrite en pascal pourrait convenir si le code ASM généré n'est pas trop mauvais, mais il est probable que le pascal soit quand même 5 à 10x plus lent que l'asm optimisé à la main (et on peut en faire des optims avec le 6809).

sam.

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 25 Juil 2020, 19:00 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Pour le jeu c'est probablement bubble-bobble. Ca fait des années que je me disais de le porter sur thomson.. mais le courage et moi ca fait 2 (surtout que j'ai pas le code source pour commencer.)[/quite]

Oui c'est bien ça!! J'avais adoré le portage sur Atari Falcon via l'émulateur NES. Et d'ailleurs, cette société de dév (reservoir prod) avait porté pas mal de jeux NES sur GFalcon ainsi que de jeux gameboy (dont Link's awakened, autrement dit, Zelda 4, un super jeu qui m'avait vraiment séduit et que j'ai mis sur la liste des jeux à porter sur Thomson).
Voici une vidéo qui compare les différentes version existantes
phpBB [video]
. La version amstrad comerciale est nulle, alors que la version amstrad homebrew est parmi les meilleure en ordi 8 bits.

Et une autre qui voit tous les niveaux de Bubble Bobble
phpBB [video]

100 niveaux + le gros boss de fin, c'est vrai que ça fait du taf.

Citation:
Pour le BOXF, je pense qu'il laisse $A7C0/$E7C3 sur une banque écran qui n'est pas celle attendue.


Tu veux dire 2 ou 3 au lieu de 0 par défaut ? Je vais vérifier ça. Mais c'est quand même étrange, boxf n'exxiste-t-il pas déjà en basic 1.0 ?

Citation:
Perso pour les sprites, je le ferais en ASM appelé depuis le basic. C'est très facile et bougrement efficace. A la limite au lieu du basic, un appel à une routine écrite en pascal pourrait convenir si le code ASM généré n'est pas trop mauvais, mais il est probable que le pascal soit quand même 5 à 10x plus lent que l'asm optimisé à la main (et on peut en faire des optims avec le 6809).

Avec Pascal Base, on peut aussi créer des routine assembleur avec la fonction ENCODE(). C'est d'ailleurs comme ça que certaines procédures/fonction moniteur, comme Line, peek, poke, pset sont codées.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 26 Juil 2020, 09:12 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
Neotenien a écrit:
Mais quand on enlève le commentaire de la ligne 39, quo'n utilise donc BOXF, on obtient ça

C'est tout simplement du au fait que tu commences en RAMB

Il suffit de rajouter ceci - i=peek(&he7c3): i=(i AND 254): poke(&he7c3),i - juste après le BOXF pour que ton programme fonctionne normalement ;)


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 26 Juil 2020, 16:15 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Re-bonjour

J'ai un autre soucis, j'ai voulu faire cette version avec Pascal Base (Free Game Blot) et lors de la compilation, ça me met une erreur "261 - erreur interne : table pleine" après la compilation des 2 premiers fichiers segmentés. Cette erreur survient après une déclaration de variable dans une procédure (alors que le logiciel que j'avais compilé il y a 2 jours avec les même API de moniteurs ne m'avaient pas donné cette erreur)

Je crois que ça viens du fait qu'il y a peut-être trop de variable ? Je vais peut-être réduire la taille du tableau des sprites de 128 à 64 (déjà que le Pascal Base ne gère que des INTEGER de 16 bits).


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 26 Juil 2020, 16:21 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
jasz a écrit:
Neotenien a écrit:
Mais quand on enlève le commentaire de la ligne 39, quo'n utilise donc BOXF, on obtient ça

C'est tout simplement du au fait que tu commences en RAMB

Il suffit de rajouter ceci - i=peek(&he7c3): i=(i AND 254): poke(&he7c3),i - juste après le BOXF pour que ton programme fonctionne normalement ;)


Merci Jasz, c'est exactement ça!! J'aurai dû réfléchir un peu plus!
Alors j'ai raccourci la déclaration, j'ai mis i=peek(&hec73) AND 254.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 26 Juil 2020, 16:21 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
oui probablement trop de symboles pour la table... des symboles. Peut-être y-a-t-il moyen de l'augmenter ? (je ne connais pas pascal-base)

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 26 Juil 2020, 18:20 
Hors ligne

Inscription: 13 Juin 2005, 21:50
Messages: 290
Localisation: Planete Zorg (31)
Tu peux mieux faire en matière de réduction
Code:
POKE &HE7C3, PEEK (&HE7C3) AND 254

En Machine comme pour le BASIC
LDA   $E7C3 (PEEK)
AND.A #$FE
STA   $E7C3 (POKE)


Pour le reste je ne connais pas plus le Pascal Base, mais rien ne vaut le codage manuel ;)


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 26 Juil 2020, 18:32 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Oui surtout que le passage RAMA/RAMB peut se faire en ASM par un inc/dec $E7C3 qui est plutôt rapide (et encore plus si on utilise l'adressage DP).

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 26 Juil 2020, 19:19 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
oui probablement trop de symboles pour la table... des symboles. Peut-être y-a-t-il moyen de l'augmenter ? (je ne connais pas pascal-base)


En gros ça signifie qu'il y a trop de "noms de variables" ?

Sachant que Pascal base ne réserve la ram pour l'exécutable qu'à partir de HAC00!! Ce qui ne laisse pas beaucoup de place en fin de compte...(Jusqu'à ADFF, 512 octets seulement!!)

Bon j'ai quand même réussi à compiler (en ne gardant que les procédures moniteurs dont j'ai besoin) le même code du basic ci dessus avec les Poke, en Pascal, pour afficher 8 Bubble ça a mis moins de 2 secondes!!
C'est pas vraiment probant, quand je compare à ce qu'a fait prehisto ( 25 image/s ??) avec Mission : liftoff... Je me demande si, au lieu de travailler directement sur la mémoire écran je ne ferait pas mieux de travailler directement avec les ram physique des banques (A000 a DFFF), puisque c'est quand même plus simple de travailler sur les adresses hautes et basses des banques de 16kO plutôt que de faire une bascule avec l'octet situé en E7C3...
Utiliser les print (ou write) c'est pas terrible si on veut faire du déplacement pxl par pxl en horizontal, alors que les print se déplace 8pxl par 8 pxl.

Voici le code que j'ai développé en Pascal Base, permettant d'afficher 50 sprites Bobble (en 7 seconde, le même code en Basic met 130 s) afin que vous fassiez des tests éventuellement...

Code:
(* Fichier Main *)
PROGRAM TESTMONI1;
VAR C, D, I, RAM : INTEGER;
T : ARRAY [0..63] of INTEGER;

PROCEDURE POKE (ADR, VAL : INTEGER);
BEGIN ENCODE ('10AE58EC56E7A4'); END;

FUNCTION PEEK (ADR: INTEGER): INTEGER;
BEGIN ENCODE ('10AE58E6A44FEDC4'); END;

PROCEDURE TRACEPT(C,D, I, RAM : INTEGER);
VAR K, F1, F2, ADR, A, B: INTEGER;
BEGIN
    if C AND 240 = 240 THEN F1:=240 else F1:=0;
    if C AND 15 = 15 THEN F1:=F1+15;
    if D AND 240 = 240 THEN F2:=240 else F2:=0;
    if D AND 15 = 15 THEN F2:=F2+15;
    FOR k:=0 TO 49 DO
        BEGIN
        ADR := RAM + 40*I+4*(K MOD 8) + 600*(K DIV 8);
        A:=PEEK(ADR);
        B := peek (ADR+1);
        POKE (ADR, F1 AND A + C AND NOT F1);
        POKE (ADR+1,F2 AND B + D AND NOT F2);
        END;
END;
(*$main1*)

(*fichier main1*)
BEGIN
T[0]:=255; T[1]:=243; T[2]:=255; T[3]:=255; T[4]:=255; T[5]:=51; T[6]:=255; T[7]:=255;
T[8]:= 242; T[9]:=34; T[10]:=51;T[11]:=255; T[12]:=34; T[13]:=34; T[14]:=35; T[15]:=255;
T[16]:= 114; T[17]:=114; T[18]:=47; T[19]:=255; T[20]:=2;T[21]:=7; T[22]:=35; T[23]:=63 ;
T[24]:=2; T[25]:=7; T[26]:=34; T[27]:=63; T[28]:=2; T[29]:=7; T[30]:=50;T[31]:=255;
T[32]:= 2; T[33]:=7; T[34]:=50; T[35]:=63; T[36]:=114; T[37]:=119; T[38]:=2; T[39]:=63;
T[40]:= 7;T[41]:=0; T[42]:=37; T[43]:=255; T[44]:=34; T[45]:=34; T[46]:=37; T[47]:=95;
T[48]:= 7; T[49]:=114; T[50]:=37;T[51]:=82; T[52]:=7; T[53]:=119; T[54]:=34; T[55]:=50;
T[56]:= 87; T[57]:=85; T[58]:=34; T[59]:=34; T[60]:=87;T[61]:=85; T[62]:=82; T[63]:=47;
write(CHR(27),CHR(94));

RAM:=#4000;
FOR I:=0 TO 15 DO
    BEGIN
    C := T[4*I+1];
    D := T[4*I+3];
    TRACEPT(C,D,I, RAM);
    END;
i:=peek(#E7C3) OR 1;
poke(#E7C3,i);
FOR I:=0 TO 15 DO
    BEGIN
    C := T[4*I];
    D := T[4*I+2];
    TRACEPT(C,D,I, RAM);
    END;
i:=peek(#E7C3) AND 254;
poke(#E7C3,i);
END.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 26 Juil 2020, 19:23 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Je pense qu'il doit être possible de largement optimiser ce code. Je ne connais pas bien le pascal mais à vue de nez il y a trop d'instructions de tests là dedans.

Question: sachant que les entiers sont sur 16 bits, pourquoi as-tu du "A" et du "B" sur 8 bits ?

Tu devrais pourvoir te faire une primitive poke en asm qui écrit la partie haute de l'entier en RAMA et la partie basse en RAMB en un seul appel avec commutation $E7C3 "intégrée".

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 26 Juil 2020, 20:19 
Hors ligne
M. DCMOTO

Inscription: 06 Juin 2004, 08:23
Messages: 681
Localisation: Provence (France)
Le calcul "ADR := RAM + 40*I+4*(K MOD 8) + 600*(K DIV 8);" dans une boucle est d'une lenteur incroyable. Il faut trouver un moyen plus rapide pour calculer l'adresse.
Quelle drôle d'idée de programmer en Pascal pour afficher des sprites. C'est tellement plus simple et plus rapide en assembleur.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 26 Juil 2020, 20:56 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Samuel Devulder a écrit:
Je pense qu'il doit être possible de largement optimiser ce code. Je ne connais pas bien le pascal mais à vue de nez il y a trop d'instructions de tests là dedans.

Question: sachant que les entiers sont sur 16 bits, pourquoi as-tu du "A" et du "B" sur 8 bits ?

Tu devrais pourvoir te faire une primitive poke en asm qui écrit la partie haute de l'entier en RAMA et la partie basse en RAMB en un seul appel avec commutation $E7C3 "intégrée".


C'est ce que j'ai pensé à faire au début mais le changement de commutation au sein de la boucle, ça fait n fois une même instruction qui se répète dans une boucle alors que j'ai préféré faire 2 boucle... Mais finalement, tu as raison, ! au lieu de 2 fois la même boucle, je devrais tout faire dans une seule...

Pour les instructions de test (filtreA et filtreB) sert pour comparer la couleur du pixel avec 15 qui est sensée être transparente (pixel de fond), ya pas le choix, je suis obligé de faire au moins 1 test.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 26 Juil 2020, 21:09 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Daniel Coulom a écrit:
Le calcul "ADR := RAM + 40*I+4*(K MOD 8) + 600*(K DIV 8);" dans une boucle est d'une lenteur incroyable. Il faut trouver un moyen plus rapide pour calculer l'adresse.
Quelle drôle d'idée de programmer en Pascal pour afficher des sprites. C'est tellement plus simple et plus rapide en assembleur.


Salut Daniel... Je pense à t'envoyer la disquette complète de la compil CLUB FRANCAIS du logiciel 1 (avec les 2 jeux VH Stratégie et Labilogic) fin de parenthèse

Pour ta question, ça sert à calculer la position de chaque sprite (yen a 50) et des éléments de chaque sprite. Le Pascal compile en pur langage machine, et si j'utilise Pascal c'est parce que c'est un langage de haut niveau, de type procédural, bien plus clair au niveau du codage que le BASIC et plus strict aussi.

Pour ce qui concerne les RAMA et B, dans la doc technique tes TO8/TO9 et TO9+, ils disent que la RAM logique écran est sur une des banques RAM physique, soit 0, 2 ou 3... Et ils disent que dans ces banques, ce qui correspond à la RAMA est dans les adresses hautes (8000 et après) et RAM B dans les adresses basses (0 à 7999) de ces banques physiques.

On peut écrire des routines en Langage Machine directement en Pascal via les procédures, je le ferai si nécessaire (et c'est pas limité à 10 procédures comme pour le BASIC).

Bon demain je tente l'assembleur pour voir si l'affichage de 50 sprites mettra moins de temps que 7 secondes... J'ai déjà écrit un petit programme en assembleur en 1993, c'était une animation à propos de tétris, mais évidemment, comme ça utilisait les caractères, c'était donc beaucoup plus rapide que les dessins de pixels.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 27 Juil 2020, 00:35 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Pour le transparent il ne faut pas "bloquer" une couleur, mais plutôt utiliser un masque séparé. C'est bien plus rapide. Ensuite "MOD 8" est très lent (ca utilise une division) ! Au lieu de ca, utilises les opérations bits à bits comme "AND 7" qui vaut la même chose de façon infiniment plus rapide. Similairement "DIV 8" est lent.. et est équivalent à une décalage à droite de 3 bits (le bascal a peut-être une primitive SHR, sinon ca serait un truc bien utile en asm), bien plus rapide.

Mais plus globalement "4*(K MOD 8) + 600*(K DIV 8)" est une expression complexe qui même is on optimise chaque bout du "+" serait lente. Mais comme K ne varie pas sur de grosses valeurs, c'est un candidat idéal au pré-calcul! Idée: tu te crée un tableau precalc[0..49] dont la valeur precalc[k] contient les différentes valeurs de "4*(k MOD 8) + 600*(k DIV 8)" calculés une fois pour toutes au début du programme. Ca ira super, super vite!

D'une façon générale, pour être rapide, il faut se rapprocher le plus possible de ce qu'on ferait en ASM (décalages, opération bits à bits) et utiliser des tables pré-calculées (ne pas faire 2 fois un même calcul coûteux si on peut pré-calculer le résultat dans un tableau de petite taille.)

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 168 messages ]  Aller à la page 1, 2, 3, 4, 5 ... 12  Suivante

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 31 invités


Vous ne pouvez pas poster de nouveaux sujets
Vous ne pouvez pas répondre aux sujets
Vous ne pouvez pas éditer vos messages
Vous ne pouvez pas supprimer vos messages
Vous ne pouvez pas joindre des fichiers

Rechercher:
Aller à:  
cron
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com