Attention, newbie en vue - Page 2

Kevin Kofler a écrit :
J'aime bien la TICT parce que:
- TI-Chess mon jeu préféré sur TI-89/92+.
- La TICT ne programme qu'en _nostub.
- Les programmes de la TICT ne plantent pratiquement jamais! - Thomas Nussbaumer a élévé Sebastian et moi à l'état d'admin sur le forum de la TICT.

lol j'avais cru lire : "Thomas Nussbaumer a élévé Sebastian et moi "

Orion_ (post n°10): "Kevin Aime la TICT on dirait, il fait de la pub pour TTOOLS, FAT ENGINE, EXT GRAPH, TICHESS dés qu'il peut"
A-t-il tort ?
Tant que j'y suis, je fais de la pub pour d'autres programmes de TICT:
TI-Chess, TI-Minesweeper, TI-TimeWaste, TI-Tiltmaze, TI-LIDS, TI-Connect 4-5, TIGCC Tools Suite, FAT-Engine, ExtGraph, une implémentation du Jeu de la Vie... Allez voir tict.ticalc.org pour le reste...
Dans la TIGCC Tools Suite, il y a des outils de debug qui sont intéressants (tthdex, tthedit). Des modifications y seront apportées cet été. D'ailleurs tthdex ne sera plus accessible au public...

Vark post n°13: " le fat engine n'a aucun intéret d'ailleurs
ils auraient mieux fait de faire un jeu avec parce-que faire leur truc sous forme de lib c gros, c chiant et en plus ça n'apprends rien du raycasting ... "
Si, ça apprend quelque chose: faire tourner un jeu correct, avec un framerate correct (plus de 3 FPS), sur des machines très peu puissantes que sont les TI-89/92+/V200... Bien sûr, il faut que tu te donnes la peine de lire le source, pour savoir si ça apprend quelque chose du raycasting ou pas...
En plus tu n'as pas compris l'intérêt du FAT-Engine, donc arrête de dire n'importe quoi. Il me semble que l'intérêt du FAT-Engine est d'avoir un SDK pour une classe de jeux, les First Person Shooter. Bien entendu, FAT-Engine n'est pas parfait, mais il est parfaitement stable. Il a servi un peu pour l'implémentation des DLL dans TIGCC (pas de polémiques sur les DLL vs. lib kernel SVP).

Faire un SDK, cela évite à chacun de faire son truc dans son coin, de réinventer la roue à chaque fois, de ne pas partager avec les autres. J'ai l'impression que les utilisateurs étrangers de TIGCC sont plus partageurs que certains français...


Vark (post n°16): "C'est vrai que tu es fort en mauvaise foi, je suis sûr que tu pourrait rivaliser avec RAGE2000"
Je ne pense pas. Kevin est plus objectif, il fait moins de flood. Et RAGE2000 a d'autres défauts que je ne citerai pas...

Faites des trucs du genre de FAT-Engine. Après on discutera.
(PpHd est exclu de cette critique, il est capable de faire un truc de la classe de FAT-Engine. sBibi aussi, je pense).


PS: post n°30 (Samuel): je pense que ce ne serait pas complètement impossible. Thomas est nettement plus âgé que Sebastian, Kevin et moi (il a commencé la programmation en 1984, je n'étais même pas né)...


Et arrêtez ces posts à la con, avec du texte en blanc !

Pour le debat Gen/_X_ .. j'affûte mes lames et j'ai tout mon temps

XDanger : si je critique le fat engine c'est pas pour dire que c un prog de merde mais pour dire que j'en ai rien à foutre d'avoir un moteur clés en mains pour faire un jeu ! ce qui m'interrsesse c la conception du moteur et je préfère nettement faire une merde tout seul qu'un truc puissant et lourd auquel j'aurais juste modifiés quelques parties !!

(PpHd est exclu de cette critique, il est capable de faire un truc de la classe de FAT-Engine. sBibi aussi, je pense).

Clair ! et largement en plus !

XDanger a écrit :
Tant que j'y suis, je fais de la pub pour d'autres programmes de TICT: TI-Chess, TI-Minesweeper, TI-TimeWaste, TI-Tiltmaze, TI-LIDS, TI-Connect 4-5, TIGCC Tools Suite, FAT-Engine, ExtGraph, une implémentation du Jeu de la Vie...

c'est vraiment déébile de dire que tous les programme de la tict sont bon parce que fait par la tict

Je ne pense pas. Kevin est plus objectif, il fait moins de flood. Et RAGE2000 a d'autres défauts que je ne citerai pas...

en tout cas il a pas l'air d'etre aigris comme toi...

Faites des trucs du genre de FAT-Engine. Après on discutera. (PpHd est exclu de cette critique, il est capable de faire un truc de la classe de FAT-Engine. sBibi aussi, je pense).

lol: je discutte qu'avec des gens de mon niveau...:
Arrete de peter plus haut que ton cul, t'es qu'n prétezntieux

Et arrêtez ces posts à la con, avec du texte en blanc !

t'es vraiment aigris toi..

c'est le topic de l'amitié ici.
Allez, on se calme...

Oué Mais moi j'aime bien les textes blancs

heu .. ya qqc de dure a faire dans le fat machin ?

TiMad a écrit :
Pour le debat Gen/_X_ .. j'affûte mes lames et j'ai tout mon temps

Vark: si c'est la conception du moteur qui t'intéresse, d'accord. Je n'ai rien dit, je te présente mes excuses.

jibax:
> c'est vraiment débile de dire que tous les programme de la TICT sont bons parce que faits par la TICT
Est-ce que Kevin ou moi avons dit ça ? En tout cas, tu reconnaîtras que les programmes de la TICT sont peu ou pas buggés. Et s'ils contiennent un bug, ce n'est pas forcément de leur faute (c'était le cas de TICT-Explorer et de ttbatt, basés sur une routine que nous n'avons pas faite nous-même, et qui plante quand le niveau des piles est trop bas, ce bug a été corrigé depuis).

> lol: je ne discute qu'avec des gens de mon niveau...
Sauf que je ne suis pas capable de faire un truc du niveau de FAT-Engine ! Je ne connais pas l'algorithmique qui permet de faire un truc pareil. C'est un des seuls softs de TICT où:
- je n'ai pas touché à la moindre ligne de code (et je ne toucherai probablement à aucune).
- je n'ai fait aucune suggestion.

Je ne suis pas vraiment impressionné par la qualité et la complexité de tes propres programmes (à part éventuellement le snake, je n'en ai jamais fait et il y en a déjà tant de bons sur Internet). La plupart de tes programmes sont faits en BASIC (ça reste du BASIC, même avec FLib)...

Excuses accéptées
Et je peux t'affirmer que faire un raycast de base (c sûr que celui de la tict est d'un niveau supérieur qd même ) n'a rien de difficile !

Un jour peut etre certains newbees apprendrons que ce qui est difficile dans la programmation n'est pas dapprendre le langage de prog, mais de faire ses propres algo...
Par consequent, un prog basic peut avoir plus de merite qu'un prog C....

XDanger
Est-ce que Kevin ou moi avons dit ça ? En tout cas, tu reconnaîtras que les programmes de la TICT sont peu ou pas buggés. Et s'ils contiennent un bug, ce n'est pas forcément de leur faute (c'était le cas de TICT-Explorer et de ttbatt, basés sur une routine que nous n'avons pas faite nous-même, et qui plante quand le niveau des piles est trop bas, ce bug a été corrigé depuis).

je reconnais qu'ils ne sont pas buggués mais c'est pas parcequ'un programme n'est pas bugguéqu'il est bon et donc qu'il faut faire de la pub pour lui ( sinon la plupart des programmes sur ticalc seraient des hit, ce qui est loin d'etre le cas )

C'est un des seuls softs de TICT où:
- je n'ai pas touché à la moindre ligne de code (et je ne toucherai probablement à aucune).
- je n'ai fait aucune suggestion.

tu te la pete u n peu la...

Je ne suis pas vraiment impressionné par la qualité et la complexité de tes propres programmes (à part éventuellement le snake, je n'en ai jamais fait et il y en a déjà tant de bons sur Internet). La plupart de tes programmes sont faits en BASIC (ça reste du BASIC, même avec FLib)...

je ne trouve pas le C tres différent que le basic: on ne doit pas mépriser le basic
et je n'ai jamais dit que j'étais un pro de la programmation et j'en est donc rien a fouttre de ton avis sur mes qualités de programmeur. Contrairement a toi , je ne recherche pas de reconnaissance (d'ailleur c'est pas parceque t'as fais trois ligne de code dans des programme de la tict que tu dois te la péter)

ceci dit mon snake est bien mieux que tous ceux existant sur ticalc donc , tu parle un peu vite (ou tu ne l'as pas éssayé)

On dit "très différent du Basic"

Euh on se calme ... ???

ouais c'est parcequ'au debut je voulais direplus facile que...

ceci dit pollux a le meme avis que moi ...

Putin c la guerre ici!

Samuel Labitte a écrit :
lol j'avais cru lire : "Thomas Nussbaumer a élévé Sebastian et moi "

Quel esprit tordu.

XDanger
a écrit : D'ailleurs tthdex ne sera plus accessible au public...

Mais est-ce vraiment si dangereux que l'on ne puisse pas diffuser la source avec des #defines à mettre pour les trucs dangereux?

Et à la limite, si tu fais qqch. dont tu ne veux pas que le grand public voie la source, ni qu'il possède le binaire (genre écriture en FlashROM), mets qqch. du genre:
#ifdef ENABLE_WRITE_TO_FLASH
#include "writetoflash.h"
#endif
et évidemment tu ne distribues pas writetoflash.h!!!

"est-ce vraiment si dangereux que l'on ne puisse pas"

zdr a écrit :
"est-ce vraiment si dangereux que l'on ne puisse pas"

Oups... Désolé pour la faute de français.
J'ai mis ce que tu viens de me dire de mettre. J'espère que c'est correct.

Kevin Kofler a écrit :
Et à la limite, si tu fais qqch. dont tu ne veux pas que le grand public voie la source, ni qu'il possède le binaire (genre écriture en FlashROM), mets qqch. du genre:
#ifdef ENABLE_WRITE_TO_FLASH
#include "writetoflash.h"
#endif
et évidemment tu ne distribues pas writetoflash.h!!!

Z'êtes complétement fou. Vous verrez l'effet que ça fait de pas voir sa calc se rallumer. Une déprotection ne doit être utilisée que très occasionnellement.

Tu n'as pas bien compris ce que j'ai dit!

J'ai dit de mettre ça dans un header qu'on ne distribue pas, et de ne pas distribuer le binaire compilé avec cette option!

Je voulais dire que même pour un usage personnel ça pouvait mal tourner.

Vous pouvez dire ce que vous voulez cacher ?
Et cette chose dangereuse sert à quoi ?

Thibaut a écrit :
Vous pouvez dire ce que vous voulez cacher ? Et cette chose dangereuse sert à quoi ?

A rendre des calculatrices complètement inutilisables... je suis d'accord avec ExtendeD, c'est trop dangereux.

Oué, attend on dirait Kevin (Q : "à quoi sert le mode kernel ?" R : "ça sert au gens qui n'ont pas compris que c'est un mode complètement obsolète et inutile")

Tu ne réponds pas à ma question.

ba c une routine de déprotection de flash ss doute

Je crois que vous parlez dans le vent... KK parle au conditionnel!

En effet, je ne sais pas vraiment ce qu'est la "chose dangereuse" dont parle XDanger. Mais à mon avis, il y a une seule chose qui mérite un traîtement spécial (comme celui que je propose dans le message 47): la déprotection de la FlashROM (parce que, comme le disent justement ExtendeD et Nitro, c'est très dangereux). Mais le système que je propose dans le message 47 peut être appliqué à n'importe quelle fonctionnalité jugée dangereuse. Donc si XDanger pense par exemple qu'il est dangereux de permettre de libérer un bloc au hasard, on peut mettre:
#ifdef ENABLE_FREE_HANDLES
#include "freehandles.h"
#endif
et ne pas distribuer freehandles.h, ni la version compilée avec ENABLE_FREE_HANDLES. Mais je pense que dans ce cas, la précaution est excessive. Je retiens qu'ici, il est suffisant comme précaution de mettre:
#ifdef ENABLE_FREE_HANDLES
/* code pour libérer les handles */
#endif
et de distribuer la source complète, mais en binaire seulement la version compilée sans ENABLE_FREE_HANDLES. Mais c'est mon avis personnel.

Je n'ai pas la moindre intention d'écrire dans la Flash ou de la déprotéger (de toute façon je ne sais pas comment faire, Zeljko Juric m'a montré récemment que ce que je pensais faire ne marche pas) ! Tout au plus, la voir en dump (si je ne me trompe, la machine ne se plante pas dans ce cas-là).
Par contre, Thomas Nussbaumer et moi avons décidé d'inclure:
- la libération des handles (je ne considère pas ceci comme très dangereux car les handles vitaux seront marqués comme tels et ne pourront être effacés).
- la modification de la RAM (ceci est beaucoup plus dangereux).
- la modification de certaines variables système (les temps d'auto-repeat, OSFastArrows...).

Bien entendu, l'utilisateur restera seul responsable de ce qui arrive à sa machine s'il fait n'importe quoi... De toute façon, tthdex est plutôt un outil de debug, qui deveait être utilisé principalement sur VTI.