Netwalk - Page 1

t1 fallait pas me montrer ce jeu

pour la génération des grilles je me demandais comme toi.
c'est possible que je porte ce jeu sur une plate forme ti ou ppc

C'est pas très compliqué.

1. Tu génères la grille résolue. C'est identique à générer un labyrinthe parfait aléatoire (Y'a de la doc sur le net sur le sujet - http://fr.wikipedia.org/wiki/Mod%C3%A9lisation_math%C3%A9matique_d'un_labyrinthe ). Les impasses, ce sont les ordis.
2. Tu tournes les pièces de manières aléatoire.

j'avais pigé 2, mais pas 1. Merci

martial > a deux?

Edited_892

- assembleur only, code pour GNU as => merde, spas portable ça
- kernel => menfou, si ça te va tant mieux
- compilation par shell script => si t'as envie de te mettre aux makefile c'est l'occasion, sinon ça me va
- nul à chier en graphisme => copaing! mais ça devrait aller, là. spas trop dur quand même des pipes et des serveurs
- prêt à implémenter des features pedrom-only (qui dispose d'un répertoire "home", idéal pour les highscores et autres bordel des jeux)
- utilisation minimale des TIGCCLIB (là je vois qu'un recours à rand(), et j'espère qu'un jour PedroM implémentera ça, même si c'est peut-être pas très unix comme fonction (j'en sais rien))
- code PIC =>
donc chais pas. si on fait ça en asm68k je pourrais rien reprendre pour une version pocket PC (arm)
bon, spas grave! nous arrêtons pas là.

je vais déja penser à la structure de données du labyrinthe, moi.

huhu ^^

vu que chaque case contient une unique pièce, 3 bits suffisent pour coder la pièce contenue dans une case.
2 bits pour l'orientation, ok
1 bit de mark

ça fait un octet par case ^^

mais en fait, si t'es un spécialiste de l'asm, moi je suis le même spécialiste, mais en C. Donc on risque de pas trop s'entendre, voire de perdre du temps

et si je veux le faire sur ppc, je vais pas coder de l'API win32 en asm
donc je vais le faire en C.

vaut mieux ptet pas faire un projet commun ^^
tant pis pour les makefiles

(cross) 9: sisi

Il suffit que chacun fasse sa partie dans son langage. C'est pas si compliqué. Faites d'abord une conception

En c: la génération du tableau. Peut être le moteur de jeu.
En asm: l'intégration calculette (affichage, gestion clavier, ...)

Il suffit de faire une conception avec une API détaillée de ce que squalyl fait (prototype + description).
Attendons son avis.
(Et je te rassures, çà s'apprend sur le tas).

je suis d'accord, j'osais pas le proposer pour respecter martial.

je peux faire des routines en C pour la génération des labyrinthes et te dire comment les appeler.

faut bien tout concevoir en effet.

Martial Demolins (./1) :
Je l'ai découvert dans la bêta de Fedora 9, c'est dans les jeux de KDE 4 apparemment.

Dans KDE 3 aussi.

squalyl (./8) :
- assembleur only, code pour GNU as => merde, spas portable ça

qemu-m68k?

Pour les graphismes, pourquoi pas convertir ceux de la version KDE tout simplement? Pour une fois que c'est légal...

tu t'occupes de faire un portage arm-wince-pe de qemu-m68k ou de tiemu?

ah oui bonne idée.

sinon souci algo: comment s'assurer qu'on n'aura que des intersections à 3 cotés? ie qu'on va pas générer un labyrinthe nécessitant une pièce "+" ?

C'est grave ?

ba non mais ce sera un "upgrade" du jeu initial qui ne comporte pas de pièces "+"

A mon avis, ca doit dépendre de ton algo de génération de labyrinthe. Je suis pas sûr qu'une croix arrive souvent.

pas de souci, ça, c'est le labyrinthe parfait qui le garantit (cf wikipedia)

Oui ça y est (ennfin si tu as une vraie distrib tout au moins ^^) car j'y jouais bien avant que KDE4 soit sorti. C'est sympa pour passer le temps lors d'un emerge ou apt-egt un peu longuet

Bah tiens si j'ai du temps ce week end je coderais une version DS - ça concorde avec l'un de mes objectifs, et ça fait un bout de temps que 'javais pas eu de petit projet comme ça..