l'auteur parle de C. pas de C++

godreik les tableaux pour un jeuxvideo n'on pas besoin detre protéger. l acces est indexé c'est très rapide. et tu peux écrire dans la case 3 pendant que la case 5 est lus.

dans une liste chainé, en plus d etre lent non très lent en lecture tu ne peux pas lire l élément 5 pendant que l'élément 1 est lu.

je te met au défi d avoir une erreur sur ce jeux sur n importe quel machine pourtant codé en multi thread et tableau. par contre j avais fait exactement le meme jeux en List chainé et ArrayList en plus d etre extrement lent : perso qui marche dans la semoule. plusieur erreur d accès a la chaine simultanément du a la lenteur de la lecture de la chaine ( pour les bombs ) et au rafraissment des 13ms du jeux. le jeux n arrvais pas a lire la chaine en moin de 13ms. et plus les joueur posais de bomb plus le jeux devenais lent juste qu au plantage de celui ci vert une 20 ene de bomb en meme temp.

http://actupc.fr/bomber.php

alors qu en tableau sa roule tout seul meme en java qui n'est pourtant pas super performant. pi l avantage des tableau par rapport au HashMap ou ArrayList c'est que c'est extrement facilement de passer d un langage a l autre. a l origine le moteur de mon jeux était en C++ puis en java tout ca avec quasiment que des copier coller. juste la partie graphique et controleur a changer mais tout la partis model n'a quasiment pas changer. MVC + fonction de base dans le model tu n'es quasiment plus dépendant du langage et librairie (pour la partie model). tu as juste a "refaire" la vue et le controleur.

en 5 heure mon jeux a été programmer sur
c et SDL
C++ et SDL
c++ et SFML
java et swing + réseau.
java applet sans réseau.
Alors certe c'est un tout petit jeux mais on n'est a peut pret je pense dans le niveau de difficulté d'un snake.

après sa dépend de la facon de penser de chacun. mais moi je sais que les list chainé dans les jeux plus jamais je préfere encore consommer 2 foie plus de mémoire. tout simplement parce que un jeux n'ai aps fait pour etre multi tache normalement. quand je joue je ne fait rien d autre donc je peux utiliser la mémoire dispo. par contre quand je joue je ne veux pas avoir de ralentis ou que les perf de mon jeux dépende fortement du nombre d'élément a gérer. les tableau et le stockage en mémoire de tout les élément nécéssaire plutot que de les recalculer on l avantage d offrir des performante bien supérieur.

donc en gros dans ton tableau tu skoke ton int.
et de 0 a 99 réserver au serpend.
0 la tete

quand tu appuis sur -> la case a droite de la case qui contient 0 prend 0.
dans ton tableau tout les case supérieur a 0 et inférrieur a 98 prennent +1.
dans ton tableau tu retien a chaque fois la case la plus grand inférrieur a 99. puis la case de cette index tu la met a 100 (pour indiquer case vide)

ton serpent est de la forme 0123456789.
dans un tableau a double dim ca fait

[100][100][100][100][100]
[100][000][100][100][100]
[100][001][002][100][100]
[100][100][003][004][100]

après déplement a droite. la case en X+1 de la case qui contien 0 prend la tete donc elle prend 0
tout les case du corp prennet +1. la case qui contien le nombre le plus grand ( la queu ) est suprimmée

[100][100][100][100][100]
[100][001][000][100][100]
[100][002][003][100][100]
[100][100][004][100][100]

en gros tu vien de décaler la tete d'un grand sur le X, de décaler tout le corp de ton serpend en incrémentant de 1 tout ses partie et de suprimer sa queu pour similer un avancement.

puis affichage de ce tableau.

pour regarder une colision genre la tete avec le reste. par exemple on veut se déplacer a gauche. on regarde la case a gauche de la case qui contient 0. si cette contien le nombre 100 on sais que c'est bon casr 100 = case vide. si c'est par exmple le nombre 200 on dit tien une pomme. donc cette case prend le nombre 0 (la tete) et tout le reste se fait incrémenter de 1 et cette foie une ne suprimer pas le plus grand (la qeu ) pour simuler l agrandissement.

tu as ton jeux en 1 heure avec que des chose simple ( tableau) aucun méthode fonction classe appartement a un langage précis ou des regle présisse. Donc un jeux lisssible modifiable par tout le monde ET transposable sur n importe qu elle langage.

acemicka, il y a une difference entre chez moi ca ne crash pas, et ca ne crashera jamais nul part. Coder en suposant que comme certaines operations sont tres rapides il n'y a pas besoin de protection c'est de la folie pure et simple. Tu vas te retrouver avec une race condition qui va se declancher une fois tous les 36 du mois et qui sera completement indebuggable.

Pour ton histoire de ralentissement avec les liste chaines. Ca ne m'etonnerai pas que ce soit un autre probleme que tu ai eu. 13 milisecondes c'est enorme sur une machine moderne.

"acemicka, il y a une difference entre chez moi ca ne crash pas, et ca ne crashera jamais nul part"

Ce type de crach est dérisoir et le bug est acceptable, si tu part par la tu ne codera jamais rien. tu ne connais pas le context et l environement de la ou ton programme sera exécuté. De plus meme dans les logiciel pro tous (oui tous) sont commercialiser avec des bog connu.

et programmer avec des hsoe comme des LinkedList quand ce n est pas obligatoire c'est juste augmenter les risque.

la en faite en tableau la bug a disparu parce que la lecture du tableau se fait en moins de 13 ms seul moyen de crash.
- que le PC mette plus de 13 ms a lire 15*15 case
ET
- qu une bomb soit posser juste sur la case pendant que celle ci soit en train detre lu.

en gros tu as plus de chance de te prendre une météorite. si tu veux un logiciel 0 bog ( meme connu ) tu ne le sortira simplement jamais. surtout en programmation répartie ou tu es totalement dépendant de chose que tu ne me maitrise pasou peu.

mainteant je peux poser une sécurité et ralentir le programme. probleme, ce bog ne peux arriver que sur les machine lente et pour protéger les machine lente je vais encore alourdir mon programme avec des sémaphore et autre ? je ne fait au final que agraver le probleme en risquand de rendre le jeux injouable a des PC qui avant pouvais lancer le programme a l orgine.et de toute facon les PC ayant se bug étaient déja trop lent pour jouer. donc au final je n'aurai récupérer aucun utilisateur potentiel par contre j en n aurai perdu en essayant d' éviter un bug sur des machine non adapter au programme.

NON! le bug n'est pas acceptable. Surtout des races conditions. Si un pro me dit qu'il y a une race condition dans son code qu'il le sait, que c'est facil a corriger mais qu'il la laisse parceque bon ca ne devrait pas arriver. Je le vire et je ne bosse pas avec lui parceque c'est un cretin!

Tu peux synchroniser tes structures de donnees rapidement avec des spin lock ou encore utiliser des structures lock-free.

Si tu ne maitrises pas parfaitement ton code en programmation repartie c'est parceque tu es un mauvais programmeur distribue. C'est pas quelquechose de mal en soit, la plupart des programmeurs ne sont pas forme. Tu as des tonnes d'outils pour tester ces choses la, pour faire de l'analyse statique et dynamique de code (par exemple helgrind).

Si un code est ecris comme ca, il ne passera JAMAIS a l'echelle en complexite.

alors pour toi 100 % des programme sont inaccétable et les programmeur des crétins...

pas parce que sur TON code Tu ne trouve pas d'erreur que tu n' en n'a pas.

pour moi ce qui est crétin c'est de dire que ceux qui code des programma avec des bug connu sont des crétins. parce que ton programme en a et ca j en suis sure a 100%. il faut avoir de l ouvert d esprit et l accepter...

d ailleur je pense meme l inverse de toi.
je préfere un bog connu et mis en évidence.

plutot qu un mec comme toi qui me dit. moi mon programme il n'a aucun bog. alors qu en faite c'est juste qu il ne les as pas trouvé.

ca serais plutot lui que je virais et avec qui je ne voudrais pas travailler. Outre le fait que ca fait très prétentieux et que se genre de personne me gonflerais très vite.

Je ne dis pas que mon code n'a pas de bug. Je dis que mon code ne presente pas de bug non-deterministe connu qui sont triviaux a corriger.

Evidement que mon code a des bugs. Certainement des inconnus. Et quelques bugs connu. Maus les cas connu sont parfaitement deterministes, ainsi ils sont dans la listes des bugs a corriger parcequ'ils sont importants soit dans la liste des bugs qui n'arriveront jamais en pratique. Et dans tous les cas, si il est dans la liste a ne pas corriger, il n'est pas trivial a corriger.

Avoir un bug non deterministe trivial a corriger qui n'est pas corriger pour une raison douteuse est une preuve d'incompetence.

Et recommander ce genre de comportement sur un forum n'est pas sympa.

attendez, comment vous en êtes arrivés à parler de sémaphore et de lecture/écriture simultanée à partir d'un simple snake en C? il n'est pas multithread son snake, non?

Pourquoi une liste? C'est pas bien les tableaux?

une liste possède l'avantage d'être étirable a l'infini sans se casser les pieds, contrairement aux tableaux où là, c'est plus compliqué

dans le jeu que je fais actuellement, j'utilise des tableaux pour stocker un nombre inconnu de données, quand ils sont pleins j'en créée un nouveau de taille doublée, je copie les données de l'ancien dedans avant de le détruire. ca peut être plus performant que les listes chainées, mais il y a forcément un peu de mémoire perdue. et c'est pas intuitif

pour revenir au probleme de base. Le gars a besoin de n'importe quelle structure de donne qui supporte les operations "ajouter d'un cote", "retirer de l'autre" et "lister les elements". apres comment tu implemente ce truc la n'a pas beaucoup d'importance pour OP.
Une liste doublement chaine fera ca.
un buffer circulaire le fera aussi...

• • et bcp de méthodes sont déja la qui rendent leur utilisation assez simple et intuitive.

-> (pour les liste)

"si c'est juste un booléen, pour chaque élément, t'as un booléen et une adresse de pointeur. ca peut être encore plus lourd que ton tableau a la taille doublée "

c'est ce que j'ai dit plus loin...

"la principale contrainte d'un jeu temps réel, c'est avant tout qu'il ne plante pas et évite de saturer la RAM. les jeux instables n'intéressent pas "

qui t'a parler de jeux instable
??????????????????????????????????????????????????
????????????????????!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!
pour moi ma principal contrainte c'est que le jeux tourne sur la config mini sans bug et sans lag. tout ce qui est en dessous de la config mini ne m intéresse pas ( par contre je peux tout faire pour que la config mini soit le plus faible possible).

rappel : prend ton jeux tourne la boite et derriere cherche la ligne : config mini.
tu pourra lancé ton jeux meme si ton PC est inférieur a la config mini par contre tu aura des ecran bleu de la mort par exemple. des retour windows. des zone de la carte qui ne s afficherons pas.

"en ce moment, c'est la mode des programmes exploitant le SMP, si les semaphores étaient si lourds que ça, ca se saurait "
ca se sais. c'est le 1er truc qu on apprend en progra parallele. les sémaphone c'est loin d etre anodin. en plus de risquer de ralentir de programme de facon significatif ca peut devenir très compliqué très vite. risque de famine, inter blocage , goulot d'étranglement etc...

les semaphores sur un systme d'exploitation pour machine SMP raisonnable sont implementer avec des futex. Un futex quand il n'y a pas de collision, ca s'implemente avec un test et un CAS pour prendre le futex et ca se relache avec une affectation. Si il y a une collision, ca veut a peu de chose pres dire que le jeu aurait planter, et tu prefere le ralentissement.

Si tu ne peux pas te permettre un CAS, un test et une affectation toutes les 13ms, je pense que tu as des problemes plus important que cette synchro la.

Apres, j'ai vu que vous parliez de liste chaine en java. L'implementation de java fait des liste chaine a partir de reference, mais on peut certainement les implementer plus rapidement en faisant des liste chaines dans des tableaux (allocation compacte en memoire, tout ca...).

"qui t'a parler de jeux instable

??????????????????????????????????????????????????

????????????????????!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!!!!!!!! "

ah pardon. j'ai cru qu'on parlait d'un jeu qui plantait pendant l'appui d'une touche sur une machine trop lente.

"tu pourra lancé ton jeux meme si ton PC est inférieur a la config mini par contre tu aura des ecran bleu de la mort par exemple. des retour windows. des zone de la carte qui ne s afficherons pas. "

pour des jeux codés dans les pays de l'est, sans doute!

mais dans les faits, les jeux sont plutôt tolérants au manque de ressources... généralement, c'est le manque d'espace sur la ram/le swap qui en ampute des morceaux, comme les textures (et là encore, pas de BSOD )

un jeu qui crash parce qu'une affectation dure plus que treize millisecondes, ca se voit plutôt rarement. d'habitude, ils se contentent d'être lents et injouables

"un jeu qui crash parce qu'une affectation dure plus que treize millisecondes, ca se voit plutôt rarement. d'habitude, ils se contentent d'être lents et injouables "

qui ta parlé de crash
??????????????????????????????????????????????????
????!!!!!!!!!!!!!!!!!!!!!!!!!!

ou as tu vue le mot planté
??????????????????????????!!!!!!!!!!!!!!!!!!!!!!!!
!!!!!!!!!!!!!!!!!!!!

si tu extrai une ressource, que pendant ce temp la ressource est changer et que tu remet la ressource non changer ca ne crash pas forcément ton appli !! dans ce cas la l'action ne ne sera tout simplement pas prise en compte pour se tour de boucle. si tu met un sémaphore au lieu de ne pas la prendre en compte ca retardera encore plus ton tour de boucle (super tu agraves le probleme BRAVO t'es viré )et retardera l'action qui sera par contre bien réaliser, sans doute pas du tout au momment ou elle aurai du l'etre donc sans doute décalage a la fois dans le temp et dans l espace mais elle sera bien la.

et des jeux particuliere lent qui ne prenne plus en compte les action clavier ou souris et ou tu es obligé de rester appuyé 3 fois plus longtemp tu n'a jamais vue ca ? ba écoute joue plus ou achete un PC moin puissant. ou joue a FF14

"et au rafraissment des 13ms du jeux. le jeux n arrvais pas a lire la chaine en moin de 13ms. et plus les joueur posais de bomb plus le jeux devenais lent juste qu au plantage de celui ci vert une 20 ene de bomb en meme temp. "

là.

un jeu qui crash quand il devient trop lent, a cause d'une histoire de rafraichissement de 13 millisecondes

"si tu met un sémaphore au lieu de ne pas la prendre en compte ca retardera encore plus ton tour de boucle (super tu agraves le probleme BRAVO t'es viré ) "

non, j'aurai démissionné avant, 'pas envie de bosser pour une boîte d'incompétents

pour des programmes qu'on fait pour soi, qui sont juste là pour rendre de menus services, d'accord, qu'ils crashent de temps en temps n'est pas grave, mais dès qu'on commence à diffuser le programme, la fiabilité devient plus importante. même si c'est plus lent

là.

->LOL. ta récupérer le text au début et sortis de son context. je ne parlais meme pas de ce code la !!! LOL. la c'était une autre implémentation par liste !! effectivement une liste si tu essaye de lire alors qu une donné est déja en cour d écriture il te renvoie chier justement pour evité la corruption/perte de donnée. surtout que plus la liste se remplie plus ton jeux devient lent. donc plus tu augmentes les risques la c'est logique. et dans le cas d' une liste oui tu as intéret a mettre de bonne sécurité parce que la ca pardonne pas c'est arret direct du programme

sauf que petit la on parle du code présent celui ou j'ai envoyé le lien par TABLEAU ( tu sais le truc de quoi on parle depuis 3 pages...). le fait que je dise que un jour j ai essayé un code qui plante ne veut pas dire que tout mes code plante... et surtout que c'est le cas pour le code présent ( surtout que j ai bien présiser que pour le code présent c'était des tableau et toi tu es allez récupérer un truc en 1er page ou j expliquai les probleme des List) j avoue tes fort ... ( ironie)

"même si c'est plus lent "

NON !!!!!!!!!!!!!!!!!!!!! c'est les besoins du projet qui déterminent les contraintes pas toi !!! et tu oses parler d incompétant. y en n'a qui doute de rien ...

le text complet je te rappel c'est ca.

par contre j avais fait exactement le meme jeux en List chainé et ArrayList en plus d etre extrement lent : perso qui marche dans la semoule. plusieur erreur d accès a la chaine simultanément du a la lenteur de la lecture de la chaine ( pour les bombs ) et au rafraissment des 13ms du jeux. le jeux n arrvais pas a lire la chaine en moin de 13ms. et plus les joueur posais de bomb plus le jeux devenais lent juste qu au plantage de celui ci vert une 20 ene de bomb en meme temp.

alors très imcompétant ou de mauvaise fois. dans les 2 cas ... bye.