Nouveau jeu Thomson : Mission: Liftoff

Neotenien · **Inscription:** 21 Fév 2020, 11:38 **Messages:** 372

Samuel Devulder a écrit:

Pour info Pulkomandy a fait une démo en C (>>ici<<) il y a quelques années, et même si le C est très proche de l'assembleur, on sent bien que c'est moins efficace que du code machine optimisé à la main.

Pour avoir un jeu fluide à 25 images/seconde avec du son, je pense que seul l'assembleur et les connaissances de Préhisto en sont capables. Les langages de haut niveau ne permettent pas d'être précis au cycle près, chose nécessaire sur Thomson qui ne dispose d'aucune aide matérielle pour les sprites ou le son.

Par contre d'autres jeux, plus lents, et avec moins de son doivent être possibles en Pascal en effet.

Un jour je me pencherais sur le Pascal, surtout s'il permet de la programmation modulaire.

Au cycle près non mais avec Pascal Base, on peut créer des modules en assembleur directement au sein des sources Pascal (d'ailleurs, il y a déjà 19 procédures de ce type dans la doc, comme par exemple, PEEK, POKE, PSET, POINT, LINE etc)

En voici un exemple d'ailleurs utilisant lm'asembleur pour TO7:
PROCEDURE PSET (X,Y,COLOR : INTEGER)
(*allumage d'un point en X,Y de couleur COLOR
identique à l'instruction PSET graphique du BASIC*)
BEGIN ENCODE('7F60413410AE5B10AE56EC54F76038BDE80F3510'); END;

Ou un autre exemple commun aux TO/MO
PROCEDURE CURSOFF; (*extinction du curseur*)
BEGIN WRITE (CHR(20)); END;

Imaginez si on créer une librairie complète en pascal pour les routines du moniteur ou de l'extramoniteur par cette voie On n'a plus besoin de se préoccuper des "variables", de la position des procédures et fonctions.
Cependant, ya juste un point dont je ne vois pas comment utiliser en Pascal, c'est pour l'interruption timer, où, je pense, il faut anticiper l'adresse de début d'interruption.

A ce propos, existe-t-il un moyen de changer la durée du timer qui est de 1/10s ?

Samuel Devulder · **Posté:** 07 Mar 2020, 20:40

Neotenien a écrit:

A ce propos, existe-t-il un moyen de changer la durée du timer qui est de 1/10s ?

Sur les TO oui car il y a un 6846 qui gère le timer (doc "pas fun" >>ici<<, doc sympa >>là<< ). Sur les MO non car l'interruption vient du 50hz de la prise secteur (MO5 du moins, je ne sais pas trop pour le MO6).

J'ai utilisé le timer pour changer la fréquence du son dans >>cette démo<< (1 seul canal audi)

phpBB [video]

Dans ces autres démo avec plusieurs canaux audio, je ne module plus la f'réquence du son via l'interruption timer mais je modifie sa fréquence pour que l’interruption de 10hz passe à 2000 ou 4000hz dans laquelle je calcule la sortie de chaque canal en temps réel.

phpBB [video]

Neotenien · **Inscription:** 21 Fév 2020, 11:38 **Messages:** 372

adnz a écrit:

Alors oui je suis d'accord,
le TO/MO est hyper limité, c'est une galère grave pour faire un peu comme l'amstrad (surtout en bitmap 16) avec une vitesse de jeu assez rapide....
et aussi il n'y a aucune aide hardware pour les sprites ou le son ou le scrolling (comme sur amstrad par exemple, genre gestion de sprites en hardware etc..).

Sur les Thomson faut tout ce coder à la main, et finalement on atteint assez vite le nombre de cycle max jouable pour 1 frame de jeu. En plus si on met du son digit alors là c'est bonbon :langue:

....!
(ça crain je sais pas si c'est moi, mais justement c'est ce que je kiff sur cette machine. )

Du coup quant on à tout ça en tête, le codage de Mission LiftOff c'est pfffff, je pense le truc le plus pointu réalisé sur Thomson de toute la galaxie

.
Mais c'est ça que je trouve cool, quant on arrive à ce résultat sur ces machines.

Sinon j'avais vu ce "wip zezito" avec le scroll super fluide en bitmap16... ça promet, je sais pas si ce qu'on voit tourne à cette vitesse sur un TO !
(ça serait bien un pinball avec un scrolling comme ça

)

Pour faire le parallèle avec les Commodore 64 et autre Amstrad CPC, les thomson n'ont rien à envier!! Le 6809E à 1 MHz semble à peu près équivalent aux Zilogh 3MHz en terme de performance. Ces bécanes ont tous 16kO en RAM vidéo... L'Amstrad apparemment n'aurait que 3 modes vidéo en bitmap (d'après ce que j'ai lu) mais avec une palette de 56 couleurs (je crois) allant de 160x200 à 640x200. ON peut comparer graphiquement et techniquement certains jeux où Thomson est meilleur que l'Asmtrad:
- Astérix et la potion magique
- Bactron
- Bivouac
- Blue Star
- Turbo Cup
- Etc

D'autres jeux où la version Asmtrad est meilleure (Comme Arkanoïd) etn d'autres où les 2 sont équivalentes (Bob winner). L'amstrad a théoriquement 128 kO et le TO8 256 jusqu'à 512...

Mais quand on compare au C64 ou pire au ZX spectrum, inférieur aux niveau techno (aussi bien processeur pour le C64 que graphique) et que chacune de ces 2 plate formes dispose de plus de 5000 jeux... A savoir que le Basic 1.1 de l'Amstrad est bien plus limité que le Basic 512 (Voir avec "Speedy Wonder" le compilateur Basic de l'Amstrad également dispo sur Thomson) et que le Basic du C64 est une horreur (et que tous les jeux sont écrits en assembleur)... Avec Pascal Base (qui compile le code directement en langage machine) on a là un outil permettant de créer des jeux rapide facilement

Je suppose que vous connaissez ces jeux montrant les possibilités de la bécane : Tout Schuss, MGT, Bactron, Mission, 3D Fight (qui est un Xwing!!), Minotaure 3D, Space game. Ce qui est dommage est que nombre de jeux d'arcade ont été portés sur les C64, Spectrum et Amstrad et pas sur Thomson. Alors qu'en théorie c'est faisable. Des hit tels International Karaté, Street Fighter, Super Mario, Bubble Bobble, Frozen Bubble, Chuchu rocket (parking) ou même Zelda (le 1er) sont portable sur TO... A ce propos, les jeux vu de dessus (avec scrolling) ne sont pas légion sur Thomson, à part "Avenger", "Slap fight 1 et 2" et Road killer.

PulkoMandy

Samuel Devulder a écrit:

Pour info Pulkomandy a fait une démo en C (>>ici<<) il y a quelques années, et même si le C est très proche de l'assembleur, on sent bien que c'est moins efficace que du code machine optimisé à la main.

Euh, alors, celle-ci en particulier a été faite rapidement sur un week-end et sans trop prendre le temps d'optimiser quoi que ce soit. C'est loin d'être une référence pour ce qu'on peut faire en C.

Cela dit, effectivement il y a des soucis de performances sur les machines Thomson, principalement à cause du manque de matériel pour le son. Sur un Amstrad par exemple, on peut se contenter d'envoyer quelques dizaines d'octets à la puce son une fois toutes les 20ms et elle se débrouille pour le reste. Sur Thomson, il faut gérer ça avec le CPU et avoir un timing précis, impossible en C.

Ce que je fais souvent, c'est un mélange de C et d'assembleur, qui me permet d'avancer vite en écrivant en C, puis ensuite de passer du temps à réécrire à la main les parties qui méritent d'être optimisées pour obtenir les performances voulues.

Neotenien · **Inscription:** 21 Fév 2020, 11:38 **Messages:** 372

Prehisto a écrit:

Par exemple, vous pourrez toujours chercher les graphismes des sprites en mémoire, vous ne les y trouverez pas. Parce que tous ces graphismes ont été convertis en code. Chaque point de couleur est appliqué "à la main" sans passer par une matrice. Par exemple, une partie du code de l'affichage du jetpack (X contient le pointeur écran, B contient #$F0 (soit 240, pour passer les lignes)):

Code:

       ...
       SOUNDA
       abx    
       lda    #$f0
       anda   ,x
       adda   #$09
       sta    ,x
       lda    #$f0
       anda   40,x
       adda   #$04
       sta    40,x
       lda    #$44
       sta    -120,x
       sta    -80,x
       sta    -40,x
       abx    
       sta    80,x
       lda    #$a3
       ...

Je suis moi même en train de coder, depuis quelques jours, des choses pour des adaptations de jeux sur Thomson (des grand titres existant sur d'autres plate-forme... je pet juste une photo sur un article que je vais publier)

Et je ne comprend pas pourquoi ce codage à la main des pixel sans data derrière ?

Moi j'ai trouvé une astuce pour avoir une couleur "transparente" sur un pixel en mode bm 16.
Il suffit de se dire que "15" est la couleur transparente des sprites. et que si on le rencontre, on utilise un filtre du genre "Ecran AND 240" ou "Ecran and 15" (dépendant du pixel bm sur lequel on travaille)

Je vous fournis une partie de ce traitement

Code:

for i=0 to 15 : C= bubble%(4*i+1): D= bubble%(4*i+3) : GOSUB 200
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))
next : next :  i=peek(&hE7C3): i=(i OR 1): poke(&he7c3),i
for i=0 to 15 :C= bubble%(4*i): D= bubble%(4*i+2) : GOSUB 200
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))
next : next :  i=peek(&hE7C3): i=(i OR 1): poke(&he7c3),i
IF (C AND 240) = 240 then FILTREA= 240 ELSE FILTREA = 0
IF (C AND 15) = 15 then FILTREA= FILTREA+15
IF (D AND 240) = 240 then FILTREB= 240 ELSE FILTREB = 0
IF (D AND 15) = 15 then FILTREB= FILTREB+15
RETURN

Il y a 64 data correspondant à des Octet full, donnant sur les 4 bits de poids fort la couleur sur les pixels pairs (RAMA ou RAMB) et sur les 4 bits de poids faible, la couleur des pixels impairs. Il y a un test sur la couleur 15 indiquant si le filtre s'applique sur la couleur du fond ou sur le pixel du data! FiltreA correspond au pixel pair et FiltreB pour le pixel impair. Ceci est en basic, mais je vais faire une version PURE Pascal pour voir ce que ça donne en terme de vitesse (comparé à BASIC)
Ce code est certainement plus court que le fait d'écrire à la main chaque pixel, tout ça pour l'effet transparence. Et ce code se sert de DATA en matrices.

Samuel Devulder

Préhisto a mis les data dans les valeurs immédiates pour gagner un max de cycles. Par exemple LDA #123 (adressage immédiat) coûte 2 cycles, alors que LDA ,X+ (adressage indexé, le registre X pointant sur les données) coûte lui 4+2=6 cycles, soit trois fois plus lent. Ca prends plus de place en "code", mais l'avantage en vitesse est primordial si on veut maintenir les 25 images par secondes.

Neotenien · **Inscription:** 21 Fév 2020, 11:38 **Messages:** 372

Samuel Devulder a écrit:

Préhisto a mis les data dans les valeurs immédiates pour gagner un max de cycles. Par exemple LDA #123 (adressage immédiat) coûte 2 cycles, alors que LDA ,X+ (adressage indexé, le registre X pointant sur les données) coûte lui 4+2=6 cycles, soit trois fois plus lent. Ca prends plus de place en "code", mais l'avantage en vitesse est primordial si on veut maintenir les 25 images par secondes.

Wow ça fait un travail monstre! Ce genre de truc est irréalisable avec Bubble Bobble (avec les centaines de sprites qui existe dessus)... Mais je me contenterais du 8 image/s (25/3), avec test du filtre de la couleur du pixel = 15.

Neotenien · **Inscription:** 21 Fév 2020, 11:38 **Messages:** 372

Samuel Devulder a écrit:

Préhisto a mis les data dans les valeurs immédiates pour gagner un max de cycles. Par exemple LDA #123 (adressage immédiat) coûte 2 cycles, alors que LDA ,X+ (adressage indexé, le registre X pointant sur les données) coûte lui 4+2=6 cycles, soit trois fois plus lent. Ca prends plus de place en "code", mais l'avantage en vitesse est primordial si on veut maintenir les 25 images par secondes.

Sauf que, je viens de me rendre compte en Assembleur qu'en utilisant LDD en mode étendu (6 cycles, soit en utilisant les régistres A et B), ça fait à peine plus que l'appel de 2 fois LDA en mode direct! (2x2), et c'est exactement ce font j'ai besoin pour l'affichage des sprites en mode bm 16c!! Et évidemment, c'est 2 fois moins que les 2xLDA en mode étendu (10 cycles) C'est une des forces du 6809 qui est sans doute sous exploitée... Au leu d'être à du 25img/s on serait à du 20 en mode indexé ?

Même mieux, en mode indexé, on peut faire un LDD en 5 cycles contre 2x2 avec LDA en mode immédiat!
Ca signifie qu'on peut utiliser les accès mémoire en 20 img/s! Et pas besoin de rafraichir le fond d'écran, on n'a juste besoin de rafraichir les zones concernant les sprites.

Samuel Devulder

En asm un truc bon à savoir le ",x+" est pas mal coûteux (et encore plus si c'est un ",x++"). Souvent il est préférable d'utiliser n,x avec n constant ("1,x", "2,x", "-8,x" etc) On doit gagner 1 cycle ou 2 par instructions avec ca facile. Ca n'a l'air de rien, mais les petits ruisseaux font les grandes rivières.

Je pense que le pascal est un bon choix pour le haut niveau (algorithme du jeu). Ensuite se faire des primitives en ASM pour afficher les sprites est un excellent compromis.

Concernant les 20imgs/s ca fait 50ms par image, soit 50 000 cycles par image. Ca a l'air beaucoup mais ca part très très vite. Mieux vaut ne pas se préoccuper de l'optim fine tout de suite, mais déjà implémenter un moteur qui tourne bien, est bien découpé en opérations indépendantes ce qui laisse de la place aux optims locales si besoin.

sam.

Neotenien · **Inscription:** 21 Fév 2020, 11:38 **Messages:** 372

Samuel Devulder a écrit:

En asm un truc bon à savoir le ",x+" est pas mal coûteux (et encore plus si c'est un ",x++"). Souvent il est préférable d'utiliser n,x avec n constant ("1,x", "2,x", "-8,x" etc) On doit gagner 1 cycle ou 2 par instructions avec ca facile. Ca n'a l'air de rien, mais les petits ruisseaux font les grandes rivières.

Je pense que le pascal est un bon choix pour le haut niveau (algorithme du jeu). Ensuite se faire des primitives en ASM pour afficher les sprites est un excellent compromis.

Concernant les 20imgs/s ca fait 50ms par image, soit 50 000 cycles par image. Ca a l'air beaucoup mais ca part très très vite. Mieux vaut ne pas se préoccuper de l'optim fine tout de suite, mais déjà implémenter un moteur qui tourne bien, est bien découpé en opérations indépendantes ce qui laisse de la place aux optims locales si besoin.

sam.

Oui ça passe très vite, surtout sachant qu'une RAM écran c'est 16kO! Et le jeu qui m'épate le plus au niveau du scrolling sur Thomson c'est Bob Morane SF ou Prohibition (ça doit être le même auteur). En supposant qu'il y a 16 kO par écran... A mon avis, ils ont dû utiliser toute la RAM pour y mettre les pixel écran (à supposer que ça fasse 2x4 écran de large, on arrive déjà à 128kO de RAM

J'ai déjà dans l'idée de comment optimiser pour un scrolling type Mario BROS. En utilisant (et conservant) le timer à 0.1s ça devrait déjà être pas mal.

Pour Bubble Bobble, il y a rarement + de 5 sprites à l'écran (+ les bubules.. Et vu déjà la démo de Wip Zezito sur TO8 (qui me parait vraiment la version la plus réussi de l'auteur comparé à Amstrad, BBC Micro, ZX 81 etc)

phpBB [video]

, ça devrait pourvoir se faire pour Bubble Bobble ausssi

Bentoc

Neotenien a écrit:

Samuel Devulder a écrit:

Préhisto a mis les data dans les valeurs immédiates pour gagner un max de cycles. Par exemple LDA #123 (adressage immédiat) coûte 2 cycles, alors que LDA ,X+ (adressage indexé, le registre X pointant sur les données) coûte lui 4+2=6 cycles, soit trois fois plus lent. Ca prends plus de place en "code", mais l'avantage en vitesse est primordial si on veut maintenir les 25 images par secondes.

Wow ça fait un travail monstre! Ce genre de truc est irréalisable avec Bubble Bobble (avec les centaines de sprites qui existe dessus)... Mais je me contenterais du 8 image/s (25/3), avec test du filtre de la couleur du pixel = 15.

C'est réalisable en utilisant un générateur qui va convertir les images directement en code.
J'en ai écrit un en Java, je compte partager le code avec vous tous, il me faut quelques semaines pour mettre tout ça en forme.
en attendant voici en pj une petite démo sur TO8 (utiliser B pour lancer), le personnage bouge avec la manette (Gauche, Droite, Bouton).
Il y a 66 images différentes pour le personnage.
Le code généré effectue le dessin selon la même méthode que prehisto, mais dans cette même méthode on va lire le fond et par auto-modification de code sauver le fond dans une routine de sprite compilé dédiée à l'effacement. La taille du code est donc doublée ...
On optimise ainsi le déplacement du pointeur et on ne parcourt que les pixels utiles (les pixels transparents sont sautés), on bénéficie également des 16 couleurs puisqu'on ne sacrifie pas 1 couleur pour la transparence.
C'est très rapide mais prend pas mal de place ... Mais ça peut être intéressant dans le cas de sprites avec bcp de pixels transparents ou avec une forme autre que rectangulaire. Je n'ai fait aucun bench pour le moment ni comparé avec d'autres méthodes.

Dans l'archive il y a également une image avec le code compilé correspondant à cette image.
DRAW_HIR0 => sprite compilé pour la sauvegarde du fond et l'écriture du sprite
ERASE_HIR0 => sprite compilé pour l'effacement du sprite

J'ai commencé le dev assembleur sur TO8 en septembre dernier ... donc soyez indulgents si vous voyez des énormités !
Si vous êtes intéressés on peut continuer sur un autre fil pour ce sujet en particulier ... en attendant que je trouve le temps pour écrire un article sur le sujet.

Bentoc

ça donne a peu prés pour l'image en exemple (taille 24x48 px) :
2714 cycles pour la sauvegarde du fond et l'écriture du sprite
1103 cycles pour l'effacement du sprite en rétablissant le fond

(le nb de cycles est calculé par le générateur et ne prend pas en compte les qq cycles en début et fin de méthode, juste la partie "dessin").

Samuel Devulder

Réponse sur un fil séparé dans la partie programmation: viewtopic.php?p=6233#p6233

adnz · **Inscription:** 06 Avr 2010, 01:59 **Messages:** 482

question !

Y a t-il une édition physique de Mission: Liftoff ??
(boite + disquette etiquette et tout )

exocet · **Posté:** 13 Nov 2022, 23:11

adnz a écrit:

question !

Y a t-il une édition physique de Mission: Liftoff ??
(boite + disquette etiquette et tout )

Désolé Adnz, je viens de voir ton message avec quasiment un an de retard

Depuis la sortie du jeu en 2018, Prehisto et moi avons continué à travailler sur l'édition physique de Mission: Liftoff. Malgré beaucoup de retard, les choses se précisent et normalement le jeu sera disponible d'ici quelques semaines !

Mission: Liftoff - Special Edition est une version améliorée du jeu sorti en 2018, avec en particulier :
- 2 nouveaux niveaux avec 256 ko de RAM, 4 avec 512 ko
- 2 nouveaux ennemis
- Le support de multiples types d'ennemis par niveau
- Optimisations diverses et variées sous le capot

Le jeu sera vendu sur disquette dans un boitier cristal type CD mais conçu pour les disquettes 3.5" :sol:

Logicielsmoto.com

Nouveau jeu Thomson : Mission: Liftoff

Qui est en ligne