C et ASM: Tutorial Kernel - Page 2

Bonne raison pour remettre DoorsOS au gout du jour

Je te signale que Thomas Nussbaumer a trouvé pas mal de bogues juste en survolant la source C de DoorsOS. Par exemple des SYM_ENTRY * qui sont utilisés à travers des compressions du heap. Il faudra relire attentivement chaque ligne si tu veux en faire quelque chose de stable.

J'utilise shrinklib pour la compression des données externes, et je ne compte pas revenir en arrière. Mais Kevin, ce n'est pas parceque Kururin est en kernel que tous mes projets le sont et le seront, ni que je suis un pro-kernel.

Tu devrais revenir en arrière. ttpack compresse mieux que shrnklib de manière significative.

Veux-tu vraiment que la stabilité de tes programmes dépende de celle des versions antiques de DoorsOS???

bah... tu peux toujours tester quel kernel est installe...
et de ttes facons, tant mieux si ca bug avec les vieux kernel, ca obligera le gars a les updater...
et puis tu peux la marquer dans le readme...

(ah oui, trinity est 100% pur kernel bien sur )

sBibi a écrit :
Veux-tu vraiment que la stabilité de tes programmes dépende de celle des versions antiques de DoorsOS???

bah... tu peux toujours tester quel kernel est installe... et de ttes facons, tant mieux si ca bug avec les vieux kernel, ca obligera le gars a les updater...

Je n'aime pas cette attitude d'"obliger" les gens à faire des trucs pour que tes programmes marchent. Il faut qu'il y ait le moins possible de contraintes pour l'utilisateur.

et puis tu peux la marquer dans le readme...

Parce que tu crois que ce qui ont encore DoorsOS sur leur calculatrice sont ceux qui lisent les readmes? Ce sont en général ceux qui reçoivent le programme de 3^ème ou 4^ème main, à travers le câble calc-to-calc.

(ah oui, trinity est 100% pur kernel bien sur )

Bref, rien ne remplace FAT Engine.

non, les personnes qui telechargeront mon jeu DEVRONT lire le readme qu ileur dira de mettre preos et de virer ce caca doorsos, ou mieux je detecte ds mon prgm si doorsos est sur la calc et je le vire

Ton message est un exemple parfait du total manque de respect de l'utilisateur présent chez les programmeurs pour kernel.
Moi, un programme qui fait ça, je l'appelle un troyen.

je plaisante bien sur !!!
ds le readme, je mettrai qu'il faut absolument preos pour que le jeu fonctionne bien et je fournirait preos avec si g l'accord.....apres si l'utilisateur lit pas le readme, c qu'il est pas digne de jouer à mon jeu

if (doorsos)
{
delete(doorsos)
printf("vous avez besoin d'un kernel recent: http://www.timetoteam.fr.st")
exit(1);
}

"Je n'aime pas cette attitude d'"obliger" les gens à faire des trucs pour que tes programmes marchent. Il faut qu'il y ait le moins possible de contraintes pour l'utilisateur."

bah... pourquoi? il est ou le mal? moins de contraintes, si au final c'est mieux que ce qu'il avait avant...
c comme si tu veux jouer a UT2003 t oblige de passer de windows 3.1 a windows 98, 2000 ou XP... et de t'acheter un nouveau pc si t'as un 386...
la c'est encore mieux, Preos ca marchera sur ttes les 89/92(+), c juste un zip a telecharger... keske c contraignant...

"Parce que tu crois que ce qui ont encore DoorsOS sur leur calculatrice sont ceux qui lisent les readmes? Ce sont en général ceux qui reçoivent le programme de 3ème ou 4ème main, à travers le câble calc-to-calc."

celui qui leur a passe a bien du le dl a un moment ou a un autre, dc il a le readme...
pour en revenir a l'exemple d'au dessus:
si t'as windows 3.1 et qu'un gars te passe le cd d'UT2003 grave, y aura pas marque dessus qu'avec win 3.1 ca marche pas... par contre c marque sur la boite du cd original... et si le gars qui te l'a passe arrive a le faire marcher, c'est qu'il a tout ce qui faut... dc a la rigueur le PreOs il doit l'avoir

"Bref, rien ne remplace FAT Engine."
t'as des jump pads dans le FAT engine? t'as des teleporteurs? c en plein ecran? tu peux te pencher sur le cote? regarder en haut et en bas? aller ABSOLUMENT PARTOUT avec? (en altitude aussi), avoir autre chose que des murs orthogaunaux et de meme hauteur? les textures animees? (scrolling, rotations, scaling) des evenements entierement scriptables declenchables par l'entree du joueur dans des volumes definis dans la map? une belle console? ( bon, ok elle bug godzil et melbournian pourront confirmer )

bon ok il est carrement pas fini mais bon

solid> t'affiche le readme au lancement du prog "please read me first"

c bon g LA solution ultime pour obliger chaque utilisateur a lire le readme

sBibi a écrit :
"Je n'aime pas cette attitude d'"obliger" les gens à faire des trucs pour que tes programmes marchent. Il faut qu'il y ait le moins possible de contraintes pour l'utilisateur."
bah... pourquoi? il est ou le mal? moins de contraintes, si au final c'est mieux que ce qu'il avait avant...

Le problème est que l'utilisation d'un kernel ne donne pas quelque chose de "mieux que ce qu'il avait avant". Tu peux faire exactement les mêmes choses en _nostub qu'en kernel. Voire plus de choses (installer des TSR par exemple).

c comme si tu veux jouer a UT2003 t oblige de passer de windows 3.1 a windows 98, 2000 ou XP... et de t'acheter un nouveau pc si t'as un 386...

Win32 est une plateforme totalement différente de Win16. Le mode kernel est juste un layer supplémentaire et totalement inutile par dessus le vrai système d'exploitation (AMS), qui reste totalement inchangé.

la c'est encore mieux, Preos ca marchera sur ttes les 89/92(+), c juste un zip a telecharger... keske c contraignant...

Le simple fait qu'il faut PreOs est une contrainte. Et on peut facilement éliminer cette contrainte, donc pourquoi ne pas le faire?

"Parce que tu crois que ce qui ont encore DoorsOS sur leur calculatrice sont ceux qui lisent les readmes? Ce sont en général ceux qui reçoivent le programme de 3ème ou 4ème main, à travers le câble calc-to-calc."
celui qui leur a passe a bien du le dl a un moment ou a un autre, dc il a le readme...

Penses-tu vraiment que le message passe encore quand on en est à la 3^ème ou 4^ème main? S'il passait, explique-moi pourquoi les personnes en question utilisent encore DoorsOS...

pour en revenir a l'exemple d'au dessus:
si t'as windows 3.1 et qu'un gars te passe le cd d'UT2003 grave, y aura pas marque dessus qu'avec win 3.1 ca marche pas... par contre c marque sur la boite du cd original... et si le gars qui te l'a passe arrive a le faire marcher, c'est qu'il a tout ce qui faut... dc a la rigueur le PreOs il doit l'avoir

J'ai déjà dit que ton exemple est mauvais. Un exemple comparable avec le tien serait un programme qui ne marche qu'avec un système d'exploitation à jour, par exemple qu'avec AMS 2.04 et supérieures. Le cas du kernel est différent: il s'agit d'un layer supplémentaire, qui ne change rien aux fonctions proposées par le système d'exploitation.

"Bref, rien ne remplace FAT Engine."
t'as [... (je saute les questions rhétoriques)] une belle console? ( bon, ok elle bug godzil et melbournian pourront confirmer )

FAT Engine propose également une console de débogage.
Quant aux autres fonctionnalités que tu cites dans tes questions rhétoriques, ça ne sert pas pour la plupart des jeux 3D.

solid
a écrit : c bon g LA solution ultime pour obliger chaque utilisateur a lire le readme

Au lieu de chercher des solutions compliquées pour obliger les gens à lire le readme, tu devrais plutôt faire en sorte que ton programme marche de manière intuitive.

marche de maniere intuitive ? il le sera TOTALEMENT !! avec tinstall de mastergb, l'installation sera hyper simple, ensuite g une idée pour obligé l'utilisateur a avoir le readme a coté de lui lors du 1er lancement du jeu

Kevin Kofler a écrit :
Le problème est que l'utilisation d'un kernel ne donne pas quelque chose de "mieux que ce qu'il avait avant". Tu peux faire exactement les mêmes choses en _nostub qu'en kernel. Voire plus de choses (installer des TSR par exemple).

ca c TON avis , qui n'est pas forcement l'avis de tt le monde... et tu n'as pas compris ce que je voulais dire, je parlais dans le cas ou DoorsOs etait installe precedemment.... donc a moins que tu le trouve mieux que PreOs...

Win32 est une plateforme totalement différente de Win16. Le mode kernel est juste un layer supplémentaire et totalement inutile par dessus le vrai système d'exploitation (AMS), qui reste totalement inchangé.

.......
c pas possible tu le fais expres la... ct un EXEMPLE... on s'en fout de win16/32, ca aurait pu etre "truc qui marche pas sous 98 mais qui marche sous 2000/XP"...

Le simple fait qu'il faut PreOs est une contrainte. Et on peut facilement éliminer cette contrainte, donc pourquoi ne pas le faire?

en quoi c'est une contrainte? pour moi envoyer un ou deux fichiers sur la calc n'est pas une contrainte... surtt quand c'est 1 fois a chaque reset, et a la rigueur meme pas si t'archives les fichiers en question...

Penses-tu vraiment que le message passe encore quand on en est à la 3^ème ou 4^ème main? S'il passait, explique-moi pourquoi les personnes en question utilisent encore DoorsOS...

pke elles n'utilisent peut etre que des vieux jeux ou que tout marche quand meme avec DoorsOs... raison pour laquelle il vaut mieux obliger l'utilisateur a avoir PreOs, vu qu'il n'y a que des avantages par rapport a DoorsOs... c'est plutot un service qu'on lui rend

J'ai déjà dit que ton exemple est mauvais. Un exemple comparable avec le tien serait un programme qui ne marche qu'avec un système d'exploitation à jour, par exemple qu'avec AMS 2.04 et supérieures. Le cas du kernel est différent: il s'agit d'un layer supplémentaire, qui ne change rien aux fonctions proposées par le système d'exploitation.

je t deja dit que t'av rien compris a mon exemple (ou fait expres de pas comprendre)

FAT Engine propose également une console de débogage.

soit, je savais pas

Quant aux autres fonctionnalités que tu cites dans tes questions rhétoriques, ça ne sert pas pour la plupart des jeux 3D.

[/cite]

ah? c'est nouveau tiens... les "jeux 3D" auxquels tu joues doivent etre bien plats alors

Au lieu de chercher des solutions compliquées pour obliger les gens à lire le readme, tu devrais plutôt faire en sorte que ton programme marche de manière intuitive.

ah pke si tu dois lire un readme qui te dit que tu dois utiliser PreOs, ca rend ton programme pas intuitif?
on a pas la meme notion d'intuitivite alors...

solid
a écrit : marche de maniere intuitive ? il le sera TOTALEMENT !! avec tinstall de mastergb, l'installation sera hyper simple,

Argh, un programme d'installation sur une calculatrice! Désolé, mais je trouve ces systémes de programme d'installation totalement contre-intuitifs. Il n'y a qu'à voir Chrono et le nombre de questions "Comment on installe ce truc?" qu'on voit. Intuitif, c'est: on envoie le programme et on le lance, point final.

ensuite g une idée pour obligé l'utilisateur a avoir le readme a coté de lui lors du 1er lancement du jeu

Je t'ai déjà dit que je n'en ai rien à f**tre si tu as une idée pour ça, parce que le simple fait d'essayer d'obliger l'utilisateur à lire le readme est une mauvaise idée.

sBibi a écrit :
ca c TON avis , qui n'est pas forcement l'avis de tt le monde... et tu n'as pas compris ce que je voulais dire, je parlais dans le cas ou DoorsOs etait installe precedemment.... donc a moins que tu le trouve mieux que PreOs...

Mais:
1. DoorsOS n'est pas forcément installé lui non plus.
2. Pourquoi demander de mettre à jour le kernel si on peut tout aussi facilement ignorer complètement la présence du kernel dépassé et utiliser AMS directement.

c pas possible tu le fais expres la... ct un EXEMPLE... on s'en fout de win16/32, ca aurait pu etre "truc qui marche pas sous 98 mais qui marche sous 2000/XP"...

Ben, dans ce cas, je réitère ce que j'ai déjà dit: ce n'est pas comparable avec le fait de nécessiter un kernel, mais juste avec le fait de nécessiter une version à jour de AMS.

en quoi c'est une contrainte? pour moi envoyer un ou deux fichiers sur la calc n'est pas une contrainte...

Arrête de disputer les faits avec comme "arguments" des "pour moi". Le programme ne marche pas si on n'a pas fait X, donc X est une contrainte pour l'utilisation du programme, quel que soit X. Ici, X est "installer un kernel". C'est un fait.

surtt quand c'est 1 fois a chaque reset, et a la rigueur meme pas si t'archives les fichiers en question...

Ça ne change rien au fait que c'est une contrainte.

pke elles n'utilisent peut etre que des vieux jeux ou que tout marche quand meme avec DoorsOs... raison pour laquelle il vaut mieux obliger l'utilisateur a avoir PreOs, vu qu'il n'y a que des avantages par rapport a DoorsOs... c'est plutot un service qu'on lui rend

On lui rend un service en ne dépendant d'aucun kernel. Comme ça, ça marchera sans kernel, ça marchera avec DoorsOS et ça marchera avec PreOs. Et exactement de la même manière. Et s'il se retrouve avec exclusivement des programmes qui n'ont pas besoin de kernel, il va bien finir par effacer DoorsOS parce qu'il ne lui sert à rien, donc on lui aura aussi rendu ce service-là. Et en même temps, on l'a libéré complètement du joug des kernels, pas seulement de DoorsOS.

je t deja dit que t'av rien compris a mon exemple (ou fait expres de pas comprendre)

Cf. quelques paragraphes au-dessus.

ah pke si tu dois lire un readme qui te dit que tu dois utiliser PreOs, ca rend ton programme pas intuitif? on a pas la meme notion d'intuitivite alors...

Bon, je le dis à toi aussi: Intuitif, c'est: on envoie le programme et on le lance, point final.

>>>>parce que le simple fait d'essayer d'obliger l'utilisateur à lire le readme est une mauvaise idée.

?????? alors ça c la meilleure !!! à croire que tu aimes repondre aux questions dont la reponse est ds le readme

>>>>Argh, un programme d'installation sur une calculatrice! Désolé, mais je trouve ces systémes de programme d'installation totalement contre-intuitifs. Il n'y a qu'à voir Chrono et le nombre de questions "Comment on installe ce truc?" qu'on voit. Intuitif, c'est: on envoie le programme et on le lance, point final.

On envoit le prgm d'installe sur sa calc et on le lance, point final.

>>>>Et en même temps, on l'a libéré complètement du joug des kernels, pas seulement de DoorsOS.

belle preuve de ta subjectivité, je ne suis pas anti nostub que je sache, alors pkoi est tu anti kernel ?

solid a écrit :
>>>>parce que le simple fait d'essayer d'obliger l'utilisateur à lire le readme est une mauvaise idée.
?????? alors ça c la meilleure !!! à croire que tu aimes repondre aux questions dont la reponse est ds le readme

L'idée est qu'il ne devrait pas y avoir ce genre de questions. Bien sûr, c'est le cas idéal, mais il faut se rapprocher au maximum de ce cas idéal. Ça implique entre autres de la programmation "idiot-proof".

>>>>Argh, un programme d'installation sur une calculatrice! Désolé, mais je trouve ces systémes de programme d'installation totalement contre-intuitifs. Il n'y a qu'à voir Chrono et le nombre de questions "Comment on installe ce truc?" qu'on voit. Intuitif, c'est: on envoie le programme et on le lance, point final.
On envoit le prgm d'installe sur sa calc et on le lance, point final.

Ça reste lourd par rapport à un programme qui fonctionne directement, sans programme d'installation.

donc mon idee de verifier que la personne possede le readme au 1er lancement du prgm sur sa calc est de l'idiot proof donc c'est une bonne idée.

et l'installation de CF reste tres intuitive, toutes les operations sont expliquées clairement !!!! c'est mm plus simple que d'envoyer 5 fichiers sur sa calc venant de 5 rep différents !

Kevin Kofler a écrit :
Argh, un programme d'installation sur une calculatrice! Désolé, mais je trouve ces systémes de programme d'installation totalement contre-intuitifs. Il n'y a qu'à voir Chrono et le nombre de questions "Comment on installe ce truc?" qu'on voit. Intuitif, c'est: on envoie le programme et on le lance, point final.

cf la reponse de liquid

Je t'ai déjà dit que je n'en ai rien à f**tre si tu as une idée pour ça, parce que le simple fait d'essayer d'obliger l'utilisateur à lire le readme est une mauvaise idée.

idem

Mais:
1. DoorsOS n'est pas forcément installé lui non plus.
2. Pourquoi demander de mettre à jour le kernel si on peut tout aussi facilement ignorer complètement la présence du kernel dépassé et utiliser AMS directement.

PreOs n'est pas un kernel depasse...

Ben, dans ce cas, je réitère ce que j'ai déjà dit: ce n'est pas comparable avec le fait de nécessiter un kernel, mais juste avec le fait de nécessiter une version à jour de AMS.

putain... DANS LE CAS OU LE GARS A DOORSOS ET OU LE PROG A BESOIN DE PREOS!!!

Arrête de disputer les faits avec comme "arguments" des "pour moi". Le programme ne marche pas si on n'a pas fait X, donc X est une contrainte pour l'utilisation du programme, quel que soit X. Ici, X est "installer un kernel". C'est un fait.

justement, c'est ca ton probleme, c'est que au lieu de dire des "pour moi", tu assumes que les "pour moi" sont des "pour tout le monde"...

Ça ne change rien au fait que c'est une contrainte.

c aussi une contrainte de devoir telecharger le prog, de lancer graph-link, de brancher son cable... rhalala c vrai qu'en _nostub il te suffit de regarder ta calc, de la mettre de vant l'ecran, de dire "je veux ca:" et pouf, magique, t'as le prog dessus....
en fait non, juste le fait de dire "je veux ca" et de mettre la calc devant l'ecran c aussi une contrainte...

On lui rend un service en ne dépendant d'aucun kernel. Comme ça, ça marchera sans kernel, ça marchera avec DoorsOS et ça marchera avec PreOs. Et exactement de la même manière. Et s'il se retrouve avec exclusivement des programmes qui n'ont pas besoin de kernel, il va bien finir par effacer DoorsOS parce qu'il ne lui sert à rien, donc on lui aura aussi rendu ce service-là. Et en même temps, on l'a libéré complètement du joug des kernels, pas seulement de DoorsOS.

le "joug des kernels" LOL...
pas besoin de re-argumenter sur les avantages kernel/_nostub, ya d'autres topics pour ca... et tu es totalement libre de faire ce qu'il te plait avec TA calc, mais essayer d'imposer tes preferences a tout le monde, c'est bas, pretentieux et egoiste... (et la, vu que c a la mode visiblement ces temps ci, je suppose que tu vas sortir un truc genre "oh! une attaque personnelle!! COMMENT OSES TU??!! (c)" )

Cf. quelques paragraphes au-dessus.

Cf. quelques paragraphes au-dessus.

Bon, je le dis à toi aussi: Intuitif, c'est: on envoie le programme et on le lance, point final.

bah c'est ce que tu fais si t'as deja un kernel...
et si tu l'as pas, bah tu le fait une fois et c bon....

Ça reste lourd par rapport à un programme qui fonctionne directement, sans programme d'installation.

c sur qu'un programme d'install pour backgammon...

Le simple fait qu'il faut PreOs est une contrainte. Et on peut facilement éliminer cette contrainte, donc pourquoi ne pas le faire?

Parceque PreOS a aussi des avantages
[cite]J'ai déjà dit que ton exemple est mauvais. Un exemple comparable avec le tien serait un programme qui ne marche qu'avec un système d'exploitation à jour, par exemple qu'avec AMS 2.04 et supérieures. Le cas du kernel est différent: il s'agit d'un layer supplémentaire, qui ne change rien aux fonctions proposées par le système d'exploitation.[cite]Très bien alors un exemple plus clair: les jeux qui demande une certaine version de Direct X ca te va?

Argh, un programme d'installation sur une calculatrice! Désolé, mais je trouve ces systémes de programme d'installation totalement contre-intuitifs. Il n'y a qu'à voir Chrono et le nombre de questions "Comment on installe ce truc?" qu'on voit. Intuitif, c'est: on envoie le programme et on le lance, point final.

Pour ces gens la c'est pas bien grave : Il arriverons jamais a faire marcher le jeu : Y'a plein de texte dans Chrono Fantasy est s'ils sont incapable de lire les message sur l'écran de leur calculatrice et bien ca veut dire que il seront incapable de comprendre le jeu. CF c'est pas un jeux pour analphabètes.

Je t'ai déjà dit que je n'en ai rien à f**tre si tu as une idée pour ça, parce que le simple fait d'essayer d'obliger l'utilisateur à lire le readme est une mauvaise idée.

Je pense que c'est a l'auteur de choisir, pas toi.

1. DoorsOS n'est pas forcément installé lui non plus. 2. Pourquoi demander de mettre à jour le kernel si on peut tout aussi facilement ignorer complètement la présence du kernel dépassé et utiliser AMS directement.

1. et bien il n'y a qu'a l'installer
2. Parce que l'on perd ces avantages

Arrête de disputer les faits avec comme "arguments" des "pour moi". Le programme ne marche pas si on n'a pas fait X, donc X est une contrainte pour l'utilisation du programme, quel que soit X. Ici, X est "installer un kernel". C'est un fait.

C'est un fait, mais c'est un détail.

?????? alors ça c la meilleure !!! à croire que tu aimes repondre aux questions dont la reponse est ds le readme

Mais bien sur il adore comme ca il dit laisse tomber CF c'est du kernel: Backgammon est bien mieux et en Nostub

L'idée est qu'il ne devrait pas y avoir ce genre de questions. Bien sûr, c'est le cas idéal, mais il faut se rapprocher au maximum de ce cas idéal. Ça implique entre autres de la programmation "idiot-proof".

Pour moi il y a une limite au idiot-proof

Kevin Kofler a écrit :
Le problème est que l'utilisation d'un kernel ne donne pas quelque chose de "mieux que ce qu'il avait avant". Tu peux faire exactement les mêmes choses en _nostub qu'en kernel. Voire plus de choses (installer des TSR par exemple).

Mais a quel prix ? Beaucoup plus de places perdus ! Une impossibilite d'upgrade globable. Des incompatibilites futures potentielles.

Win32 est une plateforme totalement différente de Win16. Le mode kernel est juste un layer supplémentaire et totalement inutile par dessus le vrai système d'exploitation (AMS), qui reste totalement inchangé.

Aucun argument.

Le simple fait qu'il faut PreOs est une contrainte. Et on peut facilement éliminer cette contrainte, donc pourquoi ne pas le faire?

Ce n'est pas une contrainte si c'est distribue avec. De toutes facon, il y a pleins de fichiers annexes. Alors pkoi pas un kernel ?

Penses-tu vraiment que le message passe encore quand on en est à la 3^ème ou 4^ème main? S'il passait, explique-moi pourquoi les personnes en question utilisent encore DoorsOS...

Parce que personne ne veux utiliser mes extensions

J'ai déjà dit que ton exemple est mauvais. Un exemple comparable avec le tien serait un programme qui ne marche qu'avec un système d'exploitation à jour, par exemple qu'avec AMS 2.04 et supérieures. Le cas du kernel est différent: il s'agit d'un layer supplémentaire, qui ne change rien aux fonctions proposées par le système d'exploitation.

Et qui fonctionne partout : c'est plus simple !

FAT Engine propose également une console de débogage. Quant aux autres fonctionnalités que tu cites dans tes questions rhétoriques, ça ne sert pas pour la plupart des jeux 3D.

MORT DE RIRE

Kevin Kofler a écrit :
Je n'aime pas cette attitude d'"obliger" les gens à faire des trucs pour que tes programmes marchent. Il faut qu'il y ait le moins possible de contraintes pour l'utilisateur.
Parce que tu crois que ce qui ont encore DoorsOS sur leur calculatrice sont ceux qui lisent les readmes? Ce sont en général ceux qui reçoivent le programme de 3^ème ou 4^ème main, à travers le câble calc-to-calc.

Une bonne raison d'utiliser lex extensions Preos. Ca empechera l'execution avec de vieux kernels.

Kevin Kofler a écrit :
Argh, un programme d'installation sur une calculatrice! Désolé, mais je trouve ces systémes de programme d'installation totalement contre-intuitifs. Il n'y a qu'à voir Chrono et le nombre de questions "Comment on installe ce truc?" qu'on voit. Intuitif, c'est: on envoie le programme et on le lance, point final.

Y'en a pas eu tant que ca. je m'attendais a bien pire.
Et la plupart c'est a cause du bugue de l'english. AMS merci

Je t'ai déjà dit que je n'en ai rien à f**tre si tu as une idée pour ça, parce que le simple fait d'essayer d'obliger l'utilisateur à lire le readme est une mauvaise idée.

HEIN ? Purquoi ? Imaginerais-tu archive utility sans que l'utilisateur lise le readme ?

Mais:
1. DoorsOS n'est pas forcément installé lui non plus.
2. Pourquoi demander de mettre à jour le kernel si on peut tout aussi facilement ignorer complètement la présence du kernel dépassé et utiliser AMS directement.

Parce que le kernel offre une vrai gestion des ressources partagees.

Arrête de disputer les faits avec comme "arguments" des "pour moi". Le programme ne marche pas si on n'a pas fait X, donc X est une contrainte pour l'utilisation du programme, quel que soit X. Ici, X est "installer un kernel". C'est un fait.

A la rigueur. Mais ttstart en une une aussi.

On lui rend un service en ne dépendant d'aucun kernel. Comme ça, ça marchera sans kernel, ça marchera avec DoorsOS et ça marchera avec PreOs. Et exactement de la même manière. Et s'il se retrouve avec exclusivement des programmes qui n'ont pas besoin de kernel, il va bien finir par effacer DoorsOS parce qu'il ne lui sert à rien, donc on lui aura aussi rendu ce service-là. Et en même temps, on l'a libéré complètement du joug des kernels, pas seulement de DoorsOS.

Et on lui impose de patcher tous ces programmes pour tous les versions future d'AMS.
Grand avantage.
On lui fait perdre plein de place aussi.

Bon, je le dis à toi aussi: Intuitif, c'est: on envoie le programme et on le lance, point final.

Bref, tu dois pas aimer les programmes avec plus d'un fichier. Bref, tu aimes pas ttstart. Deux fichiers, arg !

et il n'aime pas non plus les "DLL nostub", quelle contrainte !!!

Kevin Kofler a écrit :
Bref, rien ne remplace FAT Engine.

Trinity Engine ECRASE Fat engine, et pese largement moins lourd.

Bref, rien ne remplace Trinity Engine.

Trinity Engine ECRASE Fat engine, et pese largement moins lourd.

pt de vue technique et possibilites gfx, certainement (#modestie#)
mais le pbl est qu'il est carrement pas fini, dc tout a fait inutilisable dans un jeu... et la g pas le temps de le finir (ou meme de le continuer), peut etre que pdt les vacances d'ete (cad quand on doit faire notre stage), je trouverai du temps pour le rendre utilisable...

Et alors on s'en fout
FAT Engine c qu'une "demo" qui pese supra lourd.. (jamais vu de raycaster aussi lourd d'ailleur :/)

Trinity est plus qu'une demo

FAT Engine n'est pas une démo, c'est une librairie déjà utilisée par pas mal de jeux. Et elle est aussi grosse pour des raisons de vitesse.