je reprends depuis le début :
un jour j'ai voulu faire un espèce de truc en 3D qui est aujourd'hui bien connu (Halflife)
et j'avais du me résigner à enregister toutes les images dans le programme, ce qui est une affreuse méthode !

donc maintenant que je suis passé à la vitesse supérieure, et que j'ai lu quelques trucs pour faire un moteur avec un pas différent de 90° (par pas de 1° je pense), j'ai vraiment envie de le faire !

j'ai compris plein de choses sur le site d'un gars qui fais un half pour HP, avec la méthode des portails.

j'ai donc plein de question ! (avant de m'y mettre et de rien réussir)
si je capte bien le principe, je me met à l'ouvrage juste après finir rtype !

donc voila mes questions :

1) l'aspect d'un niveau :
quelle est la méthode la plus apropriée ? avoir des murs plats ou faire un système de carrés pleins ou vides (pour un fps important)

2) pourquoi plus les textures sont grosses, les moteurs graphiques rament-il ?
puisse qu'il y a le même nombre de points à l'écran au final !

3) le site de half sur HP donne une méthode pour le moteur :
on regarde dans une direction D, et on regarde avec un angle de 90°.
donc on part d'un angle D-45 jusqu'à un angle D+45.
on balaye donc de D-45 jusqu'à D+45 et à chaque fois on regarde jusqu'ou ce rayon de vision va aller, donc en gros tant que l'on a rien il avance toujours !
c'est ce que j'ai cru comprendre, mais comment on teste ça, surtout comment on gère un rayon de vision ?

4) il faut ensuite afficher la texture sur le mur, la hauteur de ce mur a un rapport avec la taille du rayon de vision, ce rapport est il linéaire ?
si, non, y a une formule ?

5) pour la texture en elle même (animée ne pose pas plus de problème que si elle y est pas, je pense), il faut trouver la distance entre le début de cette texture et l'endroit ou on vient la toucher avec le rayon de vision. je pense juste ?

6) pour rendre le jeu plus intéressant, il pourrait etre sympa de faire l('affichage, car on n'y verra que des murs de hauteur identique (je pense) et des gugus qui se baladent, mais comment gérer le fait d'avoir des taches de sang ou des imacts sur les murs ?
ça vaut le coup d'enregister les modification sur la texture du mur, ou ç'est superposé ?


j'ai du oublier pleins de questions !
mais ce qui est sur, c'est que j'ai bien besoin d'aide sur ce coup la !


et le smiley qui s'impose : (vu que c'est le même espris !)

aaaaaahhhhh

pour tt ce qui est spécifique au raycasting, je sais pas, paske mon moteur, c de la vraie 3d, dc ça n'a rien à voir...

pour les textures, c le perspective texture mapping simplifié, vu que tes murs seront toujours verticaux, tu fais des lignes de balayage verticales.

pour les taches de sang, ça se superpose à la texture, si tu veux un truc à la quake, où les taches s'effacent au bout d'un certain temps, sinon, tu modifies carrément ta texture, mais au chargement de ton prog, fo recopier ttes les textures en ram et pas les mod ds le prog, sinon tu gardera tes taches, et ça, je pense pô que ce soit très bo

c la mm chose que la tict ?

ouais................
sinon, t'as demandé à NITRO comment il avait fait???
c'était en C je crois donc en asm, cela pourra aller beaucoup plus vite

vive la vraie 3D !!
#rebelle#
#warrior#

en fait, on s'en fout si c'est de la vrai ou de la fausse, on veut juste un bon résultat.
après, la méthode ......

tu peux mater celui de la TICT... bien qu'il ne soit pas fini, je trouve qu'il est pas mal...
Bon courage !

aghnar avait repris celui de la TICT et avait rajouté ce qui manquait le plus : les diagonales
demande lui comment il a fait

sBibi > bon courage quand meme, si tu y arrive, tu aura d'autant plus de mérite

sBibi>Vu comment ton moteur avance sur ma HW1 , si tu veux faire un jeu je te souhaite bien du courage (et encore y a pas de texture mapping).
Mais bon , je te fait confiance, tu va bien l'optimiser.

on veut juste un bon résultat> justement, ac la "fausse 3d", le résultat est "pourri", cad qu'il se limite à un labyrinte... à un doom quoi.
par contre ac la vraie 3D, tu fé ce que tu veux, et c bcp+ joli
(bcp + lent aussi mais j'y arriverai!!! #re-warrior#)

tu veut faire quoi avec ??? unn doom avec des "étages", ca serait génial !!!

moi? ce que je veux faire avec?
de "vrais niveaux"!
comme ça:



de vrais niveaux comme ceux de quake, des niveaux en extérieur, avec des colonnes, des objets, des grilles, des jump pads, bref, de la vraie 3D koi, pas juste des murs verticaux!
[edit]Edité par sBibi le 04-11-2001 à 21:37:50[/edit]

1) l'aspect d'un niveau :
quelle est la méthode la plus apropriée ? avoir des murs plats ou faire un système de carrés pleins ou vides (pour un fps important)

Les fps ne jouront pas trop sur cet aspet du moteur, mais bien entendu le plus avantageux est d'avoir des mur plats...


2) pourquoi plus les textures sont grosses, les moteurs graphiques rament-il ?
puisse qu'il y a le même nombre de points à l'écran au final !

je ne comprend pas tres bien ta question je risque donc de repondre hors sujet, mais plus un structure est petite et plus la deformation demandera moins de c/S... pour cela je te conseil d'aller voir le cite de la TICT


3) le site de half sur HP donne une méthode pour le moteur :
on regarde dans une direction D, et on regarde avec un angle de 90°.
donc on part d'un angle D-45 jusqu'à un angle D+45.
on balaye donc de D-45 jusqu'à D+45 et à chaque fois on regarde jusqu'ou ce rayon de vision va aller, donc en gros tant que l'on a rien il avance toujours !
c'est ce que j'ai cru comprendre, mais comment on teste ça, surtout comment on gère un rayon de vision ?

Le principe de balancer un rayon dans le unniveau est en fait simple... tu as une matrice et tu doit lancer un rayon... l'algorithme a utiliser est le meme que celui pour tracer une droite sur l'ecran, c'ad bresenham..

NB: Il me semble que pya avait fait autrement, c'ad avec un table de cos precalcule... et apres c'est qu'une simple formule de trigo..., mais je pense que cela demande plus de c/S qu'avec bresenham.


4) il faut ensuite afficher la texture sur le mur, la hauteur de ce mur a un rapport avec la taille du rayon de vision, ce rapport est il linéaire ?
si, non, y a une formule ?
En fait il s'agit juste d'un aspet de perspective... c'est du thales en quelque sorte...
Si tu recherches avec google, tu trouveras peut etre un article de HPmad qui donne le bon coefficient en fonction de la taille du lcd, mais bon ca tu peux le trouver tout seul a vu d'oeil..
Sinon il y a le cite de la tict


5) pour la texture en elle même (animée ne pose pas plus de problème que si elle y est pas, je pense), il faut trouver la distance entre le début de cette texture et l'endroit ou on vient la toucher avec le rayon de vision. je pense juste ?

Si la texture est anime, cela pose demande beaucoup plus de c/S que lorsqu'elle ne l'est pas... en effet, la deformation due a la perspective doit etre applique sur chaque image de l'animation... celaa demander beaucoup plus de c/S, car la deformation de la texture et l'opperation qui prend le plus de temps dans un miteur avec les zoom..


6) pour rendre le jeu plus intéressant, il pourrait etre sympa de faire l('affichage, car on n'y verra que des murs de hauteur identique (je pense) et des gugus qui se baladent, mais comment gérer le fait d'avoir des taches de sang ou des imacts sur les murs ?
ça vaut le coup d'enregister les modification sur la texture du mur, ou ç'est superposé ?


Pour les taches de sang.. l'astuce est plutot simple... tu copies toutes les textures en rame.. et tu fais les modification dessus...
Neanamoins cela peut devenir genant si tu veux faire beaucoup de precalcule (surtout au niveau de la deformation des structure) car une tache de sang demandera de modifier toutes les structure precalculees..

A oui j'oubliais.. dans ce genre de jeux, le plus dure n'est pas de faire le moteur en lui meme.. c'est plutot simple.. mais c'est au niveaux des enemis que cela deviens vraiment dure.. zoom rotation en temps reels... en bref une veritable difficulte..
D'apres mes souvenir seul un programmeur a reussit a faire cela sur calc c'etait HPmad qui a fait un doom ou l'on pouvait jouer a 4 en reseau (4 calc racorde par cable) mais avec le 4 Mhz, il n'y avait pas de texture, les mures etaient blanc, et il n'y avait pas de monstre, mais bon il l'a quand meme fait;)

[edit]Edité par TiMad le 04-11-2001 à 17:22:29[/edit]

2) En fait on efectue un zoom sur chaque colonne de texture avant de l'afficher: plus la texture est haute plus il y aura de poiels à redimensionner... D'aileur cette partie du rendering prend 90% des ressources raycaster+renderer, le raycasting en lui meme est relativement rapide.

3) Dans le cas ou tu utilise des blocs de mur: le niveau correspond à une matrice: connaissant ton angle et ta position, à l'aide de sinus et cosinus, tu determines les cases par lesquelles ton rayon passe et tu teste au fure et à mesure, la valeur de la case dans la matrice, 0 il n'ty a rien et on continue ou autre chose, il y a quelque chose et on s'arrete. On determine, les points d'intersection de chaque rayon avec les murs pour appliquer la texture à la bonne échelle. La table précalculée est plus rapide que bresenham (il faut d'ailleurs pas mal adapter cet algo: car on ne connait qu'un extremité du segment) car on a besoin de moins d'operations: tu peux regarder la source de la TICT: elle est en C et tres claire... Pour ceux qui vont se dire que l'on pourrait l'optimiser et la traduire en asm pour obtenir plus de fps, ne perdez pas votre temps avec ça; Je l'ai deja fait quand je bossais avec thomas: le gain en fps ateint au maximum deux ou trois: donc c'est une perte enorme de temps pour rien

5) Animée ne pose pas de probleme si l'animation consite à afficher plusieures textures en alternance. Par contre si il consiste à modifier les textures en temps reel, mieux vaut eviter pour le moment.

TiMad: oui si on arrive a faire un scaler, assez rapide! En utilisant des murs blancs, HPMad avait contourné cette difficulté.

Hervé: Si tu as besoin, d'aide, tu peux me mailler, mais je ne suis là que le week-end.

C'est quoi la différence entre ce que veut faire herve et ce que fait sBibi ? (vraie et fausse 3D)

si je vais avoir besoin d'aide ?
peut-etre pas directement au niveau du codage, mat vraiment au niveau des algos !

je vais passer sur ce fameux cite ! (tict)

donc commençons par le plus dur : le moteur lui même ! (je pense que la suite ce sera plus facile, car la gestion des ennemis me parait pas si balèze que ça au premier abord !)
donc après avoir réfléchi un peu (ça m'arrive, oui !) je me dis que le niveau stocké sous forme de matrice sera la plus simple des solutions, niveau codage, et je me suis dit que pour le niveau au final, il y a moyen de rendre l'unité de largeur d'un mur faible, comme ça on aura plus de liberté (mais les niveaux seront gros en mémoire )

donc je dois déjà reussir à balader une caméra dans un niveau tout noir sans textures !
bon, bah je vais essayer ! (je promet rien !)

et je ferai peut-etre un tuto dessus, mais seulement si j'y arrive

j'ai rien trouvé sur le site de la tict ! (y a bien 'FAT', mais j'ai jamais vu de source dedans !)

jakiechan>ce que veut faire HerveRV, c un RAYCASTER, pas moi.
lui aura des murs verticaux, et UNIQUEMENT DES MURS... bref, la carte de son niveau est stocké sous forme de matrice, ac des "blocs" correspondant aux différents éléments, par exemple 0=rien 1=mur de briques 2= mur en bois, etc, etc

mon moteur, cad la "vraie" 3d, c'est à dire que la carte de mon niveau n'est pas une matrice, mais une suite de coordonnées dans l'espace, correspondant aux polygones.
c'est la méthode utilisée par tous les jeux actuels (quake, hl, may payne, wolf, etc...)
donc tu peux afficher tout et n'import quoi.

si g envie d'afficher une sphère, je peux.
avec un raycaster du type de doom, non.

pour le moteur de Rv, les bots seront des sprites, pour le mien des persos composés de polygones 3d...

en clair, avec un raycaster, tu peux afficher un beau labyrinthe composé uniquement de murs verticaux, alors qu'avec de la vraie 3d, tu peux afficher tout ce que tu veux (piliers, jump pads, plates formes complexes, etc...)

oui, mais la ou je suis pas d'accord avec toi, c que la ti89/ti92+ et les polygones !
je veux pas etre méchant, mais si tu arrives à faire un truc qui déchire tout ( ce que je ne doute pas du tout), ce sera obligatoirement très lent !
lmoi je cherche à faire un truc jouable !
même si le principe de jeu sera limité avec ma méthode, ce qui compte pour moi, c'est déjà d'apprendre la méthode du raycasting, puis ensuite de me défouler sur le prog (si un jour ce sera possible)
et de toute façon, je ne saurai jamais faire un programme comme toi !

bien sur, rv, mais mon moteur est avant tout destiné A UN JEU, je te le rappelle: quake 3 et je pense pouvoir y arriver (je ne peux pas donner de date, paske c qd même assez costaud à faire), et j'y arriverai.
le but que je me fixe est de 15 fps avec les textures... voila.
ça prendra le temps qu'il faudra, mais j'arriverai à faire un truc jouable! na!
#motivé#

Premier souci : pourquoi Quake 3 ne tourne que sur des engins plus de 30 fois plus rapides que la TI ?
Deuxième souci : 15 fps c'est bien, mais c'est peu - il est vrai que LCD = pas de scintillement -
Troisième souci : vitesse de balayage réel

certes, mais bon, j'en doute !
15 fps c'est mon but aussi !

Miles>le "vrai" quake 3 tourne en 800*600 en 16 millions de couleurs, oui.
mais la ti, c 240*128 maxi en 4 couleurs
et ce qui prend le plus de temps, c l'affichage... n'oublie pas aussi qu'on peut très bien faire un moteur 3D sur un 386
de tte façon, c clair que mon moteur ne sera qu'un moteur primaire, mais néanmois ac un texture mapper
je pense que c suffisant pour faire un bon jeu en vraie 3d
et si le fps n'est pas tombé trop bas, je pourrai rajouter qques "gadgets" du genre ombrage...
(je sais déjà comment le faire de façon assez rapide )

>Herve :


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

Donc n'hésites pas à le mailer pour demander à l'aider : je te rappelle son mail :
gmx.net'>thomas.nussbaumergmx.net

Il avait meme commencé à faire des outils d'extraction de textures pour des jeux comme Wolf3D.

A l'epoque je m'tais meme amuser à foutre 3 textures de Wolf3D (recuperes sur un site ki les avait toutes, je sais plus ou est ce malheureusement), ca rendait trop bien, enfin tout ca pour dire k son systeme permettait de faire des maps/textures soi meme tres simplement donc franchement ce serait bete d'abandonner un si beau projet !

Enfin je dis pas ca parck c en nostub, tu peux tres bien reprendre ca en mode kernel puisk apperement tu deteste le nostub.

Vala good luck parck c un projet ki demande enormement de motivation !
[edit]Edité par Aghnar le 05-11-2001 à 20:01:50[/edit]

je me contrefous du kernel/_nostub !!
je le fais en mode kernel, mais quand ce sera fini, je le compresserai peut-être en ppg...

euh ... je m'adressais à Hervé, pas à toa. je viens d'editer mon précédent post pour k ca soit plus clair.

je me contrefous aussi du kernel/_nostub !!

je préfère programmer en kernel, vu que je trouve ça plus sympa, c tout !

c super, ce matin dans le bus, g eu une sorte d'illumination ! comme ça : "ah bah tient g trouvé un système qui devrait marcher !"
je disais vrai, g sortis la 89, et 15 minutes après (juste au terminus) le programme était terminé !
au menu gestion de la carte depuis une matrice et affichage de celle ci en mode raycasting (pas du tout optimisé ni finalisé ni joli)
une fois le cour idéal entamé, je peux seulement tester le prog, et à part 2-3 ptits oublis, ça marche bien, donc il faut quand même pas loin de 20 minutes pour calculer le rendu ! (il faut + de temps pour calculer un image que pour coder le prog ! )
je me suis alors amuser à enregister une toute petite animation basse résol (pas de 5 pixels sur l'horizontale), et ça rend bien pour un début !

je suis donc parti ! maintenant faut passer à l'asm, puis gerer le gris et les textures !
étape n°2 : me voila !

j'ai pas précisé, g fait ça en basic ! (merci sbibi, donc je précise)