En fait je viens de me rendre compte que cette représentation n'est pas correcte, l'espace CMJN devrait être plus grand, là il donne l'impression d'être entièrement à l'intérieur du RVB alors que ce n'est pas le cas.
Texte tiré de "Computer arts n°63" illustrant la même image :
Cette image est une représentation théorique de l'espace calorimétrique Lab, c'est à dire de l'ensemble des couleurs visibles à l'oeil humain. Les espaces RVB et CMJN ne couvrent qu'une petite partie du gamut Lab. Ils ne partagent pas non plus les mêmes couleurs.
Oui, mais Office est un nom commun en anglais alors que OpenOffice est une marque déposée qui n'appartient pas aux développeurs de OpenOffice.org. Ca m'étonne que leur service légal ait pu laisser passer ça, surtout après l'affaire Mike Rowe...
Ce qui serait drôle, c'est que les détenteurs de la marque OpenOffice leurs cherchent des noises pour préjudice à leur image... :)
C'est quand même amusant qu'une boîte de cette envergure n'ait pas remarqué que le vrai nom de son concurrent est OpenOffice.org et pas OpenOffice. C'est pourtant écrit partout sur le site et c'est même expliqué dans la FAQ :
Why should we say "OpenOffice.org" instead of simply "OpenOffice"?
The trademark for "OpenOffice" belongs to someone else. Therefore we must use "OpenOffice.org" when referring to this open source project and its software.
> Par contre, pour en faire un terminal internet, je le sens moins.
Essaye de trouver une ancienne version d'Opéra pour Windows 3.11, ça marchait pas mal à l'époque et c'était plutôt rapide même sur un 486. Par contre ça risque de pêcher un peu niveau compatibilité avec les normes actuelles du Web, mais ce sera toujours mieux que les anciennes versions de Netscape.
J'en suis à 12 sur le premier avec les tiens :
Day of the Tentacle, Baldur's Gate, DOOM, Half-Life, Quake II, Command & Conquer, Hexen, EverQuest, Starcraft, Earthworm Jim, Crazy Taxi, Z.
Sur le deuxième, j'en suis qu'à 3 :
Q*Bert, Tetris, Zaxxon.
> Mais pour des raisons de sécurité, entre autre la gestion en temps
> réel des informations ce ne peut etre la base du logiciel.
Je ne vois vraiment pas où est le problème. Justement, comme toutes les requêtes passent par le serveur, il a un contrôle total sur ce qui se passe, ce qui n'est pas le cas dans une architecture basée sur de multiples clients accédant à une base de données centralisée. Le serveur sait automatiquement quand un client est en mode modification, il peut donc agir en conséquence pour les autres demandes de modification sur les mêmes données.
> Imaginez que vous retouchiez une facture enregistrée, de
> l'autre bout, le comptable ouvre la piece pour enregistrer les
> dernieres écritures, il se retrouve à rentrer des données incorectes
> car en court de rectification, là un logiciel permet simplement, par le
> réseau, de bloquer l'acces à la piece en conversant avec les autres
> client.
Il suffit de faire ce bloquage côté serveur, je ne vois pas ce qui gêne. Ca me paraît beaucoup plus propre et beaucoup plus sûr que de le faire côté client.
Euh, je ne vois pas bien en quoi un logiciel client permettrait de mieux contrôler les entrées qu'une appli serveur.
Sinon, c'est clair que les applis Web ne sont pas forcément adaptées à toutes les utilisations, mais dans le cas d'une gestion commerciale, je trouve que c'est plutôt bien adapté.
S'il y a besoin d'un serveur pour la base de données, pourquoi ne pas faire une application type Web en PHP, Perl ou Java/JSP ?
Ca éviterai d'avoir quoi que ce soit à installer sur les postes clients (à part un navigateur Web) et de centraliser la maintenance et les mises à jour sur une machine unique.
J'ai encore les sources sur ma machine, ça fait dans les 3 Mo, tu veux que je te les envoie directement par mail ?
J'avais jeté un oeil lorsque l'auteur les avait passé en GPL, mais c'était tout en assembleur et assez imbitable. Pas évident à réécrire dans un langage d'un peu plus haut niveau.
Si tu trouves qu'il y a des choses à améliorer/modifier/corriger, tu peux le proposer en "Game of the Month" sur "The Linux Game Tome" : http://www.happypenguin.org/(...)
J'ai pas essayé, mais j'ai vu que des gens arrivaient à se connecter à Battle.net sur Linux. D'ailleurs dans le "Running Warcraft 3 under Wine - HowTo", l'auteur indique une marche à suivre qui fonctionne chez lui : http://appdb.codeweavers.com/noteview.php?noteId=76&appId=897&a(...)
Déjà, tu peux oublier Fmod étant donné que tu veux faire du développement libre, car malgré ce qui est indiqué sur le site de la librairie, c'est tout sauf libre. Si tu veux une librairie libre multi plates-formes pour le son, il faut choisir OpenAL, c'est ce qu'il y a de mieux.
Ensuite, il faudrait préciser ce que tu veux faire exactement, parce qu'il y a deux approches possibles dans ce que tu indiquais. Soit utiliser une librairie de gestion d'interface graphique, soit utiliser une librairie de développement de jeux vidéo.
Pour la première solution, le cadre d'utilisation concerne surtout des applications utilitaires (applis scientifiques graphiques, modeleurs 3D, logiciels auteurs, etc.) dans lesquelles l'interface est basée sur l'idée de fenêtre. La plupart des librairies type GUI conviennent dans ce cas, elles fournissent en général ce qu'il faut pour la 2D et s'interfacent facilement avec OpenGL pour la 3D.
Exemples : GTK+/gtkglext, WxWidgets, QT, etc.
Pour la seconde solution, le cadre est celui des jeux vidéos et autres types d'applications qui ne sont pas centrées sur le principe de fenêtre, ie. leur mode d'utilisation général est le plein-écran. Elles fournissent en général tous les services associés, comme les timers, la gestion des joysticks/claviers/souris, etc.
Exemples : Allegro/AllegroGL, SDL, Plib, ClanLib, Ogre, Nebula Device, NeoEngine, NeL, Cube Engine, etc.
Si tu veux faire de la 2D, je te conseille Allegro, c'est la plus simple à prendre en main et celle qui simplifie le plus la tâche du programmeur.
Si tu veux faire de la 3D, je te conseille de commencer par OpenGL/Glut/FreeGlut qui est un hybride entre ces deux solutions pour te faire la main. Tu peux suivre en parallèle les didacticiels OpenGL de http://nehe.gamedev.net(...) et de http://www.linuxgraphic.org/(...) (down pour le moment). Ensuite, tu pourras choisir une librairie un peu plus évoluée en connaissance de cause.
Je trouve assez étonnant que tu trouves Allegro moins performant que SDL sur les routines d'affichage. Il utilise l'accélération matérielle 2D, il permet l'utilisation de bitmaps compilés pour accélérer encore les traitements et les routines sont écrites en assembleur optimisé. Les sources de tes tests sont disponibles quelque part ?
A priori, j'aurais dit : C/GTK+, C++/gtkmm ou C++/WxWidgets/GTK++, mais étant donné les contraintes, ça semble ne pas convenir. Alors je propose FreePascal/GTK+.
Respect des contraintes :
Licence LGPL modifiée/GPL
Plus expressif que le C
Moins lourdingue que le C++
Gestion de la mémoire relativement simple
Typage statique fort
Quelques atouts supplémentaires :
- la courbe d'apprentissage est aisée par rapport à la plupart des autres langages cités ici (Java, Python, OCaml, Perl, C#, etc.).
- compatible avec Kylix/Delphi et Turbo Pascal (permet de capitaliser sur l'expérience de ces implémentations et sur du code déjà écrit pour elles)
- les performances des exécutables en termes de vitesse et d'occupation mémoire sont sensiblement identiques à des programmes écrits en C/C++ (voir http://dada.perl.it/shootout/craps_cpumem.html(...))
- supporte la programmation orientée objet, le paradigme étant plutôt bien intégré au langage
- est fourni avec un IDE dédié
- portable sur un très grand nombre de plates-formes et de processeurs
- c'est agréable à programmer (avis très personnel :)
[^] # Re: Dessin Assisté par Ordinateur - Paysagiste
Posté par Frédéric Lopez . En réponse au journal Dessin Assisté par Ordinateur - Paysagiste. Évalué à 1.
http://bourbon.usc.edu:8001/tgif/(...)
[^] # Re: Sortie de Gimp 2.0
Posté par Frédéric Lopez . En réponse à la dépêche Sortie de Gimp 2.0. Évalué à 2.
Une autre image :
http://home.wanadoo.nl/paulschils/09-color-squares/cie-x-rite.jpg(...)
[^] # Re: Sortie de Gimp 2.0
Posté par Frédéric Lopez . En réponse à la dépêche Sortie de Gimp 2.0. Évalué à 2.
Texte tiré de "Computer arts n°63" illustrant la même image :
Cette image est une représentation théorique de l'espace calorimétrique Lab, c'est à dire de l'ensemble des couleurs visibles à l'oeil humain. Les espaces RVB et CMJN ne couvrent qu'une petite partie du gamut Lab. Ils ne partagent pas non plus les mêmes couleurs.
[^] # Re: YAST en GPL
Posté par Frédéric Lopez . En réponse à la dépêche YaST en GPL. Évalué à 3.
http://gnu.dk/software/harmony/harmony_faq.html(...)
[^] # Re: Microsoft parle d'OpenOffice.org
Posté par Frédéric Lopez . En réponse à la dépêche Microsoft parle d'OpenOffice.org. Évalué à 1.
Ce qui serait drôle, c'est que les détenteurs de la marque OpenOffice leurs cherchent des noises pour préjudice à leur image... :)
# Re: Microsoft parle d'OpenOffice.org
Posté par Frédéric Lopez . En réponse à la dépêche Microsoft parle d'OpenOffice.org. Évalué à 2.
http://www.openoffice.org/FAQs/faq-other.html#7(...)
Why should we say "OpenOffice.org" instead of simply "OpenOffice"?
The trademark for "OpenOffice" belongs to someone else. Therefore we must use "OpenOffice.org" when referring to this open source project and its software.
[^] # Re: Havoc Pennington se pose des questions sur les langages du libre
Posté par Frédéric Lopez . En réponse à la dépêche Havoc Pennington se pose des questions sur les langages du libre. Évalué à 1.
[^] # Re: Archéologie comparée
Posté par Frédéric Lopez . En réponse au journal Archéologie comparée. Évalué à 1.
Essaye de trouver une ancienne version d'Opéra pour Windows 3.11, ça marchait pas mal à l'époque et c'était plutôt rapide même sur un 486. Par contre ça risque de pêcher un peu niveau compatibilité avec les normes actuelles du Web, mais ce sera toujours mieux que les anciennes versions de Netscape.
[^] # Re: XAML et l'avenir de GNOME
Posté par Frédéric Lopez . En réponse à la dépêche XAML et l'avenir de GNOME. Évalué à 1.
http://www.gamasutra.com/features/20000802/huebner_pfv.htm(...)
[^] # Re: Sortie d'aMSN 0.90
Posté par Frédéric Lopez . En réponse à la dépêche Sortie d'aMSN 0.90. Évalué à 1.
> que j'ai amsn 0.90 marqué compilé le 17/02/2004
Peut-être parce que la nouvelle en français sur le site de aMSN ne date que du 07/03/2004...
# Re: Mais quel est ce jeu ?
Posté par Frédéric Lopez . En réponse au journal Mais quel est ce jeu ?. Évalué à 1.
http://www.shacknews.com/extras/game/lnc_030404.x(...)
J'en suis à 12 sur le premier avec les tiens :
Day of the Tentacle, Baldur's Gate, DOOM, Half-Life, Quake II, Command & Conquer, Hexen, EverQuest, Starcraft, Earthworm Jim, Crazy Taxi, Z.
Sur le deuxième, j'en suis qu'à 3 :
Q*Bert, Tetris, Zaxxon.
[^] # Re: Programmer oui ! Mais...
Posté par Frédéric Lopez . En réponse au journal Programmer oui ! Mais.... Évalué à 1.
> réel des informations ce ne peut etre la base du logiciel.
Je ne vois vraiment pas où est le problème. Justement, comme toutes les requêtes passent par le serveur, il a un contrôle total sur ce qui se passe, ce qui n'est pas le cas dans une architecture basée sur de multiples clients accédant à une base de données centralisée. Le serveur sait automatiquement quand un client est en mode modification, il peut donc agir en conséquence pour les autres demandes de modification sur les mêmes données.
> Imaginez que vous retouchiez une facture enregistrée, de
> l'autre bout, le comptable ouvre la piece pour enregistrer les
> dernieres écritures, il se retrouve à rentrer des données incorectes
> car en court de rectification, là un logiciel permet simplement, par le
> réseau, de bloquer l'acces à la piece en conversant avec les autres
> client.
Il suffit de faire ce bloquage côté serveur, je ne vois pas ce qui gêne. Ca me paraît beaucoup plus propre et beaucoup plus sûr que de le faire côté client.
[^] # Re: Programmer oui ! Mais...
Posté par Frédéric Lopez . En réponse au journal Programmer oui ! Mais.... Évalué à 1.
Sinon, c'est clair que les applis Web ne sont pas forcément adaptées à toutes les utilisations, mais dans le cas d'une gestion commerciale, je trouve que c'est plutôt bien adapté.
[^] # Re: Programmer oui ! Mais...
Posté par Frédéric Lopez . En réponse au journal Programmer oui ! Mais.... Évalué à 1.
Ca éviterai d'avoir quoi que ce soit à installer sur les postes clients (à part un navigateur Web) et de centraliser la maintenance et les mises à jour sur une machine unique.
[^] # Re: Vieux clone de bomberman: Mr Boom
Posté par Frédéric Lopez . En réponse au journal Vieux clone de bomberman: Mr Boom. Évalué à 1.
[^] # Re: Vieux clone de bomberman: Mr Boom
Posté par Frédéric Lopez . En réponse au journal Vieux clone de bomberman: Mr Boom. Évalué à 2.
Il y a les sources (mrb30asm.zip) et les exécutables (mrboom30.zip).
# Re: Vieux clone de bomberman: Mr Boom
Posté par Frédéric Lopez . En réponse au journal Vieux clone de bomberman: Mr Boom. Évalué à 1.
J'avais jeté un oeil lorsque l'auteur les avait passé en GPL, mais c'était tout en assembleur et assez imbitable. Pas évident à réécrire dans un langage d'un peu plus haut niveau.
[^] # Re: TransGaming trois ans plus tard
Posté par Frédéric Lopez . En réponse à la dépêche TransGaming trois ans plus tard. Évalué à 1.
> A quand un clone libre, pas une version émulée, une version native
> en OpenGL avec des personnages différents (je veux un RMS!!)
Il y a TuxKart dans le genre :
http://tuxkart.sourceforge.net/(...)
Si tu trouves qu'il y a des choses à améliorer/modifier/corriger, tu peux le proposer en "Game of the Month" sur "The Linux Game Tome" :
http://www.happypenguin.org/(...)
[^] # Re: Installer une imprimante sous linux...
Posté par Frédéric Lopez . En réponse au journal Installer une imprimante sous linux.... Évalué à 1.
http://appdb.codeweavers.com/noteview.php?noteId=76&appId=897&a(...)
# Re: Installer une imprimante sous linux...
Posté par Frédéric Lopez . En réponse au journal Installer une imprimante sous linux.... Évalué à 1.
> j'ai gardé pour Warcraft 3 capucépalibre)...
Tu sais que Warcraft 3 fonctionne avec Wine sous Linux ?
# Re: OpenGL ? SDL ? Fmod ?
Posté par Frédéric Lopez . En réponse au journal OpenGL ? SDL ? Fmod ?. Évalué à 1.
Ensuite, il faudrait préciser ce que tu veux faire exactement, parce qu'il y a deux approches possibles dans ce que tu indiquais. Soit utiliser une librairie de gestion d'interface graphique, soit utiliser une librairie de développement de jeux vidéo.
Pour la première solution, le cadre d'utilisation concerne surtout des applications utilitaires (applis scientifiques graphiques, modeleurs 3D, logiciels auteurs, etc.) dans lesquelles l'interface est basée sur l'idée de fenêtre. La plupart des librairies type GUI conviennent dans ce cas, elles fournissent en général ce qu'il faut pour la 2D et s'interfacent facilement avec OpenGL pour la 3D.
Exemples : GTK+/gtkglext, WxWidgets, QT, etc.
Pour la seconde solution, le cadre est celui des jeux vidéos et autres types d'applications qui ne sont pas centrées sur le principe de fenêtre, ie. leur mode d'utilisation général est le plein-écran. Elles fournissent en général tous les services associés, comme les timers, la gestion des joysticks/claviers/souris, etc.
Exemples : Allegro/AllegroGL, SDL, Plib, ClanLib, Ogre, Nebula Device, NeoEngine, NeL, Cube Engine, etc.
Si tu veux faire de la 2D, je te conseille Allegro, c'est la plus simple à prendre en main et celle qui simplifie le plus la tâche du programmeur.
Si tu veux faire de la 3D, je te conseille de commencer par OpenGL/Glut/FreeGlut qui est un hybride entre ces deux solutions pour te faire la main. Tu peux suivre en parallèle les didacticiels OpenGL de http://nehe.gamedev.net(...) et de http://www.linuxgraphic.org/(...) (down pour le moment). Ensuite, tu pourras choisir une librairie un peu plus évoluée en connaissance de cause.
[^] # Re: OpenGL ? SDL ? Fmod ?
Posté par Frédéric Lopez . En réponse au journal OpenGL ? SDL ? Fmod ?. Évalué à 1.
[^] # Re: Microsoft pris dans la toile... chronique d'une mort annoncée
Posté par Frédéric Lopez . En réponse à la dépêche Microsoft pris dans la toile... chronique d'une mort annoncée. Évalué à 3.
# Re: Quel langage choisir.
Posté par Frédéric Lopez . En réponse au journal Quel langage choisir.. Évalué à 1.
http://www.freepascal.org/(...)
http://www.freepascal.org/packages/gtk.html(...)
http://gtk2forpascal.sourceforge.net/(...)
Voir aussi les bindings fpGTK fournis avec le compilateur.
Respect des contraintes :
Licence LGPL modifiée/GPL
Plus expressif que le C
Moins lourdingue que le C++
Gestion de la mémoire relativement simple
Typage statique fort
Quelques atouts supplémentaires :
- la courbe d'apprentissage est aisée par rapport à la plupart des autres langages cités ici (Java, Python, OCaml, Perl, C#, etc.).
- compatible avec Kylix/Delphi et Turbo Pascal (permet de capitaliser sur l'expérience de ces implémentations et sur du code déjà écrit pour elles)
- les performances des exécutables en termes de vitesse et d'occupation mémoire sont sensiblement identiques à des programmes écrits en C/C++ (voir http://dada.perl.it/shootout/craps_cpumem.html(...))
- supporte la programmation orientée objet, le paradigme étant plutôt bien intégré au langage
- est fourni avec un IDE dédié
- portable sur un très grand nombre de plates-formes et de processeurs
- c'est agréable à programmer (avis très personnel :)
Mes 0.02
[^] # Re: The rize of the evil - incomprehensible
Posté par Frédéric Lopez . En réponse au journal The rize of the evil - incomprehensible. Évalué à 1.