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

L'auteur de Space Demantia (moitib) entame un nouveau jeu en 3D.
Probablement un jeu de course de voitures.
Un screenshot :

http://moitib.free.fr/

waaa
J'espère qu'il le finira

De la concurence pour Trinity

Tout à fait, j'ai vraiment envie de voir ce que ca donne celui là ...

joli je suis curieux de savoir ce que ca va donner

hehe, je suis en train de coder le clipping...
mais la suite des concours arrivent pour moi...snif

Au fait, sBibi, tu bosses (toujours) sur Trinity ? Et le doom-like qui était envisagé ?

non je bosse plus dessus, le doom-like je comptais le faire une fois le moteur fini, mais vu qu'il est loin d'etre fini... la pour l'instant le projet est en pause pour une duree indeterminee

ok.

ca utilise ton propre moteur ou un truc comme fat-engine ?
En tout cas ca tape

fat-engine
LOOOOOOOOOOOOOOOOOOOOOOOOL

Ce n'est clairement pas du FAT Engine. Ça se voit de loin: FAT Engine est optimisé pour des endroits avec beaucoup de murs, là il n'y en a pratiquement pas! Autre indice: FAT Engine est du "Fixed Angle Texturing", alors que là, on est en flat-shading (pas de textures)! C'est donc un moteur différent.

quand je disait fat-engine c'etait pour demander si le moteur etait bien de lui et si non lequel etait-ce
mais je me suis mal exprime

Nan nan c'est moi qui fait le moteur... C'est le plus interressant alors j'ai pas envie de reprendre un truc tout fait.

Kevin : Il me semble qu'avec le FAT, on ne peux avoir qu'un niveau, que des murs à 90°, etc... (C'est du raycasting koi)

Euh sinon je cherche (ou je cherche des infos pour en faire une) une routine qui remplit des triangles (rapidement ), sans déformations pour les triangles très grands qui dépassent largement les bords de l'écran... Je m'explique :
J'ai une routine qui en gros pour avancer le long d'une ligne calcule (dx<<7)/dy
(déja la division ca fait perdre un peu de temps) puis avance de ce pas (>>7) à chaque fois. Le problème c'est la mauvaise précision quand dy devient trop grand... d'ou la déformation du triangle...

Je pensais à un truc du genre brensenham mais en avancant sur deux lignes différentes (et la routine fonctionne différemment suivant que dx >= dy ou dx < dy)
en même temps ça s'annonce chaud...

Si quelqu'un à déja planché sur le pb je pense qu'il comprendra...
Merci.

genlib possède des fonctions de remplissage de triangles qui sont sûrement très rapides.
Moi même, je vais en écrire une (en ASM), mais c'est pas pour tout de suite.
Sinon, il me semble que nEUrOne en a une sur son site (en C) : http://neurone.kouette.com/index.php?do=partie/prog/ti/source

Je viens de regarder :
En effet, il y a une routine de dessin de triangle plein, mais elle fait pareil que celle que j'ai (3 divisions), sauf qu'il passe par des long et qu'il fait des décalages de 16 bits...
J'y avait pensé. J'ai pas encore essayé mais je vais le faire...
Passer par des long devrait permettre d'accepter des coordonnée jusqu'a 65000 et quelques sans retour à l'autre bout de l'écran...
Ouais ca devrait marcher en fin de compte

En fait, je savais que nEUrOne avait une fonction de remplissage de triangles sur son site, mais je ne l'avais jamais regardée en détail.
Là je viens de la regarder et je pense qu'elle est largement optimisable en bresenhamisant le tout. (par contre, le code sera nettement plus compliqué et plus gros).
Mais sache qu'un décalage de 16 bits sur un long prend 8+16*2=40 cycles, ce qui est beaucoup.
Je te conseille d'utiliser celle de PpHd. À mon avis, il a tout bresenhamisé, lui.
Sinon, tu peux demander à sBibi la sienne.

jackiechan
a écrit : Mais sache qu'un décalage de 16 bits sur un long prend 8+16*2=40 cycles, ce qui est beaucoup.

C'est bon à savoir, en effet ...
Je vais voir avec PpHd ou sBibi.

moitib a écrit :
une routine qui remplit des triangles (rapidement )

Tu dis ça pour exclure FillTriangle de AMS?
(Remarque, c'est normal, les ROM_CALLs ne vont pas à une vitesse suffisante pour de la 3D. Ils sont prévus pour de la 2D.)

Ils ne sont mêmes sûrement pas prévu pour des jeux, mais simplement pour les applications de AMS.

Kevin Kofler a écrit :
Tu dis ça pour exclure FillTriangle de AMS?
(Remarque, c'est normal, les ROM_CALLs ne vont pas à une vitesse suffisante pour de la 3D. Ils sont prévus pour de la 2D.)

C'est clair que ça a été exclu d'office
C'est ce que j'avais utilisé pour le premier test au tout début et ct sans surprise lent comme un escargot...

ouaou c cho comm ejeu, il est gras bô !
yep j'espere qu'on arrivera a ce niveau aussi (la 3d arrive a grand pas)

Kevin Kofler a écrit :
Tu dis ça pour exclure FillTriangle de AMS?
(Remarque, c'est normal, les ROM_CALLs ne vont pas à une vitesse suffisante pour de la 3D. Ils sont prévus pour de la 2D.)

quand on dessine c tjs en 2D ()

erf, moi j'utilise aussi trois divisions, mais des swap pour decaler de 16 bits...
qd t'as besoin de la bonne coordonnee, tu swap et tu recupere la bonne valeur dans le reg.w
c'est quand meme mieux que de decaler de 16 bits a chaque fois...

Dac.
Il vaudrait mieux que je réécrive la routine en assembleur dans ce cas, ca serait plus propre

le C c'est bien pour optimiser l'algo, mais y arrive un moment ou quand les differences de vitesse entre != algos deviennent trop faibles, ou que tu bloques, y vaut mieux passer a l'asm et optimiser directement le code
et optimiser le code en nettoyant et en passant tout dans les registres permet parfois aussi de se rendre compte qu'un algo qui paraissait moins avantagueux qu'un autre peut (une fois les deux passes en asm et le code nettoye et optimise) s'averer etre plus rapide

le C, c'est bien, l'asm, c'est mieux! (c)

La routine de filltriangle est pas bonne pour faire de la 3D rapide

tu parles de celle qui est sur ton site ou de celle de l'AMS ?

sur mon site ...
A l'époque on avait testé avec lolo ... il s'était avéré que ce n'était pas jouable !

genlib a des fonction de triangle assez rapide, tu pourais essayer

J'ai regardé celle de sBibi, elle a l'air bien rapide aussi.