Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » Forum Ti68K » Programmation Assembleur 68K » Répandez la bonne parole autour de vous

(21 réponse(s))

./POST DE DEPART (post n°0) Marquer comme non lu.

Folco

Ecrit le: Jeudi 14 avril 2005 à 10:51

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Post trouvé sur un forum parlant de TI:

Comme son nom l'indique, il faut bien que je vous le racompte, parceque cette histoire m'a vraiment beaucoup ému. J'étais juste en train de discuter avec mon frangin (Riri) sur msn, voici un extrait de la conversation:

RiRi:
T'aurais pas un tuto sur les Kernel en ASM?

Mars:
tu veux quoi sur le kernel comme tuto?

Mars:
le mieux c la doc de preos

RiRi:
Hier soir j'ai lu un tuto sur l'asm

Mars:
les ramcalls

RiRi:
mdr je me suis planté de touche

Mars:
je vois pas ce que tu peux voiloir sur le kernel

Mars:
><

RiRi:
Nan pour les rom_calls j'ai lu ça hier soir justement

Mars:
les RAMcalls

Mars:
c'est des appels à des fonctions ou des variables du kernel

RiRi:
mais je croyais qu'il y avais des différences justements

RiRi:
ouis c'est plus ça qu'il m faudrait

Mars:
ben oui, mes ROM_CALLs sont les fonctions de ams

RiRi:
lol c'est croisé dans tous les sens notre discussion, et c'est trop chiant

Mars:
att

Mars:
go

Mars:
!

Le transfert de "doc.rar" est terminé.

Mars:
ok

Mars:
c toute la doc de preos

Mars:
après, tu peux aussi trouver des trucs dans les headers des libs si tu cherches un truc bien spécifique

Mars:
mais tu veux savoir quoi précisément sur le kernell?

RiRi:
En bref hier j'ai lu un tuto sur l'asm kernel, j'ai vu comment utiliser les Rom_colls pas de pb, mais j'avais cru comprendre qu'il y avait des différences avec l'asm Kernel c'ets pou ça

Mars:
pour les rom calls, juste
jsr tios::romcall

RiRi:
sinon Merci pour la doc, ça je l'avais déjà je crois

Mars:
mais pour compiler, utilise le tios.h de preos, c TRES IMPORTANT

Mars:
et si tu veux d'autres headers, si tu peux pas les chopper, demandes-les moi.

RiRi:
Sinon il me semble que tu utilise A6 adresse de la table des Rom_calls?

RiRi:
il manque comme

Mars:
et bien la doc c'est tout ce qu'il y a dans la distrib de rpeos

Mars:
ne nostub oui

Mars:
ne kernel pas besoin

RiRi:
okay

RiRi:
pour info les programmmeur utilise A5 en générale, tout comme TIGCC

Mars:
vu que pour appeller un romcall tu fais juste:
jsr tios:: OSSetSR ;par exemple

Mars:
oué mais rab de tigcc

Mars:
en tout cas utilise surtout pas le header de tigcc pour faire du kernel

Mars:
et n'oublies jamais, kernel powaaa

RiRi:
Ce n'est aps une norme, c'ets juste un façon de fair fréquemmment car c'est un registre très rarement détruis (encore moins souvent que A6)

RiRi:
je n'en suis pas encore convaincu, on verra aprè lecture de la doc qui me semble bordelique

Mars:
non non, et puis c'est une question de logique, tu te vois avec 3 jeux qui ont chacun 20 kilos de fonctions d'Extgraph dans le ventre? x/

Mars:
et naturellement, tous les passer à GhostBuster hein

RiRi:
non bien sur...

Mars:
et pas compatibles on-calc, ça serait trop commode

Mars:
et pas compatibles futurs ams, pareil, ça t'empêcherait de maintenir

RiRi:
c'tes vrai, mais le nostub me semblait plus simple à programmer

Mars:
et être copain avec KK, hein, sinon tu passerais pour un con

RiRi:
lol ça jamais

Mars:
non, d'une c'est STRICTEMENT pareil

Mars:
sauf que le kernel sauve les registres, et l'écran, et que les romcalls c plus simple en kernel

Mars:
et ya un anti-crash

RiRi:
bon je crois que je vais finir par être convaincu

Mars:
kk critique la taille du stub des rpogs kernel, mais maintenant avec la taille de leur nostub modifié, leur stub est aussi gros voir plus :/

RiRi:
mais bon si t'écoute KK tu perd de la place avec des fonctions incluses dans certaines librairies que tu n'utiliseras jamais... Du point de vue de la place, je pense que les deux se valent

Mars:
et en plus, si tu as un kernel, tu as preos, et donc stdlib, et donc tu te fatigues pas avec les fonctions lentes et bugguées du tios, ou avec la taille des celles d'Extgraph, tu as directement tout sous la main pour pas un octet en plus

RiRi:
lol

RiRi:
Je pense que ce qu'il y a de plus intéressant, c'est la portabilité et l'anti crash

Mars:
oui, mais kk est toujours pour la portabilité ceci-cela, mais il est comme un con avec HW3 et les nouveaux ams, à chaque fois il doit tout patcher

Mars:
alors que si PpHd mets à jour preos, nous on se tourne les pouces

Mars:
avantage majeur entre tous et décisif pour moi pour choisir kernel ou non

RiRi:
Le fait d'avoir des fonctions plus rapides que AMS, c'est assez intéressants

Mars:
ben oui, tu vois genlib 1.00 avec ses 13000 sprites 16*16 /s, tu hallucine grave mortel total intense méchant terrible

RiRi:
c clair autant qu'il n'y en ait qu'un (et pas des moindre) qui s'occupe de la portabilité, il y a moins de pertes de temps

RiRi:
lol c cliar

RiRi:
Kernel Powaa!

Mars:

vala vala, si vous prennez le temps de lire, vous ne serez pas sans remarquer les arguments à l'arrache, parfois pas très juste (bon pas très faux non plus), mais qu'importe, sur un coup comme ça, la fin justifie les moyens, et là le but est atteint, donc tout va bien

j'ai pas perdu ma soirée #hehe#

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°1 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 14 avril 2005 à 11:36

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Martial Demolins :
vala vala, si vous prennez le temps de lire, vous ne serez pas sans remarquer les arguments à l'arrache, parfois pas très juste (bon pas très faux non plus), mais qu'importe, sur un coup comme ça, la fin justifie les moyens, et là le but est atteint, donc tout va bien

Pfff, franchement, lisant ce paragraphe, je devrais déjà te bannir pour ça. Tu répands volontairement du FUD (lien Wikipedia), bref tu fais de la propagande malhonnête. (Et ne fais pas semblant que le post que tu cites n'est pas de toi, je sais très bien qui est "Mars" et tu m'as dit aussi que tu es le frère de RiRi.)

Mars:
pour les rom calls, juste
jsr tios::romcall

... ce qui prend 6 octets + 2 octets minimum pour le relogement.

À titre de comparaison:

move.l romcall*4(a5),a0
jsr (a0)

prend 6 octets sans relogement, et:

dc.w $f800+romcall

prend 2 octets sans relogement.

Mars:
mais pour compiler, utilise le tios.h de preos, c TRES IMPORTANT

Non. Le tios.h de PreOs n'est pas supporté par TIGCC. Il faut utiliser doorsos.h qui est livré avec TIGCC pour programmer en ASM kernel.

RiRi:
Sinon il me semble que tu utilise A6 adresse de la table des Rom_calls?

a6 est normalement utilisé pour des stack frames. La table des ROM_CALLs, si on en utilise une, on la met plutôt en a5.

Mars:
ne nostub oui

Mars:
ne kernel pas besoin

Si tu as envie de te taper un relogement (8 octets pour le premier ROM_CALL, 6 octets pour le premier ROM_CALL avec un n° donné, 2 octets pour ceux qui suivent) pour chaque appel, pas besoin, effectivement. Si tu veux utiliser une convention efficace, il faut faire comme en _nostub (et donc le kernel ne sert à rien dans ce cas).

Et sinon, il y a toujours la F-Line, qui est de loin la méthode d'appel de ROM_CALLs la plus efficace: 2 octets seulement!

RiRi:
pour info les programmmeur utilise A5 en générale, tout comme TIGCC

Effectivement.

Mars:
en tout cas utilise surtout pas le header de tigcc pour faire du kernel

Et pourquoi? Tu ne donnes aucun argument.

RiRi:
je n'en suis pas encore convaincu, on verra aprè lecture de la doc qui me semble bordelique

Bah, que veux-tu, c'est une doc kernel. #roll#

Une doc claire comme celle de TIGCCLIB, tu ne la trouveras pas du côté des kernelistes.

Mars:
non non, et puis c'est une question de logique, tu te vois avec 3 jeux qui ont chacun 20 kilos de fonctions d'Extgraph dans le ventre? x/

20 KO, tu te fous de sa gueule? Les fonctions de ExtGraph, ça prend 1-2 KO seulement, normalement. (Je rappelle que seules les fonctions effectivement utilisées sont copiées dans le programme, c'est le gros avantage des librairies statiques.)

Mars:
et naturellement, tous les passer à GhostBuster hein

N'importe quoi! Pour du C:

_nostub

PreOs

Pour de l'assembleur, ben soit on utilise des fonctions de TIGCCLIB, alors le discours est le même qu'en C, soit on n'en utilise pas, et alors il suffit de coder correctement (ne pas utiliser des hacks incompatibles avec la Titanium) pour qu'on n'ait pas besoin de GhostBuster. Le fait que ce soit du kernel ou pas ne change absolument rien à la situation!

Mars:
et pas compatibles on-calc, ça serait trop commode

Tous mes programmes _nostub (qu'ils soient en ASM ou en C) sont compatibles on-calc, alors arrête de raconter n'importe quoi.
TIGCCLIB propose aussi un code de démarrage qui s'occupe tout seul de la détection du modèle, si tu programmes en ASM avec code de démarrage (ce qui est parfaitement possible), tu n'as plus qu'un tst.w __calculator à faire. (D'ailleurs, si tu programmes avec code de démarrage, cf. ci-dessous, il suffit d'utiliser __calculator et le bon code de démarrage est importé automatiquement.)

Mars:
et pas compatibles futurs ams, pareil, ça t'empêcherait de maintenir

Je ne vois pas en quoi les programmes _nostub seraient moins compatibles avec les futurs AMS que les programmes kernel.
Encore une fois, il suffit de ne pas utiliser de hacks, les ROM_CALLs existent pour une raison. Le problème des hacks est exactement le même en kernel et en _nostub.

RiRi:
c'tes vrai, mais le nostub me semblait plus simple à programmer

Et tu as raison.

Mars:
et être copain avec KK, hein, sinon tu passerais pour un con

Attaque personnelle.

Mars:
non, d'une c'est STRICTEMENT pareil

Sauf les RAM_CALLs et tout le bordel qu'on attend de toi que tu utilises si tu choisis le kernel. (Sinon, le kernel ne sert à rien.)

Mars:
sauf que le kernel sauve les registres, et l'écran,

3 mots: code de démarrage!

include "OS.h"
xdef _ti89
xdef _ti92plus
_ti89ti: xdef _ti89ti
_v200: xdef _v200

_tigcc_native: xdef _tigcc_native
__ref_all___startup_code: xdef __ref_all___startup_code
__ref_all___nostub: xdef __ref_all___nostub
__ref_all___save_screen: xdef __ref_all___save_screen

xdef __main
__main:
rts

Voilà un programme ASM qui utilise la sauvegarde de l'écran de TIGCCLIB, tu n'as pas une ligne de code à mettre, juste des __ref_all. C'est tellement simple que je peux le coder de mémoire!

et que les romcalls c plus simple en kernel

dc.w $f800+romcall

c'est très simple (et prend aussi au moins 6 octets de moins que la version kernel).

Mars:
et ya un anti-crash

_nostub

KerNO

_nostub

Mars:
kk critique la taille du stub des rpogs kernel, mais maintenant avec la taille de leur nostub modifié, leur stub est aussi gros voir plus :/

Ça dépend de ce que tu veux, si tu veux une sauvegarde d'écran, ça ne va pas se passer par magie, c'est clair. Mais tout est facultatif (le code de démarrage le plus simple prend 0 octets, c'est juste un jmp qui est viré par les optimisations du linker), on peut en ASM aussi utiliser le _nostub strict sans aucun code de démarrage, et certaines méthodes de code de démarrage servent à économiser beaucoup plus de taille dans un programme de taille suffisamment grande (pour les autres, on n'a qu'à ne pas les utiliser, je rappelle encore une fois que tout est facultatif!) qu'elles ne consomment (sections BSS, relogements Mlink, détection du modèle, ...).

Et tu as habilement passé sous la table la taille du kernel!

RiRi:
mais bon si t'écoute KK tu perd de la place avec des fonctions incluses dans certaines librairies que tu n'utiliseras jamais... Du point de vue de la place, je pense que les deux se valent

Effectivement.

Mars:
et en plus, si tu as un kernel, tu as preos, et donc stdlib,

... qui prennent de la place eux aussi!

et donc tu te fatigues pas avec les fonctions lentes et bugguées du tios,

Donc tu défends activement l'utilisation de fonctions obsolètes qui ont été écrites à l'époque où on ne connaissait pas le ROM_CALL correspondant? Ces fonctions ne servent qu'à perdre de la place! Et perso, si je fais ma version de ces libs, j'en ferai des wrappers autour des ROM_CALLs, donc ce sera encore plus lent que le ROM_CALL.

ou avec la taille des celles d'Extgraph,

Elles ne sont pas grosses, les fonctions de ExtGraph (même si, si tu veux des fonctions de sprites vraiment optimisées en taille, je peux t'en faire).

tu as directement tout sous la main pour pas un octet en plus

"Pas un octet de plus"? Et PreOs et stdlib, ils ne consomment rien, à ton avis?

Mon but est d'éradiquer le kernel pour qu'on puisse enfin économiser cette place perdue. Pour cela, il faut éliminer ou remplacer tout programme kernel. C'est pour ça que je suis aussi intolérant envers les programmeurs kernel.

Mars:
oui, mais kk est toujours pour la portabilité ceci-cela, mais il est comme un con avec HW3 et les nouveaux ams, à chaque fois il doit tout patcher

N'importe quoi.
Un programme _nostub n'a pas besoin d'être modifié pour tourner sur un nouvel AMS. La Titanium, c'était un changement matériel, et on s'en est très bien sorti (avec le TIGCC le plus récent, aucun problème).

Et les programmes kernel ont tout aussi besoin d'être patchés que les programmes _nostub, c'est juste que PpHd a caché un patcheur techniquement inférieur à GhostBuster, qui gaspille constamment de la place en RAM, ne sert à rien si on a GhostBuster et ne peut pas patcher tous les programmes, dans le kernel.

RiRi:
Le fait d'avoir des fonctions plus rapides que AMS, c'est assez intéressants

C'est de la duplication de code, et puis les fonctions ne sont pas forcément plus rapides.

Mars:
ben oui, tu vois genlib 1.00 avec ses 13000 sprites 16*16 /s, tu hallucine grave mortel total intense méchant terrible

Bah, genlib, c'est un cas particulier, mais c'est une lib énorme aussi! 20 KO, ou 12 KO dans la version "small"! Je suis pratiquement sûr que je pourrais en faire une version en quelque chose comme 5 KO si PpHd sortait les sources. Mais il refuse de sortir les sources parce qu'il sait très bien qu'on en ferait immédiatement une version statique, parce que les librairies dynamiques sont lourdes pour les utilisateurs.

RiRi:
c clair autant qu'il n'y en ait qu'un (et pas des moindre) qui s'occupe de la portabilité, il y a moins de pertes de temps

Et tu crois que c'est comment en _nostub? Je m'occupe de la portabilité, cf. GhostBuster, et cf. la mise à jour de TIGCC avant-même la sortie officielle de la Titanium! Si les programmeurs avaient fait leur boulot (Project / Build, je ne vois pas ce qu'il y a de dur), à la sortie de la Titanium, tous les programmes auraient déjà été compatibles, vu que TIGCC a été mis à jour avant.

Merci Martial pour avoir rendu publique cette discussion et ainsi m'avoir donné moyen de répondre.

Bref, je vous conseille de répandre la bonne parole du _nostub autour de vous, pas le côté obscur du kernel. Ce qui m'énerve le plus dans ton argumentation, c'est que tu utilises volontairement des arguments pour lesquels tu sais très bien qu'ils sont faux parce que j'y ai déjà répondu. Ce n'est pas en mentant que tu vas arriver quelque part!

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°2 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 14 avril 2005 à 11:45

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Et non mon cher, je n'effacerai pas ce topic (en revanche, je me réserve le droit de locker des réponses si elles sont HS ou contre la charte). Contrairement à toi, j'argumente sérieusement, et je n'ai rien à cacher. Il y a une chose que je ne supporte pas, ce sont les gens qui mentent pour faire passer les gens à leur cause.
-Edité le Jeudi 14 avril 2005 à 11:45 par Kevin Kofler-

./Post n°3 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 14 avril 2005 à 12:03

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Ah oui, et j'ai une bonne raison de ne pas installer un kernel à proposer maintenant: Si on a un kernel installé, on n'a pas assez de RAM pour jouer à Corridor 99.

./Post n°4 Marquer comme non lu.

geogeo

Ecrit le: Jeudi 14 avril 2005 à 12:10

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

Vous me saoulez avec votre guerre stupide entre kernel et Nostub #roll#

Moi je me réserve le droit de locker ce topic!
Martial> Encore un topic débile et je te met un carton jaune!
-Edité le Jeudi 14 avril 2005 à 12:52 par geogeo-

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°5 Marquer comme non lu.

Onur

Ecrit le: Jeudi 14 avril 2005 à 12:32

Membre: Maître Ultime

Groupe: Orage Studio

Messages: 1604

Membre n°341

Inscrit le 02 juillet 2004

Martial, tu es vraiment bizarre..

sinon y a plein de fautes: "racompte" <<-- c'est le plus terrible je pense.

je ne dirai rien sur nostub/kernel.

Je ne veux pas faire quelque chose de bien, je cherche l'excellence:ETP Studio...

et autres projets à finir avant 2010

./Post n°6 Marquer comme non lu.

Jfg

Ecrit le: Jeudi 14 avril 2005 à 13:44

Administrateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 1260

Membre n°60

Inscrit le 23 février 2004

Encore un truc:

"ben oui, tu vois genlib 1.00 avec ses 13000 sprites 16*16 /s, tu hallucine grave mortel total intense méchant terrible "
Ça m'éttonerait que tu fasses un jeu qui a besoin de cette vitesse, donc l'utilisation de genlib ne te serait pas utile.
En plus ExtGraph possède bien plus de fonctions que ta lib (enfin... je suppose! Je ne connais pas genlib).

Kill Mario

./Post n°7 Marquer comme non lu.

Sasume

Ecrit le: Jeudi 14 avril 2005 à 14:06

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Il y a des fonctions de genlib qui ne sont pas dans extgraph, et des fonctions d'extgraph qui ne sont pas dans genlib.

ExtGraph fournit plein (vraiment beaucoup) de fonctions réalisant la même opération avec quelques toutes petites différences à chaque fois (mode d'affichage, cliping, niveaux de gris, ...)

Genlib fournit des fonctions de link, de remplissage de triangles, de cercles.

./Post n°8 Marquer comme non lu.

Flanker

Ecrit le: Jeudi 14 avril 2005 à 14:59

Membre: Disciple

Messages: 126

Membre n°207

Inscrit le 23 avril 2004

Bah, que veux-tu, c'est une doc kernel.

ça au moins c'est de l'argument ! programmez en nostub, comme ça vos docs seront claires #top#

L'anti-crash ne sert à rien depuis qu'il y a la récupération de l'archive.

ça sert à rien d'avoir un os stable, suffit de rebooter #tritop#

Un programme _nostub n'a pas besoin d'être modifié pour tourner sur un nouvel AMS.

#hum# on devrait faire le compte de progs nostub qui ont été codés pour ams 1.05 et qui marchent sur 3.01 sans modification ... txtrider, lui, il marche

Je suis pratiquement sûr que je pourrais en faire une version en quelque chose comme 5 KO si PpHd sortait les sources.

moi j'en suis moins sûr ...
et suffit de connaître les specs pour recoder, pas besoin d'avoir la source

./Post n°9 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 14 avril 2005 à 15:09

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Flanker :

L'anti-crash ne sert à rien depuis qu'il y a la récupération de l'archive.

ça sert à rien d'avoir un os stable, suffit de rebooter #tritop#

L'anti-crash n'est pas stable, ça laisse le système dans un état instable et ne fait en général que retarder le plantage définitif de quelques minutes. La seule chose raisonnable à faire après un "Crash intercepted" est un reset.
Si tu veux comparer avec les OS PC, l'anti-crash ne se compare pas avec un "OS stable" (chose qui n'est pas possible sans MMU), mais avec les anti-crashes pour Windows 9x/Me. J'en ai essayé un à une époque, ça n'a eu qu'un intérêt très limité, et souvent ça a empiré le plantage. Et mon expérience avec les anti-crashes sur TI n'est pas meilleure.

Un programme _nostub n'a pas besoin d'être modifié pour tourner sur un nouvel AMS.

#hum# on devrait faire le compte de progs nostub qui ont été codés pour ams 1.05 et qui marchent sur 3.01 sans modification ...

Il y a eu des changements matériels.
Et ensuite, à l'époque pre-AMS 1, c'était encore l'époque des programmes kernel, il n'y avait que très peu de programmes _nostub, et justement, Cave Blaster et CReversi (2 jeux _nostub) étaient les premiers à marcher sur AMS 2, et sont restés longtemps les seuls à marcher sur HW2 AMS 2. (C'était avant le HW2Patch, je rappelle.) Et pas mal des programmes kernel codés pour AMS 1 étaient incompatibles avec AMS 2 à sa sortie.

txtrider, lui, il marche

Ta mémoire est courte, ou alors tu parles de choses que tu n'as pas vécues, TxtRider a aussi eu besoin de modifications pour AMS 2, et les libs qu'il utilise (notamment ziplib qui est du même auteur, Marc Teyssier) aussi. Pratiquement tous les programmes kernel ont eu besoin de modifications, mais pas CBlaster et CReversi en _nostub.

Je suis pratiquement sûr que je pourrais en faire une version en quelque chose comme 5 KO si PpHd sortait les sources.

moi j'en suis moins sûr ...

Bah, il y a des tas d'optimisations taille qu'on peut faire: enrouler toutes les boucles, virer toutes les tables précalculées, remplacer la routine d'effacement de l'écran par des PortSet et ScreenClear appelés à travers la F-Line, ...

et suffit de connaître les specs pour recoder, pas besoin d'avoir la source

Bah, j'y ai pensé (faire une imitation en librairie statique de genlib avec la même API), mais c'est quand-même un gros effort.

./Post n°10 Marquer comme non lu.

Folco

Ecrit le: Jeudi 14 avril 2005 à 15:15

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

>>Martial> Encore un topic débile et je te met un carton jaune!

Remarque, ça doit être au moins le... premier, facile

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°11 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 14 avril 2005 à 15:54

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Non, tu en as déjà un, daté 11 décembre 2004. Donc a priori ton prochain carton sera rouge, pas jaune.
-Edité le Jeudi 14 avril 2005 à 15:54 par Kevin Kofler-

./Post n°12 Marquer comme non lu.

Folco

Ecrit le: Jeudi 14 avril 2005 à 16:35

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Bon, de toute façon ce soir j'écrirai un e-mail à geogeo pour lui dire ce que j'ai sur le coeur, ras-le-bol de jouer au faux-cul ici. Je m'expliquerai une bonne fois pour toute en pv avec lui.

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°13 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 14 avril 2005 à 17:41

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Tu en as ras-le-bol de quoi? Du fait que les "arguments" volontairement malhonnêtes (cf. "vous ne serez pas sans remarquer les arguments à l'arrache, parfois pas très juste (bon pas très faux non plus), mais qu'importe, sur un coup comme ça, la fin justifie les moyens, et là le but est atteint, donc tout va bien

") ne sont pas tolérés ici?

./Post n°14 Marquer comme non lu.

Folco

Ecrit le: Jeudi 14 avril 2005 à 17:46

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Non, de toute façon, la valeur des """arguments""", j'en suis bien conscient, je l'ai donnée à la fin du log. C'est autre chose.

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°15 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 14 avril 2005 à 17:48

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Tu veux encore râler à mon sujet derrière mon dos? Je trouve que tu as vraiment passé ta limite de mauvaise foi. #roll#

./Post n°16 Marquer comme non lu.

Folco

Ecrit le: Jeudi 14 avril 2005 à 18:10

Administrateur

Groupe: Staff de Ti-Gen

Messages: 1286

Membre n°181

Inscrit le 05 avril 2004

Gloups, mettre les choses au clair à plusieurs points de vue, je suppose que ça sera mieux que de se lâcher en troll, non?

<<< Kernel Extremist©®™ >>>
Pas la peine d'aller là plus d'une fois tous les six mois...

"Il faut apprendre pour savoir qu'il faut apprendre pour savoir."

./Post n°17 Marquer comme non lu.

Lionel Debroux

Ecrit le: Jeudi 14 avril 2005 à 19:45

Envoyer un message privé à Lionel Debroux

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Quel culot, Martial...
Et à part ça, je ne devrais pas troller ? Voir http://www.yaronet.com/en/posts.php?sl=&s=60290&p=1
et encore mieux
http://www.yaronet.com/en/posts.php?sl=2&s=60574&p=1
-Edité le Jeudi 14 avril 2005 à 19:46 par Lionel Debroux-

Lionel Debroux - membre de TICT.

./Post n°18 Marquer comme non lu.

Flanker

Ecrit le: Jeudi 14 avril 2005 à 19:52

Membre: Disciple

Messages: 126

Membre n°207

Inscrit le 23 avril 2004

Bah, il y a des tas d'optimisations taille qu'on peut faire: enrouler toutes les boucles, virer toutes les tables précalculées, remplacer la routine d'effacement de l'écran par des PortSet et ScreenClear appelés à travers la F-Line, ...

vive la vitesse avec toutes ces optimisations ... #roll#

./Post n°19 Marquer comme non lu.

Lionel Debroux

Ecrit le: Jeudi 14 avril 2005 à 20:28

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Flanker, tu connais bien les positions de Kevin en matière d'optimisation. J'en pense la même chose que toi. Beaucoup ont à s'en plaindre. Mais c'est ainsi...

Un carton jaune pour Martial Demolins, c'est plutôt gentil. Le topic sur yAronet montre que c'est par provocation qu'il poste ça ici...

Lionel Debroux - membre de TICT.