Hardcore Retrogaming

J'aime bien les 3 Super Mario bros pour des raisons differentes mais ils ont chacun un truc qui m'agace un peu donc je cherche des alternatives, le jeu de plateforme NES parfait (autre que les Ducktales).
J'ai tenté Gimmick (de Sunsoft qui fait vraiment pas mal de bon truc sur NES) et Little Samson qui semblaient tous les 2 tres prometteur en video et dont j'entendais du bien mais dans la pratique je trouve que ludiquement ca tiens pas, soit des gros defaut de gamedesign soit du level design insipide, bref ca arrive pas a la cheville d'un Ducktales qui tiens pourtant sur une cartouche 3 fois plus petites que ces jeux, c'est toujours ca qui est fou.
Kirby j'aime pas (et lui il fait 6 fois la taille d'un Ducktales, vraiment too much pour de la NES). J'ai fais aussi Adventure island 4 qui est en quelque sorte le monster land de la NES, j'aime bien, c'est mieux que ceux que j'ai cité mais il manque encore un petit quelque chose (toujours pareilles, ludiquement ca ne tiens pas face aux Ducktales malgres que ce soit encore une grosse cartouche) mais ca m'a fait rigolé que l'ultime arme du jeu soit la hache en pierre de Wonder boy smile

Donc si vous avez des idées.

Les jeux 8bit vieillissent quand meme mal ludiquement (par rapport aux jeux 16bit qui vieillissent pas), c'est difficile de trouver de vrai bon jeux en faisant abstraction de l'effet nostalgie.
Par contre en puzzle game les adventure of lolo c'est cool.

Ma copine s'est remise à jouer à Pharaon, elle squatte mon PC depuis plusieurs jours (heureusement Uncharted 4 est là).

Ca m'a redonné envie de jouer à Caesar III !!! Sierra la bonne époque.

Je cherche un outil pour faire de la capture d'ecran video sur mon PC. Je voudrais un truc qui permet de faire de la capture de mon ecran jusqu'a 60fps si nécéssaire et juste dans une fenetre qu'on delimite soit meme.
en gratuit j'avais pris CamStudio qui apparemment semblait etre le classique dans le domaine mais ca marche tres mal, y a aucune correspondance entre les reglages de framerates que tu fais et ce que tu obtiens (qui peine a depasser les 20fps meme sur une toute petite fenetre)
En fait je voudrais un truc aussi efficace que Fraps (avec lequel je capture sans probleme a 60fps et en HD) quite a ce que ca compresse tres peu pour etre leger en charge mais qu'on puisse definir la fenetre d'enregistrement dans notre ecran (ce que Fraps ne fait pas) et puis aussi un petit logiciel de montage basique tant qu'a faire.

OBS

https://jp9000.github.io/OBS/sources/windowcapture.html

Merci, ca m'a l'aire completement parfait.
En outils de montage gratos on m'a parlé de Pinnacle Videospin

Quelques nouveaux gif NES en vrac

Hardcore Retrogaming - Page 26 Rain_Effect

Hardcore Retrogaming - Page 26 Batman2_1

Hardcore Retrogaming - Page 26 Micro_Machine

Hardcore Retrogaming - Page 26 Afterburner

Hardcore Retrogaming - Page 26 Metal_Storm2

Hardcore Retrogaming - Page 26 Metal_Storm3

Hardcore Retrogaming - Page 26 Metal_Storm

Hardcore Retrogaming - Page 26 Batman_Tilset

Hardcore Retrogaming - Page 26 Crisis_F4

Hardcore Retrogaming - Page 26 Crisis_Force3

Hardcore Retrogaming - Page 26 Crisis_Force1

Hardcore Retrogaming - Page 26 Crisis_Force2

Hardcore Retrogaming - Page 26 Crisis_F3

Qu'est-ce que j'aimais bien ces petits effets de scrolling parallax sur plusieurs plans avec les 8 et 16 bits smile

Vlan!

Hardcore Retrogaming - Page 26 Shatter_Hand_FX

Hardcore Retrogaming - Page 26 Shatter_Hand

Hardcore Retrogaming - Page 26 Rade_Racer

Hardcore Retrogaming - Page 26 Rad_Racer_Mirroring

Hardcore Retrogaming - Page 26 Space_Harrier_Palette

Hardcore Retrogaming - Page 26 Space_Harrier

Hardcore Retrogaming - Page 26 3_DWorld_Runner

Hardcore Retrogaming - Page 26 Cosmic_Epsilon

Hardcore Retrogaming - Page 26 Cosmic_Epsilon2

Hardcore Retrogaming - Page 26 Cosmic_Epsilon3

Hardcore Retrogaming - Page 26 Cosmic_Epsilon4

Hardcore Retrogaming - Page 26 Summer_Carnival

Hardcore Retrogaming - Page 26 Summer_Carnival2

Hardcore Retrogaming - Page 26 Jackie_Chan

Hardcore Retrogaming - Page 26 Prince_Of_Persia

Hardcore Retrogaming - Page 26 Contra_IIISNES

Hardcore Retrogaming - Page 26 Aleste_SNES2

Hardcore Retrogaming - Page 26 Aleste_SNES1

Hardcore Retrogaming - Page 26 Aleste_SNES

Comme pour la serie précédente j'aurais plein de truc a dire sur chaque image mais comme pour la serie précédente j'ai trop la flemme. Pour l'instant j'archive en gif et en notes

Et comme pour la série d'avant, je me régale, je me pose des questions et je te remercie (enfin) !
super de mettre le contenu des tilesets ! les trics de ouf ! jamais j'aurais imaginé des jeux si beau sur nes !! j'ai pourtant bien joué sur nes, mais aussi bien raté des jeux visiblement smile2

Jacky Chan, (PCE) Super Alest, (snes) ... love3

keep sending the good stuff good

C'était quoi le shoot'm up snes en mode 7 qui en mettait plein les mirettes ?

il y avait aussi quelques prouesses techniques dans certains jeux de konami sur PCE (Parodius, twin bee, ...) et aussi hudson et nec avenue sur super CDROM² : Star parodia, et d'autres shoot...

quelques partages qui valent le détoure :

et les sound track de ses chefs d’œuvres de zic de JV pour l'époque :

Ys4:
https://youtu.be/X1UdAt_OcjU?list=PL0d3YQV7_Ia5jGbmHew2yImNRLJzGpTeO
#13, 19, 20, 21, 23, 26, 28 love2

34

, 37, 39

, 43 (reprise boosté d'une de Ys 1&2), 44, 45, 48 !! , 53, 54, 55,

Ys 3:
https://youtu.be/4BPTZHbvFy8?list=PL73B6C402EDFA57CA

Ys 1&2:
https://youtu.be/yELuvkU32Lg?list=PL714885386BC83971

Et un collector que je n'ai pas réussit à finir (en Jap) aux musiques toutes aussi superbes :

un top 50 avec une pub LOL de l'époque au début :

Doc 42 a écrit:: C'était quoi le shoot'm up snes en mode 7 qui en mettait plein les mirettes ?

Ce n'était pas Axelay ?

Doc 42 a écrit:: Et comme pour la série d'avant, je me régale, je me pose des questions et je te remercie (enfin) !
super de mettre le contenu des tilesets ! les trics de ouf ! jamais j'aurais imaginé des jeux si beau sur nes !! j'ai pourtant bien joué sur nes, mais aussi bien raté des jeux visiblement

Jacky Chan, (PCE) Super Alest, (snes) ...

C'est deja bien de reconnaitre les jeux.
Super Aleste je l'ai mis pour cette combinaison ingenieuse d'utilisation du HDMA et de l'offset per tile qui permet de faire cette effet qu'on peut pas reproduire avec la table de scroll de la MD pourtant si pratique (ca n'empeche pas de pouvoir le reproduire autrement avec une simple animation de tile mais c'est classe de l'avoir fait sans animation de tile, tout en distorsion).

Jackie Chan c'est pour illustrer les astuces d'utilisation des priorités sprite/background sur PCE et NES (Prince of persia) qui sont 2 machines tres semblables (la vrai Super NES c'est la PCE)

Citation :: C'était quoi le shoot'm up snes en mode 7 qui en mettait plein les mirettes ?

Axelay?
Celui que j'ai gifé sur NES c'est Cosmic Epsilon, je connaissais pas, tres impressionnant (et qui fonctionne avec les lunettes 3D de la Famicom)

Je me tate un peu en ce moment a faire de la video/micro sur le sujet. Ca pourrait etre pratique pour montrer certaines chose directement en enregistrant le PC et les emulateurs et en parlant dessus pour epxliquer (et profiter encore une fois de ma connection fibre maintenant que je peux uploader).
Pour l'instant j'ai encore la flemme donc ca sera pas pour tout de suite mais pour me motiver j'ai deja ouvert la chaine smile2

https://www.youtube.com/channel/UCyAdEBnIruZZnfDY1zwceVA

egb a écrit:: Ma copine s'est remise à jouer à Pharaon, elle squatte mon PC depuis plusieurs jours (heureusement Uncharted 4 est là).

Ca m'a redonné envie de jouer à Caesar III !!! Sierra la bonne époque.

Caesar III. J'ai passé beaucoup de temps sur ce jeu. Un de mes premiers sur PC love2

cool ta chaine upsi cool2

J'aime le titre !

J'attendrai Wink

Si il y a un outil pour le faire tu pourrais compiler tes GIF animés les uns à la suite des autres avec les titres des jeux en +

(oui, c'est bien Axelay le jeu auquel je faisais allusion ! Merci Rendering et Upsi tchin

j'ai été remater le niveau de la lave smile

)

Spoiler:

Cool merci. tchin

A l'époque, des programmeurs astucieux et imaginatifs connaissant parfaitement les limitations et spécificités techniques de chaque machine codées en bas niveau pouvait contribuer à faire grandement la différence.

Le contexte a beaucoup changé depuis. La compétence des codeurs n'a plus autant d'importance pour se démarquer. Pour faire du AAA, il faut des équipes énormes, des millions, et des outils performants pour faire la différence au détriment de l'investissement technique qui est mutualisé (Unreal Engine, CryEngine, Unity Engine, Fox Engine, Luminous Engine...) de la plupart des studios à cause de la convergence des hardwares devenu très complexe (combien de studio s'amuse à faire de l'assembleur sur PS4 ?) et du multiplateforme PC majoritaire.

Tout les un ou deux ans j'ai une envie de programmation mais comme j'ai tout oublié entre temps alors je change de machine ou de langage... la plutot que de reprendre le C++ (un peu l'usine a gaz je trouve) j'ai essayé le Python, vraiment tres sympa, ca m'a conquis sensei

.

Du coup comme premier programme python j'ai fais un programme qui decrypte les fichiers ROM du famicom disk pour en extraire un maximum d'information. Je m'etais pas mal intéressé au Famicom Disk mais me manquait des informations plus précise et général sur l'utilisation et les disquettes donnent pas mal d'informations dans leurs metadata.

le FDS utilise des disquettes (qui ont 2 faces, et qu'il faut retourner manuellement) qui ne contiennent pas de secteur ou de track, y a juste une seul piste en spiral comme un CD sauf que sur un CD tu peux quand meme faire des acces random (meme si c'est lent), sur les disquettes FDS non. a chaque acces tu lis l'integralité de la piste (donc de la disquette) pour récuperer les fichiers qui t'intéresse.
Donc c'est un systeme tres simplifier que ce soit pour la mecanique du lecteur (une piste en spirale) que pour la gestion des fichiers (pas d'acces random) mais qui correspond bien au besoin puisque l'usage le plus classique va etre de charger l'integralité (ou quasi) de la face A dans la ram interne (qui emule la ROM cpu et la ROM gpu d'une cartouche 40ko classique sans mapper) au boot de la machine et donc c'est surtout sur cette premiere tache qu'il faut assurer l'efficacité car elle va s'effectuer a chaque fois que tu lance ton jeu donc le principale c'est que cette etape la soit rapide. Cette grosse simplification du systeme (et la faible densité) leur a sans doute permis d'avoir un chargement complet rapide (c'est 6 seconde le loading) a cout faible.

Ce qui est amusant dans la gestion des fichiers des disquettes FDS c'est que ce n'est pas le programme mais chaque fichier qui decide tout seul si ils doivent etre charger au boot et surtout a quelle endroit (quelle adresse mémoire), tout ca est inscrit dans leur metadata ce qui est assez original (et intéressant car ca nous donne des informations précieuse), y a aussi des noms de fichier dans les metadata mais facultatif, ce n'est pas utilisé pour la gestion des fichiers (qui sont géré uniquement par leur ID, ils peuvent d'ailleurs avoir la meme ID, il se distingue de toute facon par l'adresse a laquelle ils vont s'auto-charger) mais les nom de fichier nous donne aussi des informations donc ca vallait le coup de les récupérer aussi.

Donc mon petit programme te demande un path (vers un dossier) et il va chercher toute les ROM FDS contenu dans ce dossier (en séparant celle qui sont des ROM officiel de celle qui ne sont pas officiel) et les analyser pour extraire un max d'info et sortir 4 fichiers. un fichier qui contient les details de chaque disquettes et un autre qui contient plutot un résumé avec quelques stats (et pareille pour les ROM non officiel)
Faut rappeler que Metroid, Zelda, Castlevania, Kid Icarius, Mario 2... sont des jeux qui ont ete concu pour le Famicom Disk avant d'avoir le droit a des portages cartouches donc c'est quand meme intéressant de s'y intéresser.

Par exemple pour Metroid ca donne ca en version détaillé

Spoiler:

Y a les informations lié a chaque face et les informations de chaque fichier avec notamment le nom, l'adresse a laquelle il est destiné (et j'ai meme précisé si c'etait la WRAM ou la VRAM et meme si c'etait dans le tileset ou la tilemap). J'ai verifié et indiqué aussi si jamais c'etait un fichier vide (souvent le cas pour les fichier de sauvegarde qui se trouve en fin de disquette) ou quand c'etait un fichier qui contient le text de licence Nintendo qui s'affiche au debut et qui sert de controle. et d'autre type d'information.
Et a la fin y a la quantité total de donnée de la face. y a 3 chiffres different. le total de fichier, le total en ajoutant aussi les metadata, et le total juste de fichier de donnée pour le jeu (donc sans les fichier vide ou fichier de licence) qui est le chiffre qui m'intéresse.

En version résumé (sans les détails) ca donne ca (sur les jeux licencié)

Spoiler:

Avec a la fin quelques stats

Citation :: average bytes per side: 48026 (max: 54608)
average bytes per file: 3855 (max: 32896)
average files per side: 12 (max: 40)

Faut compter en général 50Ko par face. Ca en fait quand meme la disquette avec la plus faible densité que je connaisse. J'ai pas trouvé historiquement de disquette plus faible. Du coup le support s'est tout de suite fait rattrapé par les cartouches et son atout s'est vite limité a ses capacités d'ecriture.

Les fichiers complets
https://drive.google.com/open?id=0B399kteofpYuUEhjZTdDczhZWmM
https://drive.google.com/open?id=0B399kteofpYuMkxWODFBR3h6NVE
https://drive.google.com/open?id=0B399kteofpYudzBJR202VHFhdWM
https://drive.google.com/open?id=0B399kteofpYuYjhGTkRIaFF1TE0

Je viens de decouvrir le nom des lunettes Master System au bresil smile2

Hardcore Retrogaming - Page 26 Oculos203d20caixa20frente

Je suis tombé sur des infos techniques détaillés du System 16 de Sega (c'est pas souvent sur le hardware Arcade) qui est donc le systeme des vieux classique de Sega (Golden axe, Shinobi, Fantazy Zone, Alteread Beast...) et proche du system 1 (celui des encore plus vieux classique comme Wonder Boy, Choplifter...) et j'ai vu des choses intéressantes.

http://cgfm2.emuviews.com/txt/s16tech.txt

Hardcore Retrogaming - Page 26 System16b_motherboard

Hardcore Retrogaming - Page 26 System16b_motherboard

Notamment j'ai ete surpris de decouvrir que le background est en 3bpp (donc 8 couleurs par tuile) alors que la norme c'est plutot le 4bpp (16 couleurs par tuile) de loin, meme la Master System est full 4bpp (meme si c'est la premiere et que c'etait avant-gardiste) du coup ca fait bisarre de se dire que le System 16 qui est quand meme un system puissant ne supporte pas le 4bpp sur le background alors que la SMS le fait.

Alors évidemment ca n'empeche pas le system 16 d'exploser la Master System meme sur le background car la difference entre les consoles et l'arcade c'est toujours le nombre de palettes, ici t'as une bibliothèque 128 palettes locales pour le background donc tu peux avoir des palettes sur mesure pour la moindre tuile alors que sur une Master System c'est en gros une seul palette local a partager avec toutes les tuiles du background donc tu peux pas exploiter le 4bpp. Le system 16 peut donc quand meme afficher beaucoup plus de couleur (et infiniment plus de nuance, c'est un DAC 16bit contre 6bit sur SMS) et en plus il a 2 layers de background.
Ce format 3bpp est suffisant la plupart du temps pour des tuiles de background (les sprites sont en 4bpp) tout en permettant d'augmenter la taille de ton tileset de 33% avec la meme quantité de ROM donc ca peut etre un bon compromis. On peut comprendre ce choix d'optimisation.

Mais c'est intéressant de voir concretement un systeme 3bpp car c'est pas courant et justement je me suis toujours dit qu'une NES avec du 3bpp (au moins pour les sprites) au lieu de son 2bpp ca aurait ete top car autant 3 couleurs pour un sprite tu peux rien faire, autant 7 couleurs (3bpp) pour un sprite c'est nickel, le 4bpp de la SMS est too much.

Sauf qu'il y avait peu de chance de voir ce genre de format intermediaire sur console car c'est compliqué le 3bpp c'est un format pas optimal a manipuler.
Deja on comprend bien que des pixels avec une profondeur de 3bit c'est compliqué a caser dans un octets. du 2bpp c'est simple tu met 4 pixels dans un octets car 4x2bit = 8bit, pour du 4bpp t'en met que 2. du 3bpp tu peux pas mettre 3 pixels dans un octets (ca fait 9bit) et si t'en met 2 ca fait enormement de gachie (ca consommerait autant que du 4bpp) donc aucun interet.
Pour ce probleme la ca fait longtemps qu'il y a la solution deja utilisé sur toutes les consoles, c'est le format bitplan ou chaque octets contient systematiquement les information d'un groupe de 8 pixels (que ce soit du 1bpp, 2bpp, 3bpp, 4bpp...) mais seulement 1bit par pixel et donc selon la profondeur du pixels va falloir cumuler plusieurs octets. Par exemple une tuile 2bpp sur NES est en gros composé de 2 tuile 1bpp, ou 2 bitplan. Ca simplifie le probleme pour le GPU qui quelque soit le format aura toujours son groupe de 8 pixels par octets chargé, faudra juste multiplier les acces selon la profondeur des pixels (en contrepartie le bitplan est un format galère a traiter en software avec le CPU puisque les pixels sont dispersé bit par bit donc c'est destiné a des machines qui s'appuie sur des fonctions graphiques cablés en hard, le bitplan on le croise rarement sur micro)

Mais le format bitplan est pas suffisant pour rendre le 3bpp pratique a manipuler. Faudrait aussi que l'adressage des tuiles reste toujours un mutliple d'une puissance de 2. par exemple une tuile 4bpp 8x8 c'est 32 octets c'est un multiple d'une puissance de 2 et qu'on va donc retrouver dans l'adressage des tuiles. on aura en mémoire une tuile tout les 32 octets et donc calculer l'adresse de la tuile numeros 27 par exemple revient a simplement multiplier 27 par 32 et en binaire quand on multiplie par une puissance de 2 ca revient juste a un décalage de chiffre exactement comme quand on multiplie par 10 ou 100 en décimale.
une tuile 2bpp c'est 16 octets donc la aussi ca marche tres bien, mais une tuile 3bpp c'est 24 octets et multiplier par 24 en binaire c'est une tout autre histoire (c'est comme comparer une multiplication par 10 et par 24 en décimale, c'est pas du tout pareille comme exercice, essayez de tete)

Sur le System 16 qui est de l'arcade ils reglent le probleme de facon simple. Deja toutes les tuiles sont en ROM et y reste car sont accessible directement par le GPU, y a jamais besoin de les deplacer en RAM pour les utiliser comme sur console en général donc pas de deplacement de tuile, le probleme reste confiné a l'adressage de la ROM mais la NES aussi permet cette configuration (les tuiles fixé en ROM).
Ici ce qui va faire la difference c'est qu'en Arcade ils utilisent plein de petit chip de ROM et pas juste un seul gros chip comme dans une cartouche console du coup ils peuvent se permettre de disposé plein de ROM en parallele et donc ici ils mettent les ROMs par groupe de 3 en parallele, une pour chaque bitplan du coup il se font sur mesure un bus 24bit (au lieu de 8bit) avec donc des acces par mot de 24bit qui contiennent en un seul coup les 3 bit plan d'un groupe de 8 pixels et donc l'adressage retombe sur un multiple d'une puissance de 2. Plus de probleme.

Voila pourquoi ce format 3bpp batard peut etre un bon compromis en Arcade (optimisé la quantité de ROM reste le nerd de la guerre meme en arcade, y en a pas tant que ca, un Shinobi Arcade c'est seulement 1Mo par exemple) mais pas optimal sur console alors que c'est la qu'il aurait ete bien utile sur la periode 8bit, a defaut il a fallu se contenter du contraignant 2bpp (NES) ou du gourmand 4bpp (SMS) sans intermédiaire.

Par contre niveau sprite ca defouraille. C'est vraiment la que se crée tout le temps le gouffre entre arcade et console de salon. on passe de 64 pixel-sprite par scanline sur Master system a 800 sur le system 16. On retrouve d'ailleurs cette difference au niveau de la repartition des ressources ROM entre sprite et background (le System 16 permettant de bien distinguer les 2 puisqu'ils utilisent des configuration de ROM differente, c'est pratique) ou l'on constate sur les jeux System 16 qu'il y a bien plus de data sprite que de data background (Golden Axe le plus frappant avec 4 fois plus de sprite que de background) alors que sur console 8bit ca va etre plutot l'inverse.

Et les sprites sur le system 16 sont assez particulier, c'est pas un assemblage de tuiles (et de bitplan) ni meme des formats classique genre 16x16, 32x32, 64x64. non les metadata du sprite pointe directement une adresse de debut et de fin dans les bank de sprite et tu peux ainsi definir directement un bloc bitmap de la taille que tu veux et qui sert de sprite.
Alors pas tout a fait car t'as une granularité de 4 pixels (alignement 16bit) sur la largeur donc la largeur du sprite est un mutliple de 4 (-1) mais sur la vertical tu choisie la dimension que tu veux au pixel (a la ligne) et le max etant 256x256 mais ca laisse donc beaucoup de liberté de format de sprite.
Les sprites sont 4bpp (c'est necessaire d'autant qu'ils peuvent etre gros contrairement au tuile 8x8 du background ) sauf qu'en plus de perdre une couleur pour la transparence (couleur 0) ici tu perd une autre couleur (couleur 15) qui sert de marqueur pour indiquer la fin d'une ligne de sprite. Ca c'est assez bisarre, l'information sur la largeur du sprite n'est pas dans ses metadatas mais integré dans le flux de pixels de chaque ligne de la pattern du sprite, faut que chaque ligne du sprite se termine par un pixel de couleur 15 (comme le code "saut de ligne" dans du texte). J'ai pas bien saisie l'avantage de ce choix. et du coup sur les 16 couleurs il n'en reste plus que 14 effective donc meme pour les sprites c'est pas tout a fait du full 4bpp.
Par contre la encore t'es tres confortable en nombre de palette local, t'en a 64 pour les sprites donc en gros chaque sprite peut avoir sa propre palette (dans les fait les jeux on l'aire d'utiliser qu'une douzaine de palette, ca a l'aire souvent too much le nombre de palette local en arcade)

Je sais pas si y a des gens qui programmes en Python ici? C'est vraiment tres cool comme langage. Tres simple d'acces (c'est un langage interpreté donc pas de prise de tete avec les compilo et y a une console pour tester au coup par coup les lignes de commande, verifier un typage apres tel manipulation... parfait pour apprendre), tres evolué (et tres objet) donc a l'inverse d'un assembleur NES, tres lisible aussi (c'est la priorité de la philosophie Python), tres bien documenté (tres tourné vers l'apprentissage) et tres bien fournis en fonction par defaut (on peut vraiment tout faire avec le build par defaut).
Je pense que c'est parfait comme complement retro-gaming pour faire des outils ou traiter/transformer des données d'autres sources ou outils surtout quand c'est pour un usage tres occasionnel, je pense que c'est un langage sur lequel on peut revenir facilement apres de longue pause donc nickel pour dépanner ponctuellement quand un besoin se présente en hobby.

Par exemple en une seul ligne comme ca:

Code:: fds_files = [name for name in all_files if name[-3:] == "fds" and name.count("Unl") == 0]

Je fais le trie de ma liste de fichier pour enlever les fichiers qui ne sont pas des ROM Famicom Disk et parmis les ROM FDS enlever celle qui ne sont pas officiel. Tout ca avec une simple ligne.
Quand tu connais bien le langage je pense que tu dois pouvoir faire des truc tres rapidement.

upsilandre a écrit:

Je sais pas si y a des gens qui programmes en Python ici? C'est vraiment tres cool comme langage. Tres simple d'acces (c'est un langage interpreté donc pas de prise de tete avec les compilo et y a une console pour tester au coup par coup les lignes de commande, verifier un typage apres tel manipulation... parfait pour apprendre), tres evolué (et tres objet) donc a l'inverse d'un assembleur NES, tres lisible aussi (c'est la priorité de la philosophie Python), tres bien documenté (tres tourné vers l'apprentissage) et tres bien fournis en fonction par defaut (on peut vraiment tout faire avec le build par defaut).
Je pense que c'est parfait comme complement retro-gaming pour faire des outils ou traiter/transformer des données d'autres sources ou outils surtout quand c'est pour un usage tres occasionnel, je pense que c'est un langage sur lequel on peut revenir facilement apres de longue pause donc nickel pour dépanner ponctuellement quand un besoin se présente en hobby.

Par exemple en une seul ligne comme ca:

Code:: fds_files = [name for name in all_files if name[-3:] == "fds" and name.count("Unl") == 0]

Je fais le trie de ma liste de fichier pour enlever les fichiers qui ne sont pas des ROM Famicom Disk et parmis les ROM FDS enlever celle qui ne sont pas officiel. Tout ca avec une simple ligne.
Quand tu connais bien le langage je pense que tu dois pouvoir faire des truc tres rapidement.

Oui, je l'utilise un petit peu (sur les raspberry pi c'est surement le langage le plus utilisé).
C'est un peu le nouveau Basic, en quelque sorte, c'est utilisé un peu partout.

C'est ce que je m'etais dit. C'est le basic des temps moderne.
Si vous n'etes pas programmeur et que vous voulez vous essayer a la programmation en dilettante faite du python c'est tres bien. Et pour les programmeur aussi je pense que c'est intéressant en terme de rendement.

je connais (appris en 2015, depuis le temps qu'on me le conseillait) et j'aime bien. C'est un langage objet (interprété) orienté traitement complexe de données qui ambitionne d'être aussi simple que le langage naturelle.
C'est effectivement hyper puissant ce que tu peux faire en peu de ligne et c'est idéale pour manipuler des fichiers textes ou binaires formatés, faire des tris, des listes, manipuler une petite DB, etc... j'ai un cours... ou plutôt j'avais un super cours ... je vais chercher si je retrouve ça. je te tiens au courant Wink

C'est un peu le fils du java et du basic avec une ambition d'un ancêtre lointain : le cobol et ses capacités de manipulations de données XXL (mais bcp + facilement).

Et en plus c'est libre et multi plate-formes, si tu as un mobile android ou iOS, tu as moyen de dev dessus smile2

Doc 42 a écrit:: j'ai un cours... ou plutôt j'avais un super cours ... je vais chercher si je retrouve ça. je te tiens au courant

peut etre pas la peine, y a deja de quoi faire sur le net. Et puis plus que des court ce qu'il me faut c'est des petits projets pour pratiquer, la j'ai pas d'idée de truc vite fais qui m'interesserait et pas envie de faire des tuc juste pour faire des truc.
Faudrait que je reprenne le dev sur NES ca me ferait un prétexte pour faire des outils en Python (et touché un peu aux fonction d'interface graphique, ca doit etre bien utile aussi)

» Retrogaming - emulation
» Hardcore Retrogaming