algo pour faire un raycasting - Page 2

ce serait possible que tu m'envoie le code pliz?
[email]alecbug@free.fr[/email]

Tu n'es pas obligé d'envoyer le code, mais est-ce que tu pourrais juste m'expliquer la technique, STP ?

aRf

sBibi : D'accord on peut avoir un moteur 3D sur 386, mais fera-t-il fonctionner correctement un jeu style Quake - pas besoin de tout, mais correctement j'entends - puis faire passer ça sur un 68000 qui est plus vieux que ce vieux 386 ?

pour le code, patientez, je ferai un tuto la dessus !

bon, vala, j'ai trouvé environ 2h pour programmer la même chose qu'en basic, et il y a évidemment les mêmes problèmes a résoudre !
à savoir la vitesse !
même pas 3fps ! (code pas encore optimisé, mais je pense pas que ça changera grand chose, alors je parle même pas quand il y aura des textures !)
le principe de détection des murs, je le fais avec des sin et cos, et je crois que ça, ça ralenti vraiment le prog, car quand je me déplace contre un mur, je monte vers les 6fps, et quand je m'en éloigne beaucoup, ça rame c pas croyable !
ensuite vient le problème des murs ronds : comme j'affiche la distance qui sépare la caméra d'un mur par un trait vertical, c'est donc normal de voir ça, mais bon, c pas du tout estétique !

Tiens si jamais t'as besoin de renseignements supplémentaires, ce site est vraiment nickel : http://www.permadi.com/tutorial/raycast/index.html .
Les murs arrondis c'est l'effet fishbowl, on y remédie avec une table de cos (y'a que ça dans un raycasting d'ailleurs, des tables et encore des tables...) bon courage

pour éviter les ralentissements près des murs, utilises des tables de sin et cos...
En effet, les calculs en virgule flottante sont extrémement lent...

Miles-> sur un 386, quake fonctionne
évidemment, si tu veux du trilinear texture mapping, soit du mip mapping, des textures 32 bits, une résolution de 1024*768, c cler que ça va pas tourner, mais un moteur 3D basique tourne sans problème sur 386...

(soit dit en passant, merci de me décourager; )

RV->tu vas en chier

RV-> regarde les sources de mon raycastingil est pas optimiser , et fais en C , et pourtant il tourne bien

sbibi, je sais, j'en chie déjà ! ça rame grave !
j'ai des problèmes d'arrondis, et je ne bosse qu'avec des mots (2 octects)

pour les murs arrondis, euh, vous pourriez etre + précis sur la solution ?

et chez moi, plus on s'approche d'un mur et plus le jeu vas vite !
- la gueule collée contre le mur : 22fps
- à 5 m (si le mur en fait 2 de haut) : 5 fps
- à 10 m : 1à2 fps
en fait j'ai tout fais à l'envers pour cette histoire ! surtout pour le rendu !

bon, vous pouvez trouver le zip du fichier asm sur mon site, comme ça vous verrez de quoi je parle !

j'étais déjà passé sur le site avant (je me suis pas lancé tout de suite la dedans !)
mais, j'ai ou pas trouvé le bon endroit du site, ou le point qui m'intéresse n'existe pas à cette adresse.

le lien vers le fichier est à "béta du moteur de raycasting" sur ma page

Pour les murs arrondis, c'est juste une question de "mauvaise distance" que tu corrige en multipliant par cos(angle), où angle est est relatif au rayon que tu es en train d'envoyer...
C'est plus clair sur cette page : http://www.permadi.com/tutorial/raycast/rayc8.html

aie, la méthode est pas bête (forcement), mais j'e suis convaincu que ça va encore + ramer .....................................

HerveRV: si tu veux vraiment gagner au niveau des fps.. rajoute un effet sombre.. c'ad ca limite la distance des rayons.... mais bon theroiquement ca devrai pas ramer autant surtout en asm...

Je me trompe peut-être sur ce que je dis, ou bien je suis complètement hors-sujet, mais pour les problèmes de ralentissements avec les cos, et les sin, tu n'as qu'à les précalculer au début du programme, tu fais l'équivalent d'une boucle FOR qui va de 1 à 360 et tu calcules pour chaque valeur le cos et le sin.
J'avais vu ça sur la page de christophe heulin (http://http:/www.multimania.com/heulin)...

Au fait RV.. n'arrete pas l'asm surtout pas, ou alors prog en C sous ti avec des lib comme genlib ce qui te permet de faire pas mal de chose....

euh, mais c ce qui est incorporé à rv_lib ça
car tous les jeux qui utilisent la rotation/trigo, c pour ça que j'ai une lib

Merde!
Bon, bah tant pis!

c pas grave, mais ta nouvelle url me plait beaucoup (tu vois, fallait la mettre )
http://epistein.multimania.com/Soute1/HTML2/DISTORCORR.htm
et c en français !
donc je comprends déà beaucoup mieux !

RV: ça c bien, c sur le site que t'as donné, et y a tt... c cool ça
http://epistein.multimania.com/files/Francho.zip

oui, il est loin d'etre beau, mais vu qu'il est bien illustré, et que c'est du français, c bien !
sinon, y a quand même des phrarses bizarres, difficilement compréhensibles, mais je vais pas trop me plaindre !

bon, si j'applique le correction de perspective, ça marche bien quand on est face à un mur, mais sinon c pas encore ça !

Idéal (ce que je cherceh à atteindre :

X
X
XX
XX
XXX
XXX
XXXX
XXXX
XXX
XXX
XX
XX
X
X

ce que j'ai:

XX
XXX
XXX
XXXX
XXXX
XXXX
XXXX
XXXX
XXXX
XXXX
XXXX
XXX
XXX
XX

ces croquis sont obtenus en longeant un mur, et en regardant parallélement à celui-ci
donc j'ai appliqué la formule (avec le cos) et c pas satisfaisant du tout, et j'y arrive même pas en basic

et ce que tu avais avant de multiplier par le cos, ça donnait koi?

des murs ronds et après aussi, mais pas tout le temps

bon, si multiplier par 2, ça inverse l'arrondi, essaye de multiplier par le cos lui-même...

Si ton mur est de longueur finie, c'est normal qu'il finisse en une verticale en perspective (comme dans ton 2ème schéma). En admettant que la hauteur du mur est constante, les segments correspondant aux plans supérieur et inférieur du mur ne se rejoignent comme dans ton 1er schéma que quand le mur est de longueur infinie (ou en pratique quand il est très long et que le segment vertical est négligeable).
[edit]Edité par Kevin Kofler le 08-11-2001 à 23:06:01[/edit]

non, non, je ense que tu as mal compris ce qu'il voulat représenter, c ça:

(le mur n'est pas infini, et c'est effectivement la première image qui est la bonne perspective...)

Ah, bon. Oups...

J'espère ne pas dire encore une bêtise, mais je pense bien que si c'est ça, c'est qu'il faut corriger à la fois en horizontale et en verticale, et donc multiplier par les cosinus respectifs de 2 angles, l'angle en l'horizontale et l'angle en verticale.

ben, je crois que c'est ce qu'il a fait (enfin, il me semble...)