Vers un nouveau StormMesa….
-
salut alain,
Merci a vous tous pour le boulot
.Lorsque je vois le thread sur utilitybase, avec les bugs et probleme trouvés sur warp3D et stormmesa, je me dis que le 68k n’a pas eu de chance et encore maintenant vu que les sources de warp3D 68k ne sont meme pas dispo (bien dommage).
mesa->wazp3D->gallium (ou plus court) sera une bonne alternative pour comparer un rendu soft 3D sur classic et sur AOS4 (merci gunter) avec tinyGL et ptet hard un jour avec gallium et l’opengl d’hyperion.
– Est ce que stormmesa est bien le mesa3D ??? (stormesa est bien mesa3D compilé avec stromC ??).
– Si oui, pourrait il etre amelioré, avec les données se trouvant sur mesa3D.com ???
Juste curiosité, j’ai pas dis de le faire
salut,
Moi, je me disais juste que ptet les bugs sont ptet corriges sur une version de mesa (sur le site mesa3d) legerement au dessus du dernier stormmesa de l’amiga.
sinon il est vrai que…..je n’y connais pas grand chose
mais je suis curieux de voir un jour wazp3D et strommesa corrigé et tourner sur un classic et sur AOS4. Honnétement je pense pas que les bugs
sur l’ancien StormMesa soit des bugs de Mesa à proprement parler : on en a pas vu pour l’instant Ce sont des bug du « wrapper » Mesa ->Warp3D
Par exemple j’avais trouvé que StormMesa pouvait demander les possibilités de Warp3D avec comme paramétre le format d’écran (destfmt) égal à 0 !!!
Apparemment dans l’esprit des anciens concepteurs de StormMesa cela voulait dire « pour tout les formats d’écran possible »
Mais apparement beaucoup des drivers récents de Warp3D eux suivent la documentation de Warp3D où la valeur 0 est pas définie alors ils répondent » on sait pas faire » (cad W3D_NOT_SUPPORTED)
==> Mesa se dit « la carte sait rien faire je passe en rendu software » ===> lent ===> tout le monde dit « StormMesa est lent et fait n’importe quoi »
Pour faire un apparté:
Les anciens Mesa convertissaient ( + ou – ) chaque fonction OpenGL en (un ou des) appels au driver==> le code mesa était très imbriqué de nombreux code d’appels au driver = compliqué
L’idée de Gallium (enfin ce que j’en comprends) c’est on laisse faire Mesa dans son coin: genre Mesa active le brouillard ok on fait rien en hard et on positionne juste le « state » fog=TRUE; il active le texturage on fait rien en hard et on positionne juste le « state » texture=TRUE;
….
On continue
…
Et quand on va vraiment tracer qque chose alors le programme nommé « state-tracker » analyse tout les « state » de Mesa et (uniquement) pour ceux qui ont changés les convertit en fonction/states Gallium
Puis gallium trace
L’intéret évident c’est quand aucun states ne change vraiment entre deux tracés alors le hard 3d ne fait que du tracage
Moi je vais faire plus basique Wazp3D stockait lui aussi tout les states: alors dans mon futur Wrapper Wazp3d->Gallium avant de tracer je vais convertir TOUT les states de Wazp3D en fonction/states Gallium puis gallium tracera
Voili Voilà
Alain
lecteur d’utilitybase a mes temps perdu (je ne comprends pas la programation mais la on voit ce que les gens programment), tout est partis des bugs 3D et de couleurs de P96/voodoo3 puis rebondit sur les bugs et la pauvre vitesse du 3D sur 68k (warp3D)+ un peu de netsurf 68k et SDL.
AU depart warp3D 68k et stormmesa 68k etaient en ligne de mire puis, a ce qu’a dit alain dans ce thread, plus que warp3D 68k qui est tres buggés.
Ensuite alain (merci a lui) est apparu dans la discussion et a de suite mieux cernés les problemes sur ce sujet et des personnes courageuses se sont atteles a l amiase a jour et a la correction des problemes.
Bien sur et comme dit, au depart cest 68k mais rien n’empechent au final de se retrouver sur les autre systemes.
@elwood, si tu proposes de l’aide, et bien il faudrait que ces programmeurs disposent de la version 68k de warp3D afin d’y apporter des corrections mais que diraient Hyperion ???Mathey avaient deja fait quelques fix dans les warp3D librairies (buffer Z qui merde,…) mais ce n’est qu’un patch et cela seraient tellement mieux dans les sources 68k.
Ah si hyperion et un des programmeur de la liste pouvaient toucher a warp3D 68k (et du meme coups corriger warp3D AOS4) ou avoir vraiment les bugs trouvés corrigés par Hyperion.
Finalement l’aide que tu propose seraient d’oir hyperion y participer un petit peu
Du cote stormmesa, bernd a dit hier (hum, j’ai lu hier) avoir recu de H&P l’autorisation de poursuivre le developpement de stormmesa et avoir recu les sources d’origine de H&P.
Les sources de stormmesa seront compilable sur tous compileurs et donc tout ceci pourraient se retrouver sur toutes plateformes et ptet gallium (note: alain essaie de ne faire que le wrapper).
Tout ceci est IMHO et tiré des lectures ici et sur utilitybase. Si des erreurs ou conclusions futurs ont ete dites par moi ici, priere de m’excuser
serait cool: mesa -> wazp3D AOS3 + AOS4 (software).
Salut
Je suis pas sûr de réimplémenter la même chose que dans le stormmesa original : il utilisait une libbbase par task et obtenait ainsi le context courant de Mesa genre LibBase->CurrentContex;
Bon tu trouve rien sur les sites UK (mais sur utilitybase) c’est normal on est juste trois-quatre types à avoir constaté que StormMesa->Wazp3D->WinUAE marchait dans plus de 99% des cas (grace à mes patches inclus dans Wazp3D qui corrigeaient enfin StormMesa) et tout le monde s’est dit « StormMesa est pas un si mauvais produit il suffirait de corriger qques trucs pour que ça marche tout le temps » bon on aurais pu le faire dans MiniGL mais il est pas « libre » alors on se concentre sur StormMesa
Aujourd’hui j’ai fusionné notre source debugguée de StormMesa avec la library « multi-bases » de Itix …. et ça marche pas … ça me gave vraiment grave….
(((Alors, je me dis, on a pas besoin de vraiment refaire StormMesa à l’identique (avec une library-base par task) donc demain je fais une autre tentative avec une liste chainée des Context par tasks: genre je créé un Context d’OpenGL & je stocke aussi sa Task dans une liste
Puis on cherche le « CurrentContext » de cette « Task »
A pluche…
Alain
Bonjour.
Juste pour donner des nouvelles sur notre StormMesa version 2010 :
Les bonnes nouvelles:
Ca se recompile on a une nouvelle agl.library compilée avec GCC (un peu plus petite)
Les Library Bases multiples qui contiennent le context OpenGL sont implémentées
Donc avec WinUAE/Wazp3D on peut lancer plusieurs progs StormMesa sans problèmes
Les +- 200 demos/jeux StormMesa marchent avec WinUAE/Wazp3D (donc comme avant)
Les bug connues ont été enlevées du source
Les mauvaises nouvelles
J’ai introduit récemment une nouvelle bug : ça marche plus avec le vrai Warp3D
… mais on se calme on va y arriverLa fameuse bug du Zbuffer survient toujours dans certaines circonstances (malgré des correctifs)
Certains progs marchent pas ou plantent: TiltNRollDemo, IHaveNoTomatoes, Tales of Tamar 3D
Le dernier (qui marchait très bien avant) prouve qu’on a introduit de nouvelles bugs qque part
Il faut dire que les sources étaient pas si complétes et qu’il nous a fallu créer les glue-functions (les programmeur comprendront) de la library ==> source d’erreurs potentielles
Voilà y a du bon y a du mauvais mais ça avance petit à petit
Mais j’aurais pas cru que cela serait si difficile….
Alain Thellier
- Vous devez être connecté pour répondre à ce sujet.
