Civilisation - Page 11

Oui, mais ttstart est moins pratique à utiliser (sauf si on a autostart avec)

bah pour tester sous VTI autant ne pas compresser du tout c'est plus simple et plus rapide

Oui, mais ttstart est moins pratique à utiliser (sauf si on a autostart avec)

alors ça prend moins de place de faire un programme basique qui fait ttstart("myprog") que d'utiliser le lanceur.

#301> Si je compresse pas du tout, il faut je teste avec un kernel (à cause des 24Ko). Certes c'est pas la mort d'avoir un kernel, mais je crois que si les jeux Kernels sont souvent bogués c'est parceque le kernel avec lequel ils ont été testés interceptait les erreurs qui n'ont donc pas été corrigées, et du coup ça plante sous tout les autres Kernels (voir même sous toutes les autres versions du kernel). Donc par respect de la déontologie, je prefere tester mon prog sans kernel, maintenant qu'il est en nostub.

Quand un kernel intercepte une erreur le programme s'arrete quand même c'est juste que la calculatrice n'est pas complètement bloquée. Si les progs kernel sont buggés c'est parce qu'en général ils sont plus anciens qui n'ont pas étés mis a jour depuis longtemps et qu'a l'époque la stabilité n'était pas une très grosse priorité.

Peut-être aussi le fait que les anciens programmes ont été écrits surtout en ASM fait qu'ils sont plus buggés parce que c'est bien plus facile de bugger un prog ASM qu'un prog C..

Pour revenir à nos moutons (civilisation), j'ai uploadé une nouvelle version, _Nostub, avec tout un tas de chose en plus et qui devrait bien marcher sous 92+/V200, et p'tet même chez St Patric (?)
La principale nouveauté et la gestion des unités, impliquants celle de l'ombre, des résaux (routes)...


J'en profite pour relancer un appel à ceux que ça interresse : ce projet risque de tomber à l'abandon, je ne vais plus pouvoir m'en occuper pendant deux ans de prépa, alors si quelqun veut reprendre le flambeau...

mais si tu pourras, ya tjs le tps en prepa

Ca suffit pas d'avoir le temps si j'ai plus d'ordi...

Bah y a gtc

Non, "y a" pas.

GTC qui n'est pas compatible avec TIGCC...
Mais c'est vrai, C bien ferait ici de GTC la seule utilisation intéressante de GTC, qui est clairement inférieure pour toutes les autres à TIGCC...
Ceci dit, j'attends de voir on-calc à la fois:
* TIGCCLIB de TIGCC 0.95;
* d'autres choses dans TIGCCLIB qui vont rajouter des centaines de KB à TIGCCLIB (ExtGraph + d'autres headers);
* la doc de TIGCC 0.95 presque complète (des trucs sont sans utilité avec GTC) - il reste encore des centaines de ROM_CALLs à ajouter, ça va augmenter de centaines de KB la taille de la doc.

Je ne suis pas sûr que même avec PedroM, ça soit possible... GTC ne rattrapera jamais TIGCC.

on dirais que tu prends un malin plaisir à dire ça

Je ne suis pas sûr que même avec PedroM, ça soit possible... GTC ne rattrapera jamais TIGCC.

Il n'a pas tort.

Je ne vois aucun problème à dire la vérité...

Peut-être que le but n'est pas de "rattraper" TIGCC ...

#inique#

Le but n'est certainement pas non plus de faire un truc pas bien et incomplet, n'est-ce pas ?

Ah euh nan pas de sous entendus, je voulais juste dire que Pollux a tout a fait le droit de faire son compilo sans pour autant considérer que le but est de faire la même chose que TIGCC.
Suite de la discussion -> topics/18104-gtc-un-tigcc-sur-votre-calculatrice

Ximoon
: Ah euh nan pas de sous entendus, je voulais juste dire que Pollux a tout a fait le droit de faire son compilo sans pour autant considérer que le but est de faire la même chose que TIGCC.

Et tout ceci ne serait pas un problème s'il n'y avait pas un certain Thibaut qui ne peut pas s'empêcher de comparer GTC à TIGCC (alors que Pollux lui-même dit ne pas vouloir concurrencer TIGCC) pour la seule raison qu'il déteste mon équipe.

PS: Désolé, mais je n'ai aucune envie de remonter le topic à la con de Thibaut.

Il a été remonté hier tu peux y aller

XDanger :
GTC qui n'est pas compatible avec TIGCC...

pas tres loin de 90% si mes souvenirs sont bons, et ça lui permet au moins de coder un minimum, ce qui est mieux que rien

Mais c'est vrai, C bien ferait ici de GTC la seule utilisation intéressante de GTC, qui est clairement inférieure pour toutes les autres à TIGCC...

d'ailleurs, ayant testé gtc, tu es tres bien placé pour dire ça

Ceci dit, j'attends de voir on-calc à la fois:
* TIGCCLIB de TIGCC 0.95;
* d'autres choses dans TIGCCLIB qui vont rajouter des centaines de KB à TIGCCLIB (ExtGraph + d'autres headers);

est ce vraiment utile ? encore une fois je ne crois pas, ou alors cite moi des prgms qui utilisent plus de 20% du contenu de tigcclib
qt à extgraph, c'est une lib non officielle de tigcc, on attend tjs la version 2 au fait

* la doc de TIGCC 0.95 presque complète (des trucs sont sans utilité avec GTC) - il reste encore des centaines de ROM_CALLs à ajouter, ça va augmenter de centaines de KB la taille de la doc.

tres tres utile la doc complete... ça n'a pas d'interet de l'avoir oncalc, au pire ça s'imprime une doc

Je ne suis pas sûr que même avec PedroM, ça soit possible... GTC ne rattrapera jamais TIGCC.

je ressent de la jalousie ds ton post qui te force à demonter gratuitement le travail des autres en faisant un post pseudo argumenté..

solid
:

XDanger :
Ceci dit, j'attends de voir on-calc à la fois:
* TIGCCLIB de TIGCC 0.95; * d'autres choses dans TIGCCLIB qui vont rajouter des centaines de KB à TIGCCLIB (ExtGraph + d'autres headers);

qt à extgraph, c'est une lib non officielle de tigcc

Maintenant qu'elle est en bêta, oui. Mais elle sera intégrée à TIGCCLIB.
Et d'ailleurs, GTC ne va avoir aucune des fonctionnalités de notre nouveau linker (à moins que Pollux ne porte le linker et la nouvelle tigcc.a). Donc pas d'optimisations du linker, pas de tables de relogement compressées, pas de BSS automatiquement alloués en _nostub etc.

solid
:

XDanger :
* la doc de TIGCC 0.95 presque complète (des trucs sont sans utilité avec GTC) - il reste encore des centaines de ROM_CALLs à ajouter, ça va augmenter de centaines de KB la taille de la doc.

tres tres utile la doc complete... ça n'a pas d'interet de l'avoir oncalc, au pire ça s'imprime une doc

On ne peut pas programmer quoi que ce soit d'intéressant sans avoir la documentation sous les yeux! Même moi qui connais pas mal de la documentation par cœur, j'ai besoin de regarder des trucs assez souvent. Évidemment, si on reprogramme tous les ROM_CALLs au lieu de les utiliser...

Solid, c'est toi qui m'accuses de faire un post pseudo-argumenté ?
Et "tres tres utile la doc complete... ça n'a pas d'interet de l'avoir oncalc, au pire ça s'imprime une doc", c'est un argument, sans doute ? Imprimer une doc de la taille de celle de TIGCC... Quelle inutilité !
Ca montre avec quelle mauvaise foi tu as posté ce pseudo-argument...

> je ressent de la jalousie ds ton post qui te force à demonter gratuitement le travail des autres
J'ai déjà dit que je ne ferais pas, d'une part parce que je ne suis pas capable, d'autre part parce que je ne vois pas l'intérêt, de faire un compilateur.
Ca n'est pas de la jalousie, c'est le difficulté à voir pourquoi on n'utilise pas à fond / améliore ce qui existe (AMS, TIGCC) plutôt que de faire de nouveaux trucs dont l'intérêt et l'opportunité peuvent être discutés - pas ici - (PedroM, version on-PC de GTC).
J'ai déjà dit qu'AMS était loin d'être utilisé à fond, je le maintiens.

Pour ExtGraph, ça prendra le temps qu'il faut, mais ça sera intégré à TIGCCLIB... Une chose qui est à peu près sûre, c'est que l'intégration ne sera pas faite cet été.

Quand tu auras fait la même chose que moi dans la documentation de TIGCC, que Kevin pour TIGCC en général, tu pourras parler... Mais je crains que tu n'y arrives jamais. Pas par incompétence: autant qu'il me semble, solid = liquid, qui a fait des choses intéressantes... Mais par manque de volonté, manque d'intérêt.

Pke y'a pas que ça dans la vie

C bien> Bon, j'ai testé la dernière version, et c'est pas mal.
Mais les touches ne réagissent pas toujours vite, je trouve.
Le coup du brouillard à plusieurs niveaux, c'est très bien.
Par contre, je ne peux pas déplacer mes unités partout, ça c'est pas pratique du tout.

Jackie>"Pas partout" j'imagine que c'est par exemple pas en jungle ni montagne?
En fait tu peux, mais ça demande du temps. J'ai défini un temps de parcourt pour chaque type (en général le mouvement dont dispose un colon par tour, mais plus pour la montagne et moins pour la cote et la route) et si il ne reste pas à l'unité assez de mouvement pour faire le déplacement demandé, elle le fait pas et attend d'avoir plus de mouvement. Dans ce cas, au lieu de metre le mouvement à sa valeur par défault pour l'unité au début du tour, cette valeur(celle par défault de l'unité) est ajoutée à ce que l'unité avait avant. Je vois pas comment faire un temps de trajet élevé en montagne à part comme ça (dans civ3, tu te déplace même si tu as pas assez de déplacement, je trouve ça con).
Par contre, il faudra que je modifie un peu pour qu'une fois qu'il a assez assez de mouvement il bouge automatiquement.(je m'en occuperrai plus tard)

Ah ok, je n'avais pas vu qu'on pouvait faire comme ça.
Moi je trouve ça mieux de pouvoir se déplacer au moins une fois quand même.

Oui, mais si on peut se déplacer partout au moins une fois, ça change rien que le trajet soit plus long sur certains types.

Non, si une unité a 2 points de mouvement au départ, elle pourra se déplacer 2 fois sur des cases qui ne coûtent qu'une unité de mouvement, mais une seule sur des cases qui coûtent 2 (ou plus) unités de mouvement.

Oui, mais au début on a des unités qui ont un de mouvement, et après on a en général des routes. Donc à mon avis ça sert pas à grand chose si ça s'applique que à ceux qui ont beaucoup de mouvement