Forum Programmation.c++ pre-realease de battle-rage un jeu de combat a la street fighter.

Posté par Linuxator (site web personnel) le 20 octobre 2016 à 07:07. Licence CC By‑SA.

Étiquettes :

oct.

2016

Salut les C++,

je vous annonce de part ce présent message la pre-release de ma dernière création:

battle-rage: un jeu de combat en 2D a la street fighter écrit en C++ avec la bibliothèque sdl2, sdl2_image, sdl2_ttf et sdl2_mixer.

1. Choisissez le mode de jeu:

Player vs Computer.
Player vs Player.
Computer vs Computer.

2. Puis choisissez votre combattant parmi les 16 combattants disponibles ainsi que votre adversaire ou laisser l'ordinateur tirer au hasard.

3. Combattez dans plusieurs rounds: chacun un combat a mort (plus de points de vie). Maximum 3 rounds.

NOTE: Une manette PC est requise pour jouer a battle-rage !

Chaque combattant est dotée de propriétés:

Rapidité.
Agressivité.
Force.
Résistance.

J'ai pris les images des 16 combattants (personnages) d'un jeu de combat analogue pour XBox 360: NeoGeo Battle Coliseum sur un site de sprites.

Vous pouvez retrouver les personnages dans l'index de mon site.

TECHNIQUE:

J'ai stocker des séquences d'images dans une liste chaînée simple: std::forward_list<SDL_Texture*>

puis j'ai stocker cette structure de données dans une table de hachage:
std::unordered_map<int8_t, std::forward_list<SDL_Texture*>> afin de pouvoir look-up les coups des combattants.

Je me suis demander tout au long du développement est-ce que il est mieux de d'utiliser un type int8_t (char) ou un type uint8_t (unsigned char) ???

J'ai penser que le type signé est plus naturelle pour un ordinateur malgré que il faut une opération supplémentaire a chaque fois: le contrôle du signe.

Mais par contre avec un type signé l'on peut utiliser l'option d'optimisation: -fno-signed-zeros ???

J'ai fait un véritable effort sur le packaging:

Version Windows 64 bits: fichier *.exe auto-extractible.
Version Linux: *.deb et *.rpm
Version tarball: un tarball avec les autotools.

Une manette PC est requise pour jouer a battle-rage !

D'ailleurs j'ai pas mal galérer la dessus car je me suis basé sur le Input_Handler de Shaun Mitchell auteur du livre: SDL Game Development. Que j'ai amélioré !

Je suis ouvert a toute forme de critiques, remarques, conseils, etc…

Merci pour vos réponses.

PS: Ca y est: j'ai vendus mon âme a C++ car l'exécutable fait plus de 5 Mo (non-stripped) alors que en C cela ferai que quelques centaines de Kilos.

# Liens

Posté par jnanar (site web personnel) le 20 octobre 2016 à 08:33. Évalué à 1.

Bonjour,

Bravo pour le lancement du jeu mais les liens du post ne fonctionnent pas. Pourrais-tu les réintroduire dans un commentaire?
- [^] # Re: Liens
  
  Posté par Framasky (site web personnel) le 20 octobre 2016 à 08:56. Évalué à 4.
  Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
# Mammouth

Posté par papap le 20 octobre 2016 à 08:49. Évalué à 2.

"j'ai vendu mon âme à C++ car l'exécutable fait plus de 5 Mo (non-stripped) alors qu'en C cela ne ferait que quelques centaines de Kilos."
Je plussoie,ça fait un moment que je l'avais remarqué.
Sinon, au final,le jeu n'est pas sous licence libre donc ?
- [^] # Re: Mammouth
  
  Posté par Framasky (site web personnel) le 20 octobre 2016 à 08:57. Évalué à 3.
  
  Si ! En GPLv3. Par contre je ne sais pas si les graphismes sont libres car en dehors du dossier contenant la licence.
  
  Being a sysadmin is easy. As easy as riding a bicycle. Except the bicycle is on fire, you’re on fire and you’re in Hell.
  - [^] # Re: Mammouth
    
    Posté par Exosta le 20 octobre 2016 à 11:23. Évalué à 2.
    
    Ça m'étonnerait que les graphismes soient libres, c'est un mélange de personnages de Garou: Mark of the Wolves et Fatal Fury (j'en loupe peut-être d'autres).
    - [^] # Re: Mammouth
      
      Posté par Linuxator (site web personnel) le 20 octobre 2016 à 17:59. Évalué à 1.
      
      Merci pour vos réponses et bien pour éluder le mystère:
      
      Toutes les images a part les joueurs, sons et musiques vienne de ce site: http://opengameart.org
      
      Et les licences des ressources de ce site sont:
      
      License(s)
      CC-BY 3.0
      CC-BY-SA 3.0
      GPL 3.0
      GPL 2.0
      OGA-BY 3.0
      CC0
      LGPL 3.0
      LGPL 2.1
      
      Je pense quelles sont toutes libres, je crois.
      
      Sinon les images des joueurs viennent de ce site: www.spriters-resource.com et si c'est sur un site de sprites connus il ne doit pas y avoir de problème.
      
      Et il ont cas mettre les licences et des README dans les archives comme je l'ai fait lorsque j'ai renommer et re-packager les images des joueurs.
      
      Et le problème comme souvent dans ce cas est que il n'y pas de README et/ou de texte licence avec l'archive que tu télécharge malgré que j'en ai bien trouver quelques une dedans.
      
      Sinon pour jnanar: j'ai eu le temps de réparer les liens (j'avais mis des apostrophes entre les ()) et merci pour le compliment.
      
      Sinon pour papap: et oui malgré que j'ai ce genre de structures de données en C sauf le tableau grossissant (std::vector) mais si l'on strip le programme il fait quelque centaines de kilos.
      
      Merci pour vos réponses.
      - [^] # Re: Mammouth
        
        Posté par jihele le 21 octobre 2016 à 09:38. Évalué à 5.
        
        Sinon les images des joueurs viennent de ce site: www.spriters-resource.com et si c'est sur un site de sprites connus il ne doit pas y avoir de problème.
        
        Et il ont cas mettre les licences et des README dans les archives comme je l'ai fait lorsque j'ai renommer et re-packager les images des joueurs.
        
        Et le problème comme souvent dans ce cas est que il n'y pas de README et/ou de texte licence avec l'archive que tu télécharge malgré que j'en ai bien trouver quelques une dedans.
        
        Ouch.
        
        Il est à peu près évident que les sprites des jeux ne sont pas libres. Et ce n'est pas la faute de l'ayant droit si un site les balance sur internet sans y mettre de licence. Sauf libération par SNK, les personnages de Fatal Fury ne sont pas libres.
        
        Après rien n'empêche de faire un moteur de jeu libre et de le distribuer sans les images non libres, ce ne serait pas le premier. Quitte à indiquer comment récupérer des images sur le site de sprites.
        
        [^] # Re: Mammouth
        
        Posté par Linuxator (site web personnel) le 22 octobre 2016 à 06:12. Évalué à 0.
        
        Ce ne sont pas les personnages de Fatal Fury,
        
        les personnages de Fatal Fury ne sont pas libres.
        
        Mais les personnages de NeoGeo Battle Coliseum.
        
        Bon sachant que c'est un jeu de XBox ils ne sont peut-être pas libre mais dans ce cas le site: www.spriters-resource.com devrai fermer.
        
        Car la XBox c'est bien Microsoft et Microsoft c'est du propriétaire.
        
        Et sur le site www.spriters-resource.com ont peut choisir la console dont ont veut récupérer les sprites (merci de bien vouloir suivre les liens).
        
        Malgré que je pense que c'est Microsoft qui devrai fermer, ce qui n'arrivera pas au vue de leur domination mondiale, au vue de leur politique.
        
        Sinon deux Questions:
        
        Si jamais ces images ne sont pas libres, est-ce une raison pour ne pas jouer a mon jeux ?
        
        Que veut dire ce SNK qui revient aussi sur d'autres sites (merci de bien vouloir mettre la signification d'une abréviation) ?
        
        Merci pour vos réponses.
        
        [^] # Re: Mammouth
        
        Posté par papap le 22 octobre 2016 à 12:11. Évalué à 2. Dernière modification le 22 octobre 2016 à 12:16.
        
        On peut très bien jouer à ton jeu pas libre. On le classe alors en "partiellement libre". Ca n'enlève en rien son intérêt joualistique. D'ailleurs, la plupart des joueurs se contrefoutent de ces notions de licences.
        
        [^] # Re: Mammouth
        
        Posté par jihele le 24 octobre 2016 à 09:55. Évalué à 4.
        
        Ce ne sont pas les personnages de Fatal Fury, […] Mais les personnages de NeoGeo Battle Coliseum.
        
        Mea culpa…
        
        Bon sachant que c'est un jeu de XBox ils ne sont peut-être pas libre mais dans ce cas le site: www.spriters-resource.com devrai fermer.
        
        C'est pas parce que ce site n'est pas carré sur les licences qu'on peut faire n'importe quoi avec son contenu.
        
        Si jamais ces images ne sont pas libres, est-ce une raison pour ne pas jouer a mon jeux ?
        
        Non, c'est juste une raison pour empêcher sa redistribution complète (moteur + graphiques) sous licence libre. Mais comme c'est compliqué de faire des graphiques, ça peut être un moindre mal qui permet la diffusion d'un moteur libre, donc c'est mieux que rien.
        
        Que veut dire ce SNK qui revient aussi sur d'autres sites (merci de bien vouloir mettre la signification d'une abréviation) ?
        
        Sans déconner…
        
        https://en.wikipedia.org/wiki/SNK
        https://en.wikipedia.org/wiki/Neo_Geo_(system)
        
        [^] # Re: Mammouth
        
        Posté par Nerach le 08 novembre 2016 à 01:02. Évalué à 1.
        
        Les personnages suivant sont issue de la serie des Fatal Fury: Terry Bogard, Mai Shiranui, Kim Kaphwan, Geese Howard, Tung Fu Rue, Jin Chonshu, Jin Chonrei, Rock Howard, Hotaru Futaba.
        
        Les autres personnages sont issue d'autres titres de SNK tel que King Of Fighter, Metal Slug, Samurai Shodown, World Heroes, etc…
        
        Plus d'infos sur la page de NeoGeo_Battle_Coliseum (en) sur Wikipedia ou sur le site officiel (jp)
        
        Tous les personnages de NBC appartiennent à SNK playmore.
# C++ type et performances

Posté par Space_e_man (site web personnel) le 20 octobre 2016 à 15:26. Évalué à 2. Dernière modification le 20 octobre 2016 à 15:27.

… est-ce que il est mieux de d'utiliser un type int8_t (char) ou un type uint8_t (unsigned char) ?

Franchement, à moins que tu ne vises un microcontrôleur avec 64 ko de mémoire vive, utilise le type int tout simplement. Je serait pas étonné que pour un microprocesseur 64 bits, manipuler de simple octet soit plus compliqué qu'un int, fut-il sur 64 bits, en rapport avec la taille de ta texture, c'est rien… Éventuellement le type unsigned.

C'est pareil pour forward_list et unordered_map, par soucis de lisibilité du code, j'utiliserais simplement list et map. Sauf si tu devais stocker plusieurs milliers d'entités (particules), ça va pas être super significatif sur les performances globales.

Quant à l'option fno-signed-zeros, elle concerne les flottants…
- [^] # Re: C++ type et performances
  
  Posté par Linuxator (site web personnel) le 20 octobre 2016 à 18:10. Évalué à 0.
  A mince pour l'option d'optimisation: -fno-signed-zeros.
  
  Mais même si c'est futile (différence entre int8_t et uint8_t) j'y tiens car:
  - A chaque fois perdre 3 octets (différence entre un int et un int8_t).
  - Et vérifier le bit du signe a chaque fois alors que ce n'est pas nécessaire, c'est bête.
  Car j'avais le problème dans un autre programme (Edip: Easy digital Imaging Processing) que je n'avais besoins que des valeurs -1, 0, 1: une sorte de tribooleanisme:
```
#ifdef TRIBOOL                 /**  The idea is to make a trilogic boolean type. **/
#include <stdint.h>

/**  This doens't really make sens but we can do this
  *  in assembly with (a one or two) bit test feature...
  *
  *  If you don't get interest in my idea, simply erase
  *  this, on the other hand contact me,
  *
  *  at mail address: <mrcyberfighter@gmail>
  *
  *****************************************************/

typedef int_least8_t tbool;

tbool tb_minus  =  -1   ;
tbool tb_none   =   0   ;
tbool tb_plus   =   1   ;

#endif
```
  Tu peut en lire plus ici, dans les source de mk-project.
  - [^] # Re: C++ type et performances
    
    Posté par benja le 21 octobre 2016 à 02:59. Évalué à 3.
    Sans répondre directement à ta question (qui demande une connaissance de l'architecture sous-jacente, x86 je suppose dans ton cas), quelques remarques:
    - premature optimization is the root of all evil. Dans ton cas, et vue la complexité des différentes couches utilisées par ton application, tu peux simplement arrêter de te poser la question car tu ne verras probablement pas la différence (sauf juste par curiosité, pour la beauté du geste ou pour apprendre :p)
    - mesure, mesure, mesure. toute spéculation ne vaut rien dans qu'elle n'a pas été mesurée.
    Sinon pour répondre à ta question de int signed vs unsigned, j'ai comparé la sortie de gcc des deux types d'addition, il n'y a aucune différence (merci la représentation en complément à 2)… "La vérification du signe" (je me demande bien ce que tu veux dire par là ??) est faite de manière automatique avec la mise à jour du registre des flags. Btw, le C est indéfini en ce qui concerne les overflows, donc bon si tu ne testes pas dans ton code, le compilo ne va pas rajouter du code par magie pour faire quelque chose d'indéfini. Ça peut par contre avoir une incidence sur l'optimisation de certains tests que tu aurais toi-même écrits. Genre si tu fais "if (x > 0)" avec x unsigned, le compilo peut supprimer le test (désolé pour cet exemple absurde je n'en ai pas de meilleur sous la main).
    
    En ce qui concerne la taille des données, "int" (signé ou non-signé) est sensé être la représentation la plus efficace pour le cpu cible. De plus, ce que tu vas gagner en utilisation mémoire tu risques de le perdre en faisant des accès non-alignés (bien que x86 semble moins pénalisant que d'autres archis). Aussi avec une représentation plus petite qu'un mot cpu, la différence signé vs non-signée a une incidence car le cpu doit faire une extension du bit de signe en fonction de l'instruction utilisée (je doute qu'un compilo émette facilement une addition sur 8bit). À voir donc…
    - [^] # Re: C++ type et performances
      
      Posté par benja le 21 octobre 2016 à 03:23. Évalué à 2.
      
      s/x > 0/x >= 0/
      - [^] # Re: C++ type et performances
        
        Posté par Linuxator (site web personnel) le 22 octobre 2016 à 05:59. Évalué à 1.
        
        Merci benja: pour ces commentaires hautement didactiques.
        
        Peut-être l'accès aux AL (ou là ou le compilateur met le octet (int8_t ou uint8_t) dans le registre) est peut-être plus plus coûteuse en terme de temps d'accès CPU.
        
        Mais comme je l'ai déjà dit: perdre 3 octet pour rien cela ne me plaît pas:
        
        sinon pourquoi existerai il des types char et short si tout peut ce régler avec un int (type de base) ?
        
        Merci pour l'expression dont je ne connaissais la définition:
        
        premature optimization is the root of all evil.
        
        NOTE: Je me suis fait déjà fait corriger concernant la vérificaton du signe et notre vénérable complément a 2, le bit du signe n'est que réserver qu'aux flottants…
        
        Désolé d'avoir mis des insanités sur le net mais c'est comme cela que l'on apprends, encore désolé.
        
        Et merci pour cette leçon.
        
        [^] # Re: C++ type et performances
        
        Posté par Linuxator (site web personnel) le 22 octobre 2016 à 06:32. Évalué à 1.
        
        Bon ayant réfléchis un peu je me suis dit que:
        
        Pour un unsigned la machine n'a pas besoin du complément a 2:
        
        Car il lui suffit de lire les bits dans le bon sens pour déterminer la valeur.
        
        Mais bon comme tu dit: une suspicion ne suffit pas il faut encore l'avoir vérifier !
        
        Qu'en pense tu ?
        
        [^] # Re: C++ type et performances
        
        Posté par benja le 23 octobre 2016 à 19:45. Évalué à 2. Dernière modification le 23 octobre 2016 à 19:48.
        
        Le complément à deux est simplement la représentation binaire d'un entier négatif. Le truc c'est qu'en utilisant cette représentation une addition n'a pas besoin de tester le signe des opérantes. Au niveau du cpu, cela ne change strictement rien, il n'y pas de test supplémentaire, d'ailleurs comment ferait-il pour faire la différence entre une valeur signée d'une non signée ?? Pour le prouver il suffit de créer un fichier signed.c qui contient la fonction "int monadd(int a, int b) { return a+b;}", tu fais de même avec unsigned.c "unsigned int monadd(unsigned a, unsigned b) {return a+b;}", tu compiles avec gcc -save-temps -c unsigned.c, tu regarde le fichier assembleur .s et tu verras qu'il n'y a aucune différence. Comme je l'ai dit, ce qu'il peut y avoir comme différence serait du à une décision de l'optimisateur de gcc qui pourrait supprimer du code. Donc bref, tu mets unsigned si c'est effectivement le domaine de ta variable, c'est très bien mais ça ne changera strictement rien en ce qui concerne la rapidité d'exécution.
        
        Par contre il ne faut jamais assigner un unsigned vers un signed ou inversément. Le language C admet cela en tant que cast implicite, si tu as de la chance ton compilateur t'arvertira, ou pas… Parce ça peut avoir de fâcheuses conséquences et est une source de problèmes de sécurité à cause des overflows et des optimisations. Malheureusement c'est un peu plus compliqué à expliquer de manière succinte.
        
        Pour en revenir au int8 vs int. Si tu utilises des int8s sans padding (ce que tu sembles vouloir faire car pour pouvoir économiser de la mémoire), tu vas imposer de facto des lectures non-alignées car l'adresse de ta variable ne tombera pas toujours sur un multiple de 4 octets. Certaines archi imposent d'utiliser une instruction différente ou une série d'instructions pour cela. Grossièrement, elles vont lire la lecture du mot à l'adresse alignée inférieure et faire un shift de bit pour avoir ton octet dans la partie lsb. Encore pire, si tu lis un int32 non aligné (c.-à-d. à cheval sur deux int32 alignés), elle va devoir lire le mot d'en dessous, faire un shit, celui du dessus, faire un shift et enfin combiner les deux moitiées. x86 est "non-alignée" (excepté les instructions style mmx,sse,etc.), ce qui fait que la même instruction marche avec les deux types d'adresse, néanmoins elle reste moins performante avec des adresses non-alignées car la même partie de passe-passe va être faite par le cpu, dans ton dos.
        
        Ceci dit, ça n'est pas pour cela que c'est une mauvaise idée ou que cela sera toujours moins performant. En effet, la mémoire sauvegardée peut servir à autre chose; par exemple dans un environement restreint type console de jeux, ça peut-être un bon calcul.
        
        [^] # Re: C++ type et performances
        
        Posté par Linuxator (site web personnel) le 24 octobre 2016 à 07:48. Évalué à 2.
        
        Merci pour cette réponse fort didactique.
        
        Apparemment tu t'y connais en assembleur, code machine, etc…
        
        Mais comme j'ai dit auparavant:
        
        Si tu déclare une valeur non-signé (unsigned).
        
        Le compilateur saura que la représentation de cette valeur est non-signé (unsigned) vue que tu l'a déclaré ainsi et du coup qui pourrai simplement lire le registre (en admettant que ce soit aligner correctement) bit après bit pour récupérer la valeur de la variable non-signé (unsigned).
        
        Mon raisonnement ne te plaît pas ou j'ai simplement tord et je m'obstine.
        
        Auparavant tu m'a dit que:
        
        Cela ne valait pas le coup de déclarer des variables uint8_t, int8_t et qu'il vaut mieux utilisé un int (le type de base) afin de garder le truc aligné.
        
        Mais un registre est composé de sous registres, plus petit (cela va jusqu'au octet) AL et AH.
        
        Donc je voit mal des valeurs valeurs stocker dans plusieurs registres se chevauchant…???
        
        Puis tu me dit que dans que c'est pareil un entier non-signé (unsigned int) et un signé (int).
        
        Pourquoi le compilateur s'emmerderait a faire un complément a 2 alors que il peut simplement lire la valeur bit après bit, dans le cas d'un non-signé (unsigned).
        
        Peut être pour faire des additions…???
        
        Mais le processeur peut très bien faire des additions de valeur directe ou déduites, c'est son boulot.
        
        Il faut peut-être chercher un peu plus loin que le petit programme qui fait une addition avec des signés et des non-signés (unsigned). Par exemple analyser le code machine.
        
        D'ailleurs pourquoi ça existe des non-signé alors si le processeur bosse avec des signé, pour l'abstraction.
        
        Et c'est pour l'abstraction que le char et le short existe en 2 versions.
        
        Peut-être que le processeur a un moyen de savoir, si la valeur est a calculer en signé ou non-signé.
        
        Après il faut savoir a mon sujet que j'ai lu qu'un seule livre sur le fonctionnement d'un ordinateur et du coup du sur le fonctionnement du microprocesseur entre autres. Mais des tas d'autres en parle sans être un parfait manuel.
        
        Et que je n'ai pratiquer l'assembleur que pendant 1 mois (32 et 64 bits, syntaxe Intel), faute aux fonctions EXTERN, ce qui m'a ramener au C.
        
        Et puis dès que l'on rentre dans ce genre de domaine vous voulez toujours avoir raison a tout pris, alors je vous donne humblement raison et vous me laissez tranquille avec mes petites idées d'optimisation.
        
        Ne le prends pas mal, tu voulais simplement partagé ton savoir mais moi j'en ai strictement marre qu'on me contredise a chaque fois que j'ai une idée.
        
        Ou suis-je simplement un âne borné pour l'instant, car je ne compte pas en rester là dans les sciences informatiques et peut-être un jour ce sera moi qui aurai raison.
        
        Merci.
        
        PS: Si tu en le courage ont peut reprendre le truc (int8_t vs int) et (unsigned vs signed) en mettant l'accent sur la différence entre le compilateur qui produit du code machine et le processeur qui va exécuter le code machine.
        
        PS2: Je me pose la question suivante depuis longtemps:
        
        Est-ce-que le compilateur passe par du code assembleur pour produire du code machine ?
        
        [^] # Re: C++ type et performances
        
        Posté par benja le 24 octobre 2016 à 14:11. Évalué à 3. Dernière modification le 24 octobre 2016 à 14:15.
        
        En changeant l'ordre des questions.
        
        Est-ce-que le compilateur passe par du code assembleur pour produire du code machine ?
        
        Oui. L'assembleur va simplement transformer un fichier d'assembleur en un fichiers objet. Les instruction (mnemoniques) sont transformées en valeurs (opcodes) directement utilisable par le cpu. Donc ce que tu vois dans ton fichier .s correspond à un objdump -D sur ton fichier .o. À une exception près que certaines mnémoniques sont des mneoniques qui codent en fait une séquence d'autre mnémoniques, un peu comme si c'était des macros.
        
        (C'est ensuite l'éditeur de liens (le linker) qui lors de l'assemblage des différents fichiers objet va substituer certaines valeur d'adresse par le valeur absolue (en simplifiant). C'est cette étape qui permet à ton code de faire un "jmp label_fonction". Tu peux appeller sans problème une fonction "extern" depuis du code assembleur)
        
        Donc je voit mal des valeurs valeurs stocker dans plusieurs registres se chevauchant…???
        
        Je parlais de l'alignement en mémoire des tes variable.
        Si tu as:
        
        |00|01|02|03||04|05|06|07| (addresse) |--|B4|B3|B2||B1|--|--|--| (variable)
        
        Le mot B4B3B2B1 est à cheval sur les "mots mémoire" 0-1-2-3 et 4-5-6-7. Pour le charge dans un registre R1, tu vas d'abord le charger dans R2 le mot 0-3, R2 vaudra --B4B3B2. ensuite tu fais un shit pour avoir R2=B4B3B200, ensuite tu charge/shift 4-7 dans R1=B1------, R1=000000B1 et tu combine R1=R1 AND R2 = B4B3B2B1. Tout cela parce qu'un cpu 32 bit est éléctriquement conçu pour travailler sur des mots aligné sur 4 octes. Admettons que B3 soit un int8 que tu veuille mettre dans un registre, il vaut lire 0-3, et faire p.e. 2 shift, un à droite puis un à gauche (sur une archi petit boutant). Sur x86 c'est transparent, le cpu va le faire pour toi automatiquement, mais c'est plus lent donc vaut mieux travailler avec des variables alignées.
        
        j'en ai strictement marre qu'on me contredise a chaque fois que j'ai une idée.
        
        Ne te méprends pas là n'est pas mon objectif qui est de te donner de nouvelles notions et de répondre à ta demande de feedback. Comme je t'ai dis ce n'est pas une mauvaise idée en soit car il est vrai que tu économises de la mémoire en ce faisant.
        
        Si tu en le courage ont peut reprendre le truc (int8_t vs int) et (unsigned vs signed) en mettant l'accent sur la différence entre le compilateur qui produit du code machine et le processeur qui va exécuter le code machine.
        
        Je t'invite à faire l'expérience que je t'ai suggéré et en plus de faire un objdump -D sur les fichiers .o pour constater que tu auras strictement 2 fois la même chose. Tu peux encore utiliser le debugger gdb pour là partie "éxécution" mais tu ne verras rien de nouveau que tu n'aurais pas déjà vu dans le désassemblage par objdump.
        
        [^] # Re: C++ type et performances
        
        Posté par Linuxator (site web personnel) le 25 octobre 2016 à 10:24. Évalué à 1.
        
        Merci de pas t'être énerver face a mes propos, un peu agressif envers toi a mon goût, ce pourquoi je m'excuse.
        
        J'avoue que je comprends pas trop ton histoire de registres et d'adresses séparés.
        
        Car selon ce que j'ai appris:
        
        Un registre peut contenir une adresse (en flash ou plus loin) ou une adresse vers une adresse ?
        
        Ou bien une valeurs (après l'avoir été chercher a une adresse, si il le faut) et dans ce cas le processeur fait une opération sur 2 registres enfin.
        
        Mais j'ai bien compris, concernant mon int8_t, que sur une architecture 32 bits il va y avoir du zéro filling pour rester aligner sur 32 bits ce pourquoi un processeur 32 bits est électriquement conçus (avec des transistors groupé en registre) pour rester aligner sur 4 octets.
        
        Donc l'accès a un int8_t est pareil sinon plus longue que un int.
        
        Tout cela a cause de l'alignement sur 32 bits.
        
        Si j'ai tout bien compris ?
        
        Alors que pense tu de mon utopie qui suit:
        
        Un registre 64 bits de base ressemble a cela pour moi:
        
        +---------------------------------------+ | RAX | +-------------------+-------------------+ | EAX | | +----+----+----+----+----+----+----+----+ | AL | AH | | | | | | | +----+----+----+----+----+----+----+----+
        
        Remarquez que l'on peut avoir l'impression que l'on ne peut pas accéder aux parties (cases) de droites vides…
        
        Faux ! Cela se fait avec un offset si je dis pas de bêtises.
        
        Alors pour revenir a nos int8_t et uint8_t.
        
        Si le compilateur remplis chaque case du RAX (AL, AH, et les suivantes sans noms) avec une valeur uint8_t ou int8_t
        
        C'est parfaitement aligné !
        
        D'ailleurs je pense c'est que ferai un programmeur assembleur si il a besoin de 8 octets séparé (uint8_t ou int8_t).
        
        Mais tu parlait en terme d'adresses et là je ne sais pas grand chose a part la taille (4 octets en 32 et 64 bits).
        
        Et ce que j'ai dit auparavant concernant l'accès aux valeurs a différentes adresses.
        
        Mais cela se termine avec des valeurs dans les registres.
        
        :note: Désolé si j'ai dit des bêtises, je ne suis pas grand expert.
        
        :footer: Cela est un peu flou pour moi qu n'a pas fait des études d'ingénieurs sur le sujet et qui doit se faire image avec quelques bouquins et tutoriels.
        
        Merci pour ce que tu m'a appris, le peu que j'ai pût en comprendre.
        
        PS: Tu parle souvent d'architecture 32 bits mais je pense que de nos jours c'est le 64 bits qui domine, faudrait peut-être faire une petite mise a jours concernant la nouvelle architecture 64 bits, pour mettre a jour ton grand savoir.
        
        Et sache que j'ai énormément de respect envers toi, car tu en sais des choses, tu les expliques bien, et tu reste cool quand je devient nerveux.
        
        [^] # Re: C++ type et performances
        
        Posté par benja le 26 octobre 2016 à 01:07. Évalué à 2. Dernière modification le 26 octobre 2016 à 01:10.
        
        Mais j'ai bien compris, concernant mon int8_t, que sur une architecture 32 bits il va y avoir du zéro filling pour rester aligner sur 32 bits
        
        Quand je parle d'alignement et de conception électronique, je parle au niveau des transfert vers ou depuis la mémoire centrale depuis ou vers le cpu. C'est à dire tout les instruction dont une des opérante est une adresse va faire en sorte que le cpu lise ou écrive depuis la mémoire centrale.
        
        PS: Tu parle souvent d'architecture 32 bits mais je pense que de nos jours c'est le 64 bits qui domine, faudrait peut-être faire une petite mise a jours concernant la nouvelle architecture 64 bits, pour mettre a jour ton grand savoir.
        
        L'archi 64 bit étant rétro-compatible avec la 32, cela ne change rien, à taille d'opérante ou instruction identique! De plus vous comprendrez qu'il m'a bien fallut trouver un exemple et que je n'ai pas la prétention de vous faire un exposé exhaustif. Je vous renvois donc vers la section du manuel d'intel pour plus de précisions http://www.intel.com/content/dam/www/public/us/en/documents/manuals/64-ia-32-architectures-software-developer-manual-325462.pdf
        
        4.1.1 Alignment of Words, Doublewords, Quadwords, and Double Quadwords Words, doublewords, and quadwords do not need to be aligned in memory on natural boundaries. The natural boundaries for words, double words, and quadwords are even-numbered addresses, addresses evenly divisible by four, and addresses evenly divisible by eight, respectively. However, to improve the performance of programs, data structures (especially stacks) should be aligned on natural boundaries whenever possible. The reason for this is that the processor requires two memory accesses to make an unaligned memory access; aligned accesses require only one memory access. A word or doubleword operand that crosses a 4-byte boundary or a quadword operand that crosses an 8-byte boundary is considered unaligned and requires two separate memory bus cycles for access.
        
        note: word = 16bit, double = 32, quad = 64. On peut lire que l'alignement minimum d'un cpu 32 ou 64 bit est 16 bit en utilisant les instructions travaillant avec des opérantes de 16 bits uniquement!!! Il n'est mentionné nul part quel est l'alignement naturel des opérations qui travaillent sur un byte, genre MOVZB. On peut raisonablement penser dire que l'alignement minimum des archi Intel 32 et 64 bit est de 2 octets. Mais bon, peut-être qu'effectivement il n'y a jamais de problème d'alignement en utilisant les instruction avec une "memory operand" de 8 bits. Ensuite le manuel écrit textuellement que pour un accès non aligné le cpu doit réaliser deux accès alignés, ce que j'ai tenté de vous expliquer au moyen d'une illustration.
        
        Par ailleurs il se peut que le compilateur s'arrange pour faire un alignement optimal tout seul. Quand vous utilisez un tableau int8[], ben il ne peut pas ajouter du padding entre chaque élément et vous êtes à peu près sûr que 1 octets sur 2 ne sera pas aligné sur 16 bit, 3/4 sur 32 et 7/8 sur 64. Dans le cas d'une structure il est très facile de "désaligner" certains membres en intercallant des membres plus petits. Une recherche sur "C structure packing alignment" vous donnera des résultats très pertinents à ce sujet. Quant à moi je m'arrête ici dans l'espoir de ne pas vous perturber d'avantage. Je voulais simplement vous donner une réponse à votre question "est-ce qu'utiliser des int8 rend mon code plus rapide", celle-ci est "non sauf si vous avez de grosses contraintes mémoire (et que vous ne faites pas de padding!!!) ou que ces int8 n'entrainent pas un désalignement d'autres variables/membres". Je vous concède que j'aurais peut-être mieux fait de m'abstenir d'entrer dans de telles considérations de micro-optimisation car il est évident que même si utiliser un int8 serait légèrement plus rapide (ce dont je doute très sincèrement mais bon je n'arrive pas à trouver la preuve alors admettons*), vous n'aller rien gagner du tout compte tenu de la complexités des bibliothèques et systèmes graphiques que vous utilisés.
        
        PS1: J'accepte vos excuses mais tâchez quand même d'être moins abrasif envers ceux qui veulent vous faire avancer. Btw je suis aussi un autodidacte, je ne prétend pas avoir la science infuse et je me trompe naturellement assez régulièrement. Je ne vous dois rien si ce n'est le respect. Je vous souhaite donc de persévérer, et dites vous bien que ce qui ne fait pas de sens aujourd'hui en fera sûrement demain.
        
        *: Sur ce document il est montré sur un ensemble de processeurs différents qu'un mov de 32 bit n'est pas plus rapide qu'un de 64 bit, c'est identique voire dans certains cas plus lent…: https://gmplib.org/~tege/x86-timing.pdf
- [^] # Re: C++ type et performances
  
  Posté par benja le 21 octobre 2016 à 03:06. Évalué à 3. Dernière modification le 21 octobre 2016 à 03:10.
  
  qu'un int, fut-il sur 64 bits
  
  Attention, attention ! Contrairement à une croyance fort répandue, le type int sur linux/amd64 ne vaut pas 64 bits ! Merci de ne pas caster des int en pointeur et vice-versa, en vous remerciant d'avance pour les bugs évités :)
  - [^] # Re: Mammouth et Co. a entièrement raison c'est illégal !!!
    
    Posté par Linuxator (site web personnel) le 22 octobre 2016 à 13:39. Évalué à 1.
    Salut et revoir battle-rage.
    
    Car je me suis inscrit sur https://www.spriters-resource.com qui s'appelle en faîtes www.vg-resource.com héberger par ovh.ca dans les forums pour en discuter…
    1. J'ai demander sur la légalité de leurs ressources et ils m'ont dit que je ne pouvait pas en faire usage a but commerciale nie sur aucune platformes (je me demande si github ne va pas me virer ?).
    Je me demande encore si l'on peut en faire un usage personnel ?
    
    Puis je leurs ai poster ça:
```
Sensitization campaign: Do It Intelligently (Licesing, README,...)

Hi to all the community:

I want to make everybody aware of the fact of uploading content

and provide a How-To upload with severals advices:

Important Rule 1: Add a README.

Important Rule 2: Add a license.

1. If you provide a sprite (an images contains more than one figure).

  1. Add a README with the suppose coordinates for every figure.

    Because if the sprite isn't regular ( I mean if the sprite doesn't use regular intervals. )

    The programmer which will use your sprite will be in big troubles with the coordinates.

    The best is to do regular sprites, even if you lose some place.

    * And you can keep a rectangle for adding your signature.

  2. IMPORTANT: add a free license for your work.

    Because if someone use your sprite and release his work with your sprite inside

    it's better that he can show a license,

    else he can go into jail for usage of illegal content.

2. If you provide some images in an archive:

  * Think at right numbering the images if they follow in a sequence.

3. If you do some ripping work on a game.

  * Be aware of the fact to not do this with propretary content.

    Else you can be pursued in justice.


  Let the propretary people swim in their propretary $h|t.


  If you have the right to do the work, add a LICENSE and a README like explain in

  the points 1 and 2 from the section above.


  If the work you are ripping provides a license think at read it to sea if you can

  change modify the license or if you must provide the same.


  You can use the concept of copyleft to add a license.

  :note: I don't really know the world of sprites or imahge ripping.

:footer: Some free licenses link.
```
    Avec les liens qui vont avec et quelques corrections
    
    et suite a ça
    
    quand je me dit que j'allais parler au seule administrateur qui m'a répondus:
    
    Je me suis donc connecter au site et surprise:
```
Your forum account is currently banned. Ban Reason: Spam
Ban will be lifted: Never
```
    ???
# Combattre pour le libre de manière intelligente.

Posté par Linuxator (site web personnel) le 22 octobre 2016 à 19:15. Évalué à 2.

Merci pour ces vives discussion techniques (int et uint8_t) et de licences (copyright).

Mais il y a personne qui veut tester le jeu ou lire (jeter un œil me suffit) le code afin que j'ai du feedback sur ces points…

Merci de bien vouloir me donner vos impressions concernant le jeu et|ou son code lui-même.

PS: Je vais régler cette histoire de copyright concernant les personnages du jeux NeoGeo Battle Colliseum,
que j'ai trouver sur le site pirate (c'est un site de ripping de ressources donc illégale)…

N'allez pas sur ce site pour trouver vos sprites, images, sons, musiques…

Ce site la est parfaitement légale: http://opengameart.org/.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.