squale92 a écrit :
> Il y a certainement un moyen de le faire. Si c'est possible en BASIC, c'est aussi possible en C
moué.. mais alors, ça fait partie des choises qu'il vaut mieuxf aire en basic que C, non ?
un peu comme les progs pr faire des maths : c'est aussi rapide en basic qu'uen C, ou presque... et le basic ratrappe déjà plein de trucs (tandis que le C, par exemple, olante sur les divide by 0)
Il est non seulement tout à fait possible de coder des programmes mathématiques en C sous AMS, ça permet aussi de faire plein de choses qu'on ne peut pas faire en BASIC. Par exemple, rechercher des sous-expressions d'un certain type dans une expression et faire des manipulations sur les sous-expressions trouvées.
oéu, mais c TI : ils font un peu comme ils vuelent 
Mais il n'y a quand-même pas de fortes chances que
sprintf change de manière imprévue.
pourtant, ce serai pas mal d pouvoir rediriger la sortie standard de printf vers un fichier [sous TIGCCLIB] 
Mais bonjour la taille des routines qui permettent cela...
ma foi... chacun sa définition de compatibilité, je suppose...
Qd j'aurai quitté la communauté, j'aimerai bien qu'un kernel se charge de rendre mes progs compatbiles avec ce qui va arriver dans le futur
(enfin, pr ça, fodrait que je code en kernel
)
De toute façon, la compatibilité binaire parfaite est illusoire. Par exemple, les kernels ont été incapables de garantir la compatibilité binaire entre AMS 1 et 2, il y a eu besoin de changements dans les kernels et de recompilations, de réassemblages, voire de portages assez complexes pour les programmes. Alors que les premiers programmes
_nostub (on les comptait sur les doigts d'une main à l'époque) n'avaient pas besoin de portage du tout d'ailleurs (sauf pour
basiclib qui utilisait des adresses absolues toutes les 3 lignes

).
>Il y a de bonnes chances que je serai toujours membre de l'équipe de TIGCC.
qui sait ce que l'avenir nous réservera...
il suffit de bien peu pr changer l'avenir... Car "toujours en mouvement est le futur" 
J'ai dit "il y a de bonnes chances". Mais je suis très déterminé à rester.
je croyais que ct toi qui avait avancdé la durée de 2 mois pr PpHd.
si je me trompte, dsl... c un peu long à tout relire pr trouver le post 
J'ai dit "des mois". Je n'ai pas précisé le nombre parce que je ne me rappelle plus exactement, mais ce qui est sûr, c'est que c'étaient plus de 2 mois.
dans mes programmes, il y a de nombreux appels de fonctions qui tiennent sur plus d'une ligne, pr des raisons évidentes de clarté !
(je sortirai pas d'exemple ici... mais dans mon projet de fin d'IUT, il doit y en avoir qui sont pas mal
)
Je fais ça aussi en général. Mais doit-on compter ça comme plusieurs lignes?
je n'abuse pas des sprites pour "remplir l'écran entier", mais pour afficher tout ce que j'ai à afficher, voila tout !
Tu as trop à afficher.
en appellant 3 fois la fonction pr scroller un plan... et deux fois pr l'autre... vive la rapidité 
C'est la meilleure manière de défiler de plusieurs pixels à la fois en horizontale. Le flag X utilisé par
roxl/roxr ne peut contenir qu'un bit à la fois.
là, tu n'as fait que le fonc, en plus
par dessus, il faut mettre les murs, les ennemis, les missiles (du joueur et des ennemis, et des murs ennemis), les power-up, les explosions, le joueur et les morceaux anexes à son vaisseau, ...
Évidemment. Mais le scrolling différentiel est un effet qui s'applique au fond, donc j'ai fait la partie relevante.
exelente question
mais il me semble qu'il y a des shells qui sont en gray 
Il y a toujours des gens qui aiment les choses inutiles.
j'aime jouer sur les mots et les imprecisions
surtout qu'il est rare que tu laisse de telles failles dans ce que tu dis 
je suis à 100% d'accord... voila pkoi j'utilise ttpack pour KII
cela dit, ziplib a un avantage par rapport à ttpack : ziplib fonctionne on-calc
et pr un shell, il est bon de pouvoir décompresser, certes, mais il peut aussi être utile de compresser, tu crois pas ?
Le plus important, c'est la décompression sur demande des exécutables, comme le fait
TICTEX. Le reste est beaucoup moins important. On n'a pas vraiment besoin de compresser des fichiers on-calc. Si les fichiers sur lesquels on travaille sont suffisamment gros pour mériter une compression, il vaut mieux les éditer sur PC, ce qui permet aussi de les compresser correctement.
> Ce n'est vraiment pas ça qui remplit la mémoire de mes calculatrices (je rappelle que j'ai une TI-89 et une TI-92+). Ça ne remplit même pas 2% de ma mémoire archive
ce sont les petits rien qui font les gd tous 
Pas du tout. J'ai déjà fait la somme de toutes les copies pour avoir les 2%, donc il n'y a plus rien à rajouter pour en faire un "grand tout". Donc ça reste un "petit rien". Et comme j'ai déjà dit, ce qui remplit vraiment ma mémoire archive, ce sont des fichiers de grande taille.
cf ce qu'on dit depuis 9 pages : le kernel n'est pas dépassé, puisqu'il évolue encore 
Ça ne veut pas dire qu'il n'est pas dépassé! Comme j'ai déjà dit: il y a toujours des nostalgiques pour faire évoluer les systèmes totalement dépassés!
alors que le nostub n'évolue pas... auquel cas on peut dire qu'il est dépassé 
Le format de base ne change pas parce qu'il n'a pas besoin de changer. Il est très bien comme il est. Et il y a des évolutions à l'intérieur de ce format de base. Par exemple le format de commentaires et autres données qui est en développement.
oué, ok
mais dans KII, par contre... les 10 fps sont pas toujours atteints 
Trop de sprites, trop d'animations => framerate insuffisant. C'est une implication logique.
ils apportent un peu plus de fun
je peux faire KII en noir et blanc, en affichant des lettres au lieu de sprites, et sur l'écran prmIO, sur tu veux...
comme ça, puisqu'il n'y aura que peu d'effets graphiques, ça ramera peut-être pas trop... et la jouabilité sera aussi bonne ? fo pas abuser qd même !
En effet, il ne faut pas abuser.

Mais pas dans l'autre sens non plus! Il s'agit de trouver le juste milieu, et tu en es très loin à mon avis.
et bien, c plus joli, voila tout
entre une dinde bien grasse et une jolie fille, tu crois pas que la jouabilité est supérieure avec une jolie fille ?
(lol... enfin, ma foi, tant qu'il n'y a pas de filles qui passent dans cette partie du forum...
)
Et même si elles passent, je doûte qu'elles liront ce débat sans fin.
tu devrai me le répéter encore une fois ou deux, au cas où j'ai mal saisi ton point de vue 
ah, cette fois, tu ne le dit pas clairement, mais avec un sous-entendu... je compta ça pour 1/2 fois que je le répéte
Tu vieillis : tu commence à radoter 
ah, tu commence à t'en rendre compte ?
Désolé, la même réponse convenait à tellement de paragraphes que je ne voyais pas trop comment éviter de me répéter. Cette fois-ci, j'ai tout simplement déplacé les citations pour répondre à toutes en même temps.
>Ça n'apporte pas grand chose en fonctionnalités par rapport à KerNO qui fait la moitié de la taille
tout ce que le "NO" de kerno signifie
(entre autre)
Ce que le "NO" signifie, c'est qu'il n'y a pas de support pour le format "kernel" (
DoorsOS). À part le support pour ce mode dépassé, il ne lui manque pas grand chose.
un pb quelqure part... de ton point de vue
moi, je veux gagner le max de temps qd je peux, pr pouvoir rajouter des effets en plus, voila tout 
Tu devrais commencer par "gagner le max de temps" en virant tous les effets qui n'apportent rien à la jouabilité.
Allegro est loin d'être compliquée
sinon, je l'aurai pas pris pour projet de fin d'IUT, avec 3 gars qui n'avaient jamais touché à une librairie graphique 
Bon, de 2 choses l'une:
- soit elle ressemble à
genlib.
- soit elle est simple d'utilisation.
Je ne connais pas suffisamment
Allegro pour dire laquelle des 2 solutions est la bonne, mais je connais suffisamment
genlib pour pouvoir dire que si elle ressemble à
genlib, elle n'est pas simple d'utilisation et vice-versa.
> l faudra m'expliquer de quels TSRs vous parlez! Parce qu'un programme _nostub n'a normalement besoin d'aucun TSR pour tourner!
ça tombe bien, puisque preOS permet aussi de faire tourner des progs non-nostub 
Le rapport avec ce que j'ai dit, il est où???
heu... excellente question
j'ai mis le define EXECUTE_IN_GHOST_SPACE dans le fichier principal (ou quelque chose dans ce style)
Ça, c'est bon, ce
#define est là pour ça.
puis, ensutie, je décompresse de l'archive vers la RAM le code que je veux exécuter
puis je fais un EX_patch dessus (sur ce qui est décompressé en RAM)
puis je branche dessus
J'espère que tu as ajouté
0x40000 à l'adresse avant de faire
EX_patch et de brancher.
c'est bon comme ça ? ou fo quelque chose de plus ?
(question non sarcastique, cette fois-ci : je voudrai pas que ça foire
)
Ça devrait être bon, sauf si tu as oublié d'ajouter
0x40000 à l'adresse.
>Je dirais plutôt: si tu veux faire des librairies pour réutiliser du code entre plusieurs projets, les librairies statiques sont vraiment prévues pour
ah non, justement !
c'est dans CE cas précis que tu as 36 fois le même code sur ta machine !
- "36 fois" est largement exagéré.
- Qui dit que les programmes se trouveront forcément en même temps sur la même machine?
- Même si c'est le cas, ce n'est pas une raison à elle toute seule de ne pas utiliser les librairies statiques. Déjà, les librairies statiques ont aussi leur manière d'économiser de la taille (ne pas linker les fonctions inutilisées). Et ensuite, même dans le cas très improbable où la librairie statique prendrait plus de place, les avantages des librairies statiques justifient nettement le sacrifice minimal en taille.
cf un peu plus haut, d'une...
Encore une fois: je ne vois pas pourquoi il serait si horrible que ça d'avoir plusieurs fois le même code sur une même machine, si toutes les copies sont utilisées. Je trouve bien pire de voir de la mémoire gaspillée pour du code qui traîne complètement inutilisé!
et de deux, c'est, une fois en core, TON point de vue.
perso, je préfère avoir une seule ois le code sur ma TI que 10 fois !
si les routines de grays étaient dans un lib dynamique, je te raconte pas la place qu'on gagnerai sur nons machines en mémoire !
10 fois 1 KO (taille des routines des niveaux de gris) = 10 KO. Ce n'est pas grand chose du tout.
si je reste en mode nostub, ce n'est pas parce que TU me dit (sans argumenter
)
Les pages entières que j'ai remplies ne te suffisent pas en tant qu'argument?
que c mieux, mais parce que j'en ai envie.
Je suis content que tu en aies envie alors.
Thibaut a écrit :
Tout ça pour un débat qui n'aboutira jamais, puisque le kernel a autant de défauts que le nostub, et le nostub autant d'avantages que le kernel. Mais il y a ici deux personnes qui ne le savent pas 
Ben non, le kernel a plus de défauts:
- impossible de lancer un programme sans installation préalable d'un programme tiers.
- gaspillage de place en utilisant une surcouche d'émulation par dessus AMS (pour une estimation de la place gaspillée, comparez la taille de
PreOs avec celle de
KerNO).
- complique la vie aux développeurs d'outils de développement à cause de son format difficile à gérer pour le linker.
- gaspillage de place pour les routines inutilisées des librairies dynamiques.
etc...
squale92 a écrit :
sauf que Os n'est pas vraiment des plus rapides, en général 
Ça ne change pas grand chose à la vitesse en général.
sur l'anticrash peut-être...
mais il reste ce que le "NO" met en évidence 
Mais c'est quand-même un concurrent pour
PreOs.
ma foi, je suis assez d'accord... ça serait bien pratique que ce soit intégré au kernel...
comme ça, on tape directement le nom du ppg dans la ligne d'entrée, pas besoin d'appeller ttstart...
(en supposant que ce soit possible, ce serait bien pratique !)
Tu peux utiliser
AutoStart si tu veux.
http://calc.gregd.org.
et mixer les deux [support DLL, découpage automatique] ne seait pas une bonne idée ?
Peut-être. Reste à savoir si on peut implémenter le découpage automatique dans le linker de manière acceptable. Ce ne sera presque certainement pas dans la 0.95 beta 1. Par la suite, peut-être.
>C'est peut-être du "fun", mais ça ne change rien au fait que c'est lent
voila justement pkoi l'optimisation est nécessaire
et pkoi il est nécessaire d'utiliser ce qu'on a de plus rapide, dans tous les dommaines 
Ben non, voilà justement pourquoi il est nécessaire de laisser tomber ce qui est lent de par sa nature!
la superarme "neige", ou "glace", ou un truc comme ça il me semble, où on voit un polygone 3D tourner dans les airs 
Ah bon... Je n'ai jamais essayé
CF, il nécessite beaucoup trop de mémoire (à la fois archive et RAM). Pour moi, la limite de l'acceptable en comsommation de mémoire est
TI-Chess. Tout ce qui consomme plus consomme trop.
fonctions de sprites par transparence ?
C'est à ça que servent les masques. Ils sont aussi plus flexibles.
encore une fois (ùmême si, cette fois, on ne parle pas de kerno), il prend moins de place... mais a moins de fonctionanlités 
Certes, mais il propose exactement les fonctionnalités que Uther demandait...
et, en plus de cet avantage, elle ont l'avantage d'être bien lente...
cela est quelque chose de formidable ; en effet, si on n'utilise pas d'effets graphiques dans un jeu, il risque de tourner trop vite... il faut donc trouver un moyen de le ralentir !
Et bien, ce moyen est trouvé 
Si tu trouves nos routines de sprites lentes, tu dois n'avoir jamais essayé
BitmapPut.
>Je dis qu'il abuse parce qu'il n'adapte pas du tout son usage d'effets spéciaux à la plateforme sur laquelle il programme
n'exagérons tout de m^me pas !
Je n'exagère pas. Une arme de jeu qui tire 96 missiles à la fois n'est pas du tout adaptée à un processeur à 10 ou 12 MHz.