Crisot, Hans a répondu sur Amigans (sur le sujet consacré à ton jeu) :

"I know. I read some of his MiniGL criticism, and I disagree with a lot of what he says. I have refrained from commenting so far, but since you brought it up...

Crisot is absolutely correct that using Warp3D directly will give you better performance than using MiniGL. His preference to use Warp3D directly isn't surprising given that he knows how to use it and is writing stuff from scratch. However, his criticism of MiniGL is overly harsh because there is no way that any OpenGL via Warp3D library could be made without adding performance reducing overhead.

Crisot claims that MiniGL renders polygons one by one, but that's not true. It assembles them into vertex arrays even when the app/game developer provides vertices one by one. So, it renders groups of primitives at a time (where possible). Developers should be passing MiniGL vertex arrays, anyway. In fact, MiniGL even supports the GL_EXT_compiled_vertex_array extension, which Quake 3 uses to improve performance. I tried disabling this extension once, and the difference was noticeable. Sadly, very few know that this extension even exists in the OpenGL specification.

Crisot complains about MiniGL's locking method, which is unusual. However, it's unusual for a reason. MiniGL holds on to the lock as long as it does is to maximise performance while minimising audio stuttering. Yes, you read correctly: the smartlock mode maximises performance while minimising audio stuttering. The difficulty is that OpenGL has no concept of hardware locking, and so doesn't indicate when is a good time to lock and unlock the hardware. Hence, the complicated locking system. It is possible to set MiniGL to manual lock mode and take full control, but most people aren't going to do that, especially with *nix ports. Even then, a custom Warp3D engine will be faster...

MiniGL is significantly faster than StormMESA. I don't know the exact numbers but, IIRC, it is at least twice as fast. The bottom line is, mapping the OpenGL API to Warp3D efficiently isn't easy, and MiniGL does a pretty good job. There may well be a more efficient method, but it will never be anywhere near as efficient as using Warp3D directly. "

J'ai rien traduit (ça ne concerne que les spécialistes 3D). Mais en substance il dit qu'il est pas trop d'accord avec toi et qu'il existe bien certaines fonctions MiniGL que tu dis ne pas exister.

Mais il est te rejoint sur le fait qu'un moteur Warp3D sera toujours plus rapide qu'un moteur MiniGL reposant ensuite sur Warp3D.

Il est aussi bien content que tu bosses sur ce projet et trouve que ce proejt est très prometteur ! :-)

Bon, j'irais pas me prendre le choux avec Hans, je l'aime beaucoup, c'est un mec qui se prend le choux à longueur de journée pour nous pondre des drivers, mais:

-L'existance des compiled vertex array dans MiniGL, je la connais. C'est justement de ce coté que j'ai regardé puisque mon soft de test était... Quake3! Et si il est vrai que les polygones non clippés (ceux qui tiennent entièrement dans l'écran) sont rendus d'un coup, les polygones clippés eux (ceux qui sont à cheval dans l'écran et hors de l'écran), sont bel et bien clippés un à un et tracés un à un!

-Le lockmode, pareil. Il dit que ça permet de minimiser la corruption sonore, j'irais beaucoup plus loin. Le smartlock est la PARFAITE solution pour MAXIMISER la corruption sonore, pour s'assurer que les sons soient le plus souvent possible corrompus. Et j'exagère à peine! J'ai pas le temps de détailler pourquoi vu que je devrais déjà être au boulot. Mais le fait qu'OpenGL n'ai pas de notion de hardware locking on s'en fout. On lock avant de tracer, on unlock après avoir tracé, POINT.

Par contre je suis convaincu: Dés que j'ai du temps pour ça (après Odyssey), je réécris un OpenGL. Je ferais chier des gens comme Alain et Amidark pour m'envoyer progressivement du code miniGL de plus en plus difficile à compiler (au début un cube, après des textures, après de la lumière, etc...), et ferait en sorte que ça compile aussi bien avec MiniGL qu'avec mon code, avec le même rendu, et ce, jusqu'à ce que MiniGL finisse au trashcan.

Hello Crisot
Je pense que le vrai problème, d'une manière ou d'un autre, c'est que MiniGL (ou StormMesa ou le Prog qui les appelle comme SuperTuxkart) ont tendance à appeler Warp3D pour tracer les triangles un par un
Attention, comme le fais remarquer Hans, y a des cas où MiniGL peut tracer plein de truc d'un coup mais le problème c que c pas systématique.

DONC
Il faut ce que j'appelle un StateTracker : cad que toutes les opérations de traçage sont bufferisés et uniquement quand quelque chose change (un "state" est modidifié comme l'état gouraud passe de activé à désactivé ) alors on fait un flush de toutes les primitives bufferizés (en fait il s'agit d'une pure et efficace implémentation du mode INDIRECT qui existait dans de vieux driver Warp3D)
cad
tex 0
couleur rouge
gouraud OFF
trace un tri (bufferizé)

tex 0
couleur rouge
gouraud OFF
trace un tri(bufferizé)

tex 0
couleur rouge
gouraud OFF
trace un tri (bufferizé)

tex 0
couleur rouge
gouraud ON
trace un tri (flush 3 tris,bufferize ce tri)

J'avais déjà implémenté cela dans Wazp3D pour 3 fonctions (W3D_DrawTriangle/Line/Points)
uniquement (mais il existe 9 autres fonctions de tracage)
Là j'ai tout implémenté pour la future v54 mais j'ai pas eu le temps de compiler/tester (je suis sur Microbe3d à 100%)

Bref ce que je veut dire c'est tu devrais partir du Mesa3D Aros (j'ai démandé à DeadWood de le compiler pour os4 (j'attends....) mais en mode software only) et faire un wrapper+statetracker pour Warp3D
Ainsi on aurait le dernier Mesa3D(OpenGL) :-)

Alain

A la limite le plus radical c'est de reprendre du code de Wazp3D

exemple sur W3D_SetState() :
mais y a plein d'autres fonctions w3d qui changent WC->state.Changed

Tout est écrit au fur et à mesure dans une structure state (WC->state)
et quand on trace on le compare au final (encore) avec le state courant SC->state

Oui je sais c Top ;-)


/*==========================================================================*/
BOOL SetState(W3D_Context *context,ULONG state,BOOL set)
{
struct WAZP3D_context *WC=context->driver;
ULONG newstate;
/* simpler W3D_SetState used internally */

if(set)
if(context->EnableMask & state)
{
newstate=context->state | state;
if(context->state!=newstate)
WC->state.Changed=TRUE;
context->state=newstate;
return(TRUE);
}

if(!set)
if(context->DisableMask & state)
{
newstate=context->state & ~state;
if(context->state!=newstate)
WC->state.Changed=TRUE;
context->state=newstate;
return(TRUE);
}
return(FALSE);
}
/*==========================================================================*/
ULONG W3D_SetState(W3D_Context *context, ULONG state, ULONG action)
{
void W3D_SetFrontFace(W3D_Context* context, ULONG direction);
struct WAZP3D_context *WC=context->driver;

WAZP3DFUNCTION(5);
PrintState(state,action);

/* set state if possible */
if(SetState(context,state,(action==W3D_ENABLE)) == FALSE)
WRETURN(W3D_UNSUPPORTEDSTATE);

if( state==W3D_ZBUFFERUPDATE)
if(action==W3D_ENABLE)
SetState(context,W3D_ZBUFFER,W3D_ENABLE); /*patch: for MiniGL/OS4 that forgot to enable zbuffer*/

if(state==W3D_BLENDING)
WC->CallSetBlending=TRUE;
if(state==W3D_CULLFACE)
W3D_SetFrontFace(context,context->FrontFaceOrder);

WRETURN(W3D_SUCCESS);
}


/*==================================================================*/
struct state3D /* v52: now all is described in a drawing state */
{
unsigned char Changed;
unsigned char ZMode;
unsigned char BlendMode;
unsigned char TexEnvMode;

unsigned char PerspMode;
unsigned char CullingMode;
unsigned char FogMode;
unsigned char UseGouraud;

unsigned char UseTex;
unsigned char UseFog;
unsigned char pad3;
unsigned char pad4;

unsigned char CurrentRGBA[4];
unsigned char EnvRGBA[4];
unsigned char FogRGBA[4];
unsigned char BackRGBA[4];

unsigned long PointSize;
unsigned long LineSize;
unsigned long primitive;
float FogZmin;
float FogZmax;
float FogDensity;
void* ST;
unsigned long gltex; /* GL texture */
};
*/*=============================================================*/
void SOFT3D_SetDrawState(APTR sc,APTR sta)
{
struct state3D *state=sta;
struct SOFT3D_context *SC=sc;
struct SOFT3D_texture *ST=state->ST;


if(!Wazp3D->PrefsIsOpened) /* if the user dont changing debug states */
LibDebug=Wazp3D->DebugWazp3D.ON; /* synchronize soft3d's LibDebug with global debug value "DebugWazp3D" setted with Wazp3-Prefs */
SFUNCTION(SOFT3D_SetDrawState)
if(Wazp3D->DebugSOFT3D.ON)
{
Libprintf(" state:Changed%ld UseTex%ld ST%ld ZMode%ld TexEnvMode%ld BlendMode%ld UseGouraud%ld UseFog%ld\n",(ULONG)state->Changed,(ULONG)state->UseTex,(ULONG)state->ST,(ULONG)state->ZMode,(ULONG)state->TexEnvMode,(ULONG)state->BlendMode,(ULONG)state->UseGouraud,(ULONG)state->UseFog);
PrintST(state->ST);
Libprintf(" CurrentRGBA: %ld %ld %ld %ld\n",(ULONG)state->CurrentRGBA[0],(ULONG)state->CurrentRGBA[1],(ULONG)state->CurrentRGBA[2],(ULONG)state->CurrentRGBA[3]);
}

if(!state->Changed)
{
SREM( state unchanged) /* not changed ==> do nothing */
return;
}

if(Wazp3D->UseStateTracker.ON)
if(!Wazp3D->PrefsIsOpened) /* if the user dont change states */
if(SC->state.ST ==state->ST)
if(SC->state.ZMode ==state->ZMode)
if(SC->state.BlendMode ==state->BlendMode)
if(SC->state.TexEnvMode ==state->TexEnvMode)
if(SC->state.PerspMode ==state->PerspMode)
if(SC->state.CullingMode==state->CullingMode)
if(SC->state.FogMode ==state->FogMode)
if(SC->state.UseGouraud ==state->UseGouraud)
if(SC->state.UseTex ==state->UseTex)
if(SC->state.UseFog ==state->UseFog)
if(SAMERGBA(SC->state.FogRGBA ,state->FogRGBA))
if(SAMERGBA(SC->state.CurrentRGBA ,state->CurrentRGBA))
if(SAMERGBA(SC->state.EnvRGBA ,state->EnvRGBA))
if(SC->state.PointSize ==state->PointSize)
if(SC->state.LineSize ==state->LineSize)
if(SC->state.FogZmin ==state->FogZmin)
if(SC->state.FogZmax ==state->FogZmax)
if(SC->state.FogDensity ==state->FogDensity)
{
SREM( all same states) /* if nothing truly changed ==> do nothing */
SC->state.Changed=state->Changed=FALSE;
return;
}


SC->state.ZMode =state->ZMode;
SC->state.BlendMode =state->BlendMode;
SC->state.TexEnvMode =state->TexEnvMode;
SC->state.PerspMode =state->PerspMode;
SC->state.CullingMode =state->CullingMode;
SC->state.FogMode =state->FogMode;
SC->state.UseGouraud =state->UseGouraud;
SC->state.UseTex =state->UseTex;
SC->state.UseFog =state->UseFog;
COPYRGBA(SC->state.FogRGBA ,state->FogRGBA);
COPYRGBA(SC->state.CurrentRGBA ,state->CurrentRGBA);
COPYRGBA(SC->state.EnvRGBA ,state->EnvRGBA);
COPYRGBA(SC->state.BackRGBA ,state->BackRGBA);
SC->state.PointSize =state->PointSize;
SC->state.LineSize =state->LineSize;
SC->state.FogZmin =state->FogZmin;
SC->state.FogZmax =state->FogZmax;
SC->state.FogDensity =state->FogDensity;
SC->state.ST =state->ST;
/*hard stuffs */
SC->state.gltex =0;
if(ST!=NULL)
SC->state.gltex =ST->HT.gltex; /*direct access to gltex value */
SC->HC.state=&SC->state; /*direct access to state */


/* flush remaining pixels before any changes */
SOFT3D_Flush(SC);

/* Now change hardware/software drawing functions */
#ifdef USEOPENGL
if(SC->UseHard) HARD3D_SetDrawFunctions(&SC->HC);
#endif
if(!SC->UseHard) SOFT3D_SetDrawFunctions(sc);

SC->state.Changed=state->Changed=FALSE; /* change treated */
}
/*=============================================================*/

Buffuriser les triangles ce serait surtout un moyen de limiter la casse en surcouche de MiniGL.

Si déjà, pour chaque demande utilisateur de tracer un objet, MiniGL se contentait de bel et bien tracer les objets, mais avec un minimum d'appels, on serait déjà sur quelque chose de bien plus rapide, et ce, même si l'utilisateur est un mauvais codeur qui fait beaucoup d'appels à MiniGL pour peu de polygones. Mais là le code qui serait lent serait uniquement celui mal codé. Hors, y'a aucune appli MiniGL qui tourne correctement.

Parceque là en parlant des problèmes d'appels trops nombreux aux fonctions de traçage, c'est une chose. Mais c'est pas comme si c'était le seul défaut de MiniGL. Honnêtement, tout est mal écris dans MiniGL. Même les loops CPU heavy sont mal foutues, trop longues, pas optimisées...

C'est pas parceque ça fonctionne bien que ça fonctionne vite. Et ça y'a plus personne qui en tiens compte.

Oui ... Mais peut-être devrais-tu "modérer" tes propos ..
Tu craches peut-être dans une soupe qui est pas si dégueulasse que cela ...

MiniGL c'est une couche OpenGL et à la Base, OpenGL n'est pas là pour pallier aux conneries du codeur ... Il est là pour être une couche 3D... De plus, Hans a expliqué la gestion du rendu, les limitations (liés à l'interfaçage Warp3D <-> MiniGL).

D'ailleurs je suis d'ailleurs surpris que toi qui me disait il y a quelques jours de cela "j'y pige que dalle au code source de MiniGL", tu puisses apporter autant de détails sur les processus interne de la librairie sachant que certains limitations sont parfois liés à d'autres commandes et l'interfaçage Warp3D <-> MiniGL.
Je sais que tu est un très bon coder (probablement meilleur que moi) cependant, je pense que tu fais beaucoup de "gueulantes" pour rien. (pour rien car ça ne changera pas la donne)

Je comprends qu'il y ait des choses qui ne puissent pas être faite "simplement" donc résultat. Ce qui a été fait est déjà "beau" vis à vis des moyens accessibles financiers, etc., mis en oeuvre pour réaliser cette couche 3D.

Tu vois où je veux en venir ?

Quoi qu'il en soit, pour ma part, MiniGL j'en suis très content et j'espère que l'AmiDARK Engine permettra de faire des jeux en 3D sur Amiga ... Même si on peut pas avoir 50.000.000 de Triangles dans la scène ... On peut déjà faire bien avec beaucoup moins ;)

@+

Perso, j'y connais rien.. Mais je pense que Criso sait ce qu'il pense et ce qu'il fait....
Purée. Si on pouvait avoir cette animation en jeu sur un AmigaNG... J'me casserais plus le fion à acheter des Pcs aussi chéros !!! Un FPS ou jeu de rôle avec la palette odyssey.. Ce serait terrible quand même .......
Enfin.... Entre coders.. vous vous comprenez mieux que nous....

Citation : Pseudaxos?

Un FPS ou jeu de rôle avec la palette odyssey.. Ce serait terrible quand même .......
Enfin.... Entre coders.. vous vous comprenez mieux que nous....

Je propose qu'on fasse un club des non-coders pour juger les coders. Chaque année, nous pourrions attribuer un prix au meilleur coder... selon des critères à définir. ;-)
Coders, mes frères, attention, vous allez ^etre notés ! :b

Pseudaxos, je ne dis pas que Crisot ne connaisse pas ce dont il parle car il a très bien pu se mettre tous les jours à fond pour comprendre son fonctionnement interne au MiniGL.
Cependant, la critique ne vaut que si elle permet de faire évoluer les choses....
Une critique aggressive qui n'est pas constructive et qui en plus peut servir indirectement à promouvoir ses propres produits que l'on prévoit ... Perso j'aime pas ça .. ça fait trop "je suis le sauveur de l'Humanité c'est moi qui ai la plus grosse!" .. non sérieusement.
J'aime beaucoup Crisot, je l'ai déjà rencontre à l'Alchimie ... Mais sur ce coup ... je pense personnellement qu'il va un peu trop loin et que au final .. a part créer une mauvaise ambiance avec la communauté Amiga anglphone, ça sert à rien de taper ainsi sur le bousin :p

Créols ... tu cherches à te faire taper sur les doigts ami ;)

@+

Crisot a prouvé maintes et maintes fois, par ses créations, qu'il savait ce qu'il faisait et qu'il connaissait son sujet.

De ton côté, tu a réalisé un moteur 3D basé sur DarkEngine qui est exceptionnel aussi.

Pour ma part, j'apprécie le franc parler de Crisot car il est l'un des rares à s'exprimer ainsi, mais surtout en connaissance de cause.

Je doite très fortement qu'il critique MiniGL juste pour se faire mousser ou mettre en avant son propore moteur 3D sous Warp3D.

Crisot est sur Amiga depuis tellement longtemps et il a créé tellement de choses depuis l'avènement de Warp3D (et avant si l'on considère les démos Universe de l'époque) qu'il n'a aucun intérêt à se faire mousser ou se mettre en avant.

Pour avoir discuté souvent avec lui (comme beaucoup d'ailleurs), son franc parler est ce qui fait sa personnalité et il est très apprécié pour cela.

De ton côté, tu essaies toi aussi de mettre en avant l'AmiDarkEngine, qui là aussi est un boulot étonnant et j'attends de voir les toutes premièes créations issues de celui-ci.

Je te rejoins néanmoins sur le fait qu'en effet on revient de loin et cela a permis de nombreuses créations.

Bref, j'aimerais qu'ici, en France, on unisse nos forces et nos connaissances, que l'on accepte les avis de chacun et qu'on s'entraide plutôt que de partir en vrille car l'on apprécie pas le franc parler d'un autre (souviens-toi de tes déboires sur AI).

Il y a de la place pour tout le monde ici, surtout sur Amiga-NG, profitons-en ! ;-)