Logicielsmoto.com

Nous sommes le 28 Mar 2024, 22:11

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 6 messages ] 
Auteur Message
MessagePosté: 11 Juil 2022, 20:37 
Hors ligne

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

Au hasard d'une discussion sur un des forums, j'ai vu Samuel parler d'UG Basic, qui est un langage "isomorphe" (iso signifiant égale et morphe = forme), ça signifie un langage compilateur Basic pour tous les ordinateurs 8 bits équipé de 6502, Z80 et 6809 (ce qui inclut les Thomson MOTO, les Dragon 32/64, TRS Coco).

Ce langage est une tuerie! Il est basé sur le Basic en ayant supprimé tous ces défauts:
- Il n'y a plus de numéro de ligne
- Il y a des fonctions (appelés procédure comme en Pascal) et donc permet une progammation odulaire
- Il permet de compiler et créer des binaire dans pas mal d'ordinateurs 8 bits (Même les colécovision ont eu droit à leur version!)
- Il peut même fonctionner en multitache!

Et j'ai vu que samuel avait déjà fait le test sur MO5 en faisant une animation au siens d'étoiles (comme une des démos de PULS) et ceci en BASIC à une vitesse de 30 images/s:

phpBB [video]


Il est capable de gérer tous les modes vidéos des machines 8 bits.

Je viens de tester le jeu "4 Gravity" sur MO6/PC Olivetty, mais il ne se lance pas en mode basic 128 (erreur de RAM) mais en basic 1 en switchant le mode vidéo en BM4. Ca doit être un bug de ne pas pouvoir le lancer en mode basic 128... Quoiqu'il en soit le jeu fonctione bien, il ets très rapide, sauf que les chiffres n'apparaissent pas en haut du jeu "puissance 4"

Détails technique:
- On peut utiliser UGBasic sous Windows ou Linux
- Il y a un IDE (vous pouvez donner une dotation au développeur de ce logiciel) fonctionnant sous Windows uniquement (mais mache sous Linux avec Wine mais en mode Windows 7 mininum)
- Ce langage supprime tous les défauts du Basic (lenteur de l'interprétation, pas de numéro de lignes) et intègre ce qu'il y a de mieux dans les langages procéduraux (fonctions)
- il semble qu'il n'y ait pas de typage de données (mais il yn a l'instruction "CONST" comme en Pascal).
- Existe pour MO5 et MO6 (pas de version TO ? Notamment pour les adresses différentes ?))

Ce compilateur semble vraiment avoir une palette de fonctions large facilitant la création de jeux rapide et rapidement (contrairement à l'asssembleur), il permet de créer facilement des tuiles, les positionner, des sprites etc il me fait penser à un mix entre le GFA Basic... Je me demande s'il existe une fonction de copie apide de bloc en RAM...

Dans les idées à venir, il pourrait être envisagé de tester la présence du 6309 et basculer dans ce mode (natif) et utiliser des foncton tels TFM et les opérations arithmétics boosté de ce processeur.

Il y a des dizaines de listing de ce basic sur le Github de l'auteur, j'ai bien envie d'essayer les 4 chauve souris en tran de voler dans 4 zones!


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 12 Juil 2022, 12:40 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Sisi il y a typage des données. Regardes le source de mon starfield:
https://github.com/spotlessmind1975/ugb ... ld.bas#L42

Le mot clef VAR te permet de définir une variable et son type (ici entier signé 16bits). La doc n’est pas forcément à jour.

Ce basic est bien, mais son seul défaut est d’être super jeune et très ambitieux (plein de features, plein de machines, ide, site web etc.) Du coup les targets et les mots-clefs se multiplient plus vite que le code asm optimisé aux petits oignons pour chaque machine.

En général l’auteur code pour c64 (6502), et porte pour le 6809 qu’il ne connait pas bien. On a ainsi de base un asm qui marche mais contient des trucs curieux ou inutiles qui sont suboptimaux. Cela mériterait d’être revu par des professionnels du 6809. Je l’ai fait l’an dernier mais n’ai pas pu suivre la cadence des évolutions.

Ça prends pas mal de temps, et je conçoit que, pressé, l’auteur préfère ajouter des features qu’optimiser les anciennes pour une plate-forme qu’il ne maîtrise pas bien. D’autres amélioreront pour Thomson plus tard.

Bref il est urgent d’attendre et aider l’auteur si on comprend ce qu’il fait et comment bien le faire sur thomson (ça c’est pas simple).

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Juil 2022, 18:10 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Ouai bon finalement le langage ugbasic n'est pas si génial que ça (cf déboire rien qu'avec l'animation de Streetfighter), ou alor peut-être que je ne connais pas assez bien les fonctions... Mais ça a l'air limité en nombre de sprites qu'on peut utiliser

Or il se trouve qu'hier j'ai réféchi au moyen d'avoir de nombreux sprites (finalement je pars sur du 72x48 pxl max (Hauteur-Largeur)) dans StreetFighter pour TO8, et la seule façon est d'avoir au moins 2 banques RAM pour chacun des 2 adversaires et de faire une copie de chaque sprite dans la zone $9000-$9fff ret de l'utiliser ensuite en double buffer en bank 2 ou 3... Et je ne pense pas que ugbasic, du fait de son caractère générique, puisse faore ça, d'autant qu'en plus, ya même pas possobilité de changer les couleurs de palettes.

En comparaison avec la Version Atari ST, les sprites seront juste plus petits (environ -30% sur hauteur et largeur).

En fait, dans SF II la seule dificulté est justement de gérer cette ba,nque de gros sprite en RAM, pour le reste, il suffit d'utiliser l'algorithme Assembleur que j'ai pondu (avec ton aide Samuel) pour l'afichage de Sprite/Tuiles. Je dois m'y relmettre d'ailleurs, je ne sais plus laquelle des versions ASM de cette affichage de Sprite est la bonne parmi mes versions. Mais on verra ça après juillet.


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Juil 2022, 19:53 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
C’est plus la mémoire thomson qui est limitée. UgBasic n’est pas responsable de cela.

Les graphismes prennent très vite de la place. Dans ton example sf-2, ken fait 4 images de 48x96 pixels et blanka 4 images de 72x96 pixels, soit respectivement 9.2ko et 13.8ko. Combinés ils mangent 23ko. Ajoute à cela le code et les bibliothèques, et tu as saturé la zone $3000-$9fff (environ 28ko) dispo sur mo6. Réduis la taille de tes sprites devrait aider ou attendre la gestion des sprites compressés, plus tard.

Car n’oublions pas que ugBasic est très jeune. Tout n’est pas implémenté, et encore moins optimisé. Comme je l’ai déjà dit, il est urgent d’attendre, ou du moins de modérer ses attentes (ce basic est ambitieux, mais très jeune aussi).

Sinon tu fais erreur. La palette est parfaitement modifiable.:
* https://github.com/spotlessmind1975/ugb ... lor_02.bas
* https://github.com/spotlessmind1975/ugb ... lor_04.bas

Plus généralement tu tires des conclusions trop vite sans même avoir étudié tous les exemples. L’auteur te l’a dit: la doc n’est pas forcément à jour.

Ainsi en regardant les exemples, tu aurais vu que les sprites ont une option de bank qui permettrait de mettre des data constantes en zone commutable de façon générique. Bon OK, ça marche mal sur thomson, mais tu connais la routine: urgent d’attendre. L’intention d’en faire un grand basic exploitant â fond le matériel (à l’instar de Amos/Stos en leurs temps) est là. Mais l’intention ne fait pas tout. Il faut du temps et du travail. Rome ne s’est pas faite en trois jours.

Aussi pour moi il est important de finir correctement au moins une machine thomson (l’olivetti puisque l’auteur est italien) avant d’entrer dans une fuite en avant en multipliant les machines partiellement couvertes (to8, to9, etc).

_________________
Good morning, that's a nice Tnetennba


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 15 Juil 2022, 23:09 
Hors ligne

Inscription: 21 Fév 2020, 11:38
Messages: 366
Ok ca marche

Oui je suis impatient et un gros fainéant, j'y peux rien, je suis comme ça du fait de mon métabolisme qui ne me permet pas de pouvoir être actif 24/24... (si je suis au RSA depuis des années,c'est pas pour rien)

Pour la palette, j'avais cherché un truc du genre "Palette" et j'ai pas du tout penser que "color" (qui sert à définir la couleur de caractère en Basci 1.0) serait employé pour ça...

Pour ce qui est des banques, j'avais cru comprendre que tu m'avais écrit que cette instruction "bank" n'avait rien à voir avec ce que fait les thomson avec, c'est à dire de permuter les banques... Alors j'ai cru comprendre que ce Basic finalement ne se limitait qu'aux 65kO de base et pas ailleurs, mais j'avais vu vite fait une partie sur Bank qui semblait bien utiliser des banques de mémoire... D'ailleurs l'auteur m'a répondu en disant de mettre les "load images" en "bank(1)"

Bon je verrai, ce que tu me dis m'oriente vers le fait que ce Basic semble pouvoir gérer ces trucs de banques. Fait que je regarde ce langage plus en détail mais j'avoue que mes essais préliminaire avec Street Fighter II m'ont un peu découragé de prime abord (il n'y a que 2x4 images de 48x36 pxl max).

Pour la palette est ce que c'st adaptable à chaque machine ? En fait c'est plutôt bien vu de modifier la palette suivant l'index! Le trux est que quand tu as 2 personnages, en général;, tu as 2 ou 3 couleurs de palette à changer, et donc, disons qu'il faut s'arranger pour que les codes couleur à changer pour les 2 personnages soient différents, donc ça se fait au niveau du traitement de l'image initiale, ce qui ne pose pas trop de problème finalement. Je voudrai ouvoir faire une verson de SF II proche des Atari ST, tout est une quetsion de RAM pour les sprites, plus il y a de RAM et plus on peut avoir de mbmts différents. Je ne sais pas comment la version ST arrive à gérer tous les gros sprites et tous les mouvement dans les 512 kO seulement (sachant qu'il y a également le double écran du fond et l'audio en plus). Normalement avec les 256 kO des T8 on devrait pouvoir utiliser des sprites de 72x36 ou 72x48 (ce qui fait une taille RAM globale divisée par 2 comparé aux ST)... La version C64 n'est franchement pas terrible côté Sprites. Je me sers de cette ressource pour les sprites (qui sont tous en GIF 256 couleurs). Alors bien sûr je n'utiliserai que certains d'entre eux : marche, saut, baisser, avec une moyenne de 1000 octets/sprites, on a 4 mvts minimum possible par banque de 16 kO, soit 8 pour 2 banque (en supposant que le combattant ne soit orienté que vers une direction... Allez, en admettant quo'n ait 3 banques par personnage, ça fait 6 banques, voire 8 soyons fuor (Sur TO8), le reste (8 banque mini) étant dédié à autre chose.

J'avoue que si je pouvais juste faire des converstion d'image GIF de banque de sprites existantes vers Thomson plutôt que de devoir tracer chaque sprite (il faudrait au moins 32 sprites par personnage) avec mon logiciel JavaScript de créatoins de sprites bm16 Thmson, ça m'arrangerait. Et je n'aurai pas tout le code assembleur à créer.

Est ce que l'auteur a réussi à créer le code ASM pour les sprites en BM16 des thomson ? Apparemment c'est déjà le cas, donc j'ai bossé pour rien là dessus (et passé du temps) dans le passé...


Haut
 Profil  
Répondre en citant le message  
MessagePosté: 16 Juil 2022, 07:04 
Hors ligne

Inscription: 21 Aoû 2006, 09:06
Messages: 1802
Localisation: Brest
Bank est une instruction pour gérer le placement mémoire de certaines variables, mais aussi un paramètre de chargement de sprites. Un même mot-clé peut être instruction ou modificateur d’autres instructions suivant le contexte.

Perso, ce que j’ai fait pour faire le tour du basic et voir ce qu’il a dans le ventre, je me suis pris un a un les examples, étudié le source pour voir ce qu’il était supposé faire, et test sous emulateur. Si ca marche trop lentement, ou de façon surprenante plus vite que je ne le pense (tracé de cercle par exemple), j’ai étudié le code asm. C’est très instructif.

D’ailleurs si tu regardes les examples, tu verras que l’instruction palette existe aussi. Elle est machine indépendante je crois et prends en entrée des valeurs rgb standardisés (sRGB ou dans le genre), tout en corrigeant le gamma affreux des Thomson, pour approximer au mieux possible la valeur standardisée demandée.

Faut vachement faire gaffe avec les sprites et la taille des data en général. Rien que 2×4×48×36 pixels en bm16 occupent déjà 7ko. Ça fait beaucoup pour Thomson vu que le code du basic est assez volumineux lui aussi. Pour info, dans mussion liftoff, ou sonic ce sont les sprites qui occupent le plus de ram par rapport au code.

Au fait 512ko contiguë sur ST c’est énorme quand on en a moins de 32ko sur thomson en vrai. Si tu veux faire un programme massivement basé sur les sprites, il faut utiliser la solution de Bentoc qui est capable d’avoir des sprites dans les 512ko max chez Thomson. Mais dans ce cas il ne faut pas programmer le code de dessin des sprites soit même, mais laisser le framework gérer cela. La gestion des data sur plusieurs bank est de toute façons une horreur à coder (lent, plantogene). Je suis bien content qu’il existe un framework optimisé pour ca franchement.

_________________
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  [ 6 messages ] 

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 49 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 à:  
Développé par phpBB® Forum Software © phpBB Group
Traduction par phpBB-fr.com