Démo de Rotozoom - Page 2

Ben non... Ca c'est tout juste bon pour un Mario Kart. Je ne connais pas le principe utilisé dans Doom, mais pour un jeu de ce type, on peut faire comme dans Wolfenstein à partir d'un raycasting. Et dans ce cas-là, on peut dessiner le sol en utilisant la même routine de base (mode7) et ajouter les murs aux intersections.

comme Doom, koi^^

ué enfin un sol texturé sur 89, ça va un peu bouffer 70% de la puissance de calcul pour un gain visuel à peu près négligeable...

en même temps Mario Kart sans textures sur le sol...
#jesors#
Nan, mais un Doom je suppose que ça doit être faisable sur TI. Sur Mega Drive ils ont bient fait Duke Nukem 3D, qui bien que over-moche, tourne assez rapidement. Et le proc est un 68000 à 7.5 MHz sauf erreur... donc le faire avec un affichage 2 bits sur un écran bien plus petit... il n'y a pas de raison de ne pas y arriver
Un truc que je ne comprends pas... bien que dans Doom sur SNES ils n'aient pas texturé le sol, on remarquera quand même des différentes couleurs sur le sol (matière toxique, sol illuminé, feu, ...) et selon mes tests, le gain de temps obtenu par la suppression du texturage du sol est minime s'il faut tout de même vérifier pour chaque pixel la valeur correspondante dans la matrice du sol et ainsi choisir la couleur à afficher... n'y aurait-il pas un moyen pour ne pas avoir lire la matrice du sol à chaque pixel? Parce que chez moi c'est ça qui demande le plus de temps...

Le truc c'est que la mégadrive a des cartes dédiées pour les traitement graphiques, et n'est pas obligée de faire des niveaux de couleurs en software. Le gros problème sur TI c'est que le hardware ne suit pas ...

Duke Nukem 3D sur Genesis o_O ?

Nan mais là ils n'utilisent pas le hardware (c'est normal). Au contraire, le hardware freine plutôt car il faut convertir un plan bitmap (virtuel) vers un format utilisant des tiles de 8x8 et c'est extrêmement coûteux en resources. Déjà sur GBA ça demande près de 30% de CPU rien que ça... Au moins sur SNES, Doom utilisait le mode bitmap. Malheureusement celui-ci n'est pas disponible sur Genesis à ma connaissance...
Sur TI le seul truc qui ralentit c'est les niveaux de gris...

Ca doit être tout à fait possible de faire un moteur de raycasting fluide, oui

Oui, j'en avais fait un qui tournait à 15-20 fps en gros, alors que la routine d'affichage des murs (rien n'était précalculé) était encore légèrement optimisable.
Cependant, ce qui m'ennuyait, c'était les erreurs d'imprécisions de calculs, et le fait que des fois on se retrouve avec des nombres qui tendent vers l'infini. C'est pas pratique de gérer tous ces cas particuliers.

Allez, je vais m'y mettre moi aussi. Si ça tourne (10 fps) en C je serai déjà bien content (mais faut pas trop rêver)

Un raycasting ?

Oui, un "raycasting" à la Brünni quoi...

Pourquoi perdre votre temps à re-faire, en moins bien, un pogramme alors qu'il existe déjas(c)