[Xav] Sonic the Hedgehog

[shubibiman]

Xav, n'étant pas technicos pour un rond, je ne comprends vraiment rien à tes messages mais je trouve que ce que tu fais est vraiment génial!

[peperocket]

Touko, je ne comprends pas pourquoi tu es si pessimiste...

Comme Xav l'a déjà précisé, des routines en ASM ont été ajouté au code afin justement de combler certaines lenteurs générés par le de code de HUC.

[touko]

Touko, je ne comprends pas pourquoi tu es si pessimiste...

Comme Xav l'a déjà précisé, des routines en ASM ont été ajouté au code afin justement de combler certaines lenteurs générés par le de code de HUC.

Parce que c'est hélas vrai ,d'ailleurs il en a déja faite ..
Le probleme ne vient pas de xav mais de huc, qui n'est plus maintenu, la derniere version date de 2005, avec pas mal de soucis d'optimisations.

Et puis on peut pas bourrer le code avec de l'asm.

Je pense que le fait qu'il soit optimisé pour SGX n'y soit pas étranger ..
Je ne dis pas qu'il n'y arrivera pas, mais il doit surement en chier des bulles, hein xav ??

[xav]

Je pense qu'info indus est une formation parfaite, on apprend l'algorithmique, le hard et comment y accéder, on travaille sur des projet concret et on est formé en C et asm (le vénérable motorola 6809 pour ma part).

"metrovania" est le terme qui défini le gameplay des castlevanias type "symphony of the night", c'est en effet un mix des mots metroid et de castlevania

Nous en avons déja parler touko, faire un projet de cette importance entièrement en asm revient à le repousser "Ad kalendas graecas"...
Il faut trouver le bon ratio entre la facilité de codage (C) et les performance (asm)

J'ai bien sur fait d'énorme consentions, mais il n'a jamais était dans mes intentions de créer une conversion parfaite, plutôt un plateforme classique dans l'univers de Sonic.

Je ne dis pas qu'il n'y arrivera pas, mais il doit surement en chier des bulles, hein xav ??

J'en bave oui, mais pour retravailler les graphes et faire les maps, le code est pratiquement terminé je n'ai plus qu'a rajouter des fonctions comportementale pour SEER quand je crée un nouvelle ennemie et optimisé les effet graphique pour chaque zone.

Je pense que le fait qu'il soit optimisé pour SGX n'y soit pas étranger ..

Tu peux préciser

[touko]

Tu peux préciser

il me semble bien que tu avais parlé de 2 versions de sonic non ??
Une pour sgx et l'autre pour pce, avec bien sur plus d'effets et de details dans les anims sur sgx, ou alors je m'a gouré de pochette .

D'ailleurs je me demande même si une version sgx n'aurai pas été plus simple à faire ..

[xav]

il me semble bien que tu avais parlé de 2 versions de sonic non ??

Non c'est une seule est même version, avec un autodetect

Bon SEER est en partie réecrit en asm, P*TAIN ça speede!

Mais j'ai besoin d'un petit coup de main, et s'il vous plais ne rigolé pas parce que je sais que c'est le BABA, voila j'ai ça comme variable globale:

char entity_index;
int entity_x, entities_x[128];

et je veux faire en asm ceci:

entity_x = entities_x[ entity_index ];

Je sais trés bien le faire avec des octets

#asm
ldx _entity_index
lda _entities_x, x
sta _entity_x
#endasm

OK ça marche, mais là c'est des words donc comment je m'y prend

[touko]

Bon SEER est en partie réecrit en asm, P*TAIN ça speede!

Tu t'es paluché de l'ASM ..

ça donne envie de se lancer :|

[xav]

OK je suis une grosse buse interplanétaire!

Je ne peux évidemment pas me servir du même entity_index comme compteur pour un word et pour un octet dans la même boucle, puisqu'il faut l'incrémenter respectivement de 2 et de 1 par cycle

Maintenant ça marche

Voila à quoi j'ai passé ma soirée, bon maintenant dodo...

[touko]

Un truc, si tu manipules des words donc des entiers sur 16 bits, tu ne peux pas les manipuler d'un seul bloc!!

C'est à dire tu es obligé de les stocker en 2 parties, les 8 de poid faible dans un registre et ceux de poid fort dans un autres non ??

[xav]

En effet, j'ai rajouté une variable tmp_ex indépendante de entity_index, je la met à 0 avant ma boucle principale et je peux me payer le luxe de chargé les valeurs entity_x et y sans recharger le registre x tout en incrementant correctement tmp_ex:

Ceci:

#asm
ldx _tmp_ex
lda _entities_x,x
sta _entity_x
lda _entities_y,x
sta _entity_y
inx
lda _entities_x,x
sta _entity_x+1
lda _entities_y,x
sta _entity_y+1
inx
stx _tmp_ex
#endasm

Remplace donc cela:

entity_x = entities_x[ tmp_ex ];
entity_y = entities_y[ tmp_ex ];
tmp_ex++;

Tout en contournant LA béte noire de Huc: la gestion catastrophique des tableaux

[touko]

Ouaip ça m'intéresse fortement ça, vu que les tableaux y'en à pleins dans un projet ..

D'ailleurs je viens de m'en rendre compte que ça rame sur huc en faisant des fondus de palettes multiples (style 4 ou 5) ,avec multiples differentiels en même temps ..

Mais je me demandais justement comment faire pour accéder aux variables déclarées dans huc, dans une fonction asm !!

Un truc que je comprends pas bien

Code : Tout sélectionner

lda _entities_x,x
sta _entity_x

ça charge pas 2 fois la même valeur _entities_x dans les registres x et a ??

Ah ok je viens de comprendre

[touko]

Tu inseres directement le code asm dans tes fonctions lorsque tu veux manipuler un tableau ??

J'ai fais un essai tout con ..

Code : Tout sélectionner

#include "huc.h"

main()
{
  char val;
  
  val = 0;
  disp_on(); 
  
  #asm
    ldx _val
    inx
    stx _val
  #endasm
  
  put_number(val,3,10,10);
  
}

Je voulais juste incrementer val en asm.
A la compil ça me met qu'il ne connais pas val, comment faire pour utiliser une variable definie en C dans un code ASM ???

Merde il faut que les variables soient en global

[xav]

Oui deux règles:

- Les variables doivent être globales
- Dans l'asm elles doivent être préfixé par un _

A vérifier mais ils semble que dans HuC les variables globales sont stockés dans une banque du 6280 qui demeure toujours accessible, ce qui veux dire pas plus de 8Ko de globale mais en contrepartie pas de problème de mapage.

[touko]

Remarque pour remplir 8ko de variables, faut y aller ..

Franchement c'est un peu chiant d'être obligé de mettre toutes les variables en global, ça limite la modularité du code.

Sinon, tu comfirmes qu'il y a un réel gain de vitesse en faisant l'acces aux tableaux via l'ASM ??

[xav]

Contrairement aux processeurs "évolués" comme le 68000, le 6502 n'est pas pensé pour les langages complexes, donc les globales constitue une forme d'optimisation, étrange mais vrai

Le gain de vitesse est MONSTRUEUX, SEER en gestion des tableaux C ralentis parfois avec seulement 5 entités statique à l'écran, avec l'accès en asm, j'en suis à 12 sans ralentissement notable