CBNA Rebirth Days

Petit font 5x5 monospace :


Conditions réelles :


Je compte l'utiliser plus tard pour un projet d'interface en ligne de commandes quand j'aurais mon Arduino.
Merci Arthuro pour avoir donné quelques remarques pour améliorer le font :p

Quoi comme projet exactement ? :p

J'ai déjà réservé le compilo/interpréteur arduino/c++

Térence a écrit:

Quoi comme projet exactement ? :p

J'ai déjà réservé le compilo/interpréteur arduino/c++

Un genre d'OS dans le style de linux.
Tu as ta réponse :p

Vu que je n'en possède pas encore un, je fais pas un listing de malade d'idées. Mais je pense faire un petit kernel multithread (aucune idée comment m'y prendre juste, je vais devoir look des documentations) et un système de partitions pour accéder à la carte SD comme à la flash

Je pense faire un petit interpréteur de langage à la BASIC/Bash/Axe au passage.

Soundii a écrit:

Térence a écrit:

Quoi comme projet exactement ? :p

J'ai déjà réservé le compilo/interpréteur arduino/c++

Un genre d'OS dans le style de linux.
Tu as ta réponse :p

Vu que je n'en possède pas encore un, je fais pas un listing de malade d'idées. Mais je pense faire un petit kernel multithread (aucune idée comment m'y prendre juste, je vais devoir look des documentations) et un système de partitions pour accéder à la carte SD comme à la flash

Je pense faire un petit interpréteur de langage à la BASIC/Bash/Axe au passage.

Le Axe ?

Chlorodatafile a écrit:

Soundii a écrit:

Térence a écrit:

Quoi comme projet exactement ? :p

J'ai déjà réservé le compilo/interpréteur arduino/c++

Un genre d'OS dans le style de linux.
Tu as ta réponse :p

Vu que je n'en possède pas encore un, je fais pas un listing de malade d'idées. Mais je pense faire un petit kernel multithread (aucune idée comment m'y prendre juste, je vais devoir look des documentations) et un système de partitions pour accéder à la carte SD comme à la flash

Je pense faire un petit interpréteur de langage à la BASIC/Bash/Axe au passage.

Le Axe ?

Pas le Haxe, le Axe.
http://www.ticalc.org/archives/files/fileinfo/456/45659.html

J'avais compris, d'où mon interrogation, ne connaissant pas.

Concept de langage (basic largement évolué), le aBASIC, pour ce même projet. Il remplacerait le Bash sous des OS à la *nix et est conçu pour être simple à lire, facile et rapide à interpréter en même temps. Par contre le défaut dans le concept actuel... Il y a une invasion de end et de (), au point de pouvoir concurrencer le Lisp.
Je pense permettre l'indentation pour remplacer les end (Coucou noli, je fais pas référence au Python dutout, nanan)
Exemple de GOL en moins de 100 lignes avec :

Code:

#:os:bin/abasic

.. GOL in ABasic

defc wid 16
defc hei 16

def golarray (grid2d wid hei) .. 2d array 16x16

def plist (stack (point2d)) .. pushlist
def rlist (stack (point2d)) .. remlist

func surrounding (int x) (int y)
 ret (golarray (x-1) (y-1))+cx .. cx : continue expression parsing
 (golarray (x-1) (y))+cx
 (golarray (x-1) (y+1))+cx
 (golarray (x) (y-1))+cx
 (golarray (x) (y+1))+cx
 (golarray (x+1) (y-1))+cx
 (golarray (x+1) (y))+cx
 (golarray (x+1) (y+1))
end

func update
 for (def x 0) (x<wid) (++ x)
 for (def y 0) (y<hei) (++ y)
 def surr (surrounding x y)

 if (golarray (x) (y))=0
 if (surr=3)
 set (golarray (x) (y)) (1)
 end
 else
 if (surr!2)&(surr!3)
 set (golarray (x) (y)) (0)
 end
 end
 end
end

func render
 for (def x 0) (x<wid) (++ x)
 for (def y 0) (y<hei) (++ y)
 if (golarray (x) (y))=0
 cout " "
 else
 cout "*"
 end
 end
 end
end

func flushstacks
 while ((size plist)>0)
 def stacktop (stacktop plist)
 free (stacktop plist) .. Removes the top of this queue
 set (golarray (pointx stacktop) (pointy stacktop)) 1
 end

 while ((size rlist)>0)
 def stacktop (stacktop plist)
 free (stacktop plist)
 set (golarray (pointx stacktop) (pointy stacktop)) 0
 end
end

entry main
 for (def x 0) (x<wid) (++ x)
 for (def y 0) (y<hei) (++ y)
 set (golarray (x) (y)) (rand 0 1) .. (grid2d (x) (y)) is a pointer to this cell
 end
 end

 repeat 10 .. Run the loop 10 times
 update
 flushstacks
 clr
 render
 end
end

Vu que je n'ai rien codé de l'interpréteur, certaines choses dans l'exemple au dessus ne fonctionneront certainement pas avec la version finale ou sont contradictoires. :p

Bref je veux en faire un langage simple, relativement rapide (je sais pas si je ferai un compileur ou un interpréteur, le compileur me semble plus approprié étant donné que ça sera fait pour tourner sur un OS rapide sur une machine lente) et peu dépaysant pour des utilisateurs de Basic, c++, etc.
Reste à voir si c'est pas trop difficilement concrétisable.

Ca a l'air cool, mais fais gaffe : avec ton arduino, tu va recevoir des jolis autocollants et un petit dépliant. D'après le 1.5, arduino ne doit pas être utilisé dans une "safety-critical application", il est interdit de l'utiliser pour des opérations liées au nucléaire ou pour des systèmes armés. Pas le droit de l'utiliser dans le secteur aéronautique par ailleurs :/
Moi qui comptait chauffer mon bain avec un petit réacteur nucléaire, bah je vais pas pouvoir utiliser une arduino...

Térence a écrit:

Ca a l'air cool, mais fais gaffe : avec ton arduino, tu va recevoir des jolis autocollants et un petit dépliant. D'après le 1.5, arduino ne doit pas être utilisé dans une "safety-critical application", il est interdit de l'utiliser pour des opérations liées au nucléaire ou pour des systèmes armés. Pas le droit de l'utiliser dans le secteur aéronautique par ailleurs :/
Moi qui comptait chauffer mon bain avec un petit réacteur nucléaire, bah je vais pas pouvoir utiliser une arduino...

Ah *****, mais les systèmes embarqués pour les bombes nucléaires ça compte?

Ptêt qu'ils viendront te demander des comptes au parloir

J'ai évolué l'idée de mon bash, son nom (définitif normalement) sera Ash.
La compilation sera relativement rapide et permet de gagner énormément en performances et en simplicité (et sera nécessaire de toute façon).
Les fichiers compilés (.cash) seront toujours lisibles par l'humain mais on ne peut pas coder directement avec (c'est possible mais compliqué et peu portable, et cassera à chaque mise à jour changeant l'ordre des noms compilés des fonctions).

J'ai mit l'idée de l'interpréteur (pas encore très claire en plus) et du compileur pour pas me retrouver le bec dans l'eau quand je devrais l’implanter :p
http://pastebin.com/Uaq3hR4x

Bref

Code:

0->number;                      # Set 0 to number
getline->text;          # Get a line and assign text to it
if text == "test":
        cout "Hello world";
end
number++
cout number;
 
Compile step #1 : Remove comments.
0->number;
getline->text;
if text == "test":
        cout "Hello world";
end;
number++;
cout number;

Devient :

Code:

0@aa;°gl@ab;°ifab="test":°co"Hello world";#aa$;°coaa

Edit : Awé, et j'ai fait un petit logo monochrome qui s'affichera lors de la compilation.


Edit : Parlons pas trop fort, online guardian pourrait penser qu'on prépare un attentat D:

Comme je compte aussi faire un compilo/interpréteur ces vacances, j'avais aussi réfléchi un peu à tout ca. Rien sur papier, pas le temps, mais je vois a peu près comment faire le truc.
Si je peux me permettre, on peur surement faire mieux, et difficile de juger ton truc sur 5 lignes de codes, mais le format final prend beaucoup de place :/ Comme tu l'as dit toi meme, c'est pas très utile de modifier directement le truc, donc autant laissé tomber l'idée d'un truc lisible, ce qui te permettra de faire énormément d'économies.
Pour tes fonctions par exemple : là t'utilise 2 caractères, soit 16 bits (au moins, je sais pas commt marche l'encodage des que tu veux plein d'accents). A ta place, je travaillerais directement avec des numéros. En général, les mémoires sont adressables uniquement par octet (ce qui explique qu'un boolean prenne généralement 8bits et pas 1...). Donc tu te fais un tableau sous excel pour pouvoir t'y retrouver, genre 0=cout, 1=getline, etc... Rien que là, ca te fait 256 fonctions pour un octet, ce qui devrait suffire en principe. Mais si ca te suffit pas, pas grave, pour avoir la fonction numéro 257 par exemple, bah tu mets ton octet à 255, là ca veut dire que l'octet suivant servira aussi à définir l'id de la fonction. Donc résultat pour 257, t'as un premier octet à 255, et l'autre à 3. Attention par contre, c'est bien 3 et pas 2, puisque avec un seul octet tu peux encoder seulement 255 valeurs maintenant (de 0 à 254, le 255 étant réservé pour signaler que le bit suivant est dédié à l'id de la fonction). Donc tu pers une valeur d'adressage par octet, mais t'as plus de limite pour le nombre de fonctions, et globalement tu fais des économies monstres... (surtout si tu mets les fonctions les plus utilisés dans le premier octet).
Pas sur d'avoir été clair par contre, hésite pas si t'as pas tout saisi ^^"
De la meme facon, tes points virgules ils te bouffent un octet à chaque fois ! Pour la plupart des fonctions de bases, tu connais le nombre d'arguments et leur place en mémoire, donc suffit de tenir une liste de la taille des arguments pour chaque fonction, et paf, plus besoin de délimiteur ! Par exemple, pour la fonction addition entre deux chars, dans ton fichier t'as ca (je separe chaque octet) :
120 65 66 239 ...
Donc mettons que 120 c'est l'id de ta fonction addition de char, tu sais qu'elle prend deux char en argument, donc 2 octets, donc l'octet 239, peu importe ce que c'est, tu sais que t'en as pas besoin, et t'as pas eu besoin d'utiliser un séparateur !
Bon après bien sur ta fonction cout c'est plus compliqué, mais là faut faire intervenir des tableaux,,donc c'est différent,,et perso je vois pas du tout comment faire intervenir des arrays dynamiques de façon optimisée...

Voilà, ca vaut ce que ca vaut, puis bon franchement fait comme tu veux, ce genre de projet (vu que c'est assez useless en définitive, sauf pour apprendre) c'est perso, et c'est sans doute plus intéressant d'avoir un truc moyennement opti mais que t'as fait toi, plutôt que te faire ***** à essayer de reproduire un i7... Donc bonne chance

Ps : par contre arduino c'est d'une lenteur à devenir fou dès que tu fais intervenir Serial. Donc si tu veux test h24, pour un projet comme ca, faut trouver une solution... Je sais pas s'il existe des émulateurs arduino, perso ce que je compte faire c'est dev l'interpréteur en meme temps sur l'arduino et sur un émulateur maison : genre tu fais ton truc en c++, tu vois que ca marche sur le pc, et là tu le translate sur ton arduino, sinon c'est juste pas jouable...

Térence a écrit:

Comme je compte aussi faire un compilo/interpréteur ces vacances, j'avais aussi réfléchi un peu à tout ca. Rien sur papier, pas le temps, mais je vois a peu près comment faire le truc.
Si je peux me permettre, on peur surement faire mieux, et difficile de juger ton truc sur 5 lignes de codes, mais le format final prend beaucoup de place :/ Comme tu l'as dit toi meme, c'est pas très utile de modifier directement le truc, donc autant laissé tomber l'idée d'un truc lisible, ce qui te permettra de faire énormément d'économies.
Pour tes fonctions par exemple : là t'utilise 2 caractères, soit 16 bits (au moins, je sais pas commt marche l'encodage des que tu veux plein d'accents). A ta place, je travaillerais directement avec des numéros. En général, les mémoires sont adressables uniquement par octet (ce qui explique qu'un boolean prenne généralement 8bits et pas 1...). Donc tu te fais un tableau sous excel pour pouvoir t'y retrouver, genre 0=cout, 1=getline, etc... Rien que là, ca te fait 256 fonctions pour un octet, ce qui devrait suffire en principe. Mais si ca te suffit pas, pas grave, pour avoir la fonction numéro 257 par exemple, bah tu mets ton octet à 255, là ca veut dire que l'octet suivant servira aussi à définir l'id de la fonction. Donc résultat pour 257, t'as un premier octet à 255, et l'autre à 3. Attention par contre, c'est bien 3 et pas 2, puisque avec un seul octet tu peux encoder seulement 255 valeurs maintenant (de 0 à 254, le 255 étant réservé pour signaler que le bit suivant est dédié à l'id de la fonction). Donc tu pers une valeur d'adressage par octet, mais t'as plus de limite pour le nombre de fonctions, et globalement tu fais des économies monstres... (surtout si tu mets les fonctions les plus utilisés dans le premier octet).
Pas sur d'avoir été clair par contre, hésite pas si t'as pas tout saisi ^^"
De la meme facon, tes points virgules ils te bouffent un octet à chaque fois ! Pour la plupart des fonctions de bases, tu connais le nombre d'arguments et leur place en mémoire, donc suffit de tenir une liste de la taille des arguments pour chaque fonction, et paf, plus besoin de délimiteur ! Par exemple, pour la fonction addition entre deux chars, dans ton fichier t'as ca (je separe chaque octet) :
120 65 66 239 ...
Donc mettons que 120 c'est l'id de ta fonction addition de char, tu sais qu'elle prend deux char en argument, donc 2 octets, donc l'octet 239, peu importe ce que c'est, tu sais que t'en as pas besoin, et t'as pas eu besoin d'utiliser un séparateur !
Bon après bien sur ta fonction cout c'est plus compliqué, mais là faut faire intervenir des tableaux,,donc c'est différent,,et perso je vois pas du tout comment faire intervenir des arrays dynamiques de façon optimisée...

Voilà, ca vaut ce que ca vaut, puis bon franchement fait comme tu veux, ce genre de projet (vu que c'est assez useless en définitive, sauf pour apprendre) c'est perso, et c'est sans doute plus intéressant d'avoir un truc moyennement opti mais que t'as fait toi, plutôt que te faire ***** à essayer de reproduire un i7... Donc bonne chance

Ps : par contre arduino c'est d'une lenteur à devenir fou dès que tu fais intervenir Serial. Donc si tu veux test h24, pour un projet comme ca, faut trouver une solution... Je sais pas s'il existe des émulateurs arduino, perso ce que je compte faire c'est dev l'interpréteur en meme temps sur l'arduino et sur un émulateur maison : genre tu fais ton truc en c++, tu vois que ca marche sur le pc, et là tu le translate sur ton arduino, sinon c'est juste pas jouable...

Merci, à la base je voulais faire quelque chose qui passe en string lisible... Mais oui ça ne sert vraiment à rien :^p
C'est ce que je compte faire car tout est hors stock dans ce que je veux au shop arduino. Je compte pas utiliser le serial mais un écran LCD et un joystick (donc clavier virtuel, j'essaierai d'y faire confortable au possible). Oui, il y a pas mal d'émulateurs arduino dispo, mais j'en ai vu aucun pour les basés ARM (le Due entre autres, celui que je veux), seulement des AVR. Bon, il ne doit pas y avoir de grande différence, mais déjà la taille des int... Vu que les AVR sont en 8 bits (je crois) et les ARM en 32 bits / plus...
Demain j'essaierai de commencer l'interpréteur en C++ pour *nix et quand le moteur marchera, il sera donc prêt à inclure dans du arduino.

D'ailleurs, si on pouvait bosser à plusieurs/s'échanger des idées avec ça serait pratique. :p
Je suis souvent dispo sur IRC.

Fais gaffe, parce que la compilation est très lente, et pareil pour le "televersement", c'est particulièrement ******... Bon par contre j'ai remarqué que l'upload était plus rapide sur une méga que sur une uno, avec le due ca devrait aller encore plus vite (ca doit surtout dépendre de la fréquence du uC, parce que les 9600 bauds j'ai vraiment pas l'impression qu'il les atteint...).

Marrant, toi tu veux tout faire sur l'arduino, perso je fais le compilo sur pc et l'interpréteur sur arduino (et l'émulateur). Clairement je te conseillerais vraiment de faire en parallèle sur pc, franchement le temps que tu passera à convertir ton code c++ en c arduino sera largement rentabilisé par le temps que t'economisera sur les tests sur l'arduino...

Et ouaip, clairement, s'aider mutuellement ca peut qu'être bénéfique Tu l'aura remarqué, je suis pour ainsi dire jamais sur l'irc, j'ai vraiment pas le temps actuellement (bac, projets SI et ISN (srtout ca en fait ><), etc...). Par contre d'ici les vacances, j'aurais du temps, et là je pourrais venir m'incruster sur l'irc

Et ainsi naquit AsuOS \o/

Térence a écrit:

Fais gaffe, parce que la compilation est très lente, et pareil pour le "televersement", c'est particulièrement ******... Bon par contre j'ai remarqué que l'upload était plus rapide sur une méga que sur une uno, avec le due ca devrait aller encore plus vite (ca doit surtout dépendre de la fréquence du uC, parce que les 9600 bauds j'ai vraiment pas l'impression qu'il les atteint...).

Marrant, toi tu veux tout faire sur l'arduino, perso je fais le compilo sur pc et l'interpréteur sur arduino (et l'émulateur). Clairement je te conseillerais vraiment de faire en parallèle sur pc, franchement le temps que tu passera à convertir ton code c++ en c arduino sera largement rentabilisé par le temps que t'economisera sur les tests sur l'arduino...

Et ouaip, clairement, s'aider mutuellement ca peut qu'être bénéfique Tu l'aura remarqué, je suis pour ainsi dire jamais sur l'irc, j'ai vraiment pas le temps actuellement (bac, projets SI et ISN (srtout ca en fait ><), etc...). Par contre d'ici les vacances, j'aurais du temps, et là je pourrais venir m'incruster sur l'irc

Ce que tu dis sur le temps de compilation m'étonne car sans téléverser la compilation est quasi instantanée... Le due tourne à 80Mhz, pour le reste je ne sais pas. L'uno tourne à 18Mhz je crois.

Après oui y'a moyen d'émuler ou de faire en C++ direct, mais ce qui me chiffonnait c'est que je peux pas vraiment voir l'impact mémoire, et cpu que l'interpréteur/le compileur aurait sur un vrai Arduino. Ce que je voulais faire c'est un langage qui puisse être utilisé directement depuis l'interface ligne de commande de mon système d'exploitation, un genre de Bash (le nom est basé sur ça, d'ailleurs).

Bah je devrais bien le faire, plein de trucs sont hors stock >.< : http://store.arduino.cc/category/11 - Épreuve : Trouve les produits en stock! . Du coup moi l'Arduino ne va pas arriver avant quelques temps... Je ne l'ai même pas encore commandé (car ils ont eu la superbe idée de ne pas accepter les commandes des produits qui ne sont pas en stock).

D'ailleurs ça me fait penser, je pourrais utiliser un/deux écrans de ma DS Lite avec l'arduino. Si la connectique est pas trop chiante (<10 pins, visiblement d'après sur des photos sur google il y en a pas trop, assez cool à savoir. encore me faut-il ces débilités de vis à 3 branches que nintendo a eu la génialissime idée de mettre à côté de vis cruciformes sur la même console.) ça peut être cool pour avoir un clavier virtuel.

Pour ma part j'ai pas trop de 'taf jusqu'aux vacances (mise à part le brevet, mais j'y compte pas pour du travail, sauf l'HDA, huhu). Bref je commence d'ores et déjà.

Pour connaitre l'impact mémoire, simple, tu défini un array de byte (comme ca c'est comme en vrai, un adresse pour un octet) de la taille de ta mémoire arduino, et tu gère ca de la meme facon. Après effectivement pour le temps de calculer, c'est plus chaud à simuler... Mais bon comme dit, pour les tests c'est pas tellement gênant je trouve.
Étonnant ce que tu me dis pour la compil... Pour autant j'ai vraiment eu l'occasion de tests sur un certain nombre de pc des unos et megas, c'est vraiment lent..
Pas con l'histoire de la ds, si t'arrive à trouver comment ca marche ^^ limite ca te couterait moins cher qu'un écran tactile normal ^^ (50$ environ pour du 4"3 chez gameduino)

Ahah, tu va voir, seconde c'est encore plus la branlette je trouve Ah, et tant qu'à faire, je vais m'etaler : 20/20 pour l'hda au brevet \o/ (dali, le torero, go wiki et tu fais une diapo par élément ). Nan sérieux mec, vu que tout le monde bacle à moitié son truc, si t'as choisi un truc où ia de quoi dire, ia moyen d'avoir une pjtain de note!

Térence a écrit:

Pour connaitre l'impact mémoire, simple, tu défini un array de byte (comme ca c'est comme en vrai, un adresse pour un octet) de la taille de ta mémoire arduino, et tu gère ca de la meme facon. Après effectivement pour le temps de calculer, c'est plus chaud à simuler... Mais bon comme dit, pour les tests c'est pas tellement gênant je trouve.
Étonnant ce que tu me dis pour la compil... Pour autant j'ai vraiment eu l'occasion de tests sur un certain nombre de pc des unos et megas, c'est vraiment lent..
Pas con l'histoire de la ds, si t'arrive à trouver comment ca marche ^^ limite ca te couterait moins cher qu'un écran tactile normal ^^ (50$ environ pour du 4"3 chez gameduino)

Ahah, tu va voir, seconde c'est encore plus la branlette je trouve Ah, et tant qu'à faire, je vais m'etaler : 20/20 pour l'hda au brevet \o/ (dali, le torero, go wiki et tu fais une diapo par élément ). Nan sérieux mec, vu que tout le monde bacle à moitié son truc, si t'as choisi un truc où ia de quoi dire, ia moyen d'avoir une pjtain de note!

Oui mais je compte aussi faire du multithread donc plusieurs apps à la fois, je veux que l'impact en mémoire soit extrêmement minimal huhu.
Je prendrais quand même un écran normal car ceux de la DS ne sont pas vraiment grands. Je m'en servirais juste pour des infos en plus, ou pour placer plusieurs consoles à la fois et un écran virtuel.

Ouais mais je crois que toi c'était pas pareil que nous à l'époque. Maintenant on doit faire 5 œuvres et les apprendre et une au hasard sera choisie... Je trouve ça complètement débile, c'est juste un bon moyen de gaspiller du temps (vu qu'on prend une heure toutes les deux semaines pour y préparer), de l'énergie (y'en a qui vont réviser, alors encore réviser ça ) et de détruire (encore plus) la qualité des présentations... Bref j'ai quand même choisi des trucs qui me plaisent assez (ça va, car c'est assez moderne le thème de cette année, XXe siècle).

[HS]
l'HDA c'est
Mais la seconde, c'est
[/HS]

Pas mal tout ça, allez Asu, sors-nous un bon truc

Multithread c'est devrait être facile à gérer (tu fais plusieurs compteurs ordinaux), sauf pour ce qui est de l'accès à la mémoire, faut que ce soit un minimum synchro, perso j'ai pas trouvé de meilleure solution pour l'instant que de faire une fonction pour "interdire" le changement de thread sur un morceau de code.
Par contre avec ta Due fais gaffe, 3.3v c'est pas compatible avec la majorité des trucs de bases, faut une alim en plus à mon avis :/

Ouais, en plus en troisième, j'étais en "EISE", un machin expérimental avec plus de sciences, donc c'était encore différent... On choisissait une seule oeuvre sur laquelle on passait forcément, mais en contrepartie fallait aussi parler d'un truc en rapport avec les sciences (perso avec Dali j'avais genre les illusions d'optique), et les 4 autres on le faisait vite fait, ils nous posaient juste quelques questions... Par contre nous on avait pas d'heures pour le faire en cours...

Térence a écrit:

Multithread c'est devrait être facile à gérer (tu fais plusieurs compteurs ordinaux), sauf pour ce qui est de l'accès à la mémoire, faut que ce soit un minimum synchro, perso j'ai pas trouvé de meilleure solution pour l'instant que de faire une fonction pour "interdire" le changement de thread sur un morceau de code.
Par contre avec ta Due fais gaffe, 3.3v c'est pas compatible avec la majorité des trucs de bases, faut une alim en plus à mon avis :/

Ouais, en plus en troisième, j'étais en "EISE", un machin expérimental avec plus de sciences, donc c'était encore différent... On choisissait une seule oeuvre sur laquelle on passait forcément, mais en contrepartie fallait aussi parler d'un truc en rapport avec les sciences (perso avec Dali j'avais genre les illusions d'optique), et les 4 autres on le faisait vite fait, ils nous posaient juste quelques questions... Par contre nous on avait pas d'heures pour le faire en cours...

Une lib est déjà dispo pour faire ça, et elle est très légère. Je l'utiliserai et j'y ferai très simple. Une application qui tourne en temps réel, gère les inputs et les distribue et gère les problèmes (plus de thread actif : terminal qui a planté par exemple). Bref un truc qui part d'un principe simple et puissant. :p

Perso j'aurais largement préféré faire ça.

Ah oui ok, je vois, en fait tu peux faire tourner plusieurs apps en même temps, mais chaque app est monothreadée. Effectivement, si ia déjà la lib :b

Ouaip, je veux bien le croire, parce qu'effectivement, en préparer 5 correctement :/

Nouveau font, cette fois-ci il n'est pas monospace donc il prend vraiment peu de place, j'ai essayé de le rendre confortable à la lecture au possible.
Il inclut tous les caractères ASCII de base avec quelques en bonus (smileys, flèches, petits caractères pour indiquer un chargement, sélecteurs, et un petit symbole Arduino) - Bref largement assez pour une console.

Afficher tous les caractères dont la liste dispose ne requiert même pas la moitié de l'écran que je vais prendre pour mon Arduino (128*64 monochrome, oui j'ai changé d'avis sur l'écran à prendre, je prends un truc plus petit cette fois, mais derrière je prendrais un gros tas de boutons pour faire un clavier, héhé). Le font est tracé sur une image de la taille de cet écran. :p

Version sans bordures (pour voir l'aspect et ne pas détruire à jamais vos yeux pour essayer de lire une rangée de lettres) :


Versions avec bordures (pour voir la taille réelle, etc.) :


Petite démo : Hello world (agrandi par 2) :


Bref j'y préfère largement de cette manière comparé au monospace - Beaucoup plus clair, court et confortable, même si ça ajoutera une minuscule contrainte technique au code.
Après je ne sais pas trop comment je vais y inclure à mon système d'exploitation, c'est-à-dire comment le faire charger, huhu.

Quelques screens de mon projet d'ISN, que je dois rendre pour jeudi en 8 :p

Spoiler:

et l'éditeur :

Spoiler:

C'est vachement sympa ce que tu fais là Térence !

Merci :p
Par contre faut une sacrée config... :/ Les collisions bouffent pas mal, et dès que ia pas mal d'ennemis...
Je créerais un topic quand j'aurais passé l'épreuve.

Wow ! Joli, en effet
Ca se joue en infiltration ou en mode gros bourrin ?

Térence a écrit:

Merci :p
Par contre faut une sacrée config... :/ Les collisions bouffent pas mal, et dès que ia pas mal d'ennemis...
Je créerais un topic quand j'aurais passé l'épreuve.

Si tu veux à l'occasion j'essayerais de t'aider à optimiser un poil ton code java.

Linky> infiltration, mais comme tu peux faire tout péter au lance-roquette, la tentation est forte d'y aller en mode bourrin
Chloro> bah comme dit, c'est les collisions qui font pas mal *****, j'utilise des Area avec intersect. C'est les longs murs qui doivent bouffer pas mal, la pré-vérification AABB sert pratiquement à rien, faudrait redécouper les murs, mais ca me fait des petites bordures dégueulasse... Et l'IA, forcément, mais c'est pas encore fini donc je vais optimiser tout ca. Mais ouais, à l'occasion pourquoi pas ? ^^ Le truc que j'avais dû optimiser à fond, c'est les capteurs (caméra et laser), au départ ca me bouffait des tonnes, puis après un certain nombre d'optis, c'est redevenu correct.

Merci en tous cas

Ah c'est coo- voit l'icône de java sur le deuxième screen et voit windows 8 - HAAAAN