I had a dream .. glOric

Bonjour à tous,

J'ai un rêve .. faire un truc dans ce style là (rendu 3d en mode text) sur un Oric:



Je ne sais pas si c'est un rêve (qui peut donc se réaliser) ou s'il s'agit d'un pur fantasme (qui ne se réalise pas) ..

Est-ce que ça existe déjà ?

Est-ce que vous pensez que c'est possible ?

Quels seraient les conseils, les recommandations et/ou mise en garde que vous adresseriez à quelqu'un qui voudrait faire un moteur de rendu 3D pour Oric ?

Qu'est-ce que vous attendez pour me filer un coup de main ?    

A l'époque j avais fait ca sur Oric pour la 300e du Mag, mais bon, j'ai un peu triché sur la vitesse de la vidéo...

http://www.petit-fichier.fr/2015/03/18/ceo300e/ceo300e.gif

WAOU !!! je suis sur le cul !!

C'est carrément génial !! Tu avais fait ça en quel language ?

Etais-ce du précalculé par une autre machine puis rendu sur l'Oric ou étais-ce intégralement calculé sur l'Oric ?

Combien de temps de calcul fallait-il pour faire cet anim?

Pourquoi sur l'image animé on voit des valeurs entre 43 et 52 FPS ?

Utilisais-tu des floattant ou des entiers ?

Le résultat est vraiment sympa .. est-ce que y'a moyen de voir tourner cette merveille ?

C'est du Basic, un programme que j'avais fait il y a longtemps avec un Oric reel, par contre, le fichier de donnees spatiales a ete rempli avec un emulateur Oric et la demo executee avec aussi, ce qui explique les nombres au bas, ensuite j'ai sauvegardé les images en GIF pour les concaténer dans un fichier GIF animé, sinon, en mode réel avec les calculs faits par l'Oric ça aurait été beaucoup plus long (il faut 1 seconde pour dessiner 6 segments). Je pense que la vraie vitesse serait presque réalisable avec un Oric réel si le programme Basic avait été traduit en assembleur.

Tout dépend du degré de triche que l'on s'autorise.
En gros il y a deux trucs:
- Le calcul 3D
- L'affichage
Faire les deux en temps réel sur l'Oric, c'est très très chaud, mais avec de la triche on peut faire "comme ci".

Il y a un exemple dans la démo Quintessential:
https://youtu.be/4Miw2ImYBaU?t=179

En gros c'est juste un moteur de rendu de lignes avec des motifs et il n'y a aucun calcul 3D, en gros ca déforme des triangles et quadrangles.

C'est cumulable avec une méthode de chargement depuis la disquette ou on peut par exemple définir des listes de triangles et quadrangles a rajouter a une liste, ainsi que le mouvement/vitesse de chacun des points.

Une variante est de travailler au niveau des segments de ligne, et décrire l'image sous forme de de segments avec un début et une couleur, la fin/longueur étant implicitement définie par le segment suivant, la ruse étant de réussir a encoder le "delta" entre l'image courante et la suivante et de conserver le tout bien trié, ce qui permet de ne modifier que ce qui a vraiment changé.

Salut Dbug,

Avant tout, je veux dire que suis super content de te rencontrer sur ce forum.
Je m'intéressse à la programmation ORIC depuis une quinzaine de jour seulement et je ne compte déjà plus le nombre de fois où j'ai vu ta signature.
J'étais enore hier soir en train de regarder des sources qui portaient ton nom :-)
Donc super content que tu te penches sur ce sujet ..

Dbug a écrit:Tout dépend du degré de triche que l'on s'autorise.
En gros il y a deux trucs:
- Le calcul 3D
- L'affichage
Faire les deux en temps réel sur l'Oric, c'est très très chaud, mais avec de la triche on peut faire "comme ci".

C'est bien ce qui me semblait quand j'ai vu les temps de tracé de lignes en mode hires.
Et c'est pour ça que j'en suis venu à me pencher sur le mode text.

Serait-il possible, selon toi, de:
- faire un pré-calcul d'animation 3D en ascii art en temps "raisonnable" plutôt que réel .. (pour précalculer les deltas entre frames)
- et ensuite un rendu en temps réel qui ne fait que parcourir les deltas frame après frame.

Mon idée c'est qu'en s'en tenant à du mode texte, avec des calculs 3D portant sur des entiers plutôt que des flottants, il doit être possible de faire de la 3D "rapide" sur Oric.
Bien sur je parle de calcul 3D ulra simplifiés à base de routines assembleur hyper optimisées tirant profit à fond du fait qu'en mode texte on n'a que 40*39 cases écran à gérer plutôt que 240*200 pixels.

C'est un boulot énorme et je ne sais pas si ça a une chance d'aboutir à des résultats probants .. alors ton avis me serait très précieux.

Dbug a écrit:
Il y a un exemple dans la démo Quintessential:
https://youtu.be/4Miw2ImYBaU?t=179

En gros c'est juste un moteur de rendu de lignes avec des motifs et il n'y a aucun calcul 3D, en gros ca déforme des triangles et quadrangles.

Voilà ben moi mon ambition c'est de faire, aux heureux propriétaires d'Oric, le même effet que ce genre de démo me fait.
Je veux décrocher la machoire des Oriciens par la stupéfaction et l'admiration.
Il faut qu'en voyant glOric tourner, ils se disent : "Waou putain .. ce glOric m'a vraiment mis sur le cul .. et a mis le feu à ma machine :-O. Je ne l'ai jamais vu si chaude et humide "

Dbug a écrit:
C'est cumulable avec une méthode de chargement depuis la disquette ou on peut par exemple définir des listes de triangles et quadrangles a rajouter a une liste, ainsi que le mouvement/vitesse de chacun des points.

Yes !! niark niark

Dbug a écrit:
Une variante est de travailler au niveau des segments de ligne, et décrire l'image sous forme de de segments avec un début et une couleur, la fin/longueur étant implicitement définie par le segment suivant ...

Oui  .. je ne sais pas si ça correspond à cela mais j'envisage de travailler avec des faces triangulaires ..
et je réfléchissais à un dérivé de l'algo de Bresenham pour faire une routine de remplissage de triangle

jbperin a écrit:
Je veux décrocher la machoire des Oriciens par la stupéfaction et l'admiration.

Finalement, après voir découvert certaines choses qui ont été faite avec l'Oric, je crois que je dois abandonner cet objectif ..
Je n'imaginais pas à quel point l'ingéniosité, l'inventivité et la compétences des Oriciens avaient poussé aussi loin les limites de leur machine.

J'ai l'impression que tout a déjà été fait .. et bien fait en plus ..

jbperin a écrit:
Finalement, après voir découvert certaines choses qui ont été faite avec l'Oric, je  crois que je dois abandonner cet objectif ..
Je n'imaginais pas à quel point l'ingéniosité, l'inventivité et la compétences des Oriciens avaient poussé aussi loin les limites de leur machine.

J'ai l'impression que tout a déjà été fait .. et bien fait en plus ..

Meuh non, faut pas se décourager comme ca, il y a encore des trucs qui n'on été explorés que brièvement et vaudrait le coup d'expérimenter un peu plus:
- Paysage en voxel, style Mars
- Moteur raycast, style Wolfenstein 3D, Midi-Maze
- Jeux avec scrolling qui ne pique pas les yeux, style Mario/Shadow of the Beast, etc... possiblement en AIC pour avoir de la couleur

Et un éditeur 3d "fil de fer" tout en LM, je ne crois pas que ça a déjà a été fait...

Un autre truc a considérer, c'est que une grosse majorité des trucs impressionnants sur l'Oric, c'est le résultat d'années de boulot, parfois a plusieurs personnes.

Rien qu'un exemple a la noix, mais la routine de tracé de ligne rapide utilisée dans plusieurs productions Defence Force a été modifiée par beaucoup de monde sur pas mal de temps: http://forum.defence-force.org/viewtopic.php?f=4&t=386

Pareil pour mes routines de triangles, la première version date de 1997.

De facon générale, je troue qu'il est plus facile de partir d'une idée simple, voir comment ca peut s’améliorer, modifier, etc... et seulement après voir si ca peut avoir une utilisation dans un jeu, une démo, etc... ca à l'avantage de permettre de bosser sur l'idée sans aucune contrainte technique: On peut utiliser toute la mémoire, tout le temps CPU, etc... c'est juste un exercice intellectuel.

Partir sur "moteur 3D", ca implique plein de trucs, c'est pas facile, et si le moindre truc est impossible ca remet tout en cause.

Alors que si tu pars sur plein de petits trucs indépendants, tu peux tomber sur un truc qui vaut le coup de poursuivre.

Par exemple je citais le voxel, mais pour donner une illusion de moteur 3D il y a aussi des variantes style Rescue on Fractulus (jeu Atari 800XL), il y a des jeux dans l'espace ou tout ce que tu vois c'est le star field, mais il y a aussi des variantes avec des nuages de points,

Je suis sur que ce genre de truc est faisable sur Oric:

C'est la voix de la sagesse qui parle à travers toi DBug ..

Tu as raison de dire qu'il faut faire de petites choses et les assembler plutôt que de chercher tout de suite à faire un truc trop gros.

Je réalise, au fur et à mesure que je découvre l'univers Oric, qu'il y a énormément de choses qui ont déjà été faite et ce serait dommage de prendre du temps à refaire des choses qui ont déjà été faite par d'autres .. et surtout bien mieux fait par d'autres.

D'ailleurs, à ce propos, si tu as des routines  de tracé de ligne ou de remplissage de triangle en libre accès, ça m'intéresse de les consulter .. je ne les ai pas encore trouvée.

Pour ma part, je commence à peine à avoir un environnement de développement potable qui va me permettre de mixer BASIC, C, et ASM grâce à OSDK.
J'ai documenté ma prise de connaissance sur le sujet ici
Et j'ai posé la structure d'un petit programme qui va me servir de base aux expérimentations sur les routines en assembleur. c'est dans mon répertoire de travail glOric

J'ai aussi un prototype en python de ce que je veux faire, pour valider le matériel algorithmique.
Une des plus gros  boulot va être de porter cette fonction (qui fonctionne avec des flottants) en assembleur 6502.
C'est la fonction qui fournit les coordonnées écran (L, C) d'un point à partir de ses coordonnées 3D(X,Y,Z) et il va falloir la réaliser en assembleur en utilisant des calculs sur des entiers.

J'ai commencé à dresser une liste des routines qu'il va me falloir assembler:
- soustraction et division 8 et 16 bits,
- racines carré et élévation au carré,
- arctangente

et à chercher sur le web les ressources qui peuvent m'aider:
https://github.com/jbperin/hello-world/blob/master/retro/algos.md

Voilà, je vais me focaliser sur cette fonction (L,C) = project3Dto2D (X, Y, Z).
Je vais en faire une première version en BASIC avec des calculs flottant. J'utiliserai cette version pour faire un tout petit programme de test. Et ensuite je vais chercher à la réaliser avec des entiers et enfin j'essaierai de la porter en assembleur.

J'ai bon espoir que ce soit fini dans une petite vingtaine d'année :-)

Et là, en fonction des résultats, ce sera éventuellement le point de départ d'une autre brique ...

L'idée du voxel est sans doute la première application qui pourra être faite de cette fonction. Je n'avais pas pensé à ce genre d'effet .. et c'est vrai que c'est joli.

D'ailleurs, à ce propos, si tu as des routines  de tracé de ligne ou de remplissage de triangle en libre accès, ça m'intéresse de les consulter .. je ne les ai pas encore trouvée.

Tout ca est sur le dépot SVN de Defence-Force:
http://miniserve.defence-force.org/svn/public/oric/routines/rasterization/

Et j'ai posé la structure d'un petit programme qui va me servir de base aux expérimentations sur les routines en assembleur. c'est dans mon répertoire de travail glOric

Code:

// Camera Position
_CamPosX: .word $0000
_CamPosY: .word $0000
_CamPosZ: .word $0000

 // Camera Orientation
_CamRotZ: .byt 0 // -128 -> -127 unit : 2PI/(2^8 - 1)
_CamRotX: .byt 0


Plutot que de mettre des .word/.byt 0, je te conseille de mettre des .dsw/.dsb 1, l'avantage c'est que si tu met dans a la fin de ton programme, ca ne prend pas de place dans l'exécutable, ca évite de perdre de la place sur disque ou cassette.

En bonus, pour les variables de travail importantes, tu peux mettre ca dans une section .zero, pour le coup les accès mémoire prennent 1 cycle de moins.

Dbug a écrit:
Tout ca est sur le dépot SVN de Defence-Force:
http://miniserve.defence-force.org/svn/public/oric/routines/rasterization/

WAOU !!! génial !! merci bien :-)

Je ne vais pas l'utiliser tout de suite parce que j'ai une arctan et une racine carrée à dézinguer avant ..
Mais je mesure le caractère précieux de ces ressources  .. vraiment merci
Quand j'aurais des coordonnées en 2D ..  ça risque de m'être fort pratique.

Dbug a écrit:
Plutot que de mettre des .word/.byt 0, je te conseille de mettre des .dsw/.dsb 1, l'avantage c'est que si tu met dans a la fin de ton programme, ca ne prend pas de place dans l'exécutable, ca évite de perdre de la place sur disque ou cassette.

En bonus, pour les variables de travail importantes, tu peux mettre ca dans une section .zero, pour le coup les accès mémoire prennent 1 cycle de moins.

Merci bien pour ces remarques de relecture que je me suis empressé de prendre en compte (sauf le .zero que j'ai pas encore fait).
Si tu as d'autres remarques .. saches qu'elles sont hyper bienvenues et volontiers attendues.
Aujourd'hui j'ai presque fini de porter la première ligne  de ma fonction project3Dto2D du python vers l'assembleur.
(et je réalise que j'ai oublié de gérer le cas de la division par 0 ).
Prochaine étape l'arctangente ...

Si ton but est de faire un moteur 3D, n'hésite pas à regarder dans le code de 1337 (Elite sur Oric) par Chema:
http://miniserve.defence-force.org/svn/users/chema/1337/

Son code est originellement adapté de la série de 3D sur C64 de Stephen Judd qui avait été publiée dans C= Hacking.

Le secret des gros projets c'est aussi qu'ils se basent sur des trucs existants: Plutot que de réinventer la roue, on préfère partir d'une roue qui fonctionne "pas trop mal", et après voir si on peut amméliorer, et on remet ca en circulation pour que d'autres puisse construire leurs propres roues, encore meilleures que les notres.

Quelques liens utiles pour la 3D en 6502:
- http://www.ffd2.com/fridge/lib3d/index.html
- http://www.ffd2.com/fridge/chacking/

et plus récement, sur Apple II, la démo 3D de Marc-Andre Golombeck, avec les sources disponibles
- http://www.golombeck.eu/index.php?id=35&L=1

Dbug a écrit:Si ton but est de faire un moteur 3D, n'hésite pas à regarder dans le code de 1337 (Elite sur Oric) par Chema:
http://miniserve.defence-force.org/svn/users/chema/1337/

RAH Punaise .. quelle tuerie !! J'en reviens pas. C'est vraiment super impressionnant.

J'ai un peu parcouru la lib3d utilisée  .. ça a vraiment l'air d'être une merveille .. à mon avis c'est l'état de l'art de la 3d sur 8 bits.
Y'a tout ce qu'il faut .. les matrices de rotation et de projection  ainsi que les routines qui les manipulent.

Je viens aussi d'essayer ce jeu et malheureusement je suis trop nul pour pouvoir en profiter .. mais le peu que j'ai pu voir, c'est vraiment fluide pour selon qu'il y a des calculs de fou derrière.

Fait gaffe, le gars il postait régulièrement sur Facebook avec les mises a jour de ses démos, et y'a pas mal d'optim qui sont issues de remarques par les gens qui commentaient, le code était pas si super efficace que ca à l'origine.

On a pas validé tout le code, donc il est possible que des trucs soient optimizables, et de toute facon l'Oric et l'Apple peuvent bénéficier d'optims différentes pour l'affichage.

Hey !!!  tu m'avais caché cette petite merveille:

http://forum.defence-force.org/viewtopic.php?p=16985#p16985

:-) C'est exactement dans l'esprit de ce que je voudrais (ou voulais) faire !! (à l'exception de l'utilisation du mode HiRes)

Dans ce post sur Défense Force, on te voit regretter le manque de célérité du résultat. Manque de célérité que tu associes à la gestion de l'effet fishball.

DBug a écrit:It did not go very far because I did not manage to find a satisfactory way to avoid the fish eye effect, as well as how to get some decent looking walls with shading effect that don't cost too much cpu time.

Pourtant cette gestion qu'on retrouve à la ligne 264 de main.c:

Code:

d_step=((unsigned int)CosTable[(256+i-20)&255])<<1; // Fishball nearly gone


semble plutôt économique.
Tout comme le reste du soft d'ailleurs qui a l'air d'être assez bien optimisé (avec des tables de multiplication et de cos).
C'est vraiment du beau boulot et y'a beaucoup de choses à apprendre de ce code (en tout cas pour moi).

La question qui me vient en essayant cette pépite, c'est :

Qu'est-ce que ça donnerait si, au début du main, à la place de :

Code:


hires();
 ink(3);


il y avait eu:

Code:


text();


Et que le reste du code soit adapté à cette contrainte.

Quelle proportion de la lenteur que tu déplores, provient de l'affichage et quelle proportion vient des calculs ?
En ce qui me concerne, je trouve que les calculs sont assez optimisés et j'ai tendance à penser que c'est l'affichage qui pompe trop de cycle. Mais ce n'est qu'une intuition.

Je me propose donc d'explorer la piste consistant à sacrifier la haute résolution (et le rendu de la minimap) sur l'autel de la fluidité.

En espérant que ça ne dégrade pas trop non plus l'esthétique .....

De facon générale faire les trucs en mode text plutot que hires... donne une vitesse 8x plus rapide

En fait limite ca permettrait d'optimiser certain trucs, style faire des jolies pentes en haut et en bas en générant les bons caractères tout en haut et tout en bas de chaque ligne.

Libre a toi de faire joujou avec le code: Comme je le dit souvent, au final c'est plus efficace pour la communauté d'aider les autres plutot que de tout faire soit même. Si tu arrives a nous pondre un truc sympa en 3D temps réel, niquel !

J'ai pas souvenir d'avoir eu de vrais problèmes de lenteur, c'était vraiment plutôt la correction des aberrations visuelles (déformation courbée) qui m'a pris la tete, mais bon j'ai juste passé quelques jours sur le programme.

Depuis il y a eu des portages de moteurs du meme style sur ZX81 et C64, donc on doit probablement trouver de bon tutoriels expliquant tout, voir meme du code example utilisable sur machines 8 bits.

Bon, alors moi en fait c'est pas du tout le côté 3D qui me passionne, mais la bande son de la vidéo, j'ai adoré !!!

Et l'avantage là en plus, c'est que c'est largement faisable sur Oric (ou du moins sur 2 Oric), car il y a une adaptation du thème ("Unreal Super Hero 3" by Kenet & Rez) sur Vortex Tracker II (en simulant un système à base de 2 PSG AY-3):
https://www.youtube.com/watch?v=x_36Rixs9eo

A comparer avec la version "originale", on voit (ou plutôt on entend) que nos petits AY de chez GI s'en sortent finalement assez bien:
https://www.youtube.com/watch?v=9STiQ8cCIo0

kenneth a écrit:Je pense que la vraie vitesse serait presque réalisable avec un Oric réel si le programme Basic avait été traduit en assembleur.

Je pense être sur le point de pouvoir vérifier cette hypothèse.

Une question, entre deux frames il faut que les segments dessinés sur la frame précédente disparaissent .
Est-ce un clear screen qui nettoie tout ou est-ce qu'il faut repasser sur les lignes de la frame précédente avec la couleur de fond pour les supprimer?

Le clear screen ca serait violent.
A mon avis un truc qui irait bien ca serait d'avoir deux routines de tracé de ligne: Une qui fait les trucs proprement, avec masquage des pixels, etc... et une autre qui se contente de remplacer un octet complet sans faire de masquage.

L'idée c'est de ne faire les calculs de tracé qu'une seule fois (largeur, hauteur, calcule de pente, etc...) les utiliser lors du tracé, mais aussi en faire une copie dans un tableau pour faire l'effacement rapide.

Un truc que je fais souvent dans mes démos 3D c'est de faire du double buffer en alternant entre les lignes paires et impaires, et en utilisant les attributs a gauche pour afficher ou cacher une image pendant que je bosse sur la suivante (ca aide aussi a afficher 50% de moins a l'écran)

En mode Hires, je pense qu un effacement d'écran sera trop long, par contre, on peut mémoriser l adresse du segment traité la premiere fois pour l effacer ensuite. Par exemple, si je dessine un point sur l'écran, je verifie si le segment memoire hires n a pas encore ete utilisé, si c est le cas, je mémorise son adresse sur 2 octets dans une zone mémoire et j incrémente le pointeur de 2. Si je tombe sur un segment deja utilisé, je ne sauvegarde pas ses coordonnees, vu que ca a deja ete fait. Pour effacer l' ecran a la fin, je place les deux premieres valeurs de la zone memoire dans la page zero puis j utilise un STA(xx) pour effacer le segment. Je place les 2 valeurs suivantes dans la page zero et ainsi de suite pour tout effacer jusqu au valeurs designés par le pointeur adresse. Pour effacer du "fil de fer" ca ne devrait pas ete trop long et la zone memoire de devra pas exceder 4k ce qui fait 2k de segments sauvegardes, un quart de segments utilises dans la hires.

bon les gars je ne résiste pas à l'envie de vous montrer ce que ça donne.

Normalement, je ne devrais pas publier un truc aussi buggé et baclé  sur ce fil de discussion. Et d'ailleurs je supprimera ce message dans quelques temps.

Mais grâce à la routine line8 de DBug, j'ai pu passer à la phase de test du mode hires sans trop de problème et ça donne des sensations que je veux partager avec vous.

Je préfère vous prévenir tout de suite :
- c'est buggé .. j'ai pas serré tous les boulons.
- c'est lent .. car je fais un hires entre chaque frame.

mais ça permet quand même de se faire une idée des performances de l'algo de projection.

60 points (32 000 cycles pour une projection complète => j'ai pas encore enlevé les projections qui sont hors du champ de vision :-)

On tient quelque chose là !!

la 3d prend forme
Le plus dur c'est de gerer les débordements de valeurs de calcul pour l'écran, la distance nulle entre l'observateur et l'objet(division par zero) ou négative..autant de filtres a rajouter qui vont rendre l'animation plus "pâteuse"

Doom sur Oric ! Ce n'est plus qu'une question de temps !

Tyrann 4 en 3D fil de fer avec labyrinthe en temps réel ! A portée de main !

Superbe travail jbperin