Logicielsmoto.com

Ces derniers jours j'ai avancé sur l'affichage de la piste. Toutes les images sont maintenant intégrées, y compris celles en "miroir" (virages à gauche).
Au total ça représente 106 images et environ 700Ko de sprites compilés.
On est loin des 57Ko du jeu d'origine qui lui fait appel a un algo de "fou furieux" pour compresser les données des 56 images (la symétrie est gérée au runtime).
Je ne suis pas allé en profondeur dans l'analyse de cet algo ... il y a 2000 lignes de code assembleur pour gérer tout ça.

J'ai envie d'aller jusqu'au bout de ce special stage et d'en faire une version jouable, ça pourrait faire un "mini-jeu" sympa de Sonic2 sur TO8 (avec une T.2).

Comme pour l'écran titre j'essaye de rester au plus près du code d'origine, je conserve donc naturellement le format des données :
- structure de la piste (terminé)
- emplacement des objets (en cours)
- données de perspective (pas commencé)

La bonne nouvelle c'est qu'il existe un éditeur de niveau pour le special stage de sonic2 qui produit ces fichiers en sortie.
http://info.sonicretro.org/Sonic_2_Special_Stage_Editor
Les sources sont dispo ici:
https://github.com/flamewing/s2ssedit

Donc s'il y a trop de sprites à afficher (anneaux, bombes), je pourrai facilement modifier l'agencement des niveaux.

Il y a plein de mécanismes sympa dans ce special stage ... j'expliquerai ça au fil de l'eau.

Je vais commencer par les bombes qui n'ont pas d'animation (en dehors de l'effet de zoom).
Voici la conversion en 2:1 dans la palette existante (les mêmes couleurs que celles de la petite vidéo de mon premier essai de half-pipe avec Sonic).


J'utilise maintenant les scritps photoshop pour le remap de couleurs indexées et le resize en batch, c'est un gain de temps fou !

Salut,
J'ai besoin de votre aide pour la conversion du bout de code 68k suivant :



Il s'agit de multiplier deux valeurs 16bits signées :
- d1 (range FF00-1000) : correspond à un sin ou cos * 256, c'est pour cela qu'on a une valeur de -256 à 256
- d4 (range 0001-00FF) : correspond à un rayon stocké sur un byte
puis de diviser le résultat par 256

Comme les valeurs possibles pour les arguments sont restreintes, plutôt que d'implémenter un algo de multiplication complexe pour faire une division derrière, voici ma proposition :
Remarque :
- d1 est dans d
- d4 est stocké en 2,x



Une idée pour améliorer tout ça ?

En fait e que tu veux faire c'est multiplier 8 bits non signés (le rayon) par 8 bits signés (la partie haute du 256*sin() présente en 2,x).

Je ne pige pas trop les cas particuliers dans ton codecar ici par exemple A=$FF forcément, et donc je ne comprends pas pourquoi on lui remets la même chose.

Perso je ferais tout simplement ainsiA noter:

• l'utilisation du SEX pour envoyer $00 ou $FF dans A en 2 cycles
• la macro SKIP1 qui introduit un CMPB #nn pour sauter (non rien à voir avec le SEX ) au dessus d'un seul octet (celui du MUL). Cela coûte 2 cycles au lieu de 3 pour le BRA (et oui ca coûte un BRA ).

Au niveau cycles, on a 2 cas à voir:

• si sin<0, alors le code prends 2+3+2+11+2+2+6+2=30 cycles (pire cas), et
• si sin>=0 le code tourne en 2+3+11+6+2=24 cycles.

Pas mal.

_________________
Good morning, that's a nice Tnetennba

Merci pour cette réponse rapide !



=> c'est l'inverse le rayon est en 2,x sur un octet
=> le 256*sin() est sur 16 bits signés de -256 (FF00) à +256 (0100) et est chargé dans le registre D, comme je veux garder les 16 bits dans le calcul, c'est pour ça que je gère les deux cas particuliers car pour ces deux valeurs le LSB est 00



=> effectivement il faut retirer le lda #$FF ... sorry



Du coup ça marche pas car ici on perd la partie basse du 256*sin() ...

Par contre cette macro SKIP1 est hallucinante !!!
J'ai mis 15 secondes avant de comprendre et je suis tombé de ma chaise

Oui SKIP1 est rigolo, et devines quoi.. il y a un SKIP2 aussi Je te laisse chercher une façon de l'implémenter (mais c'est pas forcément plus rapide que BRA,. C'est juste plus court ce qui est utile si on est court en place mémoire.)

Ah oui, j'avais mal compris la partie basse. Je ne sais pas pourquoi, mais dans mon esprit D=32767*sin().. mais non tu l'as même écrit que D va de -256 à + 256. Du coup je pige les cas particuliers avec A=+/-1. On reprend:

_________________
Good morning, that's a nice Tnetennba

pour le SKIP2, je vois deux options :

- un CMPX ($8C) on perd un cycle (4 au lieu de 3 pour le BRA) mais on gagne un octet en place

ou bien ... si on accepte de perdre le contenu du registre D :
- un LDD ($CC) on a le même nombre de cycles que le BRA et on gagne un octet en place

Je regarde ta réponse en détail ce soir pour la multiplication (et encore merci).

yep LDD LDX ou LDU ou les CMP correspondants avec 1 cycle de plus si on ne veut pas modifier les registres.

_________________
Good morning, that's a nice Tnetennba

Bon après avoir étudié ta proposition, j'ai fait des tests et suis arrivé à ça :



Voici la matrice d'échantillons de test ... ça a l'air de fonctionner :


J'ai été obligé de faire un équivalent NEGD pour le cas de la multiplication négative, sinon dans certains cas ça ne fonctionnait pas (avec juste un NEGA).
Dans ta version il y avait encore une coquille : le BMI NEG faisait un appel à un BEQ NEG2 qui donc ne branchera jamais.
J'ai gardé ton idée des TST en lieu et place des CMPD car le gain est très intéressant.

Au final je suis bien content de ce petit échange, encore merci.

[Edit] Pour les tests j'utilise ce site que je trouve très pratique : http://6809.uk/

Remplace le 1er TSTB par NEGB et retire celui qui arrive après, ca sera encore mieux !

Sinon oui le nega/negb/sbca à la fin c'est bof car ca ne change quelque chose que si b=0 à l'issu de la multiplication ce qui est "rare". Il faut je crois faire un produit entre 2 puissances de deux qui soit >= 256, soit

• rayon=128 et 256*sin = -2,
• rayon=64 et 256*sin=-4,
• rayon=32 et 256*sin=-8
• ...
• rayon=2 et 256*sin=-128

Donc 8 produits sur les 128*513 possibles (128 rayons, et sinus de -256à 256=513 valeurs) où l'on aura un A plus gros de 1. A voir si c'est important ou pas.

_________________
Good morning, that's a nice Tnetennba

cool 2 cycles en moins !

pour le nega/negb/sbca je verrai au moment des tests (ça me plait pas non plus).

Petite astuce du jour à laquelle je n'avais pas pensé et qui est présent dans le code que je suis en train de "porter".

Dans une sous-routine, quand on veut retourner un booléen au code appelant pour brancher sur d'autres traitements,
et ce sans toucher aux registres de données, on peut utiliser :

En fin de sous-routine


De retour dans le code appelant :


Ne me tapez pas dessus si c'est archi connu ...

ha oui ça peut faire gagner des lignes ça, moi je connaissais pas en tout cas, merci pour l'astuce

ne me tapez pas dessus si c'est connus aussi

_________________

Petit point intermédiaire, je trouvais que mes ombres étaient un peu étranges (pas symétriques et les images semblent pas idéalement placées au niveau inclinaison) :

Version TO8 Thomson :


Alors j'ai mis mon fichier de test (piste et objets) dans la version megadrive de Sonic2 et recompilé la ROM.
Sous émulateur (gensKMod) on a ça :

Version Megadrive :


Ah bah non le portage du code est bon
Au passage on peut voir que j'ai une image de décalage au niveau de la piste.

Au niveau vitesse c'est toujours rapide, même avec toutes ces bombes.
On verra quand le personnage de Sonic sera réintégré, mais il me faut porter les 900 lignes de code asm associées avant.

Je vous montre une petite vidéo dès que j'ai réglé 2 ou 3 bugs ...

wouaaa.

_________________

Voici la vidéo :



Le défilement de la piste à été réglé à la vitesse maximum de 8fps (comme le jeu d'origine), c'est synchronisé par une IRQ à 1/50s (celle qui jouera la musique et lira le joystick)
Evidement ça peut ralentir si on charge trop les objets au moment d'un rendu d'une image de piste plus lente à dessiner que les autres.
A chaque boucle principale on regarde le temps écoulé grâce à l'IRQ et si il ne s'est pas écoulé 3 frames (on est en double buffering donc 6/2=3) alors on ne fait aucun rendu de piste.

Les objets sont rafraichis à chaque tour de la boucle principale du programme et donc profitent de tous les fps/cycles disponibles entre deux rendus de piste.

Il me reste un bout de code à écrire pour réguler l'avancement des objets quand ça ralenti, pour garder une impression de vitesse constante des objets par rapport à la piste.
On peut observer ce phénomène en fin de vidéo.