Oui enfin, faut voir les jeux que tu veux mettre sur le CD comme jeu.
Si effectivement c'est un jeu qui va faire appel a quelques bonnes ressources, dont de la 3d et du son, cela signifie "ventilation".
C'est un peu ce que est pénible sur les dernières consoles TV du moment elles sont bruyantes.
Mais effectivement, dans le principe du "insert and play", c'est TRES intéressant... si le matériel est détecté.
Je vois deux problèmes majeurs donc :
- le matériel. S'il peut être détecté moyennant une spécification d'un IRQ bizarroide ou autre (ce qui fait déjà perdre tout son intérêt au principe), où stocker ça ?
- la sauvegarde. Si vous dites au joueur que pour sauvegarder sa partie, il doit se munir d'une disquette, il va vous rire au nez. Ou alors, le CD scan les disques présent et se loge quelque part (moyennant confirmation)... beurk.
A 25 fps, c'est surtout sur une télé qu'il y a une impression de fluidité, à cause du flou et de la rémanence. Sur un moniteur, c'est plutôt laid (sauf avec du motion blur, maintenant que certaines cartes permettent de faire ça rapidement).
Personnellement, travaillant toute la journée sur un écran de télé et un moniteur, je "vois" le scintillement et je fais la différence à l'oeil entre un rafraichissement à 25 et à 30.
Je ne suis plus gêné à partir de 65-70Hz non entrelacé.
Mais bon, de manière générale, si un jeu en développement tourne a 300fps, ça laisse de la marge pour mettre des choses dedans. Et Quake est avant tout un moteur que vend Id Software pour faire d'autres jeux. Ils ont donc tout intérêt à ce que ça tourne très vite.
Le nombre de monstres, assez grandement (suivant l'IA).
Graphiquement, il y a plein d'autres détails qui peuvent grandement influer : les textures (leurs mipmaps, leurs tailles et leurs nombres), la complexité des objets (voire même -> sont ils bien fait et optimisés).
Donc oui, globalement, on cherche à aller le plus vite possible pour afficher (et traiter, car derrière un jeu, il y a de l'IA, parfois un moteur physique, du traitement de données divers,...) afin de ne pas pénaliser le jeu (et parceque le hardware graphique existe. S'il y avait des cartes accélératrices de moteur physique, c'est aussi sur cette partie que les optimisations hard iraient.
Tout pareil ici. Le bouton "quitter" ne fonctionne pas.
Pour les blocages lorsque de l'appui sur les cubes, c'est que ça charge, et qu'il n'y a pas d'indicateur de chargement. En attendant un peu, ça se débloque pour moi.
Mais le bouton "quitter" n'est clairement associé à aucun évènement autre que le son qu'il déclenche.
Je crois que les principes énoncés par le document sont "naturels", dans le sens où tout le monde (?) a tendance à programmer comme ça "de base" (avant de se rendre compte, ou d'apprendre, qu'on peut mieux faire).
Pour les petits programmes fait dans un coin et jetables, je pense que c'est bien la bonne méthode. Mais le mot à retenir ici est : jetable.
Développer avec pour coeur un programme développé comme cela, c'est chercher les ennuis à moyen ou long terme.
Globalement, l'article est amusant, quelqu'un qui a déjà programmé s'y retrouve à mon avis :)
Oui c'est bien ça qui me bloque aussi dans le "deux par machine". Cela suppose que le binome bosse sans aucune pause, sans aucune information sur ce qui se passe dans la boite, rien.
Dans une équipe, chacun travaille à son rythme, certains ont besoin d'aller se dégourdir les jambes, il faut penser à se reposer les yeux fréquemment.
Et à moins de tomber sur une paire qui colle bien, je ne vois venir que des soucis.
(c'est sans compter les escapades sur le net, souvent nécessaire à l'information, mais pas toujours :) ).
Comme il est préconisé un changement fréquent de binôme, je vois "globalement" un groupe désynchronisé. Surtout que par expérience, quand on est deux sur un clavier, celui qui a le clavier fait 80% du boulot.
Il ne s'agit pas de mettre deux "coders" par PC, mais de construire le code à deux.
Tu écrits une partie, et lorsqu'elle est finie (ou avant, ou régulièrement) tu la montre à ton binôme qui le lit et le commente.
Tu fais de même pour son code.
Ca se fait aussi en "boucle" (A commente B, B commente C,...).
Cela force à avoir du code "clean". C'est extrêmement pratique, surtout sur du code qui doit durer plus longtemps que la présence du programmeur dans la boite. Il y a un minimum d'assurance que ce qu'il a fait peut être relu, compris et modifié par ses successeurs sur le projet.
Mais Cygwin apporte à la plateforme Windows quelques notions du monde Unix, comme le $HOME, l'arborescence unique,...
Porter Qt directement obligerait les applications à être plus (+) que recompilées. Il faudrait les insérer dans l'environnement Windows, avec ses notions.
La qualité du son dans un jeu est de plus en plus importante. Mais il est vrai qu'y aller à coup de wav (ou dérivés) n'est pas forcément la bonne méthode.
Justement, il y a pas mal de jeux qui utilisent la méthode des .mod-like. Ca permet en plus de faire plein de petites choses intéressantes, comme la musique dépendante du contexte, et cela permet de ne pas trop compter sur les wavetables des cartes sons (souvent tres douteuses);
Si ça ne perce pas, c'est peut-être que c'est parceque ça fait la même chose qu'un sampler couplé a un équipement midi, et que ces équipements sont généralement plus versatiles et avec des circuits de bien meilleures qualités que ceux des cartes son "classiques" sur un ordinateur personnel.
Et comme généralement, ceux qui en ont besoin on déjà bien investi dans ces appareils (qui sont pas donnés...), il ne tiennent peut être pas à utiliser des logiciels qui font assez "jouets" que sont les trackers.
Il est en développement. Inutile d'espérer en faire pour le moment son OS par défaut.
Par contre, d'un point de vue formation, c'est un très bon sujet. En effet, il est très modulaire, les sources sont claires et le noyau de taille modeste.
Donc pour les curieux, y jeter un coup d'oeil n'est pas une perte de temps.
Globalement, je suis d'accord. Je n'ai personnellement rien à faire du contenu de LM Allemagne.
Je pars du principe que si un modérateur a jugé bon de laisser passer la news, et en considérant que la modération entraine implicitement la ligne éditoriale de linuxfr.org, c'est que la news est susceptible d'intéresser une certaine partie des lecteurs du site.
C'est le "ouais mais moi, cette news elle ne m'interesse pas" qui me gênait. Ces commentaires pourraient se retrouver dans toutes les news. Il y aura toujours quelqu'un pour trouver une news donnée d'un intérêt douteux (je mets à part les quelques "ratés" de news sans aucun rapport avec linux qui sont passées quelques fois).
Peut-être faut-il envisager dans DaCode la possibilité aux utilisateurs inscrits de filtrer suivant les types de messages.
Mais aussi, les drivers iSCSI, les protections de données sur les HD, j'en passe...
Mais heureusement, personne ne parle des disques de 1,5Go. Je n'aurais donc pas à expliquer dans les commentaires d'un éventuel tel thread que ça ne m'interesse pas.
[^] # Re: Cool...
Posté par Mokona . En réponse à la dépêche Fabriquer sa propre console de jeu. Évalué à 1.
Si effectivement c'est un jeu qui va faire appel a quelques bonnes ressources, dont de la 3d et du son, cela signifie "ventilation".
C'est un peu ce que est pénible sur les dernières consoles TV du moment elles sont bruyantes.
Mais effectivement, dans le principe du "insert and play", c'est TRES intéressant... si le matériel est détecté.
Je vois deux problèmes majeurs donc :
- le matériel. S'il peut être détecté moyennant une spécification d'un IRQ bizarroide ou autre (ce qui fait déjà perdre tout son intérêt au principe), où stocker ça ?
- la sauvegarde. Si vous dites au joueur que pour sauvegarder sa partie, il doit se munir d'une disquette, il va vous rire au nez. Ou alors, le CD scan les disques présent et se loge quelque part (moyennant confirmation)... beurk.
Des idées ?
[^] # Re: et alors ?
Posté par Mokona . En réponse à la dépêche Benchmarks 3d : Windows Vs Xfree4.1. Évalué à 1.
Il n'est pas en plus garanti qu' "assez" de joueurs achèteraient les jeux.
"assez" étant pour un commercial une valeur variable, mais généralement assez grande.
[^] # Re: C'est quoi les unités ?
Posté par Mokona . En réponse à la dépêche Benchmarks 3d : Windows Vs Xfree4.1. Évalué à 1.
Personnellement, travaillant toute la journée sur un écran de télé et un moniteur, je "vois" le scintillement et je fais la différence à l'oeil entre un rafraichissement à 25 et à 30.
Je ne suis plus gêné à partir de 65-70Hz non entrelacé.
Mais bon, de manière générale, si un jeu en développement tourne a 300fps, ça laisse de la marge pour mettre des choses dedans. Et Quake est avant tout un moteur que vend Id Software pour faire d'autres jeux. Ils ont donc tout intérêt à ce que ça tourne très vite.
[^] # Re: plus de 100 fps cela sert ??
Posté par Mokona . En réponse à la dépêche Benchmarks 3d : Windows Vs Xfree4.1. Évalué à 1.
[^] # Re: plus de 100 fps cela sert ??
Posté par Mokona . En réponse à la dépêche Benchmarks 3d : Windows Vs Xfree4.1. Évalué à 1.
Le nombre de monstres, assez grandement (suivant l'IA).
Graphiquement, il y a plein d'autres détails qui peuvent grandement influer : les textures (leurs mipmaps, leurs tailles et leurs nombres), la complexité des objets (voire même -> sont ils bien fait et optimisés).
Donc oui, globalement, on cherche à aller le plus vite possible pour afficher (et traiter, car derrière un jeu, il y a de l'IA, parfois un moteur physique, du traitement de données divers,...) afin de ne pas pénaliser le jeu (et parceque le hardware graphique existe. S'il y avait des cartes accélératrices de moteur physique, c'est aussi sur cette partie que les optimisations hard iraient.
[^] # Re: ça commence bien ...
Posté par Mokona . En réponse à la dépêche Marketing Windows XP à la gare de Lyon. Évalué à 1.
Pour les blocages lorsque de l'appui sur les cubes, c'est que ça charge, et qu'il n'y a pas d'indicateur de chargement. En attendant un peu, ça se débloque pour moi.
Mais le bouton "quitter" n'est clairement associé à aucun évènement autre que le son qu'il déclenche.
Super.
[^] # Re: tri par OS
Posté par Mokona . En réponse à la dépêche SPO : à quand la Société Protectice des Ordinateurs, pour cause de maltraitance ?. Évalué à 1.
Bon, au final, c'est juste une barette mémoire foireuse qui causait les core dump variés et aléatoires...
Mais frapper sur du matériel, ça va pas non ?
Jamais ! Ca serait synonyme d'abandon.
Faut acheter un punching ball, ou un "wack-it" (très bien ça, un wack-it).
[^] # Re: Réponse idiote...
Posté par Mokona . En réponse à la dépêche Linux sur Dreamcast. Évalué à 1.
Le kit Saturn lui il est (assez) facilement trouvable sur eBay.
[^] # Re: List
Posté par Mokona . En réponse à la dépêche Lancement d'un nouveau magazine de programmation. Évalué à 1.
[^] # Re: Mélanger win et linux et le web ?!?! ARGLLL :(
Posté par Mokona . En réponse à la dépêche Lancement d'un nouveau magazine de programmation. Évalué à 1.
[^] # Re: Idée ? j'ai !
Posté par Mokona . En réponse à la dépêche Lancement d'un nouveau magazine de programmation. Évalué à 1.
Je serai certainement lecteur (au moins du premier numéro, pour me faire une idée concrète).
Ce type de magazine manque en effet (et ce sont ceux que j'affectionne le plus dans ma collecion :) )
[^] # Re: List
Posté par Mokona . En réponse à la dépêche Lancement d'un nouveau magazine de programmation. Évalué à 0.
[^] # Re: List
Posté par Mokona . En réponse à la dépêche Lancement d'un nouveau magazine de programmation. Évalué à 1.
Ca ne fait pas parti de ma collection de vieux magazines.
C'était quelle année ?
[^] # Re: Euh, tu n'as pas bien compris.
Posté par Mokona . En réponse à la dépêche Codage à grande vitesse. Évalué à 1.
(c'est un sujet qui revient bien une fois par mois dans ces "forums")
[^] # Re: coder comme un porc koi
Posté par Mokona . En réponse à la dépêche Codage à grande vitesse. Évalué à 1.
Je crois que les principes énoncés par le document sont "naturels", dans le sens où tout le monde (?) a tendance à programmer comme ça "de base" (avant de se rendre compte, ou d'apprendre, qu'on peut mieux faire).
Pour les petits programmes fait dans un coin et jetables, je pense que c'est bien la bonne méthode. Mais le mot à retenir ici est : jetable.
Développer avec pour coeur un programme développé comme cela, c'est chercher les ennuis à moyen ou long terme.
Globalement, l'article est amusant, quelqu'un qui a déjà programmé s'y retrouve à mon avis :)
[^] # Re: Deux par machine !?!
Posté par Mokona . En réponse à la dépêche eXtreme Programming Explained: Embrace Change. Évalué à 1.
Dans une équipe, chacun travaille à son rythme, certains ont besoin d'aller se dégourdir les jambes, il faut penser à se reposer les yeux fréquemment.
Et à moins de tomber sur une paire qui colle bien, je ne vois venir que des soucis.
(c'est sans compter les escapades sur le net, souvent nécessaire à l'information, mais pas toujours :) ).
Comme il est préconisé un changement fréquent de binôme, je vois "globalement" un groupe désynchronisé. Surtout que par expérience, quand on est deux sur un clavier, celui qui a le clavier fait 80% du boulot.
[^] # Re: Déjà vu ?
Posté par Mokona . En réponse à la dépêche eXtreme Programming Explained: Embrace Change. Évalué à 2.
Tu écrits une partie, et lorsqu'elle est finie (ou avant, ou régulièrement) tu la montre à ton binôme qui le lit et le commente.
Tu fais de même pour son code.
Ca se fait aussi en "boucle" (A commente B, B commente C,...).
Cela force à avoir du code "clean". C'est extrêmement pratique, surtout sur du code qui doit durer plus longtemps que la présence du programmeur dans la boite. Il y a un minimum d'assurance que ce qu'il a fait peut être relu, compris et modifié par ses successeurs sur le projet.
[^] # Re: bof, bof
Posté par Mokona . En réponse à la dépêche KDE sur Windows et BeOS. Évalué à 1.
[^] # Re: Pourquoi une couche en plus ?
Posté par Mokona . En réponse à la dépêche KDE sur Windows et BeOS. Évalué à 1.
Porter Qt directement obligerait les applications à être plus (+) que recompilées. Il faudrait les insérer dans l'environnement Windows, avec ses notions.
En passant par Cygwin, on accélère le portage.
[^] # Re: plus de précisions?
Posté par Mokona . En réponse à la dépêche Clone d'Impulse Tracker sous linux. Évalué à 1.
Justement, il y a pas mal de jeux qui utilisent la méthode des .mod-like. Ca permet en plus de faire plein de petites choses intéressantes, comme la musique dépendante du contexte, et cela permet de ne pas trop compter sur les wavetables des cartes sons (souvent tres douteuses);
Donc c'est utilisé oui.
[^] # Re: plus de précisions?
Posté par Mokona . En réponse à la dépêche Clone d'Impulse Tracker sous linux. Évalué à 1.
Et comme généralement, ceux qui en ont besoin on déjà bien investi dans ces appareils (qui sont pas donnés...), il ne tiennent peut être pas à utiliser des logiciels qui font assez "jouets" que sont les trackers.
[^] # Re: il est comment cet OS
Posté par Mokona . En réponse à la dépêche Interview du créateur d'AtheOS. Évalué à 1.
Par contre, d'un point de vue formation, c'est un très bon sujet. En effet, il est très modulaire, les sources sont claires et le noyau de taille modeste.
Donc pour les curieux, y jeter un coup d'oeil n'est pas une perte de temps.
[^] # Re: mon opinion la d'ssus
Posté par Mokona . En réponse à la dépêche Linux Magazin 05/2001. Évalué à 1.
Je pars du principe que si un modérateur a jugé bon de laisser passer la news, et en considérant que la modération entraine implicitement la ligne éditoriale de linuxfr.org, c'est que la news est susceptible d'intéresser une certaine partie des lecteurs du site.
C'est le "ouais mais moi, cette news elle ne m'interesse pas" qui me gênait. Ces commentaires pourraient se retrouver dans toutes les news. Il y aura toujours quelqu'un pour trouver une news donnée d'un intérêt douteux (je mets à part les quelques "ratés" de news sans aucun rapport avec linux qui sont passées quelques fois).
Peut-être faut-il envisager dans DaCode la possibilité aux utilisateurs inscrits de filtrer suivant les types de messages.
[^] # Re: mon opinion la d'ssus
Posté par Mokona . En réponse à la dépêche Linux Magazin 05/2001. Évalué à 1.
Pas exemple.
Mais aussi, les drivers iSCSI, les protections de données sur les HD, j'en passe...
Mais heureusement, personne ne parle des disques de 1,5Go. Je n'aurais donc pas à expliquer dans les commentaires d'un éventuel tel thread que ça ne m'interesse pas.
[^] # Re: mon opinion la d'ssus
Posté par Mokona . En réponse à la dépêche Linux Magazin 05/2001. Évalué à 1.
Enfin bref.