Encore un projet de jeu en 3D sur TI - Page 4

Au fait, la vitesse devrait etre potable sur HW2, pas terrible sur HW1, d'après l'essai de nEUrOne. Le frame rate indiqué n'est pas toujours très exact (suivant l'état des piles).

Mes piles sont neuves (ce ne sont pas des batteries)

ton jeu :

moitib, faudrait que tu fasse une version 92+, pour tester sous PedroM

moitib > Il y a quelque chose qui m'intrigue dans ton moteur 3d...
Le nombre d'images par seconde qui s'affiche n'est pas l'air tres realiste:
Il est "calculé" en moyenne a 13.5 FPS.

Or en supposant que lorsqu'on appuye sur diamond+(droite ou gauche) on tourne d'un angle de 1/256*360 degré, en 1 tour complet de la camera autour d'un axe, le moteur doit avoir affiché exactement 256 images (en tous cas, c'est comme ca que je fait pour chronometrer le mien).

Et le tour complet dure plus de 45 secondes....
Ce qui donne un FPS de 256/45 < 6 images par seconde.

Y a-t-il un probleme ? (je ne sais peut-etre pas chronometrer...)

Ou peut être qu'il utilise 512 angles différents.
De toute façon, ça reste une méthode très aproximative.

Le 5eme chiffre indiqué en bas a gauche de l'ecran est un angle qui prend les valeurs entre 0 et 255 d'ou 256 valeurs.

moitib, le nombre d'image par seconde de ton moteur 3D m'étonne enormement

Galmiza
a écrit : Le 5eme chiffre indiqué en bas a gauche de l'ecran est un angle qui prend les valeurs entre 0 et 255 d'ou 256 valeurs.

Ah d'accord, je ne savais pas.
Ben oui alors, le chiffre de 13 fps est bizarre.

>moitib, faudrait que tu fasse une version 92+, pour tester sous PedroM
t'est en retard ca fait une semaine que Pedrom est sur ma TI89

C'est vrai ?
Je l'essaierais bien. On peut obtenir la denière bêta où ?

Pour le frame-rate, effectivement il est (ca se voit) moins élévé que ce qui est affiché.
En fait il est calculé sur 10 affichages, à l'aide de l'USER_TIMER.
Je viens de me rendre compte que j'ai confondu 50 et 20 (ils est mis à jour 20 fois par seconde).
Donc divisez par 2.5 le framerate

Là je suis en train de recoder un triangle filler en assembleur... (ce qui me prend du temps car j'ai pas l'habitude des instructions). M'enfin...

Si t'as pas l'habitude de l'ASM, fait confiance aux routines de pros comme celles de PpHd, ça vaut mieux

Le must est sans doute de programmer le boucle principale en C et toutes les fonctions en ASM.

Pour l'instant je fait tout en assembleur, mais vu les problemes que j'ai pour stabiliser les niveaux de gris, je vais apprendre le C.

Si t'as pas l'habitude de l'ASM, fait confiance aux routines de pros comme celles de PpHd, ça vaut mieux.

J'ai donc eu raison de commencer la programmation avec ASM .

Je pense que c'est effectivement une très bonne chose d'apprendre la programmation dans cet ordre.
On est assez nombreux dans ce cas sur yAronet. Le principal avantage est de pouvoir programmer en C de manière très efficace (on sait par quelle suite d'instructions le compilateur va traduire telle expression).

Cela dit, je pense que tu n'as pas assez d'entraînement pour que ce soit aussi bénéfique. Tu devrais continuer à coder en ASM pendant quelques mois encore : le temps d'apprendre toutes les possibilités et les principales astuces d'optimisation

Je continuerais de coder mes fonctions en assembleur (c'est tout de meme plus rapide), mais le C a l'air beaucoup plus facile en ce qui concerne la gestion des interruptions, des horloges externes, des niveaux de gris donc de l'ecran, du clavier, de la sour...nan.

J'analyserais les exemples fournis avec tigcc pour eviter de vous poser des questions trop connes mais surtout pour que Vark, qui a un mal fou a se controler et a garder son calme, evite de piquer sa crise et de m'insulter (oui, j'ai lu le topic "les trolls").

Thibaut a écrit :
Si t'as pas l'habitude de l'ASM, fait confiance aux routines de pros comme celles de PpHd, ça vaut mieux

En fait, j'ai l'habitude de l'asm z80 mais pas 68k.
J'en profite donc pour me familiariser avec l'asm 68k...

Pour le triangle filler, je pars d'une routine optimisée en C, donc en assembleur ca devrait le faire...

Sinon, pour l'instant la routine de rendu du monde est en C, ce qui est plus pratique pour faire des modifs...
Si je considère à un moment que j'ai plus de modifs à faire, je la passerais en asm.

Je ne suis pas d'accord avec toi Thibaut, en effet beaucoup de personnes on commencé ici par l'ASM puis ensuite le C, comme moi j'ai fait mais le mieux serait moitib serait que tu te mette au C est que tu code seulement en assembleur pour des fonctions qui demande de la vitesse. En plus si tu as commencé par l'assembleur tu apprendras plus facilement le C.

moitib: des que t'as une nvelle beta pour un test, n'hésite pas

#107 : ça serait cool que tu dises pourquoi tu n'es pas d'accord

geogeo a écrit :
mais le mieux serait moitib serait que tu te mette au C est que tu code seulement en assembleur pour des fonctions qui demande de la vitesse. En plus si tu as commencé par l'assembleur tu apprendras plus facilement le C.

?

Mais je connais bien le C.
J'ai d'abord fait le l'asm z80 (pour 86) puis j'ai appris le C pour programmer sur les 68k.
Maintenant je commence l'asm pour les 68k.

Et je code effectivement en assembleur les fonctions qui necessitent de la vitesse (celle qui sont appellées le plus grand nombre de fois).

normal ... optimiser les 10% de codes qui prennent 90% de cycle proco ...

Ah d'accord, je n'avais pas compris que tu codé avant en z80.

Tu penseras à expliquer ton désaccord Je ne vois pas où tu ne me suis pas.

Uther Lightbringer a écrit :
>moitib, faudrait que tu fasse une version 92+, pour tester sous PedroM
t'est en retard ca fait une semaine que Pedrom est sur ma TI89

Chut, c pour avoir une version 92+ plus rapidement;D

Thibaut a dit: Cela dit, je pense que tu n'as pas assez d'entraînement pour que ce soit aussi bénéfique. Tu devrais continuer à coder en ASM pendant quelques mois encore : le temps d'apprendre toutes les possibilités et les principales astuces d'optimisation

Je pense qu'on peux commencer à programmer en C même si on n'as pas assez d'entraînement. Le C et l'ASM sont bien différent et pour moi ne sont pas lié.

Le C et l'ASM sont bien différent et pour moi ne sont pas lié

bah, qd tu sais comment certains trucs C sont traduit en ASM, ca te permet de faire le bon choix en C pour optimiser plus
(ou alors de carrement utiliser de l'ASM inline tellement le compilo te genere un truc affreux alors que tu peux le faire en quelques instrucitons en le faisant par toit-meme)

Bien entendus quand on a de l'expérience mais faut pas coder des programmes en C comme on le ferait en ASM.

faut pas coder des programmes en C comme on le ferait en ASM

ou l'inverse
(coder en ASM a la facon de ce que te sors un compilo... c pas optimal )

Voilà, squale92 a tout à fait exprimé pourquoi C et ASM sont liés, et pourquoi il devrait continuer l'ASM intensément avant de passer au C.