[Ancien] Blabla général Making

Une vachon, un mélange de vache et de cochon alors

Non, un cochon c'est ça :
Hum, ça :

Pourquoi ton cochon a un épis sur la tête ?

Et qui c'est que tu traites de cochon d'abord

Je comprends rien au screen. :flag:

Si tu parles des premiers screens c'était des concours de circonstance, en temps normal le programme aurait du planter parce que j'aurais essayé d'accéder à des adresses à lesquelles je n'avais pas le droit mais par grand hasard je suis tombé sur des adresses qui m'étaient autorisées, en l'occurrence celles qui contrôlaient les couleurs (d'où les problèmes de teinte).

Je parlais du dernier.

Ah ben c'était un cochon.

Question existentielle : comment peut-on avoir un code fonctionnel ET compact/aéré/joli etc... en C si ce n'est en réinventant l'objet ?
J'attendrais la rentrée mais je pense qu'il va falloir que je me mette à Java.

Qu'est-ce que tu entends par compact aéré et jolie ? Et aussi le C n'as pas besoin d'avoir d'objets

garywiss6 a écrit:

Et aussi le C n'as pas besoin d'avoir d'objets

Tu viens de me faire penser à Awa

Elle est sur Facebook si tu veux la revoir afin de sortir de ta déprime
Mais profites en d'après mes estimations t'as moins d'1 mois pour qu'elle reparte dans des contrées inconnues pendant des années.
(ceci dit elle se connecte jamais donc bon )

Oui je l'ai sur FB t'inquiète et d'après mes estimations ... Bah elle est déjà en phase "disparaition"

garywiss6 a écrit:

Qu'est-ce que tu entends par compact aéré et jolie ? Et aussi le C n'as pas besoin d'avoir d'objets

Pouvoir avoir une architecture de projet non rigide, on peut très bien tout faire en C mais ça implique des prises de tête abominables et des possibilités de post-modifications quasiment nulles.
Actuellement c'était à propos d'un arbre de scènes pour mon projet de Snake, pouvoir lier l'écran-titre avec le menu d'options, de choix de difficultés, du jeu en lui-même, du menu des scores, ceux-ci accessibles depuis l'écran-titre mais également du menu accessible depuis le jeu, tout ça en pouvant faire des retours débouchant sur la scène parente... Gros gros gros bordel en perspective, tout ça en pensant que chaque scène doit pouvoir se libérer elle-même (malloc()s etc...) en cas de quitte de force (croix rouge quoi), que certaines scènes doivent conserver leurs valeurs en passant d'un scène à l'autre comme le jeu et le menu, que certaines valeurs comme les options doivent être accessible de partout etc...
On pourrait faire ça au moyen d'une liste chaînée représentant un arbre des scènes mais il faudrait faire des #define de partout, rajouter une scène intermédiaire deviendrait très compliqué, le seul moyen de parvenir à avoir un résultat correct serait par la création de pleins de structures avec des méthodes qui leurs seraient associées, du polymorphisme pur quoi, alors autant le faire dans un vrai langage OO.

Le plus simple serait de faire un fichier par scene, et un fichier main qui inclus tout les fichiers du jeu, ensuite chaque scene auront une fonction initialisation, rendement, destruction. Et quand tu veut passer d'une scene à une autre, tu appelle la fonction de destruction de la scene, et tu appelle la fonction d'initialisation de l'autre scene.

C'était mon idée, avec des pointeurs de fonctions et des manips pour les passer en génériques pour ne pas avoir à faire plein d'éditions à chaque nouvelle scène.

Déjà je ne peux pas passer par un système aussi simpliste parce que je suis obligé d'inclure un concept de scène parente et scène fille, par exemple la scène "options" est accessible depuis l'écran-titre et le menu, il faut donc que j'enregistre à partir de quelle scène elle a été lancée, et par exemple la scène "menu" doit être fille de "jeu" car il ne faut pas que les valeurs de "jeu" (le serpent, les objets, les scores etc...) soient supprimés par l'appel du menu. Mais ça une simple liste chaînée suffit, le problème étant de pouvoir manier les scènes de cet arbre de manière propre, les lier entre elles, tout ça est très facile sur papier mais le code est beaucoup plus complexe, on se retrouve à faire des déclarations de structures imbriquées dans tous les sens, j'ai eu beau essayer de raisonner de la manière la plus logique possible à chaque fois je revenais à la même solution : soit recoder complètement l'objet en C, soit passer à un autre langage

Il y a pourtant moyen de coder des choses bien plus compliquées en C ou en n'importe quel langage... Maintenant difficule != efficacité, je sais, mais bon vous parlez tellement comme des connaisseurs que je ne parviens même pas à voir où se situe le problème ^^

Je saurais coder le système en C il n'y a pas de problèmes, mais pas au dépends d'heures entières de recopiage parce que le langage n'est pas assez efficace. Un bon programmeur doit être flemmard, c'est ce que je dis, et présentement j'ai la flemme de faire du recopiage inutile.
Difficulté != efficacité, effectivement.

Si t'as vraiment la flemme, programme en binaire Dixit, Kamikaz, le mec qui parle pour rien ...

Je m'y connait plus trop en sait mais je me souvient à quel point c'est chiant, je pense que tu devrais prendre le Lua comme langage, il me semble que c'est orienté vers les jeux et qu'il établit une compatibilité envers le C ...

Comme langage c'est Java que je veux, c'est tout

Sinon j'ai peut-être trouvé une technique, ça me permettra au moins de sortir ce jeu en C, c'est de carrément déclarer toutes les scènes à part dans un tableau, et de simplement faire pointer les éléments de mon arbre vers les scènes correspondantes, de cette manière je peux accéder facilement à n'importe quelle scène depuis n'importe quelle scène étant donné qu'elles ne sont plus interdépendantes. On perds de l'encapsulation, certes, mais au moins c'est facilement éditable. J'y réfléchi encore mais normalement ça ne devrait pas être prise de tête.

Venez faire du java, le plaisir de coder vous attend, des librairies vous facilitant la vie, idéal pour avoir des résultats rapidement et ne plus avoir à s’embêter avec la gestion de la mémoire, venez faire des listes chainés en faisait simplement un maListe = new ArrayList() et autre maListe.add(monObjet). Venez faire des simple monImage.draw(x,y), le Java c'est le bien !

Ceci était un message des adorateurs du java \o/

J'avais compris, oui

Hehe, on va dominer le moooonde !

Spoiler:

C'est génial !!

Oui passez au java est une bonne solution aussi

Purée, programmez avec un vrai langage de programmation, vous serez pas de mauvais programmeur et vous aurez du taf

[/s4suk3]