Accueil Ti-Gen Foire Aux Questions Chat sur le chan #tigcc sur IRC
Liste des membres Rechercher Aide
Bienvenue Invité !   Se connecter             Mes sujets   
Administrer
0 membre(s) et 1 visiteur(s) actif(s) durant les 5 dernières minutes Utilisateurs actifs : Aucun membre + 1 visiteur
Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.
  :: Index » Forum Ti68K » Programmation C » Affichage d'objets 2D dans un raycaster (39 réponse(s))
./POST DE DEPART (post n°0)   Marquer comme non lu.
Wahb Ecrit le: Samedi 24 juillet 2004 à 16:32 Déconnecté(e)    Voir le profil de Wahb Envoyer un email à Wahb Envoyer un message privé à Wahb  

Salut à tous !!

Je dev depuis qqes semaines un raycaster (mais par pour ti dsl :D) et ça marche très bien pour le moment. C'est un moteur "traditionnel" càd avec la méthode des intersections horizontales et verticales !!

Or depuis qqes jours je me casse la tête sur l'affichage eds objets 2D !
Vu que pas mal de programmeurs touchent pas mal niveau 3D ici j'aurais bien aimé avoir leur avis sur une éventuelle méthode à adopter pour l'affichage de ces objets (je préfère par scaling car la routine sera presque la même que pour les slices du mur #gni#)

Voila merci d'avance :)

Qqes screenshots pour finir:

http://leneuronez.free.fr/shot_mx3d_01.bmp

http://leneuronez.free.fr/shot_mx3d_02.bmp

(oui les textures viennent des gfx du fat-engine ^^ mais c'est pour tester vous en faites pas elles vont disparaitre :))

ps: ne m'insultez pas, car ce projet est pour ... graph100 #gni#
Programmeur C
^^ Adepte du hardware PC ^^
    
./Post n°1   Marquer comme non lu.
Sasume Ecrit le: Samedi 24 juillet 2004 à 17:41 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

Intéressant, je ne pensais pas que la graph100 était suffisamment puissante pour permettre de faire du raycasting.

Pour ton pb, je n'ai pas très bien compris ce qui te chagrine : tu ne sais pas comment afficher les persos ou bien tu ne sais pas comment déterminer où à l'écran tu dois les afficher ?
    
./Post n°2   Marquer comme non lu.
Wahb Ecrit le: Samedi 24 juillet 2004 à 19:10 Déconnecté(e)    Voir le profil de Wahb Envoyer un email à Wahb Envoyer un message privé à Wahb  

c'est un peu des deux :)

càd que pour le moment je trouve les persos tout comme les murs, leur affichage marche coup-ci coup-ça, donc je dirais plutôt que c'est où à l'écran que je dois les afficher je pense :)
Programmeur C
^^ Adepte du hardware PC ^^
    
./Post n°3   Marquer comme non lu.
Sasume Ecrit le: Samedi 24 juillet 2004 à 20:14 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

Tu stockes les positions des persos dans ta map 2D qui contient les murs ?
Ça n'est pas une bonne idée si c'est le cas.

Pour trouver les positions à l'écran de tes personnages éparpillés dans le monde, il te faut connaître le produit scalaire et le théorème de Thalès.
Voici un petit shéma : http://perso.wanadoo.fr/jackiechan68k/mondeverscam.png
Le but est de trouver les composantes du vecteur p, car ça correspond à la position de l'objet par rapport à la caméra, dans un repère tel que l'axe z' est dans le prolongement du regard.
Pour trouver ces composantes, la formule est simple, il faut que tu connaisses la position de l'objet Objet et de la caméra Caméra par rapport à un repère donné qu'on appellera le repère-monde.
De là, les composantes de p s'obtiennent avec deux produits scalaires :
p.x' = x' . p = x'.x*p.x + x'.z*p.z (où p et x' sont des vecteurs exprimés dans le repère-monde).
p.z' = z' . p = z'.x*p.x + z'.z*p.z
Appelons le repère dont l'origine est la caméra et dont l'axe z est dans la même direction que la où elle regarde le repère-caméra.
Nous avons p.x' et p.z' qui correspondent aux coordonnées de l'objet dans le repère-caméra.

À ce niveau là, tu peux déjà savoir si le personnage est devant ou derrière la caméra, en regardant sa composante sur z' (z du repère caméra), et tu peux donc te permettre de ne plus t'occuper des persos non visibles.
Tu peux également voir si le perso est dans le champ de vision ou non, mais ça peut être compliqué si ton champ de vision est variable (ce qui est rare dans un raycasting cependant).

Une fois que tu as trouvé ces composantes, tu dois les projeter à l'écran pour savoir où positionner ton objet précisément.
http://perso.wanadoo.fr/jackiechan68k/camversecran.png
Attention, dans ce shéma, les axes du repère caméra sont désignés par x et z, contrairement au shéma précédent.
Et nous allons projeter les coordonnées de l'objet (exprimées dans le repère-caméra) dans le repère-écran dont le centre est le milieu de l'écran et l'axe x parallèle à l'axe x du repère caméra.
Le repère-écran a également un axe y, mais nous ne nous en servirons pas ici puisque dans ton raycasting, tu ne te préocupes pas de la hauteur de tes personnages.

Donc pour trouver la position x de l'objet il faut appliquer le théorème de thalès :
o.x / o.x' = o.z / dov (où dov est la distance qui sépare la caméra de l'écran, elle dépend du champ de vision)
o.x' = o.x * dov / o.z

Ensuite, pour les afficher, il faut que tu saches quelle taille ils feront à l'écran. Cette taille dépend évidemment de la distance qui les sépare de l'écran. Le calcul est le même que celui que tu utilises pour déterminer la hauteur des murs que tu affiches (encore Thalès bien entendu).

Le vrai problème est qu'il va falloir que tu saches si le personnage que tu t'apprêtes à afficher est bien visible ou non (il peut être derrière un mur en fait).
Pour cela, je vois une méthode, je ne sais pas trop comment fonctionnent les raycastings des autres : tu affiches d'abord ton niveau, et tu stockes pour chaque colonne affichée la distance à laquelle elle était dans un tableau.
Ensuite, tu projètes tes persos et quand tu obtiens ses coordonnées dans le repère-caméra, tu vérifies qu'il est bien devant le mur qui est affiché en arrière-plan : tu testes simplement si sa composante sur z est inférieure à tab[x] (où tab est le tableau dans lequel tu as stocké pour chaque colonne de l'écran la distance à laquelle était la colonne qui y était affichée et x est la composante sur x dans le repère-écran du perso à afficher).

Un autre problème est qu'il faut trier tes persos pour être sûr d'afficher par-dessus les autres celui qui sera le plus près de la caméra.
Pour résoudre ça, le plus simple est de trier les personnages sur leur composante z du repère écran. Je te conseille un tri par insertion ou un tri shell pour ce genre de trucs parce que ça a des bonnes performances pour les données presques triées, ce qui sera le cas dans ton prog puisque d'une image sur l'autre, les données n'auront pas beaucoup changé (à moins que tes persos se déplacent vraiment super rapidement).

Sinon, une autre méthode est d'utiliser un arbre BSP pour socker tes personnages, mais c'est assez compliqué parce que les personnages sont mobiles, ou alors tu restreint leur champ d'action à certaines zones triées dans un BSP.
    
./Post n°4   Marquer comme non lu.
Benjy Ecrit le: Samedi 24 juillet 2004 à 23:05 Déconnecté(e)    Voir le profil de Benjy Envoyer un email à Benjy Visiter le site WEB de Benjy Envoyer un message privé à Benjy  


je le verrai bien adapte sur TI89 non? il a l'air super ton jeu!!!!
Le langage C y'a pas mieux!!!
    
./Post n°5   Marquer comme non lu.
Wahb Ecrit le: Dimanche 25 juillet 2004 à 15:27 Déconnecté(e)    Voir le profil de Wahb Envoyer un email à Wahb Envoyer un message privé à Wahb  

merci infiniement Sasume #merci#

ça tombe vraiment bien car je procède justement comme tu le préconises, c'est à dire une sorte de structure en array qui contient les informations sur la Slice à afficher :)

en tous cas je vais aller étudier ton explication à la loupe et je reposte au besoin !

Pour info, mon projet est presque entièrement programmé en C (oui le C est presque aussi rapide que l'asm sur g100 car les compilos sont ceux pour les proc 16bits par exemple turbo C, digital mars, Vc++1.5, open watcom, etc..) et les routines principales d'affichage sont codées en assembleur :)

Sinon Benjy, mon moteur ne différe pas grandement du Fat-Engine ... en fait pour le moment il est simplement plus rapide :D il tourne entre 13 et 18fps ^^

mais avec la gestion des objets cela devrait tomber dans les 9-10 !! mais heureusement que le motion blur de l'écran lcd est là, sinon on aurait vraiment l'impression de lag :)

Merci encore, je ne m'attendais pas à ça :D
Programmeur C
^^ Adepte du hardware PC ^^
    
./Post n°6   Marquer comme non lu.
Wahb Ecrit le: Dimanche 25 juillet 2004 à 17:23 Déconnecté(e)    Voir le profil de Wahb Envoyer un email à Wahb Envoyer un message privé à Wahb  

Bon j'ai décortiqué ta méthode.
Donc en gros, il faut que j'ajoute à ma structure de caméra la composante x' [selon ton schéma] afin de pouvoir implémenter le produit scalaire ... ok

Cela dit j'ai toujours une zone d'ombre. Je vais procéder par l'exemple.
Le joueur est aux coordonnées (96;96) [dans un repère (O;i;k)] et les blocs font 64*64.

Supposons que l'objet à afficher, symbolisé par son centre, soit aux coordonnées (125;243) [simple exemple, les axes étant orientés comme dans le 1er schéma avec la caméra pour simplifier les choses dans un premier temps]

Supposons aussi que la caméra soit orientée selon les z croissants, sans aucun angle de rotation pour le moment.

Ainsi en appliquant la formule du produit scalaire, on obtient:

p.x' = x' . p = x'.x*p.x + x'.z*p.z = 1*125 + 0*243 = 125
p.z' = z' . p = z'.x*p.x + z'.z*p.z = 0*125 + 1*243 = 243

jusque là tout est normal car la caméra n'a pas subi de rotation.

Les z allant croissant, 243>96 donc l'objet passe en phase de projection lol:

Ainsi on a:

o.x = | 125 - 96 | = 29
o.z = | 243 - 96 | = 147

[Pour la suite, faut savoir donc que l'écran de la g100 ne fait que 128 de large lol et que j'affiche sur 112 pixels (le hud fait 16 de large)]

(mon dov fait 105 -> dov = (128-16)/2 * 1/tan 30 = 97)

On obtient: o.x' = 29 * 97 / 147 = 19

donc l'objet sera affiché à o.x' + (128/2) = 83

Donc ça marche bien :)

Maintenant la question est que si la caméra a subi une rotation, les coordonnées des vecteurs unitaires x' et z' seront <1 !!

Donc pour rester dans l'usage des entiers, il faut que je multiplie par 256 leurs coordonnées...

Ainsi j'obtiens une formule de la sorte:

p.x' = x' . p = x'.x*p.x + x'.z*p.z = (256 * cos A) *125 + (256 * sin A) *243 = 42316
p.z' = z' . p = z'.x*p.x + z'.z*p.z = (256 * sin A) *125 + (256 * cos A) *243 = 66819

et donc il faut diviser par 256 p.x' et p.z' pour obtenir les coordonnées de l'objet, non ?

[évidemment sin et cos sont en fait des tableaux précalculés je ne suis pas fou sinon je ne multiplierais pas par 256 #gni#)

Ce qui donne au final p.x' = 165 et p.z' = 261.

Et ainsi de suite on effectue le même raisonnement ...

ça a l'air de coller je te remercie infiniement pour ton aide plus que précieuse :D

Si jamais t'as eu le courage de lire jusque là bah si t'as trouvé une éventuelle faille dans le raisonnement fais moi signe :)

@++

Edit:

arf jme suis planté faut pas passer par la valeur absolue lors du calcul de o.x et o.z car sinon l'objet sera toujour affiche dans la partie droite de l'écran ...
-Edité le Dimanche 25 juillet 2004 à 18:26 par Wahb-
Programmeur C
^^ Adepte du hardware PC ^^
    
./Post n°7   Marquer comme non lu.
Sasume Ecrit le: Dimanche 25 juillet 2004 à 18:51 Déconnecté(e)    Voir le profil de Sasume Envoyer un email à Sasume Visiter le site WEB de Sasume Envoyer un message privé à Sasume  

Ce que tu as marqué me paraît correct.
Juste quelques infos : le vecteur x' de la caméra se déduit de z' puisqu'ils sont hortogonaux (fais un shéma sur papier, tu le retrouveras, perso je ne l'ai pas en tête) et exprimés dans un repère-monde orthonormé.
J'avais oublié de préciser que les vecteur x' et z' doivent être des vecteurs unitaires pour les calculs (sinon, tu dois diviser par leur norme, mais c'est supra lourd).

Pour continuer avec des calculs d'entiers, je te suggère d'exprimer tes nombre en les multipliant par 256 (ce que tu as évoqué dans ton post), je te conseille de précalculer les valeurs de cos et de sin pour toute une plage d'angle en couvrant 2PI, et de les stocker dans une table, en les ayant au préalable multipliés par 256 bien sûr (mais tu l'as peut-être déjà fait pour ton raycasting).
    
./Post n°8   Marquer comme non lu.
Wahb Ecrit le: Dimanche 25 juillet 2004 à 19:19 Déconnecté(e)    Voir le profil de Wahb Envoyer un email à Wahb Envoyer un message privé à Wahb  

oui tout a déjà été précalculé en degrés multipliés par k=256 :)

... et je fais pareil pour les vecteurs unitaires càd mul par 256.

Bref là je code l'affichage à proprement parler :)
Programmeur C
^^ Adepte du hardware PC ^^
    
./Post n°9   Marquer comme non lu.
Benjy Ecrit le: Dimanche 25 juillet 2004 à 20:52 Déconnecté(e)    Voir le profil de Benjy Envoyer un email à Benjy Visiter le site WEB de Benjy Envoyer un message privé à Benjy  


pourquoi quelle est la vitesse du fat engine???
Le langage C y'a pas mieux!!!
    
./Post n°10   Marquer comme non lu.
Wahb Ecrit le: Dimanche 25 juillet 2004 à 21:00 Déconnecté(e)    Voir le profil de Wahb Envoyer un email à Wahb Envoyer un message privé à Wahb  

dans le readme c marqué:

>560-660 frames per minute on a HW1 calculator (TI-89/TI-92p)
>700-825 frames per minute on a HW2 calculator (TI-89/TI-92p)

ça fait donc entre 12 et 14fps sur hw2 :)

J'ai pas encore fini le coding des objets donc c'est prématuré de comparer! Ah voui aussi l'affichage est pas le même, il est plus restreint en largeur sur le fat, mais le fat est évidemment bien plus grand en hauteur que le mien :)
Programmeur C
^^ Adepte du hardware PC ^^
    
./Post n°11   Marquer comme non lu.
Kevin Kofler Ecrit le: Lundi 26 juillet 2004 à 01:03 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Wahb :
(oui le C est presque aussi rapide que l'asm sur g100 car les compilos sont ceux pour les proc 16bits par exemple turbo C, digital mars, Vc++1.5, open watcom, etc..)

N'importe quoi. Les compilateurs C pour DOS sont en général antiques, alors l'optimisation... Et puis même avec un compilateur C qui optimise bien, le C n'est pas "presque aussi rapide que l'ASM", surtout sur une calculatrice. GCC optimise très bien, et pourtant on voit la différence sur les TIs. Et demande-toi aussi pourquoi Patrick Davidson a écrit la version G100 de Phoenix Platinum Edition en assembleur x86 et pas en C.
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°12   Marquer comme non lu.
Wahb Ecrit le: Lundi 26 juillet 2004 à 13:14 Déconnecté(e)    Voir le profil de Wahb Envoyer un email à Wahb Envoyer un message privé à Wahb  

et bien détrompe toi ces fameux compilateurs "antiques" se débrouillent très bien en optimisation !
Le sujet avait déjà été soulevé sur le forum, et il se trouve que la différence est quand même assez minime!!

Par contre je ne dis pas qu'il faut tout prog en C, évidemment #gni#
mais que un programme dont l'affichage est codé en assembleur est presque aussi rapide qu'un programme 100% assembleur !

Mais cela dit, si Patrick davidson a écrit la version g100 en asm c'est peut-être parcequ'il maîtrise mieux l'assembleur x86, non ? Mais si le choix de coder Platinum en asm a été motivé par un souci de vitesse je pense qu'il est tout à fait faisable de faire aussi rapide en C, d'ailleurs la preuve c'est Space Invaders ! Le jeu est tout aussi fluide bien que programmé en C (compilé avec TC) et pourtant le code source en C n'est pas des plus beaux à voir lol mais c'était un début !

Cela dit il y a qd même un truc que je ne comprends pas. De temps en temps je lis par ex sur yaronet que le C est très lent sur ti, etc .. pourtant le Fat est presque entièrement codé en C :|

enfin bon encore une fois je peux très bien faire une confusion #gni#
Programmeur C
^^ Adepte du hardware PC ^^
    
./Post n°13   Marquer comme non lu.
Kevin Kofler Ecrit le: Lundi 26 juillet 2004 à 13:34 Déconnecté(e)    Voir le profil de Kevin Kofler Envoyer un email à Kevin Kofler Visiter le site WEB de Kevin Kofler Envoyer un message privé à Kevin Kofler  


Le FAT Engine utilise des quantités massives d'assembleur inline.
Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!
    
./Post n°14   Marquer comme non lu.
Lionel Debroux Ecrit le: Lundi 26 juillet 2004 à 15:59 Déconnecté(e)    Voir le profil de Lionel Debroux Envoyer un email à Lionel Debroux Visiter le site WEB de Lionel Debroux Envoyer un message privé à Lionel Debroux  

> De temps en temps je lis par ex sur yaronet que le C est très lent sur ti, etc
On ne lit pas que des vérités sur un quelconque forum, yAronet en particulier... Si on utilise les algorithmes les plus merdiques possible, -Os et qu'on ne se préoccupe pas d'optimiser quoi que ce soit à la main, c'est clair.

Je suis d'accord avec Kevin: les compilateurs 16 bits sont souvent antiques, et on a fait des découvertes en optimisation depuis... Remarque, il n'y a pas vraiment de questions à se poser sur un x86 (surtout les premières générations): le jeu d'instructions est assez mauvais pour que la seule optimisation qui ait un sens soit l'optimisation vitesse poussée...
Lionel Debroux - membre de TICT.
    
./Post n°15   Marquer comme non lu.
Wahb Ecrit le: Lundi 26 juillet 2004 à 17:38 Déconnecté(e)    Voir le profil de Wahb Envoyer un email à Wahb Envoyer un message privé à Wahb  

tu as peut-ête raison ... d'ailleurs open watcom C génère des exécutables [selon tests de framerate] 30% plus rapide qu'un même jeu compilé avec TurboC :)
-Edité le Lundi 26 juillet 2004 à 17:38 par Wahb-
Programmeur C
^^ Adepte du hardware PC ^^
    
./Post n°16   Marquer comme non lu.
bobti89 Ecrit le: Lundi 26 juillet 2004 à 18:14 Déconnecté(e)    Voir le profil de bobti89 Envoyer un email à bobti89 Visiter le site WEB de bobti89 Envoyer un message privé à bobti89  

Jolis screenshots déjà, bravo.

Si ton jeu aboutit et qu'il est programmé en C, ce ne sera pas très difficile, je pense, de le traduire pour ti68k.

En tout cas, bonne chance!!!
#top#
bob ou bob, vous ne voyez pas la différence. Pourtant il y en a une fondamentale, l'un est écrit à l'endroit, l'autre à l'envers.

Visitez mon site : http://www.bobti89.fr.st
Testez mon forum ici
    
./Post n°17   Marquer comme non lu.
Wahb Ecrit le: Lundi 26 juillet 2004 à 18:22 Déconnecté(e)    Voir le profil de Wahb Envoyer un email à Wahb Envoyer un message privé à Wahb  

lorsque la 1ere beta publique sortira, je mettrai ici un lien vers la démo (ce sont des fichiers EXE à émuler avec WinG100) et les sources si ça vous intéresse :)

edit:

Excellent les objets s'affichent correctement #topcool# j'attaque maintenant correctement le scaling horizontal maintenant ainsi que la réimplémentation du test de visibilité (mis en commentaire pour le debug)

Merci infiniement à toi Sasume, je n'aurais jamais réussi autrement !! :D

-Edité le Lundi 26 juillet 2004 à 18:47 par Wahb-
Programmeur C
^^ Adepte du hardware PC ^^
    
./Post n°18   Marquer comme non lu.
mastermage Ecrit le: Lundi 26 juillet 2004 à 18:47 Déconnecté(e)    Voir le profil de mastermage Envoyer un email à mastermage Envoyer un message privé à mastermage  

Il existe deux compilateurs 16 bits recents qui fonctionnent tres bien avec la graph100: Digital Mars (gratuit, pas libre) et Open Watcom (gratuit, Open Source). Il optimisent tres bien par rapport à Turbo C++ (mais wahb a toi de les utiliser, ya toujours mon pack Digital Mars disponible sur le forum graph100).
    
./Post n°19   Marquer comme non lu.
Wahb Ecrit le: Lundi 26 juillet 2004 à 18:48 Déconnecté(e)    Voir le profil de Wahb Envoyer un email à Wahb Envoyer un message privé à Wahb  

oui je sais mastermage mais j'ai eu la flémite aigüe de modifier mon code pour DM :D
Programmeur C
^^ Adepte du hardware PC ^^
    
  :: Index » Forum Ti68K » Programmation C » Affichage d'objets 2D dans un raycaster (39 réponse(s))
Pages : 1/3     « [1] 2 3 » »|

.Répondre à ce sujet
Les boutons de code
[B]old[I]talic[U]nderline[S]trikethrough[L]ine Flip Hori[Z]ontallyFlip [V]erticallySha[D]ow[G]low[S]poilerCode [G][C]ite
Bullet [L]istList Item [K] Link [H][E]mail[P]icture SmileysHelp
Couleurs :
Saisissez votre message
Activer les smileys
     

Forum de Ti-Gen v3.0 Copyright ©2004 by Geoffrey ANNEHEIM
Webmaster: Kevin KOFLER, Content Admins: list, Server Admins: Tyler CASSIDY and Kevin KOFLER, DNS Admin: squalyl
Page générée en 42.73ms avec 18 requetes