Désolé, je ferme, ça part trop en sucette :-(

K-L a très vivement invité à ne pas recourir aux insultes sous peine de fermeture de topic. J'y vois donc un moyen optimisé de clore une bonne fois pour toute cette conversation. Aller en piste...

Citation : AmiDARK?
Tu connais bien mes 37 ans de vie apparement ... Bravo :p Tu ne connais RIEN de mon expérience personnelle/professionnelle en développement.

A mon grand désarroi, je ne sais plus si c'était sur ce forum, en commentaire de news, en discussion Facebook, mais je me souviens très bien de toi, AmiDARK, disant grosso modo ne pas savoir utiliser Warp3D (=api rasterizer bas niveau type Direct3D d'antan) puisque lui préférant MiniGL (=api haut niveau type OpenGL).

Je sais donc, de tes mots, que ton expérience de développement n'inclue pas l'utilisation d'un rasterizer bas niveau.

Citation : AmiDARK
PS : Mon 1er moteur 3D très bas niveau était sur Amiga en pure assembleur 680x0 il y a plus de 10 ans en arrière ;) Comme quoi ... Mais c'est pas grave ... tu connais tout de ma vie, tu devais donc déjà le savoir ?

On parle de Library graphiques accélérées hardware (Composites, MiniGL, intuition...). POURQUOI est-ce que tu me les broie avec un moteur software?

Citation : AmiDARK
Postulat du message initial, tu peux vérifier en 1ère page : Quelqu'un a t-il déjà fait les tests pour comparer les performances de rendu 2D
(tracé d'images dans une fenêtre et dans un écran

En quoi Composition n'est pas capable de faire ça ?

CA, il est capable de le faire, c'est TOI qui es ensuite venu me claquer les noyaux avec tes "mode de filtrage" et "couleur RGB des vertex" juste pour me faire un discours sur l'optimisation des paramètres et des textures: Ca, NON, Composite ne le gère pas, tu aurais pu vérifier...

Citation : AmiDARK
Apparement, c'est pas ce que disent les gars sur amigans.net et amigaworld.net ... aucun dit que le mode composition ne peut pas faire ça ... Mais bien entendu, tu vas me dire "ils ont tous tord"

Si un mec t'affirmes que Composite est capable de modifier les couleurs des vertex, il est probable que je réagisse comme ça. Sources: Autodocs, !include! SDK...

Citation : AmiDARK
c'est toi le meilleur c'est ça ? ... Comme d'habitude ... C'est pathétique...

L'habitude d'avoir raison, je m'y fais, celle d'être emmerdés par des mecs [censuré], en revanche, je suis visiblement pas encore tout à fait au point.

Citation : AmiDARK
FREE: Ben apparement, après renseignements (lois, etc.) tu te gourres, c'est bien plus complêxe que ça ... mais comme d'hab tu ne vois que la partie visible de l'Iceberg ... Je t'envoie un MP avec les explications liées...

Tu te rends compte que d'un débat légitime quoi que houleux type "qui doit payer entre le FAI ou le fournisseur de contenu", t'es passé par un discours philosophique sur l'abus des gens à la surconsommation, sur l'exigence du tout "tout de suite", et maintenant tu me sors les C.G.V qui autorisent le FAI à entuber ses clients, et pire, tu va même déterrer des textes de loi pour crédibiliser les C.G.V en question??? Tu te rends compte???

Message édité par : Crisot / 07-04-2013 03:25
Message édité par : Creols / 07-04-2013 10:49

Edité par Elwood car je ne vois aucune raison de parler en ces termes, et encore moins de les laisser en ligne.
Message édité par : Elwood / 07-04-2013 13:04

Se que je comprend pas, c'est que Minigl est un truc "pour tous les OS", comment sa s'explique qu'un truc pas fait à la base pour AOS soit plus rapide que la composition?

Perso, je pense qu'il y a encore beaucoup de chose à améliorer sur AOS en terme de gestion GFx, sa devient trop généraliste à mon goût à moins que je me plante ;-)

j'ai pas AOS pour avoir un dérivé de Linux... :-(

- L'expérience dont je parle, ce n'est pas l'expérience sur le code en général ou sur le C, ou que sais-je. Partons du principe que ton expérience là dessus est 50 fois supérieure à la mienne, ça ne me dérange pas. Les faits que j'apporte sont basés sur la connaissance d'un moteur 3D bas/très bas niveau, c'est à dire plus bien bas qu'OpenGL: Ca, tu n'en a jamais fais, moi oui. Et c'est pour ça, que je t'affirme que tes tiles 32x32 se foutent royalement des paramètres que tu appliques.

Tu connais bien mes 37 ans de vie apparement ... Bravo :p Tu ne connais RIEN de mon expérience personnelle/professionnelle en développement. Que la partie visible vis à vis de l'Amiga mais à la différence de toi, je n'expose pas toute ma vie et je ne cherche pas à faire le *beau*.
PS : Mon 1er moteur 3D très bas niveau était sur Amiga en pure assembleur 680x0 il y a plus de 10 ans en arrière ;) Comme quoi ... Mais c'est pas grave ... tu connais tout de ma vie, tu devais donc déjà le savoir ?

-Par ailleur, outre le fait que ça ne fera pas grande différence, le sujet de départ est la comparaison MiniGL / Composition. Les paramètres dont tu parles sont pour la plupart inaccesibles à Composite, donc quand bien même MiniGL ralentirait énormément, Composite ne saurait tout simplement pas le faire.

Tu mélanges un peu tout ... je ne parle pas de OpenGL au sens large de toutes ses capacités 2D/3D.
Postulat du message initial, tu peux vérifier en 1ère page : Quelqu'un a t-il déjà fait les tests pour comparer les performances de rendu 2D
(tracé d'images dans une fenêtre et dans un écran (mode plein écran)) entre ces 4 composants de l'AmigaOS4 ?
Histoire de savoir lequel a les meilleures performances en rendu 2D ...

En quoi Composition n'est pas capable de faire ça ?
Apparement, c'est pas ce que disent les gars sur amigans.net et amigaworld.net ... aucun dit que le mode composition ne peut pas faire ça ... Mais bien entendu, tu vas me dire "ils ont tous tord" c'est toi le meilleur c'est ça ? ... Comme d'habitude ... C'est pathétique...

- Le hors sujet Free... osef, c'est pas le bon lieu pour le poursuivre. Dis juste à ton collègues de consulter les lois sur l'obligation de résultat, quoi qu'il y ai dans ses C.D.G.

Ben apparement, après renseignements (lois, etc.) tu te gourres, c'est bien plus complêxe que ça ... mais comme d'hab tu ne vois que la partie visible de l'Iceberg ... Je t'envoie un MP avec les explications liées...

@+
Message édité par : Elwood / 07-04-2013 13:16
Message édité par : Elwood / 07-04-2013 13:17

Amidark: Je suis obligé de faire vite non parceque je pars au boulot, hélas, mais... Tu vois, tu m'a encore argumenté que j'avais tord, je t'avais suggéré de ne pas le faire, et pourtant... Alors, version très courte:

- Je te l'avais déjà dis, mon moteur n'est PAS optimisé à un but/jeu préci. Il est capable de faire tout ce que fait OpenGL (en tout cas le notre), est à vocation multiple. En l'état, sans aucune modification, je peux faire un jeu 3D, 2D, une demo, un visualiteur pour AmigaAmp, peu importe, il fera tout, et il fera tout relativement vite. Il n'est juste pas compatible OpenGL, mais il serait tout à fait concevable qu'il le devienne si j'en avais envie. Comme je l'ai déjà dis, une Library OpenGL, ce n'est ni plus ni moins qu'un moteur 3D perso "normalisé".

-Le point de départ: Je te le ré affirme, tes tiles de 32x32, ils peuvent avoir des couleurs différentes, des filtrages différents, tous les paramètres possibles et imaginable différents, ça ne fera pas grande différence, même sur un 603e@175.

-Par ailleur, outre le fait que ça ne fera pas grande différence, le sujet de départ est la comparaison MiniGL / Composition. Les paramètres dont tu parles sont pour la plupart inaccesibles à Composite, donc quand bien même MiniGL ralentirait énormément, Composite ne saurait tout simplement pas le faire.

- L'expérience dont je parle, ce n'est pas l'expérience sur le code en général ou sur le C, ou que sais-je. Partons du principe que ton expérience là dessus est 50 fois supérieure à la mienne, ça ne me dérange pas. Les faits que j'apporte sont basés sur la connaissance d'un moteur 3D bas/très bas niveau, c'est à dire plus bien bas qu'OpenGL: Ca, tu n'en a jamais fais, moi oui. Et c'est pour ça, que je t'affirme que tes tiles 32x32 se foutent royalement des paramètres que tu appliques.

- Le hors sujet Free... osef, c'est pas le bon lieu pour le poursuivre. Dis juste à ton collègues de consulter les lois sur l'obligation de résultat, quoi qu'il y ai dans ses C.D.G.

Au plaisir! Je file!!!
Message édité par : Crisot / 06-04-2013 19:18

K-L : Ta pas compris ils sont en fase de séduction.

des je t'aime par-ci je t'aime par-la lol bande de kokinou va!

Bon je déconne mais ta raison de moderéer ça y peuvent le faire en privé ça derrangera personne :-)

K-L : I l n'est dédié qu'à la 2D ! Pas la 3D ;)
(regarde le sujet initial)

Alors voilà ce qu'on va faire :

Ce sujet n'est dédié qu'à la 3D sur AmigaOS 4.1, vous allez continuer d'en débattre techniquement et éviter un maximum les sujeté dérivés (mais vous pouvez vous troller la mouille sur Free -et j'y participerais volontiers- en ouvrant un nouveau sujet dans la rubrique "Tous Sujets" mais en conservant un esprit de convivialité).

Ensuite les jugements de valeur sont OK tant que ça ne part pas en quenouille, je pense d'ailleurs que tout a été dit à ce sujet et qu'il vaut mieux continuer sur le plan technique (c'est ce qui nous intéresse nous, les autres membres, surtout).

Ce serait dommage que je sois obligé de modérer un sujet (je crois que ce n'est encore jamais arrivé). ;-)

Crisot,

Si tu m'aimes bien, tant mieux. Perso je t'aime bien sinon j'aurais carrément occulté/ignoré tes propos (ou affiche juste un gros mépris).

Le problème est que tes constants sont souvent : à moitié vrai, à moitié faux.
Si ils sont vérifiables dans la théorie, dans la pratique il y a des cas où, ton raisonnement ne s'applique pas.

Simplement pour explication dans ce cas :
1. Dans la théorie : Si toutes les tiles 32x32 ont les mêmes paramétrages d'affichage, effectivement ce sera guère plus lent (le moitié vrai)...
2. Dans la pratique : Maintenant,Si chaque image à un paramétrage (couleurs RGB des vertex, Valeur Alpha, Coordonnées UV, Rotation & Scaling à l'intérieur de l'image même, etc.) là, ce sera plus lent forcément car il faudra redéfinir les paramètrages (OpenGL ou pas) pour chaque image.
Et le plus important, En cela en prenant en compte surtout, que nous avons dans les Amiga des machines qui ne tournent que à 666Mhz (les Sam440EP) et qu'il existe des machines Amiga OS 4 sur les anciens PPC Blizzard (à 233Mhz)
L'impact de quelques lignes de code n'est pas le même selon la puissance de la machine!

Ce qui m'amène au constat suivant :
N'oublie pas que nous codons tous deux dans 2 optiques différentes :
- Toi tu fais un moteur 3D Perso, Hyper optimisé et prévu pour 1 jeu voire 1 type de jeu.
- Moi je fais un moteur 3D Perso, optimisé comme possible mais extensible car prévu pour être un KIT de développement de jeu (et donc certaines optimisations ne sont pas possibles et ce, même en codant au mieux que possible qu'il soit)..
La différence fondamentale et, c'est là ou TU es dans l'erreur c'est que tu ne voies QUE l'optique optimisation à fond ... Résultat dans ton optique, ton constat de différence de vitesse est vrai ... Mais tu ne vois que la moitié de la programmation car tu oublies des paramètres obligatoires dans des cas différents de ta vision des choses...
Dans d'autres types de projets, les optimisations et façon de coder dont tu parles ne peuvent TECHNIQUEMENT PAS s'appliquer et donc, ton jugement est faux ... et ton "si tu sais pas coder" est encore plus abhérent car un GDK aussi optimisé soit-il sera toujours un peu plus lent qu'un moteur précis pour 1 but précis (tout aussi optimisé lui aussi).
Pour ma part, donc, contrairement à toi, je suis capable de voir les 2 côtés et donc, je te pointe lorsque tu ne vois pas les deux...

Donc, pour résumer ce que tu dis : Toi tu parles de beaucoup d'informations récupérées, etc ... maintenant, moi je te dis, "tu oublies pas mal de paramètres dans tes constats". Cela fait peut-être 10 ans que tu fais de la 3D (bien que la on parle de 2D uniquement ce qui est sensiblement différent) .. Pour ma part, je programme aussi depuis plus de 10 ans tout comme toi ... donc les arguments "j'ai une expérience, etc...", ce n'est pas valable, c'est une excuse bien trop souvent sorti par des gens pour qualifier des comportements inqualifiable (en locurrence, tu as un discours de politicien)

Supprimé par Elwood. Aucun intérêt dans la discussion.

Message édité par : Elwood / 07-04-2013 13:13

Alors Fred... Laisses moi t'expliquer pourquoi je m'enerve souvent après toi, alors que paradoxalement, je t'aime bien, et ce que tu interprètes comme de la prétention.

Quand je ne suis pas sur d'une info, je le précise toujours. "Je crois, il me semble, blablabla". J'en ai utilisés bien assez ici même. Par contre, quand on tape dans un domaine que je connais, alors là, oui, je parle avec assurance. Et si je parle avec assurance, ce n'est non pas parceque JE PENSE que l'information que je donne est bonne: C'est parceque JE SAIS qu'elle est bonne <- Gain de temps.

Supprimé par Elwood. Aucun intérêt dans la discussion.

Alors pour en revenir au problème initial: NON, mapper de la 2D avec 20 textures ne sera pas plus lent qu'avec 1 seule. En fait, si ça te convient mieux, je peux même modérer: Mapper de la 2D avec 20 textures ne sera que très sensiblement plus lent qu'avec 1 seule. Et c'est même valable pour tes tiles 32x32... Voila. Et là, tout comme je m'appuis sur l'expérience des gens bien plus expérimentés que moi, je te demande de me croire, c'est tout. Tu peux encore partir dans un discours qui m'expliquera pourquoi ça sera malgré tout beaucoup plus lent si tu veux, mais tu vas juste te planter.

Et non, je ne suis pas là pour faire du social. Du tout. Je m'exige (que mon code soit optimisé, que le résultat soit beau, que ça plaise...) donc j'exige (que Free me fournisse une connection qui marche...).

Amicalement.
Message édité par : Crisot / 06-04-2013 07:22
Message édité par : Elwood / 07-04-2013 13:11