Question à propos de votre utilisation d'extgraph - Page 2

, nan sur une HW1 je préfèrerai toujours faire du Gray7 !!!

...j'ai une hw1 et ca me passe pas par la tete de faire des trucs incompatibles avec les hw2 et la v200, c'est anti-evolutif !

...Compréhensible, dans un sens.
Mais comme en plus de ça les HW2 et les V200 ne veulent rien faire qui
soit incompatible avec les HW1, on commence légèrement à
limiter les deux, non ? On fait des trucs en Gray4 sur HW1 et des
trucs HW2 avec du code pour les HW1...

C'est pas très pratique de développer deux version d'un jeu, l'une pour hw1 et l'autre pour hw2, surtout que l'utilisateur aura peu de chance de s'y retrouver.

c'est clair, et la diffusion d'un prgm se fait plus de calc a calc que de pc a calc

Ben pourquoi pas ?
La version hw1 pourrait avoir du Gray7 sous graphlib,
et la version hw2 du Gray4 sous Genlib. ( je déconne,
y'aurait une légère différence de bauté, et de rapidité aussi,
sans compter le travail de l'auteur pour faire du tile oriented sous
graphlib)

Mais pourquoi pas deux versions ?
Et pis au pire si on a peur que l'utilisateur d'y perde, on a qu'à faire
un installeur qui détecte la calc et supprime la mauvaise version.

(Il nous faudrait un installeur commun genre un InstallShield caltos,
j'ai essayé mais trop la flemme)

C'est vrai qu'en transfert calc-calc ça se complique, mais
chez moi la plupart de ces transferts foiraient, soit que ma 92+
avait l'AMS 2.05 et ne supportait pas doors seul sans hw2patch,
soit qu'on me filait des versions antédiluviennes genre doors I.

Donc chez les nouveaux, les transferts de calc à calc foirent très
souvent de toute façon, car ils ne savent pas les histoires
de patch, de HW etc. Et quand ils le savent ben on peut
faire deux versions...

Bah écoute, personne ne t'empêche de faire comme ça mais je crois que la plupart des développeurs n'a pas envie de se prendre la tête comme ça, surtout que le mode 7 gris marche aussi sur hw2. Donc quitte à faire 7 gris autant le faire pour tout le monde...

Au fait ça fait 2 cross depuis le début du topic.

BlueSilk :


Au fait ça fait 2 cross depuis le début du topic.

Sinon, tu peux toujours parce que là, ton post 28 est vraiment n'importe quoi.

Aurait-tu l'amabilité de dire pourquoi ?

T'es lourd, BlueSilk, en plus d'être hors-sujet.

Edit: compris pk HS...

BlueSilk
: 1) Pourquoi continuer à s'emmerder avec le HW1 ?

Parce que le matériel ne peut pas être mis à jour, imbécile!

Si qqun a une HW1 de toute manière, si j'étais lui je resterais à graphlib

Très intelligent comme suggestion.
Tu sais, il arrive que les possesseurs de HW1 veulent aussi jouer aux nouveaux jeux... J'en suis un, donc: .

et je ferais du Gray7.

Et tu crois que je fais quoi? Sauf que ça marche aussi sur HW2.

2) Pourquoi le supposer ? Une routine permettant d'allouer 7680 octets sur le Heap, comme un DScreen de genlib, et puis c'est bon.

* C'est la routine de gris qui alloue les plans du buffer primaire, pas la librairie graphique. Tu ne peux pas changer les adresses du buffer primaire.
* Ton idée, comme toutes les autres du même style, gaspille 3840 octets de RAM sous HW1, donc est rejetée.

Kevin Kofler
:

BlueSilk
: 1) Pourquoi continuer à s'emmerder avec le HW1 ?

Parce que le matériel ne peut pas être mis à jour, imbécile!

Si qqun a une HW1 de toute manière, si j'étais lui je resterais à graphlib

Très intelligent comme suggestion.
Tu sais, il arrive que les possesseurs de HW1 veulent aussi jouer aux nouveaux jeux... J'en suis un, donc: .

et je ferais du Gray7.

Et tu crois que je fais quoi? Sauf que ça marche aussi sur HW2.

2) Pourquoi le supposer ? Une routine permettant d'allouer 7680 octets sur le Heap, comme un DScreen de genlib, et puis c'est bon.

* C'est la routine de gris qui alloue les plans du buffer primaire, pas la librairie graphique. Tu ne peux pas changer les adresses du buffer primaire. * Ton idée, comme toutes les autres du même style, gaspille 3840 octets de RAM sous HW1, donc est rejetée.

Merci KK
- réponse au pourqoi -

Et c'est un smaaaaaaaaaaash !!!
Le premier de Kevin, mais il est pas mal

Bon, !counter-smash Kevin Kofler

(Ca va être dur contre KK mais bon)

Kevin Kofler
: Parce que le matériel ne peut pas être mis à jour, imbécile!

Et pourquoi pas, pendant qu'on y est, faire une compatibilité TI-92 ?
Parceque c'est trop rare, que ça nous emmerde au niveau matériel et
qu'on doit faire attention à certains points. (mémoire)

Personne s'est gêné pour ne plus développer sur TI-92.
Peu de gens parmi les développeurs TI-68k en avaient une, il fallait
qu'il développe de façon théorique et testent sur un ému,
en ne voyant presque jamais un de leur potes en avoir une.

De la même façon, je vais pas m'emmerder pour des calcs que de toute
façon j'aurai jamais et qui de toute façon sont bien moins fréquentes que les
autres. (Vitesse de vente d'une V200 très supérieure à celle de la 92+, a beaucoup
plus de succès)

C'est pourquoi je ne m'arrêterai pas à des détails genre "ça gaspille 3840 octets
sur HW1" si il y a quelquechose à gagner sur HW2.
Les HW2 sont de très loin ma priorité.

Même s'il y avait une incompatibilité totale avec les HW1 ça ne pénaliserait pas
des millions de gens.

Très intelligent comme suggestion.
Tu sais, il arrive que les possesseurs de HW1 veulent aussi jouer aux nouveaux jeux... J'en suis un, donc: .

On peut toujours faire une version HW1 à part,
parceque de toute façon ceux qui ont une HW1 et veulent des progs de
maintenant ont généralement acquis le niveau nécessaire pour savoir ce
que sont HW1 et HW2 et savent chercher la bonne version sur un site,
hein Kevin ?

* C'est la routine de gris qui alloue les plans du buffer primaire, pas la librairie graphique. Tu ne peux pas changer les adresses du buffer primaire.

Changeons la routine de gris.

* Ton idée, comme toutes les autres du même style, gaspille 3840 octets de RAM sous HW1, donc est rejetée.

Qu'est-ce qu'on en a à foutre ? Y'a bien d'autres choses qui peuvent gaspiller
de l'espace et qu'on devrait éviter d'abord, et puis perdre 3840 octets de RAM
ne va faire pleurer personne vu ce qu'on a. Et ça ne concerne que les HW1.

Kevin Kofler
: Parce que le matériel ne peut pas être mis à jour, imbécile!

Et pourquoi pas, pendant qu'on y est, faire une compatibilité TI-92 ?
Parceque c'est trop rare, que ça nous emmerde au niveau matériel et qu'on doit faire attention à certains points. (mémoire)

[mode kk=on] Le linker de TIGCC 0.95 le gère [/mode]

C'est pourquoi je ne m'arrêterai pas à des détails genre "ça gaspille 3840 octets
sur HW1" si il y a quelquechose à gagner sur HW2.
Les HW2 sont de très loin ma priorité.

Même s'il y avait une incompatibilité totale avec les HW1 ça ne pénaliserait pas des millions de gens.

Alors là, n'importe quoi! Il y a qd même un certain nb de HW1 (dont moi ). Cela dit, ça ne me dérangerait pas qu'un jeu en niveaux de gris prenne 3 ko de RAM en plus si c pour être plus rapide et prendre moins de ROM.

Très intelligent comme suggestion.
Tu sais, il arrive que les possesseurs de HW1 veulent aussi jouer aux nouveaux jeux... J'en suis un, donc: .

On peut toujours faire une version HW1 à part,
parceque de toute façon ceux qui ont une HW1 et veulent des progs de
maintenant ont généralement acquis le niveau nécessaire pour savoir ce
que sont HW1 et HW2 et savent chercher la bonne version sur un site,
hein Kevin ?

Et comment on fait pour envoyer un prog entre HW1 et HW2 ?

* C'est la routine de gris qui alloue les plans du buffer primaire, pas la librairie graphique. Tu ne peux pas changer les adresses du buffer primaire.

Changeons la routine de gris.

Non, il faut en rajouter une autre, ou encore mettre un #define qui utilise la version DScreen de la routine.

Pollux :
[mode kk=on] Le linker de TIGCC 0.95 le gère [/mode]

Je suis en train de parler des programmes, non des outils.
Que ce soit possible, c'est bien, mais un prog TIGCC pour TI-92
(Sérieux, pas un test du linker) y'en a pas des masses.

Alors là, n'importe quoi! Il y a qd même un certain nb de HW1 (dont moi ).

D'où la version HW1, sinon je ne me poserais pas la question .
Je sais qu'il y en a, mais *pas des millions*. Et pas la majorité
des utilisateurs (quant aux programmeurs, j'en sait rien)

Cela dit, ça ne me dérangerait pas qu'un jeu en niveaux de gris prenne 3 ko de RAM en plus si c pour être plus rapide et prendre moins de ROM.

, allons cogner Kevin !!!

Et comment on fait pour envoyer un prog entre HW1 et HW2 ?

Mais j'ai déjà répondu là-haut... plein de merdes peuvent arriver.
Imaginons qu'un utilisateur veuille envoyer des jeux kernel et DoorsOS à son
pote, et il a un vieil AMS avec Doors I, sous hw1, et envoie ça à son pote
qui a une hw2 sous AMS 2.09. . Le transfert calc-calc devrait être
évité.

Et puis au pire doit bien y avoir une solution, genre le prog d'install,
qui met du code pour vérifier la caltos où on est (ID # ou un truc comme ça)
et si on change de caltos il dit que tout risque de foirer et qu'il vaudrait
mieux avoir le fichier 'jeusetup.asm'. Si le premier mec a gardé ce fichier,
tout va bien, sinon... le jeu essaie de se lancer. Et l'idée du prog d'install
permet d'inclure une license, de vérifier les libs...

Non, il faut en rajouter une autre, ou encore mettre un #define qui utilise la version DScreen de la routine.

Oui, je voulais pas changer tigcc.a. Il faut faire une autre routine à partir
de la première.

BlueSilk
:

Kevin Kofler
: Parce que le matériel ne peut pas être mis à jour, imbécile!

Et pourquoi pas, pendant qu'on y est, faire une compatibilité TI-92 ?

Pourquoi pas, en effet. TIGCC 0.95 le permet, et j'ai porté Backgammon vers Fargo (TI-92). J'ai aussi essayé de porter XtraKeys vers Fargo, mais les hooks d'évènements ne marchent pas particulièrement bien avec la ROM de la TI-92, donc c'est une "alpha permanente". Backgammon marche bien, lui.

Parceque c'est trop rare, que ça nous emmerde au niveau matériel et qu'on doit faire attention à certains points. (mémoire)

Pour la TI-92, oui, c'est lourd. Pour la HW1, c'est très simple de les gérer, donc il faut vraiment faire exprès de ne pas le faire! Et dans ce dernier cas, ben "" résume à peu près la situation.

Personne s'est gêné pour ne plus développer sur TI-92.

Si, moi. Cf. ci-dessus.

Peu de gens parmi les développeurs TI-68k en avaient une, il fallait qu'il développe de façon théorique et testent sur un ému, en ne voyant presque jamais un de leur potes en avoir une.

Quel est le problème? Je teste tout sur émulateur, même les programmes TI-89/92+/V200. C'est bien plus pratique que de tout envoyer à la vraie calculatrice à chaque fois. Je connais les défauts de VTI et je sais comment tester sous VTI des trucs qu'il n'émule pas directement (par exemple les histoires de protection - je les connais suffisamment bien pour les émuler dans ma tête avec les données fournies par VTI).

De la même façon, je vais pas m'emmerder pour des calcs que de toute façon j'aurai jamais et qui de toute façon sont bien moins fréquentes que les autres. (Vitesse de vente d'une V200 très supérieure à celle de la 92+, a beaucoup plus de succès)

Tu n'as pas à t'embêter, ton programme est automatiquement compatible HW1 sauf si tu fais de grosses conneries. (Bon, OK, pour le double-buffering, il y a une ligne à rajouter pour supprimer les clignotements, mais tu auras aussi cette ligne pour que ça marche bien sur VTI, qui, je te le rappelle, émule une HW1.)

C'est pourquoi je ne m'arrêterai pas à des détails genre "ça gaspille 3840 octets sur HW1" si il y a quelquechose à gagner sur HW2. Les HW2 sont de très loin ma priorité.

Il y a nettement moins de 3840 octets à gagner, donc ça ne vaut pas le coup.

Même s'il y avait une incompatibilité totale avec les HW1 ça ne pénaliserait pas des millions de gens.

S'il y a une incompatibilité avec ton numéro de série non plus. Donne-moi ton numéro de série et je vais faire en sorte que mes programmes ne marchent pas sur ta calculatrice alors qu'ils marchent sur toutes les autres. Ça va te montrer ce que c'est que les programmes qui ne marchent pas sur HW1.

Très intelligent comme suggestion.
Tu sais, il arrive que les possesseurs de HW1 veulent aussi jouer aux nouveaux jeux... J'en suis un, donc: .

On peut toujours faire une version HW1 à part, parceque de toute façon ceux qui ont une HW1 et veulent des progs de maintenant ont généralement acquis le niveau nécessaire pour savoir ce que sont HW1 et HW2 et savent chercher la bonne version sur un site, hein Kevin ?

Pourquoi t'embêter à faire 2 versions quand tu peux en faire une seule qui fonctionne partout?

* C'est la routine de gris qui alloue les plans du buffer primaire, pas la librairie graphique. Tu ne peux pas changer les adresses du buffer primaire.

Changeons la routine de gris.

Non, la routine de gris a une interface bien définie, et l'interface ne changera pas parce que monsieur BlueSilk ne l'aime pas. C'est aux librairies graphiques et aux programmeurs de se plier à l'interface des niveaux de gris, pas l'inverse. L'interface est telle qu'elle l'est pour des raisons de compatibilité antérieure et pour les raisons déjà décrites (économie de RAM - si je permets de changer les plans, tout le monde va le faire sans réfléchir, et je veux justement interdire de gaspiller 3840 octets sans raison).

* Ton idée, comme toutes les autres du même style, gaspille 3840 octets de RAM sous HW1, donc est rejetée.

Qu'est-ce qu'on en a à foutre ? Y'a bien d'autres choses qui peuvent gaspiller de l'espace et qu'on devrait éviter d'abord,

Oui, on devrait les éviter! Celle-ci en est une!

et puis perdre 3840 octets de RAM ne va faire pleurer personne vu ce qu'on a. Et ça ne concerne que les HW1.

Je ne vois pas pourquoi on gaspillerait 3840 octets sans raison valable.

Je suis d'accord avec KK.

vous avez pas l'impression qu'on s'éloigne du sujet ?
Je ne vous empêche pas de vous taper dessus mais pas forcément ici ok ?

BlueSilk
:

Pollux :
[mode kk=on] Le linker de TIGCC 0.95 le gère [/mode]

Je suis en train de parler des programmes, non des outils.
Que ce soit possible, c'est bien, mais un prog TIGCC pour TI-92 (Sérieux, pas un test du linker) y'en a pas des masses.

Il y a Backgammon. Ce n'est pas un outil, c'est un jeu. Et, même s'il a été utilisé comme test du linker, ce n'est pas que ça. La version TI-89/92+/V200 a toujours été un "programme sérieux" et le portage TI-92 l'est aussi maintenant que les bogues du linker sont corrigés.

Cela dit, ça ne me dérangerait pas qu'un jeu en niveaux de gris prenne 3 ko de RAM en plus si c pour être plus rapide et prendre moins de ROM.

, allons cogner Kevin !!!

La consommation mémoire fait partie des trucs à optimiser. Beaucoup trop de jeux consomment une quantité excessive et injustifiée de mémoire vive.

Et comment on fait pour envoyer un prog entre HW1 et HW2 ?

Mais j'ai déjà répondu là-haut... plein de merdes peuvent arriver.
Imaginons qu'un utilisateur veuille envoyer des jeux kernel et DoorsOS à son pote, et il a un vieil AMS avec Doors I, sous hw1, et envoie ça à son pote qui a une hw2 sous AMS 2.09. . Le transfert calc-calc devrait être évité.

Moi, je veux pouvoir transférer mes programmes entre ma TI-89 HW1 et ma TI-92+ HW2. C'est lourd d'avoir des versions selon la version matérielle, et c'est aussi lourd d'avoir des versions selon le modèle de la calculatrice. La compatibilité binaire (compatibilité on-calc) est de loin plus pratique. (Et les lecteurs attentifs auront remarqué que ceci est un des rares points où je ne suis pas d'accord avec la TICT. )

Et puis au pire doit bien y avoir une solution, genre le prog d'install, qui met du code pour vérifier la caltos où on est (ID # ou un truc comme ça) et si on change de caltos il dit que tout risque de foirer et qu'il vaudrait mieux avoir le fichier 'jeusetup.asm'. Si le premier mec a gardé ce fichier, tout va bien, sinon... le jeu essaie de se lancer. Et l'idée du prog d'install permet d'inclure une license, de vérifier les libs...

Oula, tout ça pour gagner une centaine d'octets gros maximum en paramètres à passer en moins. Ça ne vaut vraiment pas le coup!

Non, il faut en rajouter une autre, ou encore mettre un #define qui utilise la version DScreen de la routine.

Oui, je voulais pas changer tigcc.a. Il faut faire une autre routine à partir de la première.

Ce n'est pas la peine, je refuserai ta routine.

Kevin Kofler :
Quel est le problème? Je teste tout sur émulateur, même les programmes TI-89/92+/V200. C'est bien plus pratique que de tout envoyer à la vraie calculatrice à chaque fois. Je connais les défauts de VTI et je sais comment tester sous VTI des trucs qu'il n'émule pas directement (par exemple les histoires de protection - je les connais suffisamment bien pour les émuler dans ma tête avec les données fournies par VTI).

Le problème, c'est de faire des programmes que les gens connaissent. Je ne
vois pas comment quelqu'un parviendrait à faire reconnaître son travail
exceptionnel, s'il l'a hélas fait sur une TI-80.

Si on travaille entièrement sur ému c'est qu'il y a peu de calcs. Dans ce cas,
c'est comme travailler sur un émulateur PlayStation3, on est sûr de rien quand il
s'agit de savoir si ça va être remarqué par quelqu'un.

Il y a nettement moins de 3840 octets à gagner, donc ça ne vaut pas le coup.

Et si je te dis que je trouve bien plus pratique que les deux plans se suivent ?
Avoir une façon de programmer qui nous arrange c'est aussi un gain.

S'il y a une incompatibilité avec ton numéro de série non plus. Donne-moi ton numéro de série et je vais faire en sorte que mes programmes ne marchent pas sur ta calculatrice alors qu'ils marchent sur toutes les autres. Ça va te montrer ce que c'est que les programmes qui ne marchent pas sur HW1.

, il est fâché là.
Arrête Kevin, tu vas perdre des octets sans raison valable.

Pourquoi t'embêter à faire 2 versions quand tu peux en faire une seule qui fonctionne partout?

Non, la routine de gris a une interface bien définie, et l'interface ne changera pas parce que monsieur BlueSilk ne l'aime pas. C'est aux librairies graphiques et aux programmeurs de se plier à l'interface des niveaux de gris, pas l'inverse.

Pourquoi ? Ce sont les programmeurs qui les ont mis en place. Si son
fonctionnement les emmerde, c'est à cette interface de se plier aux programmeurs et aux libs graphique.

L'interface est telle qu'elle l'est pour des raisons de compatibilité antérieure et pour les raisons déjà décrites (économie de RAM - si je permets de changer les plans, tout le monde va le faire sans réfléchir, et je veux justement interdire
de gaspiller 3840 octets sans raison).

Pourquoi, encore une fois ? Tu pourrais le permettre, et mettre le fonctionnement
actuel par défaut.

Je ne vois pas pourquoi on gaspillerait 3840 octets sans raison
valable.

Pour être plus pratique pour le programmeur.

Oula, tout ça pour gagner une centaine d'octets gros maximum en paramètres à passer en moins. Ça ne vaut vraiment pas le coup!

Pourquoi ne pas essayer ? Ca peut ne pas prendre énormément de place.
Faudrait que j'essaie.

Ce n'est pas la peine, je refuserai ta routine.

M'en fous!
Je l'aurais faite pour moi seul de toute manière.

Putain ! Vous êtes lourds.
snow-tiger tu m'énerves, arrête de poster ici.
Non, je ne suis pas impartial.

Sasume > Bon j'arrête ça, les posts de 2 kilomètres de haut ça commence à flooder *légèrement*.

Kevin >

Ca serait bien d'avoir des fonctions originales dans ExtGraph. Genre une gestion de l'animation, qui
permet de faire se succéder deux images, avec différents paramètres optionnels (en flags)
permettant par exemple du Motion Blur, ou des trucs comme ça.

bah voyons
tu le fais comment le motion blur en 4nvg ?

Simple, tu joues sur les plans, genre tu rappelle l'image du plan 1 sur le plan 0 ou l'inverse.
Il faut 4 steps pour faire un joli effet de blur. Y'à qu'à jouer sur les plans pour en faire, je
le fais en Basic sous flib. En C bien sûr, on peut certainement procéder autrement.