Un truc qui me tripote... - Page 1

Vous connaissez le jeu Erix, sur portable ? J'ai la flemme () d'expliquer les principe, mais j'arrive pas à comprendre comment il fait pour trouver les aires fermées (et conséquemment, remplir la plus petite...). Bon, si vraiment personne connait ce jeu, je l'expliquerais

connais pas...

Ouais, moi non plus...

euh qui est ce qui te tripote ??????????????

OUARF !
Bon.
On a l'écran. Le but est de remplir 70, 75, 80 ou 85% de l'écran.
On a un curseur qui fait laisse une trace partout où on va... Lorsque l'on atteint un côté de l'écran, cela forme donc une aire 'fermée'. Cette aire est donc remplie de noir. Mais c'est seulement la plus petite aire qui est remplie. ex : Si on fait un petit carré en bas à gauche de l'écran, il faut que seul le carré soit rempli (et pas l'inverse). Et j'arrive pas à comprendre comment ils font pour calculer l'aire et la remplir (car les formes peuvent être très complexes).
Petit (+) : on perd une vie si on retouche sa ligne...

Déjà, il n'y a que 2 aires maximum dans cette configuration. Donc tout pixel est soit à l'intérieur d'une des 2 aires, soit sur la ligne, soit à l'extérieur de l'autre aire.

Donc un algorithme qui marchera (mais sera lent) est:
* copie le tout dans un écran virtuel
* fais un FloodFill d'un côté de la ligne (FloodFill est une fonction de ExtGraph)
* compte le nombre de pixels allumés (comptage tout bête - tu testes chaque pixel)
* Voilà la première aire. Mais comme il y a aussi la ligne, la deuxième aire n'est pas simplement aire de l'écran - première aire, mais tu devras tout refaire:
* copie le tout dans un deuxième écran virtuel
* fais un FloodFill de l'autre côté de la ligne
* compte le nombre de pixels allumés
* Voilà la deuxième aire. Maintenant tu compares et tu allumes la plus petite des 2 aires. (Il suffit de recopier le bon écran virtuel - FloodFill a déjà fait tout le travail pour nous.)

a la la..
dl jezzball

Jezzball est beaucoup plus simple à programmer! En effet:
- Dans Jezzball, l'aire qui est colorée est celle où il n'y a pas de balles. Donc pas de calculs d'aire à faire.
- Dans Jezzball, toutes les lignes sont soit horizontales reliant 2 murs verticaux ou verticales reliant 2 murs horizontaux.
Donc l'algorithme pour Erix est beaucoup plus complexe, et je ne pense pas que les sources de Jezzball puissent aider de quelle manière que ça soit.
[edit]Edité par Kevin Kofler le 13-12-2001 à 19:13:32[/edit]

c comme "Qix" sur gameboy première du nom.
un jeu que j'ai acheté, donc je le connais bien !
c effectivement la méthode que j'utiliserais, mais la ou je trouve ça bizarre, c que connaissant la vitesse de calcul de la bébète, ça me parait peut probable que ce soit cette méthode qui soit utilisée, même si lorsque certaine zone sont grosse à remplir.

cette fonction FloodFill, elle marche aussi pour l'image tordue de mon programme appellé "recursif" ? (dans les même conditions de départ)

>c comme "Qix" sur gameboy première du nom.
>un jeu que j'ai acheté, donc je le connais bien !

Oui, je me disais bien qu'il y avait un jeu comme ça sur Game Boy et que le nom ressemblait à ça (même si je ne m'en rappelais pas exactement). Et donc ils ont repris le nom en le changeant un peu.

>cette fonction FloodFill, elle marche aussi pour l'image tordue de mon programme appellé "recursif" ? (dans les même conditions de départ)

À priori oui, mais il faudra vérifier et je ne sais pas si la pile en a7 suffira.

alors si ça marche avec une pile a7, ça marche pas
moi j'ai été embété avec ça, il m'a fallu en faire une à la main ! (g pris 30ko de mem, car c nécessaire !)
et faudrait tester la plus rapide, la mienne étant assez optimisée, ça peut etre sympa de faire un test

Pas sûr. Ce n'est pas une fonction récursive, mais ça utilise la pile dans le cadre d'un algorithme itératif. Mais peut-être bien qu'il faudra modifier a7 pour le mettre à la fin d'un bloc long, à vérifier.

Si tu veux essayer, il suffit de mettre un bsr FloodFill en lui passant les arguments par la convention C, et de linker ton programme avec extgraph.a (par exemple: tigcc iteratif.asm extgraph.a).

oh, tu sais, moi et le tigcc, on est pas copains -> j'y touche pas

Ce n'est pas bien.

"Donc soyez gentils, et si vous êtes programmeurs (que ce soit en C ou en assembleur): Téléchargez la version la plus récente de TIGCC!"

oui, c sur !

g un projet de fin d'année en C:

c pas encore définitif, mais je vais faire un éditeur de texte pour l'asm 68k et si g le temps le compilo qui va avec
donc pas besoin du tigcc. et en plus, les interfaces qui plantent toutes seules, non. vraiment, non.

C'est une deception amoureuse. Faut le comprendre.

>HerveRV:
>c pas encore définitif, mais je vais faire un éditeur de texte pour l'asm 68k et si g le temps le compilo qui va avec
>donc pas besoin du tigcc.

Si tu nous fais ça, ça sera peut-être un concurrent valable pour TIGCC. Même si je ne pense pas que tu pourras écrire un assembleur équivalent à A68k en quelques mois. Mais DoorsOS Developer Edition est vraiment dépassé:
- leur version de A68k est vieille (ceci me rappelle que tu ne m'as toujours pas envoyé la source qui t'a posé problème avec la dernière version)
- leur linker est vieux: utilise au moins celui des TIGCC Alternative Files si tu ne peux pas te séparer de link.exe - c'est au moins une version plus récente - mais ce linker est quand-même bogué, dépassé et n'est plus maintenu (obj2ti est le futur)
- doors.bat est vraiment dépassé. Utilise au moins tigcc.exe si tu n'aimes pas les IDEs!

>et en plus, les interfaces qui plantent toutes seules, non. vraiment, non.

As-tu essayé la version la plus récente de TIGCC IDE? Peut-être que tes problèmes sont corrigés depuis longtemps! Les dernières versions de TIGCC IDE n'ont jamais planté chez moi, à part pour un problème qui est apparu très récemment et corrigé dans la dernière version: la documentation plantait et faisant planter l'IDE quand on la fermait. Mais je réitère que c'est corrigé entretemps.

>PpHd: C'est une deception amoureuse. Faut le comprendre.

Arrête de dire n'importe quoi s'il te plaît. On ne peut pas être amoureux d'un logiciel.
[edit]Edité par Kevin Kofler le 21-12-2001 à 01:54:04[/edit]

Kevin>

>je ne pense pas que tu pourras écrire un assembleur équivalent à A68k en quelques mois

je suis sur que tu as raison, mais g envie d'essayer, ce sera en C++, et au cas ou j'y arrive pas, je sais à quelle porte frapper le but étant d'avoir une bonne note à la fin, le compilo, c pas utile si mon éditeur de texte est bien (y aura vraiment pleins de trucs dedans)


>doors.bat est vraiment dépassé. Utilise au moins tigcc.exe si tu n'aimes pas les IDEs!

tant que ça marche, j'vois pas pourquoi je le changerais. je veux surtout pas etre méchant, mais c quand même depuis que g changé a68k que je rencontre des problèmes. (du coup j'ai remi l'ancienne version, et je n'ai toujours aucun problème)


>As-tu essayé la version la plus récente de TIGCC IDE ?

non, car mon modem est lent, et g pas que ça a faire, j'en ai téléchargé 2 ou 3 versions, mais j'ai jamais vu d'amélioration, donc ça m'intéresse pas, et tout ce que j'ai me suffit bien, rien ne bogge


PpHd> moi amoureux de tigcc ? tu m'as bien regardé ???

Mais si on peut etre amoureux d'un logiciel. Moi j'ailme King of Fighter !
Et si, moi j'ai fait un assembleur universel (Il accepte tous les languages) en ... 2 moi et demi. (projet d'ecole).

Mais si on peut etre amoureux d'un logiciel. Moi j'ailme King of Fighter !
Et si, moi j'ai fait un assembleur universel (Il accepte tous les languages) en ... 2 moi et demi. (projet d'ecole).

pas besoin de le dire 2 fois
bah moi, chuis amoureux de ma carte graphik, alors...

TOUT les langages? cad? combien tous?
(684098956[...]9956 )

>HerveRV:
>c quand même depuis que g changé a68k que je rencontre des problèmes.

Tu attends quoi pour m'envoyer les sources qui boguent?! Je commence à m'impatienter.
Je te signale que je peux corriger ton problème si et seulement si je peux le reproduire!
Et je t'avertis que je n'apprécie pas du tout cette attitude de dire dans des forums publics qu'un logiciel XYZ est bogué, mais de ne pas donner à l'auteur du logiciel XYZ les informations nécessaires pour corriger le bogue.
Et encore je suis patient. Je pense que Sebastian Reichelt t'aurait envoyé te ballader depuis longtemps...

>non, car mon modem est lent, et g pas que ça a faire, j'en ai téléchargé 2 ou 3 versions, mais j'ai jamais vu d'amélioration, donc ça m'intéresse pas, et tout ce que j'ai me suffit bien, rien ne bogge

Je te jure, si ça fait quelque temps que tu as essayé la dernière fois, tu ne sais pas ce que tu rates. Télécharger TIGCC, ça prend 1/2 heure sur un 56k (un peu plus sur un modem plus lent). (Je l'ai téléchargé 7 ou 8 fois avec un 56k aux USA - pour toujours avoir le service pack le plus récent.) Et l'aide syntaxique etc. en valent bien le coup. Mais attends peut-être la prochaine mise à jour, Sebastian doit corriger encore un petit problème de linking (qui survient si on linke un fichier A68k avec d'autres fichiers compilés séparément quand le fichier A68k n'est pas au début - c'est-à-dire avec des sections .data et probablement aussi .bss). Quand ça sera corrigé, plus rien ne t'empêchera d'utiliser la compilation séparée avec tous ses avantages en A68k. Pour l'utilisation des librairies statiques, ça marche déjà. (Mais pour la création de ces dernières avec A68k, pour le moment, ça ne va pas bien marcher, à cause du problème qui n'est pas encore corrigé. )
[edit]Edité par Kevin Kofler le 21-12-2001 à 21:43:56[/edit]

HervéRV: en effet, ça fait combien de temps que tu n'as pas utilisé TIGCC ?
"Une interface qui plante toute seule": tiens, ça devait être dans la version -9.06, c'est sûr que là c'était pas stable
Non, plus sérieusement, l'IDE ne bugge plus, ça fait plusieurs versions de TIGCC que je ne l'ai pas fait planter.

Pour downloader TIGCC c'est facile et ça prend pas trop de temps.
Et puis quand comprendras-tu que DoorsOS c'est dépassé ?
Utilise au moins UniversalOS qui est plus récent, si tu veux continuer à programmer sous kernel. Sinon, passe à TIGCC et au nostub.

>XDanger:
>Utilise au moins UniversalOS qui est plus récent, si tu veux continuer à programmer sous kernel.

1. Universal OS ne fournit pas d'outils de développement.
2. L'outil de développement le plus récent pour le mode kernel est le même que pour le mode _nostub: TIGCC.

Et HerveRV, je te rappelle encore une fois de m'envoyer les sources qui ne marchent pas avec la dernière version de A68k. (Je veux enfin pouvoir corriger cela.)

Kevin> je devais m'en occuper samedi mais y a tout un tas de facteur désagréable qui m'ont empêchés de le faire

tout le monde> ça change quoi d'avoir doors ou un autre truc ??? moi j'vois pas ce qu'il vous gene

>HerveRV:
>Kevin> je devais m'en occuper samedi mais y a tout un tas de facteur désagréable qui m'ont empêchés de le faire

OK.

>tout le monde> ça change quoi d'avoir doors ou un autre truc ??? moi j'vois pas ce qu'il vous gene

C'est que les anciennes versions des logiciels comportent des bogues et optimisent moins bien, et qu'on ne peut pas venir corriger des bogues dans une version qui traîne sur ton disque dur, tout ce qu'on peut faire, c'est le corriger et rendre disponible une nouvelle version sans le bogue.

Voilà.

CQFD :d

Malheureusement, les versions actuelles de TIGCC comportent plusieurs problèmes de linking (qui concernent les fichiers A68k). J'espère que Sebastian réussira à s'en occuper rapidement. Moi, je suis assez perdu dans ce domaine.
[edit]Edité par Kevin Kofler le 25-12-2001 à 17:49:23[/edit]