Arkanoid - Page 26

T'as modifié une variable sans la restaurer, point barre ._

http://tigcc.ticalc.org/doc/gnuexts.html#SEC99a

But note that the called function still has to save and restore those registers, even if they are used as arguments! In C code, TIGCC takes care of that automatically for you, but in assembly code, it is something you need to remember.

Enfin trouvé le bug très caché.
adda.l %d1,%a0

Le paramètre en %d1 était en 16 bits or la partie haute donc les bits de poids fort en 32 bits n'était pas effacé.
De plus s'était la seule routine où j'avais mis adda.l alors que les autres je mettais adda.w.
Serait-il possible qu'un compilateur en assembleur soit capable de repèrer ce genre d'erreur?

L'assembleur (ce n'est pas un compilateur) ne fait que transormer les instructions en language machine. Il n'essaye pas de comprendre ton programme (ce qu'un compilateur fait afin optimiser les programmes)

En tout cas ce genre de bug est très vicieux!

Il faudrait un programme du style de Valgrind pour les calculatrices...

Ce genre de chose n'existe pas pour 68K? Bref en tout cas je ne ferais plus ce genre d'erreur.

Conaissez-vous une routine de zoom ou plutîot de rétrécissement avec des rapports précis en assembleur ou en C de préfèrence très rapide?

Pour quoi faire? C'est toujours lent un zoom

Je pense que c'est pour faire une version TI89 sans trop se fatiguer

Je ne vois pas d'autres solutions qui donne de meilleurs résultats, surtout que je ne vois pas le rapport de passer par une routine pour adapter le jeu sur un autre support et source que je ne veux soit disant pas me fatiguer.

Si tu scrolle déjà l'écran je ne vois pas le problème?

Le problème du scrolling sur TI89 sera plus important car la zone de visibilitée sera très faible.
Il faut au minimum avoir toute la largeur du jeu visible sur l'écran.

./761>Ben disons que rétrécir l'écran est quand même une solutionde facilité...
Mais de toute façon, si tu veux faire ça, tu devras (ou tu devrais en tout cas) écrire la routine toi-même.
La technique pour l'affichage n'est pas très compliquée: tu dois juste calculer à l'avance 240 / 160 (* 256 pour le calcul en fixed point )

Oh j'avais depuis longtemps penser coder cette routine, je demandais juste déjà une routine toute faite pour voir ce que ça donne car j'hésite entre scroller ou zoomer.

Sinon tu met un lien vers Sim mais ça serait vraiment fuir la difficulté

Et le zoom n'est pas encore implémenté dans Sim!

lol ça ne fonctionne pas Protect memory violation, Sim n'aime pas arkanoid.

Kevin Kofler :
Et le zoom n'est pas encore implémenté dans Sim!

chut ^^

Voilà ce que ça donne si je fais un zoom:
Le jeu normal sur TI92+ avec une zone scroller de 224x128 pixels:


Et maintenant avec le zoom:


Je ne vois que 2 solutions, soit je fais une routine de zoom et pas de scrolling vertical mais la qualité graphique diminue ou soit je fais 2 scrolling, donc la différence entre l'écran de la TI92+ et celui de la TI89 en largeur est que de 64 pixels donc est-ce que ça vaut le coups de faire un zoom?

[EDIT] Quand à la différence entre 128 pixels pour la TI92+ et 100 Pixels pour la TI89 je peux effacer cette différence en éliminant 28 pixels du décors sur TI89!

Hmm, est-ce que ça serait possible de faire comme PocketNES, à savoir, une frame sur deux, afficher une couleur différente pour chaque pixel de l'écran qui représente 2 pixels logiques ? (Si qq1 voit ce que je veux dire)

C'est à dire trouver la couleur dominante entre 2 pixels et l'afficher? Et dans l'autre frame afficher la couleur non dominante???

En quelque sorte, oui
Enfin, si c'est trop difficile pour les lignes verticales, tu devrais peut-être essayer pour les lignes horizontales (ça résoudrait le problème des 28 pixels )

geogeo :
Enfin trouvé le bug très caché.
adda.l %d1,%a0
Le paramètre en %d1 était en 16 bits or la partie haute donc les bits de poids fort en 32 bits n'était pas effacé.

Je t'avais prévenu pourtant :

Sasume
(./713) :
Sinon, fais gaffe, tu avais fait pas mal d'erreurs portant sur la taille de l'opérande (.w au lieu de .l ou l'inverse)

Serait-il possible qu'un compilateur en assembleur soit capable de repèrer ce genre d'erreur?

Mais comment veux-tu que le compilo sache ce que tu veux faire ? Tu pourrais très bie vouloir additionner les 32 bits du registre !

Mais comment veux-tu que le compilo sache ce que tu veux faire ? Tu pourrais très bie vouloir additionner les 32 bits du registre !

Un Warning pourrais faire l'affaire.

Bon après avoir réflechie sur les divers modèles de TIs je propose divers options dans le jeu.

Pour TI92+ il sera possible de régler avec une zone d'écran de 240x128 pixels mais la qualitée graphique diminue où de choisir un scrolling vertical avec une zone de 240x200 pixels.

Pour TI89, il sera possible de régler avec une zone d'écran de 240x200 pixel mais avec scrolling horizontal et vertical, donc meilleur qualitée graphique, où zone de scrolling de 160x200 pixels soit vertical seulement mais avec une qualité bien moins meilleur ou encore une zone de 160x100 mais la qualitée graphique et vraiment nulle.

Malheuresement niveau ressource CPU certains cas demande un frameskip, vous en pensez quoi et selon vous ses modes sont suffisant?

geogeo
:

Mais comment veux-tu que le compilo sache ce que tu veux faire ? Tu pourrais très bie vouloir additionner les 32 bits du registre !

Un Warning pourrais faire l'affaire.

Mais d'où devrait-il le sortir, ton warning???
Le seul moyen de savoir qu'il y a un problème est d'exécuter le programme dans une machine virtuelle et de se rendre compte que les 16 bits de poids fort sont utilisés alors qu'ils n'ont pas été initialisés. C'est ce que fait Valgrind, mais il n'y a pas d'équivalent pour la calculatrice, malheureusement. Ça serait le genre de trucs utiles à implémenter dans un émulateur.

Ah ok je pensais qu'il était possible de faire ça directement en traitant le code.

Le mode Original est presque terminé, il me faudrait des Bêta Testeur sur TI92+ et V200 pour l'instant mais l'arriver de la version TI89 sera rapide je pense.

Les fonctionnalités du jeu sont les suivante:
-Gestion des briques finie à 100%
-Gestion des animations raquette finie à 90%
-Gestion des niveaux finie à 100%
-Collisions Billes avec le jeu finie à 80%
-Gestion Bonus finie à 100% (Total de 13 Bonus...).
-Gestions des Billes finie à 100%.

Ce qu'il reste à implanter:
-Les monstres et leurs gestion.
-Les Boss du mode Original.
-Les menus et options.
-Les introductions
-Le son.
-Support écran TI89

Dans les conditions minimal soit une raquette et une bille le moteur tourne à 70 fps et dans les pires cas à 40 fps mais je pense ajouter une option de FrameSkip pour gagner en vitesse.

Voilà donc si vous voulez m'aider pour trouver les bugs du jeu ou des améliorations. Ah oui le jeu fonctionne sur tous les OS même PedRom... Je pense fournir une version de tests demain.

Je peux tester ça sur VTI ?

Oui bien sûr.