algo pour faire un raycasting - Page 3

et justement, ça ne marche pas, enfin, si, ça marche, mais c'est encore courbé...
je lui ai suggéré de le diviser par deux, pour avventuer l'effet, mais il avait déjà essayé, et en fait, ça débombe le mur, mais trop! après, il est incurvé dans l'autre sens...

bon, pour la correction de perspective, c bon !


j'ai quand même mis un bout de temps pour trouver, vu que le basic c très lent

donc la manip c de multiplier un coéficant à la distance qui nous sépare du point d'arrivée (sur un mur), puis de multiplier aussi par le cos de l'angle existant entre la direction de visée et l'angle temporaire de balayge, puis de diviser tout ça à une constante, ce qui constitue un inversement "proportionnel", donc une bonne correction on va dire de la situation des murs bombés

il me reste encore à passer à l'asm !

et pour parler un peu du futur du prog, et j'ai bien l'intention de le faire, vu que j'ai longuement réfléchi sur son algo, mon programme s'appelle pas rf pour rien !
c un raccourci de red faction, et on pourra tirer des roquettes et passer à travers les murs explosés. j'ai également prévu de bouffer un max de ram pour que cet effet soit réussit, donc on verra bien ce que ça va donner !

on pourra jouer à deux en link ?

mouarf, avant de penser à ça, fo déjà faire un bon jeu à 1, non?

sinon, vi, ce serait bien

Aghnar: "La meilleure solution serait de reprendre le travail de T.Nussbaumer. a une epoque ou il etait encore tres actif il avait demandé l'aide d'un "wizard" en ASM et bien sur personne n'avait repondu, vive la TI-communauté super active"... Si tu avais lu mon post, tu saurais que j'ai bossé avec lui, et tu saurais aussi que l'asm n'apporte rien de plus que le C au niveau de la rapidité; la partie scaler est deja en asm: ce n'est pas le codage qui est a optimiser dans le FAT-Engine, mais l'algorithme lui-meme: et là il faut beaucoup plus de temps...

si tu veux faire ac les deux, tu passes du c à l'asm quand tu as optimisé un max tes algos, et ensuite t'optimises en asm, pour finalement terminer par les optimisations poussées,ac comptage de cycles, et là, si t'as tt bien fait, c bien optimisé
fo pas compter obtenir des vitesses faramineuses avec des algos pourris
il n'est pas rare d'accélérer d'un facteur de 10 à 100 des routines, juste en changeant d'algo ds certains cas, tu peux même accélérer encore plus...

j'utilise un algo qui de toute façon ne donnera pas un rendu superbe à la fin, mais c exprès, car pour ce que je vais en faire, c du fps qu'il me faut !
g bien optimisé, ça tourne entre 10 et 13 fps tout le temps, avec des murs pleins et de couleurs grises différentes, mais sans textures (pour ça, j'attends de bosser sur le découpage vertical de la matrice niveau, ce qui imposera une sorte de texture à sa façon, reste à voir ce que ça rend !

oué. En général, c l'algo qui est à la base de tout !

oui, mais la, le truc qui est moins bien, c que je me base sur un algo qui je le sais très bien n'est pas capable d'afficher un niveau texturé aussi bien que FAT ou TiWolf, mais il sera meilleur selon moi pour afficher les trous creusés ! et bien creusés !
donc il faut voir, et j'éspère pas faire une gaffe en choisissant cet algo, car comme c visible dans la nouvelle beta, le rendu contre un mur est pas terrible du tout, ce qu'il faut voir, c vu d'un peu plus loin, voila

bouh! marche pô, ta bêta
illegal instruction

si elle marche, mais même moi j'arrive difficilement à la faire tourner sur vti !
sur la vraie, oui et je sais pas pourquoi !
(au fait comment g fait le screenshot, hein ? )

arf...
y'a pas moyen d'avoir un joli truc, tt en ayant tt ?
(en gros, voir loin, mais voir bien ?)
arf...

Chez moi non plus, ça marche pas... (ti-89 hw2, ams 2.05)
Y a une erreur : "Protected memory violation"
[edit]Edité par jackiechan91 le 13-11-2001 à 17:46:47[/edit]

tu vois t nul!

Merde moi non plus j'arrive pas à le faire marcher

essayez avec la nouvelle version, elle marche c sur
mais je maintient que celle d'avant marchais chez moi, mais c normal en fait, mon PC ne fais jamais rien dans le bon sens.....

Nop, ca ne marche pas la version de ton site, en fait ca vient de la lib, car j'ai pris une lib plus vieille (sor3) et ca amrche...

ah... ben moi j'ai gardé la même lib, juste changé le prog, et maintenant, ça marche bien ...

c déjà ça de gagné

bon, maintenant que mes graphiques sont bien optimisés, et que enfin les murs ne rendent plus crade à leurs extrémités, je passe au mode de texturage, et au découpage vertical de la map.

sur le sujet de texturing, je pose la question quand même, afin d'avoir la solution la plus rapide, car g une méthode qui fonctionne, mais je la donne pas pour pas influencer les réponses.

il faut afficher colonne par colonne (colonnes de pixels) une texture.
négligeons le fait d'avoir une texture carré, mais considérons qu'elle est verticale, comme ça:

texture :
dc.b 1,0,0,1,1,0,0,1

bon, par exemple de 8 de haut, mais on peut bien sur en avoir une plus grande (à 2^n près)
autre chose, je connais le centre vertical de l'écran, il est à 49,5 pixels, donc g un registre D6 qui vaut la taille du mur, donc :
- la coordonnée haute est à 50-d6
- la coordonnée basse est 49+d6
et d6 est tjrs >0



voila, j'attends des idées/algos et même de l'asm si vous voulez

bon, déjà, un truc ... tu veux plaquer des textures...
donc t'as un mur comme ça:

  |\
  | \
  |  \
  |   |
  |   |
  |  /
  | /
  |/

il faut connaitre la côte verticale la + haute, la dim du côté vert le + petit, et la distance ki sépare les deux...
ça te fé 3 données...
est-ce que tu les as?
[edit]Edité par sBibi le 29-11-2001 à 17:29:25[/edit]

si oui, tu pe faire:

a=coteleplushaut
b=cotelepluspetit
c=distancehorizontale

DeltaHeight=a-b ;a>b
DeltaHeight=DeltaHeight/c

horiz_pointer=0
hoffset=texture_width/c
;ystart=la position y de départ de ton mur, xstart la position x :)
for i=0 to c
{
 horiz_pointer=horiz_pointer+hoffset
 voffset=TextHeight/a
 vert_pointer=0
 for j=0 to a
 {
  plot_point_texture(i+xstart,y+ystart,horiz_pointer,vert_pointer) ; plot_point_texture(xécran,yécran,utexture,vtexture)
  vert_pointer=vert_pointer+voffset
 }
 a=a-2*DeltaHeight
 ystart=ystart+DeltaHeight ; ben ça c si il est centré dans le plan vertical...
}

bah en faite j'en sais rien si ce truc marche, mais je vois pas pkoi ça marcherait pas... enfin le principe m'a l'air correct, mais g écrit ça vite fé et g pas relu, dc y a surement des bugs à la con... (je bosse là )

c un algo bien lourd et bien bourrin, ms g pas le temps de trouver mieux dsl
[edit]Edité par sBibi le 29-11-2001 à 17:35:54[/edit]

bah, c une possibilité, mais dans l'état actuel des choses, c pas comme ça que ça marche:
je lance un rayon par pixel, et je trouve un mur ( n° != 0 ), donc je sais quelle texture il a. je peux calcluer la coordonnée X sur la texture, par cette méthode:

  +---+
  |   |
  |   |
   |   |
   +---+

on a cette distance:
+
|
|
+

donc ici, comme mon mur fait 5 de haut, je cherche l'élément vertical 4/5 de la texture et je le colle en l'étirant juste une ligne sur une ligne verticale du plan graphique. (pixelon, méthode lente ...)

je supose que cette méthode fonctionne parfaitement, mais je suis pas convaincu qu'elle soit la meilleure.

hmmm... oui effectivement, c'est pas vraiment pareil...
je sais pas...
ça a l'air bien comme technique, même très bien...

tu n'as pas de moyen de calculer la coordonnée y dans le bloc que tu affiches??
tu dois l'avoir forcément cette coordonnée...

le dessin à foiré, g oublié qu'il accepte pas l'antislash ....

la coordonnée y n'est pas calculée, car on s'en fou, on la récupère avec la distance du mur/caméra et du rapport de percpective.
donc le pseudo y est position mini et maxi du mur à l'écran.

je réponds de travers ? (car je vois pas trop de quel y tu parle)

pour mettre un antislash, mets en deux à la suite, paske g rien compris à ton schéma...

tu as un bloc (mur):

_________
|        |
|        |
|        |
|________|

quand tu lances un rayon, et qu'il touche le bloc, il le touche en un point:

_________
|        |
|   X    |
|        |
|________|

par exemple...

la coordonnée y dont je te parle, c'est celle haut_du_bloc - point d'intersection

vu que tu as la coordonnée x aussi, ces coords sont celles du point dans la texture...
donc quand tu aff le point, tu aff le point contenu dans:

Texture[X*largueur_texture/largueur_mur,Y*hauteur_texture/hauteur_mur]
ce qui peut se simplifier si les hauteurs sont égales...
[edit]Edité par sBibi le 30-11-2001 à 10:35:28[/edit]

cette coordonnée, je l'appelle x, car c sur x que je vais charche ma texture, puis je l'affiche après

et t'as la coordonnée gauche_du_bloc - point_d'intersection ??

ça m'a pas l'air compliqué à avoir, disons que je l'ai