routine 3D ultra-performante pour 6502

Cette catégorie traite de développements récents pour nos vieilles machines, applications, jeux ou démos... Amis programmeurs, c'est ici que vous pourrez enfin devenir célèbres!

Modérateurs : Papy.G, fneck, Carl

JiBé
Messages : 13
Inscription : 30 déc. 2019 22:43

Re: routine 3D ultra-performante pour 6502

Message par JiBé »

adnz a écrit : 26 mars 2021 22:12 ho mais c'est génial ça :shock:
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.
gotcha
Messages : 2759
Inscription : 30 mars 2017 11:39
Localisation : Isère
Contact :

Re: routine 3D ultra-performante pour 6502

Message par gotcha »

JiBé a écrit : 26 mars 2021 21:24 Image
Ça a un petit air de Wofsteinstein 3D tout ça ! A quand un portage sur Oric ? ;)
Amstrad CPC et Goupil power :mrgreen:
Bénévole à l'association pour un conservatoire de l’informatique et de la télématique (https://www.aconit.org)
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: routine 3D ultra-performante pour 6502

Message par Neotenien »

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:

Code : Tout sélectionner

AngleHorizontal =  atan2((pY-cY),(pX-cY)) - caZ
DistanceHorizontale = sqrt ((pY-cY)**2+(pX-cX)**2)
AngleVertical = atan2((pY-cY),DistanceHorizontale ) - caX
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 routine est disponible en deux versions :
  • - une pour xa65 à destination de l'Oric
  • - une pour ca65 pouvant adresser plusieurs plateformes.
Alors n'hésitez pas à l'utiliser dans vos réalisations en suivant ce rapide guide d'utilisation.

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.
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: routine 3D ultra-performante pour 6502

Message par Neotenien »

gotcha a écrit : 28 mars 2021 09:38
JiBé a écrit : 26 mars 2021 21:24 Image
Ça a un petit air de Wofsteinstein 3D tout ça ! A quand un portage sur Oric ? ;)
WOW très impressionnant! :o
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: routine 3D ultra-performante pour 6502

Message par Neotenien »

__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.
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: routine 3D ultra-performante pour 6502

Message par Neotenien »

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:

Code : Tout sélectionner

AngleHorizontal =  atan2((pY-cY),(pX-cY)) - caZ
DistanceHorizontale = sqrt ((pY-cY)**2+(pX-cX)**2)
AngleVertical = atan2((pY-cY),DistanceHorizontale ) - caX
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 routine est disponible en deux versions :
  • - une pour xa65 à destination de l'Oric
  • - une pour ca65 pouvant adresser plusieurs plateformes.
Alors n'hésitez pas à l'utiliser dans vos réalisations en suivant ce rapide guide d'utilisation.

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.
__sam__
Messages : 7923
Inscription : 18 sept. 2010 12:08
Localisation : Brest et parfois les Flandres

Re: routine 3D ultra-performante pour 6502

Message par __sam__ »

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.
Samuel.
A500 Vampire V2+ ^8^, A1200 (030@50mhz/fpu/64mb/cf 8go),
A500 GVP530(MMU/FPU) h.s., R-Pi, TO9, TO8D, TO8.Démos
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: routine 3D ultra-performante pour 6502

Message par Daniel »

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.
Daniel
L'obstacle augmente mon ardeur.
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: routine 3D ultra-performante pour 6502

Message par Neotenien »

__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
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: routine 3D ultra-performante pour 6502

Message par Neotenien »

Daniel a écrit : 28 avr. 2021 09:08
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...
Fool-DupleX
Messages : 2284
Inscription : 06 avr. 2009 12:07

Re: routine 3D ultra-performante pour 6502

Message par Fool-DupleX »

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 ?

C'est par ici --> https://www.linkedin.com/in/dguillonnet

Ce qui devrait te faire plaisir, c'est qu'il a beaucoup utilisé l'instruction MUL.

Ce qui va moins te faire plaisir, c'est qu'il a aussi beaucoup utilisé ceci :

Code : Tout sélectionner

32D1 8E0000     LDX    #$0000             
32D4 108E0000   LDY    #$0000             
32D8 CC0000     LDD    #$0000             
32DB 10CE0000   LDS    #$0000             
32DF CE1A3F     LDU    #$1A3F             
32E2 3676       PSHU   S,Y,X,B,A          
32E4 3676       PSHU   S,Y,X,B,A          
32E6 3676       PSHU   S,Y,X,B,A          
32E8 3676       PSHU   S,Y,X,B,A          
32EA 3358       LEAU   -$08,U             
32EC 3676       PSHU   S,Y,X,B,A          
32EE 3676       PSHU   S,Y,X,B,A          
32F0 3676       PSHU   S,Y,X,B,A          
32F2 3676       PSHU   S,Y,X,B,A          
32F4 3358       LEAU   -$08,U             
32F6 0A2E       DEC    <$2E               
32F8 26E8       BNE    $32E2      
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: routine 3D ultra-performante pour 6502

Message par Daniel »

Neotenien a écrit : 28 avr. 2021 15:19 Tu parles sans doute du Jeu "Labyrinthe 3D'" sur Thomson édité par DC Soft ?
Non, ce que je faisais était toute autre chose. Par exemple :

Recursive_raytrace_of_a_sphere.png
Recursive_raytrace_of_a_sphere.png (494.92 Kio) Consulté 3437 fois
Daniel
L'obstacle augmente mon ardeur.
Zebulon
Messages : 2788
Inscription : 02 nov. 2020 14:03

Re: routine 3D ultra-performante pour 6502

Message par Zebulon »

Joli. Ca me rappelle mes débuts avec POV-ray http://www.povray.org/. Les images obtenues étaient superbes mais que c'était looong...
Daniel
Messages : 17316
Inscription : 01 mai 2007 18:30
Localisation : Vaucluse
Contact :

Re: routine 3D ultra-performante pour 6502

Message par Daniel »

Avec le MO5 c'était nettement moins détaillé, mais encore plus long, jusqu'à quatre ou cinq jours :wink:
Daniel
L'obstacle augmente mon ardeur.
Neotenien
Messages : 354
Inscription : 23 oct. 2020 19:15
Localisation : Le Mans
Contact :

Re: routine 3D ultra-performante pour 6502

Message par Neotenien »

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 :wink:
MDR faire du Raytracing sous MO5 c'est comme essayer de faire un grand prix de F1 avec une bicyclette LOL :D

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)
Répondre