Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 5 sur 15 PremièrePremière 12345678910111213 ... DernièreDernière
Affichage des résultats 121 à 150 sur 448
  1. #121
    Mhh, je crois avoir à peu près compris. Mais bon, dans tout les cas, on pourrait dire que tout les langages s'inspirent un peu du C, dans le sens où savoir programmer en C aide pour apprendre le C# plus que le contraire non ?
    Bah merde, j'ai plus de signature

  2. #122
    Citation Envoyé par ascdz Voir le message
    Mhh, je crois avoir à peu près compris. Mais bon, dans tout les cas, on pourrait dire que tout les langages s'inspirent un peu du C, dans le sens où savoir programmer en C aide pour apprendre le C# plus que le contraire non ?
    Le C a été créé dans les années 70 et le C# dans les années 2000
    Les langages de programmation c'est un peu comme dans tous les domaines : les nouveaux langages reprennent les points positifs présents dans les anciens langages
    Rust fanboy

  3. #123
    A ceci près que le C, c'est pas un langage objet...
    Citation Envoyé par Snakeshit Voir le message
    Mais comme on me l'a appris dans la Marine, plus les choses sont automatisées, moins ça consomme de cases plus vous en avez de libre pour choses utiles, comme penser à des filles dénudées .

  4. #124
    Mais certains tarés te diront que tu peux faire de l'objet (enfin quelquechose qui revient au même) en C. C'est moche, indigeste, mais c'est applicable.

  5. #125
    ouai ouai, un peu compliqué tout ça. Je vais continuer à apprendre le C tranquillement, tout en suivant les cours de CPC, mais pour apprendre le C#, je verrais plus tard ...
    Bah merde, j'ai plus de signature

  6. #126
    Citation Envoyé par gros_bidule Voir le message
    Mais certains tarés te diront que tu peux faire de l'objet (enfin quelquechose qui revient au même) en C. C'est moche, indigeste, mais c'est applicable.
    Structure + pointeur sur fonction .

  7. #127
    Citation Envoyé par gros_bidule Voir le message
    Mais certains tarés te diront que tu peux faire de l'objet (enfin quelquechose qui revient au même) en C. C'est moche, indigeste, mais c'est applicable.
    Les mécanismes du C++ pour faire de l'orientation objet ne sont pas du tout mystiques et peuvent tout à fait être reproduites en C

    Les fonctions membres statiques du C++ ce sont des simples fonctions
    Les fonctions membres de classes du C++ sont comme des fonctions simples mis à part qu'elles ont un paramètre caché (this)
    Dériver une classe B depuis A c'est comme si B possédait tous les membres de A ; la dérivation virtuelle d'une classe B depuis A c'est comme si B possédait un pointeur vers A
    etc.

    J'appelle pas ça "moche et indigeste"
    Rust fanboy

  8. #128
    Implémenter ce qui tu dis est déjà indigeste
    Si le langage C++ est "orienté objet", ce n'est pas sans raison.
    Enfin bon, c'est un débat qu'on connais tout.

  9. #129
    En théorie, on peut tout faire sous n'importe quelle langage.
    Mais, selon la situation, un outil est plus adapté qu'un autre.

    http://igm.univ-mlv.fr/~paumier/C/C1...s%20du%20C.pdf

  10. #130
    Mince, les mecs qui codent le noyau Linux en C ont tort, ils auraient du tout faire en OCaml

    (franchement si tu expliques les trucs contenus dans ce PDF dans une mailing list de code gurus ils vont te prendre pour un troll)

    Je suis pas du tout un supporter acharné du C, mais les arguments présentés sont un peu bidons
    Rust fanboy

  11. #131
    Citation Envoyé par Tomaka17 Voir le message
    Mince, les mecs qui codent le noyau Linux en C ont tort, ils auraient du tout faire en OCaml

    (franchement si tu expliques les trucs contenus dans ce PDF dans une mailing list de code gurus ils vont te prendre pour un troll)

    Je suis pas du tout un supporter acharné du C, mais les arguments présentés sont un peu bidons
    Clairement, tout est à charge et il enfonce des portes ouvertes.
    Il fait des typedef sur des struct .
    Il reproche au C de ne pas être un langage fonctionnel et objet.
    ...
    Et ocaml semble être le langage parfait .

    Par contre l'idée de base de bien choisir son outil, oui pas de souci.

  12. #132
    Au fait L.F.S tu vas nous fournir un game design document prochainement pour savoir quelles seront les features du jeu ?

  13. #133
    Mince, les mecs qui codent le noyau Linux en C ont tort, ils auraient du tout faire en OCaml
    L'auteur du PDF est "bon" dans tout ce qui est C et le code système.
    Il a fait ce cours pour expliquer que le langage C n'est pas parfait (il n'a pas évoqué le c++ ou c#), comme n'importe quel autre langage (Java, Python, Perl, ect ect...). En bref, qu'il faut savoir changer d'outil et de ne pas se fixer sur une seule technologie.

    Mais sans troller, vous tombez tous dans le piège .


    EDIT pour en bas :
    Ce à quoi je réponds qu'il vaut mieux utiliser un langage que l'on maitrise (en général c'est aussi celui que l'on préfère) plutôt que d'en utiliser un que l'on connaît à peine, ce qui fera perdre beaucoup de temps et créera plus de bugs
    Il est sûr que si on connait qu'un seul langage ou qu'on en maîtrise un très bien, autant l'utiliser. Mais ca sera très casse tête de faire, par exemple, de la programmation objet avec du C (le vrai), qu'avec du Java ou C#.
    M'enfin, c'est un peu le problème des informaticiens (dont moi) d'avoir du mal à sortir de sa techno d'amour :s.
    Dernière modification par Louck ; 29/10/2011 à 17h16.

  14. #134
    Ton PDF dit qu'il ne faut pas toujours utiliser le langage que l'on préfère mais plutôt celui le plus approprié

    Ce à quoi je réponds qu'il vaut mieux utiliser un langage que l'on maitrise (en général c'est aussi celui que l'on préfère) plutôt que d'en utiliser un que l'on connaît à peine, ce qui fera perdre beaucoup de temps et créera plus de bugs
    Évidemment tu vas pas coder un jeu vidéo en PHP ou un système d'exploitation en Javascript même si tu maitrises ces langages, mais ça ça coule de source
    Rust fanboy

  15. #135
    Tiens une petite question par rapport aux limites du C# pour la programmation de jeu.

    Ben... tout est dans ma première phrase en fait.
    Des exemples de ce que l'on peut faire et ne pas faire ?

    Les jeux Vlambeer, Super Crate Box et Serious Sam - The Random Encouters je présume que c'est bon non, vu le niveau de technicité inexistant ? (j'ai pas dis artistique hein)
    Plants vs Zombie peut-être aussi non ?

    Par contre pas du FPS AAA nextgen tsouintsouin parce que si j'ai bien compris le langage sera trop lent par rapport à du C++ ?

  16. #136
    Citation Envoyé par Li Kao Voir le message
    Tiens une petite question par rapport aux limites du C# pour la programmation de jeu.

    Ben... tout est dans ma première phrase en fait.
    Des exemples de ce que l'on peut faire et ne pas faire ?
    Il y a débat à ce sujet. Les benchmarks semblent indiquer que la perte de performance dans un langage managé type C# est marginale par rapport au C++, sauf pour les projets les plus hardcore de chez hardcore.

    Peut-on faire BF3 ou Crysis en C# avec des performances correctes sur un bon PC de 2011 ? Pas sûr (en même temps, personne n'a jamais essayé). Peut-on faire Doom 3 ? Certainement. Je suis loin d'être un grand programmeur et j'ai réussi à coder un moteur 3D simple mais parallax mappé et éclairé par pixel. Un mec plus doué que moi pourrait certainement créer un jeu du niveau (graphique) de Portal 2.

    Simplement, les gens qui ont le courage et les compétences pour se lancer dans ce genre de projets sont généralement habitués au C++. Ce sont les "amateurs" qui se tournent vers XNA, et ils créent surtout des jeux casual 2D. Pas à cause de XNA, mais parce qu'ils sont amateurs.

    Pour info, Magicka a été fait avec XNA. Ca aussi :

  17. #137
    Citation Envoyé par L-F. Sébum Voir le message
    Il y a débat à ce sujet. Les benchmarks semblent indiquer que la perte de performance dans un langage managé type C# est marginale par rapport au C++, sauf pour les projets les plus hardcore de chez hardcore.

    Peut-on faire BF3 ou Crysis en C# avec des performances correctes sur un bon PC de 2011 ? Pas sûr (en même temps, personne n'a jamais essayé). Peut-on faire Doom 3 ? Certainement. Je suis loin d'être un grand programmeur et j'ai réussi à coder un moteur 3D simple mais parallax mappé et éclairé par pixel. Un mec plus doué que moi pourrait certainement créer un jeu du niveau (graphique) de Portal 2.

    Simplement, les gens qui ont le courage et les compétences pour se lancer dans ce genre de projets sont généralement habitués au C++. Ce sont les "amateurs" qui se tournent vers XNA, et ils créent surtout des jeux casual 2D. Pas à cause de XNA, mais parce qu'ils sont amateurs.

    Pour info, Magicka a été fait avec XNA. Ca aussi :
    Mais XNA impose le C# ou pas ?

  18. #138
    Citation Envoyé par olih Voir le message
    Mais XNA impose le C# ou pas ?
    Oui je crois.


  19. #139
    Officiellement XNA ne supporte que le C#. En pratique tu peux utiliser d'autres langages mais tu paumes quasiment tous les bénéfices qui vont avec (en gros le workflow facile d'accès).

    Je crois que le principal souci du C# du côté des perfs, c'est l'optimisation.
    Le principe du C++ (et du C), c'est que tu maîtrises absolument tout, tu "ne payes pas pour ce que tu n'utilises pas". Donc tu vas en baver, mais tu es sûr que si tu te retrouves avec des bouts de code inutiles dans le programme final, c'est ta faute. Ça n'est pas forcément le cas en C# ou autre langage "managé".
    Ça explique en partie le fait que Magicka, par exemple, rame beaucoup par rapport à ce qu'il affiche. D'un autre côté, il serait probablement optimisable jusqu'à atteindre les perfs d'un programme équivalent en C++. Mais ça demanderait beaucoup de boulot, et tout le bénéfice de l'utilisation d'XNA serait perdu.

    Pour les possibilités de gameplay, tu peux faire ce que tu veux, ça ne dépend pas du langage. Pour les features graphiques, aucun souci non plus, Microsoft a tout intérêt à ce que tu puisses exploiter au mieux DirectX.


    En tout cas ça fait plaisir de voir cette rubrique, je suis curieux de la voir évoluer.


  20. #140
    Hé ben, je suis de plus en plus paumé en lisant vos posts
    Bah merde, j'ai plus de signature

  21. #141
    Fichus barbus.
    On commençait tranquillement la vie avec la pomme qui tombe de l'arbre.... et les voilà qui arrivent avec leur big-bang, théorie des cordes et canards de l'espace
    Normalement les tutoriels seront dans des sujets dédiés ? Sinon on aura droit à un gros coup de karcher ?

  22. #142
    Rho. Bon disons que XNA c'est vachement bien pour commencer, même de zéro, et c'est tout.

    Mais oui, je dois dire qu'on (moi le premier) a un peu tout salopé le beau thread de Sébum, un nouveau par quinzaine serait pas de refus...


  23. #143
    XNA est aussi sympa pour le multiplateforme PC / XBox360 / Windows Phone (enfin apparemment, jamais tenté le coup). Disons que des tutos made in Bilou's Corporation montrent assez bien comment penser un projet pour le multiplateforme, et comment justement exporter un projet PC vers une des deux autres plateformes.
    Franchement, c'est tentant.

  24. #144
    M'enfin, c'est très intéressant ces discussions, même pour les beginners, ça permet un peu de se situer au niveau de tout ces codes. Après, si c'est pas le bon topic, ça a toujours un certain rapport
    Bah merde, j'ai plus de signature

  25. #145
    Citation Envoyé par Tomaka17 Voir le message
    Évidemment tu vas pas coder un jeu vidéo en PHP ou un système d'exploitation en Javascript même si tu maitrises ces langages, mais ça ça coule de source
    Linux en javascript
    Time doesn't exist. Clocks exist.

  26. #146
    Citation Envoyé par messe sans cause Voir le message
    Non, un émulateur x86 en javascript.
    Dans le même style un décodeur h264 en javascript

  27. #147
    Rha mais en plus ce truc me dégoute
    Je suis justement en train de coder un truc un peu complexe en Javascript, et je me suis fait chier avec plein de fonctions du DOM pour modifier le moins de HTML possible, pour "éviter que ce soit lent"
    La prochaine fois j'irai en mode gros bourrin

    Sinon il s'est quand même bien fait chier le mec qui a fait l'émulateur
    Si t'as les connaissances pour faire ça c'est pas forcément super difficile, mais la quantité de boulot est assez gigantesque
    (il n'a pas précisé ça dans sa FAQ, mais je pense qu'il n'y a pas de mode virtuel (16bits dans du 32bits) ? car sinon chapeau)
    Rust fanboy

  28. #148
    Citation Envoyé par Tomaka17 Voir le message
    Rha mais en plus ce truc me dégoute
    Je suis justement en train de coder un truc un peu complexe en Javascript, et je me suis fait chier avec plein de fonctions du DOM pour modifier le moins de HTML possible, pour "éviter que ce soit lent"
    La prochaine fois j'irai en mode gros bourrin

    Sinon il s'est quand même bien fait chier le mec qui a fait l'émulateur
    Si t'as les connaissances pour faire ça c'est pas forcément super difficile, mais la quantité de boulot est assez gigantesque
    (il n'a pas précisé ça dans sa FAQ, mais je pense qu'il n'y a pas de mode virtuel (16bits dans du 32bits) ? car sinon chapeau)
    Bin Fabrice Bellard, le créateur de qemu et de ffmepg.
    Une légende quoi.

    PS: il y a plus d'info dans les tech notes.

  29. #149
    Ah ouai quand même

    Les technical notes sont un peu vides par contre, j'aimerais bien savoir pourquoi il n'y a pas de FPU par exemple, ça me paraît simple à faire comparé au reste
    Un peu comme si tu disais "j'ai construit une maison tout seul mais je n'ai pas mis de poignées aux portes"


    Sinon à quand un émulateur en langage Ook ?

    ---------- Post added at 20h58 ---------- Previous post was at 20h33 ----------

    Rha il a gagné l'international obfuscated C contest en 2001, rien que ça ça vaut la reconnaissance éternelle
    Dernière modification par Tomaka17 ; 31/10/2011 à 21h48.
    Rust fanboy

  30. #150
    Citation Envoyé par messe sans cause Voir le message
    C'est juste über ce truc.

    Tomaka :

    added 16 bit & segmentation support

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •