Cette catégorie traite de développements récents destinés à nos vieilles machines, applications, jeux ou démos... Amis programmeurs, c'est ici que vous pourrez enfin devenir célèbres!
adnz a écrit : ↑26 mars 2021 22:12
ho mais c'est génial ça
et ça serait donc possible pour 6809 aussi alors ? (sur les TO)
Merci. Je pense que l'aspect calculatoire du raycasting doit pouvoir facilement s'adapter à un 6809. Mais ça n'en exploitera pas toutes les capacités. Sur 6502 il n'y a pas de multiplication câblée .. donc j'ai conçu les algorithmes pour qu'ils se passent de multiplication et si j'avais eu une multiplication câblee j'aurais peut-être procédé autrement.
Par contre l'aspect rendu est vraiment spécifique à l'Oric et dimensionné pour cette machine. Il y aurait un travail d'adaptation à faire à ce niveau là.
__sam__ a écrit : ↑26 mars 2021 22:49
Je pense que c'est aussi ce qui est fait sur Oric.
Je suis passivement (lurker) le fil de discussion correspondant sur le forum dédié Oric depuis le début. Ce sera intéressant de voir ce que cela donnera in fine. Ne précipitons pas les étapes.
Oui tout à fait, le procédé utilise l'entrelacement RGB pour créer les couleurs.
J'ai déjà sorti quelques petites démo interactives et là je prépare un jeu pour qu'on puisse voir ce que ça donne en situation réelle de jeu.
Dans ce jeu il y a une routine clavier dédiée pour remplacer les appels système qui prennent trop de temps. Donc normalement ça devrait créer son petit effet waou.
Je suis un piètre game maker donc le jeu risque de ne pas casser des barres en terme d'intérêt mais par contre je pense qu'en terme de rendu et de performance graphique .. il va vraiment se distinguer de ce qui a été fait jusqu'à présent.
JiBé a écrit : ↑09 janv. 2020 09:58
Bonjour à tous,
J'ai récemment conçu et réalisé une routine de projection 3d en assembleur 6502 qui est capable d'effectuer la projection d'un point 3D sur un écran 2D en moins de 500 cycles processeur (ce qui en fait un outils idéal pour le rendu de scènes 3D en temps-réel).
Le principe consiste à effectuer la projection en utilisant la trigonométrie plutôt que l'algèbre linéaire.
Ainsi, pour un point 3D aux coordonnées [pX, pY, pZ] et une caméra à la position [cX, cY, cZ] tournée d'un angle caZ autour de son axe Z et caX autour de son axe X, les coordonnées écran sont calculées en utilisant les coordonnées angulaires du point relativement à la caméra par l'algorithme suivant:
l'arctangente est calculée par une simple abaque indexée par le résultat d'une division logarithmique entre le numérateur et le dénominateur.
J'ai utilisé l'algorithme trouvé sur codebase64.
la distance horizontale est calculée par une approximation biplanaire le norme euclidienne dont j'explique le principe d'élaboration ici.
Le code source de la routine, des outils pour le calcul des abaques, des fragments de documentation, et des exemples d'utilisation sont disponibles sur le dépôt du projet glOric.
La seule chose que je vous demande, si vous me faites l'honneur d'utiliser cette routine, c'est d'ajouter mon nom dans les crédits de vos programmes:
Jean-Baptiste PERIN
Bonjour
je ne pense pas que cette routine soit vraiment une innovation, c'est simplement des techniques d'épure et tous les matheux savent utiliser ces techniques. (perso je n'envisageais pas d'utiliser autre chose que de la trigo, ça me parait évident)
Il y a déjà des routines existant sur 6502 (sur Atari 800XL, qui, il me semble, utilise les 6502 ?) permettant de faire des labyrinthes 3D hyper rapides ... cette vidéo est vraiment bluffante!!! Je pense que seules les coins des murs sont calculés en direct, puis après, remplissage de couleur.
__sam__ a écrit : ↑26 mars 2021 22:49
Sur les TEO la mémoire vidéo est plus large (16ko vs 8ko), donc la couleur c'est chaud à faire sauf à utiliser l'entrelacement ligne R/ligne G/ligne B comme dans "Oh la belle bleue!". Je pense que c'est aussi ce qui est fait sur Oric.
Je suis passivement (lurker) le fil de discussion correspondant sur le forum dédié Oric depuis le début. Ce sera intéressant de voir ce que cela donnera in fine. Ne précipitons pas les étapes.
Je me demande... A l'instar de la 3D isométrique...
Si on réfléchit bien, un labyrinthe 3D est juste une représentation 2D sont les limites des murs (tracé supérieur du mur) ont subi un décalage horizontal et vertical. Vu qu'un mur est juste un rectangle avec 4 coins... Si on suppose qu'une extrémité de murs en 3D est au dessus du personnage en 2D, le coin supérieur le plus profond on le décale d'un certain nombre de pixel vers le bas, puis vers la droite (profondeur), on fait pareil pour les 4 coins (et on trace les lignes) et on remplit avec un algorithme de remplissage couleur rapide (couleur de la limite gauche à la limite droite du tracé du dessin). C'est le même principe que la 3D isométrique mais en un peu plus complexe. D'ailleurs, il est possible que "Minotaure 3D" sur Thomson utilise cette technique.
Et si sur les TO8 n pouvait faire un truc aussi (ou du moins à au moins 4 imf/s) rapide que pour "minotaure 3D" mais sans ce scintillement (utilisant le double buffer donc) et en remplissant par de la couleur, ça serait top.
JiBé a écrit : ↑09 janv. 2020 09:58
Bonjour à tous,
J'ai récemment conçu et réalisé une routine de projection 3d en assembleur 6502 qui est capable d'effectuer la projection d'un point 3D sur un écran 2D en moins de 500 cycles processeur (ce qui en fait un outils idéal pour le rendu de scènes 3D en temps-réel).
Le principe consiste à effectuer la projection en utilisant la trigonométrie plutôt que l'algèbre linéaire.
Ainsi, pour un point 3D aux coordonnées [pX, pY, pZ] et une caméra à la position [cX, cY, cZ] tournée d'un angle caZ autour de son axe Z et caX autour de son axe X, les coordonnées écran sont calculées en utilisant les coordonnées angulaires du point relativement à la caméra par l'algorithme suivant:
l'arctangente est calculée par une simple abaque indexée par le résultat d'une division logarithmique entre le numérateur et le dénominateur.
J'ai utilisé l'algorithme trouvé sur codebase64.
la distance horizontale est calculée par une approximation biplanaire le norme euclidienne dont j'explique le principe d'élaboration ici.
Le code source de la routine, des outils pour le calcul des abaques, des fragments de documentation, et des exemples d'utilisation sont disponibles sur le dépôt du projet glOric.
La seule chose que je vous demande, si vous me faites l'honneur d'utiliser cette routine, c'est d'ajouter mon nom dans les crédits de vos programmes:
Jean-Baptiste PERIN
Bonjour
Est ce que cet algorithme est vraiment une innovation ? Ca utilise des techniques d'épures et tous les matheux savent utiliser ces techniques.(Enfin la trigo, ça me parait évident pour ce genre d'opération). Après, concernant le raycasting je sais pas si ça a déjà été fait sur processeurs 8 bits.
Il y a déjà des routines existant sur 6502 (sur Atari 800XL, qui, il me semble, utilise les 6502 ?) permettant de faire des labyrinthes 3D hyper rapides ... cette vidéo est vraiment bluffante!!! Je pense que seules les coins des murs sont calculés en direct, puis après, remplissage de couleur.
Les exemples que tu cites Neotenien sont des polygones pleins, sans texture qui n'ont pas besoin de ray-casting (projection de rayons).
L'algo de JB fait des textures. Ca change beaucoup de choses, en premier chef de calculer le trajet d'un rayon pour chaque colonne, et afficher les textures pour cette colonne. Ca fait plein de calculs en nombre flottants. L'algo de JB s'arrange pour faire tout ca rapidement à partir d'entiers.
Dernière modification par __sam__ le 28 avr. 2021 09:16, modifié 1 fois.
Neotenien a écrit : ↑27 avr. 2021 23:50
concernant le raycasting je sais pas si ça a déjà été fait sur processeurs 8 bits.
Oui, et je suis sûr de ne pas être le seul à l'avoir fait. Avec le MO5 c'était un peu long (plusieurs jours), et il fallait éviter les micro-coupures d'EDF. J'avais inventé un petit système d'alimentation de secours avec une diode et trois piles de 4,5V pour lampe de poche.
__sam__ a écrit : ↑28 avr. 2021 01:06
Les exemples que tu cites Neotenien sont des polygones pleins, sans texture qui n'ont pas besoin de ray-casting (projection de rayons).
L'algo de JB fait des textures. Ca change beaucoup de choses, en premier chef de calculer le trajet d'un rayon pour chaque colonne, et afficher les textures pour cette colonne. Ca fait plein de calculs en nombre flottants. L'algo de JB s'arrange pour faire tout ca rapidement à partir d'entiers.
Oui en effet et quand je vois écrit "500 cycles par pixel", ça signifierait qu'à minima, ça prendrait 1 seconde pour 2000 pxl seulement (les Thomson) en 1 Mhz. Je ne sais pas si ça vaut le coup. Mais la petite vidéo que met JB est quand même étonnante. Mais ya aussi les autres élément à intégrer (les objets).
Je me demande si un algo plus simple en temps de calcul (sans passer par les arctan mais simplement un décalage horizontal et verticaux des arêtes des murs, quitte à avoir une longueur fixe de chaque portion de mur en profondeur, n'est pas plus appropriée ? On n'est que sur des machine à 1 à 4 MHz. La vidéo sur l'Atari XL me parait plus approprié en teme de fluidité...
Cependant je salue le travail effectué!! Et ça reste quand même bon si on compare aux 3 moteurs de Doom existant sur l'Atari Falcon 030 (38030 à 16 MHz et DSP 56001) qui ne font pas plus rapide!! (1 à 2 image par seconde).
J'ai aussi joué à des jeu comme "Running" (Atari Falcon), "Towers 1.2" (Atari STE/Falcon) "Substation "Atari STE/Falcon") et ces 3 jeux utilisent pourtant des labyrinthes mais sont très rapide comparé au moteur de Doom. (68000 à 8 MHz).
Dans "Towers" il n'y a pas de calcul de labyrinthe à proprement parler, ce sont juste des polygone tracés un peu comme certain jeu Thomson dans des salles (mais pas en fil de fer mais en image pleine, en fait, même dans Towers, j'ai l'impresion qu'il y a des images préexistantes!). J'ai adoré ce jeu!
J'ajoute aussi une vidéo du jeu "Minotaure 3D" de Loriciels sur TO7 et MO5... Le tracé du Labyrinthe, même si en fil de fer, est très rapide et prend quasiment tout l'écran !! En plus on peut pivoter l'angle de vue vers le hat et le bas (ce qui, d'après ce que j'ai lu pour le raycasting, semble impossible). Et dans cette vidéo, je ne vais qu'à au max 1/3 de la vitesse de déplacement maximale possible. C'est du tracé au pixel près! Je me dis que si ça avait été adapté aux TO8 et MO6, il n'y aurait pas l'effet de scintillement (puisque le gate array permet de basculer entre 2 banques de RAM pour l'affichage écran). Je me demande comment ont fait les dev de Lotriciels sur Thomson, mais encore une fois, ils ont vraiment montré leur ingéniosité.
Dernière modification par Neotenien le 28 avr. 2021 14:50, modifié 1 fois.
Neotenien a écrit : ↑27 avr. 2021 23:50
concernant le raycasting je sais pas si ça a déjà été fait sur processeurs 8 bits.
Oui, et je suis sûr de ne pas être le seul à l'avoir fait. Avec le MO5 c'était un peu long (plusieurs jours), et il fallait éviter les micro-coupures d'EDF. J'avais inventé un petit système d'alimentation de secours avec une diode et trois piles de 4,5V pour lampe de poche.
Salut Daniel
Tu parles sans doute du Jeu "Labyrinthe 3D'" sur Thomson édité par DC Soft ? Mais le raycasting c'est pas tout à fait ça. C'est le genre de moteur existant dans Doom et permettant de retracer des murs 3D avec du mapping dessus. Je n'ai pas vu ça sur Thomson...
Je me dis que si ça avait été adapté aux TO8 et MO6, il n'y aurait pas l'effet de scintillement
Sur le vrai MO5, l'image ne clignote pas de manière outrancière comme sur cette vidéo. La routine d'affichage de Minotaure 3D est calée sur l'interruption 50 Hz, donc synchronisée avec le balayage écran. Ca clignote, mais c'est peu perceptible, et surtout, parfaitement régulier, donc pas gênant. On a un peu la sensation d'une Vectrex. Pour gagner en performance, les routines standard fournies par le moniteur ne sont pas utilisées. Par exemple, le clavier est scruté avec une routine réécrite pour ne détecter que les touches utiles.
Je me demande comment ont fait les dev de Lotriciels sur Thomson, mais encore une fois, ils ont vraiment montré leur ingéniosité.
Mais il n' y a eu qu'un seul développeur, sur son coin de table de cuisine. Tu auras peut-être envie de lui demander comment il a fait ?
Daniel a écrit : ↑28 avr. 2021 21:51
Avec le MO5 c'était nettement moins détaillé, mais encore plus long, jusqu'à quatre ou cinq jours
MDR faire du Raytracing sous MO5 c'est comme essayer de faire un grand prix de F1 avec une bicyclette LOL
Moi j'avais un Atari Falcon 030 avec POV, et même avec le copro arithmétique (6882 à 32 MHz), c'était hyper lent de tracer certains script livré (en 160x200), et, comparé à des PC 486 à 32 MHz ou même certain 386 (même famille de processeur que le 68030), c'était juesqu'à 10 fois plus lent... Pourquoi ? A cause des accès mémoire beaucoup plus lent avec la ST Ram (alors qu'avec la TT Ram des TT c'était raisonnable).
Mains maintenant il y a le FireBee, basé sur un Coldfire 5407 à 266 MHz, qui est vraiment très très rapide (100 fois plus rapide qu'un Atari Falcon en gros et 400 fois un Atari ST)