Civilisation - Page 8

et oui ... d'apres TiMad, pour les routines de XLib, ca prendrait 128 cycles en plus

bah... 128 cycle, c pas énorme.

pr un sprt 16 ... ca ralenti quand mm ...

Pour la transparence, la plus rapide est la noir suiit de la blanche et des 2 grises.

Si un utilisateur( veux afficher un sprite 8x8 et qu'il ne reflechit pas alors il prend la routine 8xX de Extgraphlib alors que la veritble optimisation en taille et en vitesse et d'utiliser le format XSmall ... Et c'est pour un souci d'optimisation de taille et de vitesse que XLib ne propose que ces 2 formats, et si le programmeur ne se rend pas compte du gain tanpis!

Mais ça t'oblige à prendre 2 fois plus de place pour stocker ton sprite, si tu utilises le format XSmall au lieu du format 8xh d'ExtGraph.

mais tu n'as pas 2 routines...

Pour la transparence, perso, si il fallait sacrifier une couleur ça serait le noir ou le dark-gray, parsk'en général on les différencie pas bien. Donc si vous faites une routine de transparence, n'obligez pas à utiliser le blanc, proposez aussi au moins le noir.
Merci !

comme genlib koi

genlib permet deux couleurs de transparence, blanc ou noir.
Elle permet un troisième mode, celui appelé NB : le sprite light représente le masque et le sprite dark est affiché sur les deux plans, ce qui fait un sprite masqué en noir et blanc au final.

comme genlib koi

Oui, mais j'ai cru comprendre que pour ExtGraph, vous alliez faire de la transparence. Si tel est le cas, proposez au moins le noir.

Ximoon
a écrit : Dans ce cas (en tout cas c'est ce qui se passe chez moi) ils chargent "l'expert en calculatrices local" de leur mettre ce qu'il faut dessus (généralement pas longtemps avant les interros/concours d'ailleurs). Et lui il s'en fout que se soit kernel ou nostub, on lui a demandé textrider ou des jeux? Les bons jeux demandent un kernel, et il ne connais pas forcément les derniers remplaçants de textrider. Donc il le met le kernel (et avec un peu de chance il en met un bon)

L'"expert local" fréquente les forums, donc il connaît les derniers remplaçants de TxtRider.
Et puis, s'il ne connaît pas, il dira tout simplement qu'il n'existe pas de lecteur de texte qui ne plante pas.

L'expert comme tu ds n'a pas que ça à faire que de perdre son temps à expliquer à des types qui n'en ont rien à faire les différences subtiles entre le nostub et le kernel, ce qui risque de leur faire perdre 3-4h de discussions et 3ko sur leur RAM qui en a 200 de libre, sans compter la ROM...

Ben, il suffit de dire "Ah, ça plante? Normal, c'est kernel.". C'est ce que XDanger a dit quand on lui a demandé des conseils d'expert (cf. ses messages à ce sujet). Avec ça, pas besoin d'expliquer en détail les différences entre les 2 modes, l'utilisateur comprend tout de suite même s'il n'a aucune idée de ce qu'est un kernel.

Encore faut-il qu'il soit lui-même convaincu que les kernels sont dépassés, et ça c'est pas gagné d'avance...

S'il fréquente les forums (surtout s'il s'agit des forums internationaux), il y a de grandes chances qu'il en soit convaincu.

Trust
a écrit : jackichan: c'est une possibilité, mais 99% des gens qui utilise extgraphlib utilise 2 routine diff...

Dans ce cas, c'est parce qu'ils ont besoin d'une routine 8×8, pas 16×8. Ce n'est pas une bonne idée d'essayer de les forcer à utiliser du 16×8.

de plus les fonction de extgraphlib son ttres tres lente pour certains x ce qui la rend lente en generale.. et ca si vous ne voulez pas l'accepté c'est votre prob

Non, ce qui compte est la moyenne.

casilda liquid
a écrit : Kevin > Tu répètes dans tout tes posts que les kernels sont dépassés, minoritaires etc etc ... dans ce cas, tu eux m'expliquer pourquoi Doorsos est toujours dans le top 5 des téléchargements sur ticalc, avec près de 300 DL par semaine ?

Parce qu'il y a toujours des gens qui ne sont pas à jour. (La preuve: s'ils l'étaient, ils téléchargeraient PreOs, pas DoorsOS.)

squale92 a écrit :
pour un jeu hautement graphique, les effets graphiques sont extrémement important !
ce n'est pas parce que tu te limite aux jeux de societe que tout le monde fait pareil

Même un jeu "temps réel" (jump&run, shoot'em up etc.) ne doit pas nécessairement être "hautement graphique"! C'est ça ton erreur!

je la reduit au maximum, tout en sachant que je ne veut pas supprimer d'effets pour limite la mémoire.

Donc tu ne la réduis pas au maximum.

c'est une des solutions permettant de gagner en RAM... et j'ai l'intention de l'utliser au maximum.

Mais c'est un hack à éviter.

dommage pour la V200.

Vive l'altruisme et la compatibilité...

j'optimise en taille au maximum ce qui ne touche pas au moteur... et en vitesse ce qui touche au moteur.

Optimise tout en taille et tu gagneras la place qu'il te faut.

Trust
a écrit : Si un utilisateur( veux afficher un sprite 8x8 et qu'il ne reflechit pas alors il prend la routine 8xX de Extgraphlib alors que la veritble optimisation en taille et en vitesse et d'utiliser le format XSmall ... Et c'est pour un souci d'optimisation de taille et de vitesse que XLib ne propose que ces 2 formats, et si le programmeur ne se rend pas compte du gain tanpis!

C'est au programmeur qui utilise ta librairie de choisir la routine optimale pour son programme. Tu n'as pas à forcer un choix sur lui.

/me cite Kevin, 220

L'"expert local" fréquente les forums, donc il connaît les derniers remplaçants de TxtRider. Et puis, s'il ne connaît pas, il dira tout simplement qu'il n'existe pas de lecteur de texte qui ne plante pas.

de mon temps, il n'y avait pas d'alternative a txtrider.
et les gens de ma classe utilisaient txtrider en sachant qu'il bugguait, et acceptaient les bugs.
disons qu'ils ont pesé le pour et le contre, et qu'ils ont fait leur choix.
et ils etaient bien content d'avoir un kernel capable de rattraper une partie des plantages d'un programme.

Ben, il suffit de dire "Ah, ça plante? Normal, c'est kernel.".

c grave abusé de rejeter les fautes sur le kernel...
il doit y avoir plus de programmes nostub qui plantent, que de prog kernel qui plantent...
(tout simplement, parce qu'il y a plus de progs nostub que de progs kernel... et aussi parce que du temps des kernels, les debuttant ne diffusaient pas un programme juste histoire de dire d'avoir fait quelque chose avant de disparaitre)

[cite]S'il fréquente les forums (surtout s'il s'agit des forums internationaux), il y a de grandes chances qu'il en soit convaincu.[/cit]
je frequente les forums
(je lis parfois celui de la tict, meme si je n'y psote quasiment jamais)
je programme généralement en nostub
et pourtant, je n'en suis nullement convaincu.

Même un jeu "temps réel" (jump&run, shoot'em up etc.) ne doit pas nécessairement être "hautement graphique"! C'est ça ton erreur!

on va dire que je suis un petit enfant impressioné, et attiré, par les jolies choses
un shhot'em up tout moche, c pas beau...

Donc tu ne la réduis pas au maximum

à mes yeux si.
si je fais deux lettre a l'ecran, une en haut represeant un ennemi, et une en bas representant le heros (et eventuellement une autre pour representer les mssiles), la, j'aurai redui au maximum, pour un shhot'em up... cela dit, ce sera pas super fun...

Mais c'est un hack à éviter

toutes les solutions sont bonnes pour arriver a ses fins, tant qu'elles ne blessent personne.
Si je n'avais pas dit que je mettais du code en externe de la sorte, personne ne le saurait.

Vive l'altruisme et la compatibilité...

je code pour mon plaisir personnel
(comme le prouve K, que j'ai sorti plus d'un an apres l'avoir fini, en me disant qu'apres tout, y'en a peut-etre que ca interesserait, meme s'il ne me satisfait pas)

Optimise tout en taille et tu gagneras la place qu'il te faut

et je perdrai pas mal de fps... donc, ca deviendra injouable...
merci pour cette excellente suggestion

KK:
quand je vois tes arguments et ta faiblesse d'esprit, je prefere forcé le choix.. XLib est optimisé en taille et vitesse, et le XSmall est la meilleur solution (sinon je la proposerai pas..)
D'ailleur je me demande comment tu peux juger comme ca alors que t'as pas fais des jeux qutres que statique, et que de plus tu n'as jamais cherché a optimiser tes routines de sprites...

De plus contrairement a ce que tu dit, ce n'est pas la moyenne des fps qu'il faut compter..
quand tu fais un scroll diff, il arrive un moment ou tous tes plans sont dans un x defavorable... donc par consequent on se doit de regler le timer qui gere la fps sur cette valeur la (ou inf..). C'est l'ecart type qui est le plus important..; et non la moyenne... et ceci est encore une preuve de ton ignorance dans le domaines de jeux ... (autre que backgamin).

Bon sur ce je ne repondrait plus a ces argument d'ignorant.. j'ai quand meem passer 2 ans a prog XLib (il y avait la prepa..), pphd a passer du temps aussi sur Gen.. alors quand on voit des argument a la con comme ceux de kk , ca rage un peu...

Trust a écrit :
KK: quand je vois tes arguments et ta faiblesse d'esprit, je prefere forcé le choix.. XLib est optimisé en taille et vitesse, et le XSmall est la meilleur solution (sinon je la proposerai pas..)

C'est au programmeur du jeu de décider quelle sollution est la meilleure pour son jeu. Tu n'en sais rien.

De plus contrairement a ce que tu dit, ce n'est pas la moyenne des fps qu'il faut compter.. quand tu fais un scroll diff, il arrive un moment ou tous tes plans sont dans un x defavorable... donc par consequent on se doit de regler le timer qui gere la fps sur cette valeur la (ou inf..).

Solution simple: on n'utilise pas de timer!

(autre que backgamin).

Arrête d'écrire le mot Backgammon comme ça immédiatement!

BackGamin

Kevin Kofler
a écrit : C'est au programmeur du jeu de décider quelle sollution est la meilleure pour son jeu. Tu n'en sais rien.

tu te fous de la gueule du monde !!!!!!
pourquoi alors tu veux imposer extgraph partout si c'est au programmeur de choisir ?

Parce que justement ExtGraph permet au programmeur de choisir des choses comme la taille de ses sprites, alors que des librairies comme XLib ou genlib lui imposent ce choix.

les autres libs n'imposent rien puisque c'est le programmaur qui a choisi la lib

Kevin tu as l'art de détourner les mots et de raconter des conneries, je suis patient mais là tu mets la dose maximum ...

Mais sérieux tu peux pas te remettre en question un peu et arrêter d'enchainer connerie sur connerie sur un sujet QUE TU NE MAITRISE ABSOLUMENT PAS !

>>Ben, il suffit de dire "Ah, ça plante? Normal, c'est kernel.". C'est ce que XDanger a dit quand on lui a demandé des conseils d'expert (cf. ses messages à ce sujet). Avec ça, pas besoin d'expliquer en détail les différences entre les 2 modes, l'utilisateur comprend tout de suite même s'il n'a aucune idée de ce qu'est un kernel.

nan mais c'est carrément n'importe quoi ça !
Si il a vraiment dit ça non seulement il a menti à la personne qui lui demandait, mais en plus il a fait preuve d'une bassesse et d'une mauvaise foi exemplaire. Après on s'étonne que le mode kernel est soit-disant en manque de pratiquants si vous usez de telles techniques. Vous me dégoutez...

Ximoon: oui, j'ai osé faire ce crime horrible, dire "Ah, ça plante? Normal, c'est kernel.". Je l'ai d'ailleurs déjà écrit à au moins deux reprises, et je n'ai pas peur de le réécrire encore.

> Si il a vraiment dit ça non seulement il a menti à la personne qui lui demandait
Non. Je rappelle qu'en au moins cinq tentatives, je n'ai jamais réussi à lire un texte avec txtrider, sur diverses versions d'AMS (des 1.xx et des 2.xx) et avec divers kernels (tous des DoorsOS plus ou moins anciens). Quand j'ai mis un DoorsOS plus récent (II 0.98 au lieu de II 0.95) sur une calculette, quelque chose qui marchait avant (lancer un texte avec txtrider depuis le Doors Explorer) ne marchait plus (ERROR: memory alors qu'il y avait 140 KB de libre). Je n'ai évidemment pas mis PreOS, vu qu'à l'époque où cet épisode a eu lieu, PreOS n'était *pas vraiment* utilisable (début des v 0.50)... J'ai mis une fois la 0.52, je crois, sur ma VTI, et j'ai éteint la VTI. Ca a planté -> poubelle.
UniversalOS 1.30 existait, je ne savais pas qu'il était à peu près stable (vu ce à quoi ressemblait UniversalOS 1.14, cf plus bas).

Et puis j'ai vu un bug absolument énorme que j'avais déjà posté sur une AMS 2.05 DoorsOS II 0.98 (la personne a désinstallé le kernel après ça, vu que les examens arrivaient et qu'il n'avait pas envie de perdre ses pompes à cause des conneries de trucs mal faits). Voici un Window Screen très particulier:
xmin = 0. (pour le moment, rien d'anormal...)
xmax = 0.0212490002125 E-7032. (le système est-il censé laisser de tels nombres ?)
xscl = 2.4:0002124:8002 E -1635? (est-ce un nombre ?) Le ? à droite indique que le chiffre était en-dehors de l'écran de la 89.
ymin = 0.02124;8002124<E-6992. (est-ce un nombre ?)
ymax = <.<76002124=>E-16381. (est-ce un nombre ?)
yscl = 0.003<=1<0003<<=E1108. (est-ce un nombre ?)
xres = 0. (est-ce une valeur valide pour xres ?).
Il n'y avait pas moyen de sortir de cet écran (Protected Memory Violation, évidemment, ça n'est pas étonnant vu ce à quoi ressemblent les nombres...). Il a très certainement fallu un reset. Je précise quand même que je n'ai rien inventé...

> mais en plus il a fait preuve d'une bassesse et d'une mauvaise foi exemplaire. Après on s'étonne que le mode kernel est soit-disant en manque de pratiquants si vous usez de telles techniques. Vous me dégoutez...
Ben voyons...
C'est le mode kernel qui est responsable de sa situation actuelle, pas quelques utilisateurs partisans du _nostub... Essentiellement à cause des plantages fréquents (je rappelle qu'UniversalOS 1.14, le dernier kernel que j'ai utilisé, a été capable de me faire planter des programmes en BASIC par Address Error ou Illegal Instruction, plusieurs plantages en quelques jours quand même - j'ai perdu des données).
Ca s'est bien sûr arrangé avec des versions plus récentes d'UniversalOS ou PreOS, mais quand on a fait de la merde depuis longtemps et dégoûté les utilisateurs, c'est dur de les retrouver... Faut-il que je poste les horreurs du temps kernel que j'ai trouvées par hasard il n'y a pas longtemps ?
Pour le fait que les kernels soient utilisés presque uniquement en France: de quelle nationalité sont les auteurs de kernels depuis des années, Xavier Vassor / the Doors Team, Julien Muchembled et Patrick Pélissier ?
LA grande personne de la communauté TI est pour moi Zeljko Juric, pour des raisons que tout le monde connaît...


trust, tu commences à m'énerver... On verra bien ce qu'on verra...
Quand les routines d'ExtGraph seront toutes finies, débuggées et testées pendant un moment, il faudra que Sebastian, Zeljko et Thomas m'expliquent ce qui s'oppose à ce qu'ExtGraph soit intégrée à TIGCCLIB...

XDanger> T'est vraiment nul et en plus t'en est fier. Tu prends les pires exemple, tu utilises les kernel et les programmes reconnus comme les plus dépassé et buggés et tu t'étonne que ca plante! c'est comme si je disait qu'EXEPack c'est de la merde parceque des vielles version ont des problèmes d'incopatibilité. Tu prends UNIOS ou PreOS dernière version, les bug tu vas avoir un peu plus de mal à les trouver.
Ou alors tu te plainds pas si dès qu'il y a un programme qui plante on dit, c'est normal c'est nostub.

trust, tu commences à m'énerver... On verra bien ce qu'on verra... Quand les routines d'ExtGraph seront toutes finies, débuggées et testées pendant un moment, il faudra que Sebastian, Zeljko et Thomas m'expliquent ce qui s'oppose à ce qu'ExtGraph soit intégrée à TIGCCLIB...

Bah personellement je trouve a débile d'integrer toujours plus de trucs a TIGCCLIB. A mon avis elle aurait du dès le début ce limiter au ROMCALLS. Les autres fonctions et extragraph seraient mieux dans un pack a part, quitte à les distribuer en même temps que TIGCC.

Le fichier os.h, que j'utilise pour compiler mes programmes, est bourré de ROM_CALL, mais alors, a quoi sert TIGCCLIB ?

Il propose quelques fonctions en plus

#232>J'imagine qu'il y plus de fonctions avec TIGCC lib, et au moins tous les ROM_CALLs connus y sont parfaitement documentés, ce qui est pas une mince affaire. Si il fallait critiquer je dirait qu'il est domage que certaines docs trainent dans contrib.zip alors qu'elles sont valables, mais le temps de la TIGCC team n'est pas illimité.

Remarque la logique est imprenable: si un programme kernel plante, c'est la faute du kernel. Si j'étais d'aussi mauvaise foi que toi je ferais des progs nostub bogués rien que pour accuser le mode en question... Mais y'a des limites quand même...

il n'y a pas de limite quand on est extrémiste...

et pour couroner le tout, extrait de ton propre board, XDanger:

XDanger a dit:
PpHd, this is one of the last times I tolerate such stupid lies. You roughly lied for the programs that were supported by PedroM, you roughly lied for the native format of PedroM... That is NOT the behaviour of a reliable person.

au moins on sait ce que tu penses de toi-même maintenant

erreur

Euh... ça veut dire koi ??