Logicielsmoto.com

Nous sommes le 28 Mar 2024, 14:40

Heures au format UTC + 1 heure




Poster un nouveau sujet Répondre au sujet  [ 2 messages ] 
Auteur Message
MessagePosté: 27 Fév 2020, 22:22 
Hors ligne

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

Je projette de faire une adaptation du jeu (du moins partiellement, au moins le premier niveau) "Bubble Bobble" qui est un jeu qui m'avait vraiment séduit sur l'adaptation Atari Falcon issu des NES (émulateur de NES sur Atari Falcon). Je pense que je vais me baser sur la version Amstrad de 2011-2014 (Home Brew) qui est plutôt bien faite. Les Thomson sont la seule plate forme 8 bits sur laquelle ce jeu n'a jamais été adapté (ou trouve la version MSX, C64, ZX Spectrum, BBC Micro même, Amstrad CPC, NES, Master System etc)

Adaptation avec Pascal Base (comme je soupçonne que beaucoup de jeu FreeGame Blot ont été fait avec ce langage, notamment Blue Star). Du coup, ça vaudrait le coup de créer des routines Pascal Base pour l'ensemble du moniteur et de l'extramoniteur.

Le langage Pascal est un langage structurellement proche du C, mais la version Pascal Base a un inconvénient, est qu'il n'y a que le type "Integer" (2 octets) qu'on peut déclarer; contrairement à Pascal UCSD, mais on peut contourner le problème.. Par exemple, pour jouer la musique avec Pascal Base, il y a une procédure qui le fait avec un ensemble d'entier pour la note, l'octave etc... En fait, il n'y aurait que pour les calcul de flottant (extra moniteur) qui poserait problème...

Pour le reste, il y a une doc (sur le site DC Moto) qui fournit les sources de 19 procédures du moniteur adapté à Pascal Base (pour TO et MO), dont les PEEK et POKE

J'ai déjà effectué des comparatifs entre le BASIC et Pascal pour diverses choses... Voici les résultats:
Boucles (20x10000)
- 2'09 en basic pour 20x10000 boucles
- 37" en pascal base compilé (x3)

tri bulles 75 élément
- basic, 38 secondes
- Pascal 2s (x19)
tri 150 élément
- Basic 155"
- Pascal 21" (x7)
Je précise que les éléments en Pascal sont une répétition de mêmes élément donc avec possibilité de dégradation avec le nombre,, alors qu'en Basic c'était un RND, d'où la vitesse relative différente.

Il me reste à comparer pour les tracés de points (un sprite de 8x16 met 2 secondes en Basic, j'espère qu'en Pascal ça sera considérablement moins), pour le mode bm16c.

Pourquoi choisir le Pascal ? Parce que c'est un langage poche du C dans sa structure, qu'il est compilable, et qu'il permet des choses tels récursivité, appel de fonction par valeur OU pointeur, que ça a été mon premier langage de développement en fac et que quand je vois la super qualité des jeu freegame blot comparé à de nombreux autres... (côté graphisme et vitesse)... Et surtout que ça permet un gain considérable au niveau du développement comparé à l'assembleur! Pourquoi se priver d'un langage de haut niveau capable de compiler ?

Tout ce qu'il manque, c'est de compléter les Unité du moniteur, du son, de la manette de jeu etc... Afin d'avoir un langage aussi complet que le basic mais compilable et adapté pour les développement ambitieux (par exemple, on peut imaginer un système sommaire de graphes pour calcul d'itinéraires adapté à la limite du 6809 en terme de vitesse... Par exemple, pour un tri bulle, pas la peine d'espérer dépasser les 200 éléments (mais avec le tri quick sort ça peut facilement est x10).


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

Inscription: 21 Fév 2020, 11:38
Messages: 366
Déjà fait les premiers essai d'affichage de sprites Bubble en Basic et Pascal en mode 160x200 16c.

Affichage de 50 sprites : 7 s en Pascal compilé, 130s en Basic (même algorithme)

Je pense que je vais développer une routine perso en assembleur, que j'ajouterai dans les procédures Pascal) pour l'affichage des sprites sans transparence (pour les tiles lors de jeux futurs, comme super Mario) et sprite (avec transparence).

Il y a juste la question que je me pose à savoir comment agencer les octets (pour les tiles) de couleur bm 16 bit dans une mémoire buffer de 16 kO (dans une des banque RAM). Parce que le TO8 gère le bm 16 c d'une façon assez particulière quand même... Je pense que le mieux est de faire, par GPL, en mettant les octet impair en mémoire basse de la banque et les octets pairs en mémoire haute (ou vice versa). Mais concernant Bubble Bobble, ça ne nous concerne pas. Il n'y a pas de scrolling ici.


Haut
 Profil  
Répondre en citant le message  
Afficher les messages postés depuis:  Trier par  
Poster un nouveau sujet Répondre au sujet  [ 2 messages ] 

Heures au format UTC + 1 heure


Qui est en ligne

Utilisateurs parcourant ce forum: Aucun utilisateur enregistré et 23 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