Nekoculus : un jeu avec des yeux, un chat, et de l'esquive de balle

• Flèches pour se déplacer
  
• f pour basculer en plein écran
  
• Espace pour faire une pause
  
• Shift pour afficher la hitbox (... inutile)
  

Spoiler:

Spoiler:

Spoiler:

Nagashi a écrit:man i tried it but



c'est fucken compliqué. je suis pas arrivé à plus de 1600 points. je dois être caca mayB mais. wow.

also un peu flippant sur les bords, gg de me faire pisser dessus à 3AM parce que wow, ce. ce truc de game over après 1000 points.

non mais, je veux dire, basiquement c'est juste un petit chat kawi qui court, et je tombe sur ça c'est genre heu wow whats hapn why my eyes bleed like that pls no not again no nooo noooooooooooooo (miko chan onegai desu).

enfin bref amusant mais fear tho.

Béatrice a écrit:Mhhh. J'vais dire ce que j'en pense du point de vue d'un programmeur (le point de vue joueur plus tard).

Si tu veux distribuer tes sources : ne les mélange pas avec les dlls, exécutables et ressources dans le même dossier. Là c'est pas trop grave vu que c'est un petit projet et que tu n'utilises pas beaucoup de types de fichiers (donc c'est rapide de balancer ce qui gêne ailleurs), mais fais gaffe le jour où ça prend de l'ampleur. En bonus, propose carrément de télécharger séparément.

L'optimisation de niveau 6 ça existe pas sur g++, le niveau 3 fait déjà le maximum, de plus il peut potentiellement provoquer des bugs incompréhensibles. Le niveau 2 fait suffisamment de boulot sans pour autant supposer n'importe quoi pour optimiser à mort. Finalement, pour des raisons évidentes, l'option -g désactive TOUS les flags d'optimisation. Sauf l'inlining, je crois. Donc soit tu compiles avec -g quand tu es chez toi et que tu veux débugguer, soit avec -Ox avec x de préférence strictement inférieur à 3 quand tu veux distribuer. Si tu tiens à le faire avec -O3, je conseille avec du souligné rouge gras : met les warnings au maximum (-pedantic -Wall -Wextra) et n'en laisse aucun traîner (-Werror et remplace -pedantic par -pedantic-errors). Le moindre warning est signe avant coureur que le compilateur va optimiser quelque chose de la mauvaise manière, si ce n'est pas déjà un bug qui se cache. Si tu es parano tu peux même tester ces machins : http://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis .

Le makefile j'dis rien, chacun a sa sauce (certaines sont très épicées ~_~). Sauf la tabulation entre les règles Nekoculus.static et clean. J'pense pas que de nos jours, il existe encore un make qui soit assez con pour exécuter clean si t'essayes de compiler en static à cause de la continuité de l'indentation, mais on saît jamais.

Bon maintenant je veux compiler. Et comme je suis un boulet, mes headers de SFML sont pas accessibles directement sous Cygwin. (si un jour ça t'arrive, c'est -I, et en plus tu peux exploiter ça pour pas te taper des "../../dossiertruc/dossiermachin/bidule.h" à rallonge dans les sources si tu as un projet composé de plusieurs modules, et mettre ça une seule fois dans le Makefile à la place)

Mhhh. Enfin bref. J'ai trouvé un bug grâce aux magnifiques warnings. Regarde la ligne 76 de main.cpp, la macro DBG est vide si on est pas en debug, donc le else se raccorde au if suivant, qui teste, malheureux, une condition plus restrictive que celui du dessus, à moins que l'OS décide de stopper le jeu à ce moment-là et de reprendre quand suffisamment de temps s'est écoulé pour qu'elle devienne valide, ce qui arrivera une fois sur 10 (oui je dis ça au pif, en fait j'en sais rien mais l'idée est là), ce qui fait que ce bout de code ne sera quasiment jamais exécuté, même si ça devrait.

Non en fait je blague, y'a le point-virgule après la macro donc tout va bien. Mais ça aurait pu.

M'enfin voilà ce que j'ai sans le -pedantic et le -Werror =>

Spoiler:

Bon après j'ai la flemme de lire le code. En passant vite fait j'ai rien à dire, c'est assez lisible et tout. Par contre l'indentation est un peu trop grande pour moi, ma tabulation fait 8 caractères (par défaut), mais peut-être que chez toi elle est redéfinie à 4 ou à 2.

Bref, je vais pouvoir jouer un peu là.

Ah, et si je lance "./Nekoculus --always-dumb" je suppose que je peux y arriver du 1er coup à 4096 ?

edit :
J'ai oublié de dire que, tu compiles avec un Makefile, et ça c'est cool.
Par contre pour l'éditeur de texte, je suppose que tu utilises Notepad++ ? Je crois pas qu'il y en ait d'autres qui te laissent indenter le code avec des grosses tabulations. Essaye Emacs (c'est celui que j'utilise) ou Vim (c'est ce que les méchants pabôs utilisent). Une fois que tu auras appris une partie des raccourcis qu'ils proposent, tu iras beaucoup plus vite, tu te fatigueras moins, et tu pourras plus t'en passer aussi.

edit 2 :
Okay, en "always dumb" j'arrive à 5000, le hell mode n'est pas "dumb" du tout (mais je fais quand même le max à 25000). Je relance le sans options, et euh ... ton hell mode est tout simplement injuste, 2 boules ça passe, mais avec 4, je suis cuit à 6260 ...

Spoiler:

edit 3 :
8565
J'arrête ici, j'ai pas envie d'en voir 8 à la fois me tomber dessus. o_ô

Étant sous linux, tout était déjà dans /usr/include donc je ne me suis pas posé la question mais c'est vrai que c'est à garder à l'esprit (avec -L) si un jour je me traîne différentes versions de SFML.

Moi il m'a trouvé des erreurs car apparemment la norme interdit d'initialiser des flottants dans les déclarations de classe, ce qui est corrigé (mais pas forcément plus pratique niveau code. Quoique, ça évite de recompiler l'intégralité du code pour juste changer la valeur d'une constante).

Code:

static const float flt1 = 5.f / 3.f;

int main ()
{
  float flt2 = 5.f / 3.f;
  return (flt1 == flt2);
}

Béatrice a écrit:Pour le "optimized out" : tout bout de code se trouvant dans un header (typiquement les templates et les accesseurs), est automatiquement sujet à l'inlining, si le compilateur le juge nécessaire, peu importe le degré d'optimisation et si on est en débug (donc c'est bien ce qu'il me semblait dans mon post précédent). Ceci afin d'éviter de dupliquer plein de code dans chaque fichier objet. Il y a peut-être une exception si on link direct mais c'est pas pratique.
Ce pourquoi ça arrive très souvent (pour ne pas dire toujours ...) quand tu essayes de débugguer du code qui utilise la STL.

http://stackoverflow.com/questions/370283/why-cant-i-have-a-non-integral-static-const-member-in-a-class
Une autre raison (qui rejoint un peu certaines réponses données plus haut) pourrait venir de ça (c'est le bout de code qui m'a fait foirer ma tabulation d'ailleurs T_T ) :

Code:

static const float flt1 = 5.f / 3.f;

int main ()
{
  float flt2 = 5.f / 3.f;
  return (flt1 == flt2);
}

Si tu compiles sur ta machine pour ta machine, tu auras fort probablement 1 en valeur de retour.
Si tu cross-compiles vers une architecture qui utilise un format de flottants différent, et qu'en plus tu n'optimises pas (ça marche comme si tu t'étais arrangé pour obtenir les valeurs depuis une source extérieure pour les calculer après), le compilateur devrait effectuer la 1ère division sur ta machine, puis convertir, et laisser la 2ème division pour la machine cible en convertissant préalablement les 2 valeurs. Le résultat peut être potentiellement différent, et c'est encore pire pour les divisions étant donné que ce n'est pas faisable directement sur le hardware, chaque constructeur a sa méthode (je parie qu'il y a des brevets dessus), les optimisations dépendant aussi du format de flottant (y'a qu'à voir la fonction de calcul de racine carrée inverse de John Carmack pour être convaincu que oui, le format de représentation des flottants a son importance, et peut être exploité pour faire certains calculs différemment). Si tu as de quoi le tester, il est possible que tu doives changer plusieurs fois les valeurs avant de tomber sur la bonne combinaison, mais ça peut se faire.
Donc, comportement indéterminé, l'erreur est justifiée. Un peu comme ton histoire d'yeux qui n'apparaissent pas en fonction du degré d'optimisation (d'ailleurs faut croire que l'inlining n'est pas le seul truc qui passe quand même dans les optimisations quand on est en debug ?).

Sinon pour compiler sous Windows sans utiliser Visual Studio, en fait t'as plein de moyens d'y arriver, mais pour chacun d'entre eux il faut un peu se démerder. J'utilise Cygwin et ça marche pas trop mal, du moment qu'un chemin type Windows (avec des noms de volume et des backslashs, beurk) ne vient pas tout casser. Sinon il y a MinGW, c'est moins lourd mais y'a pas de joli terminal, pas de joli shell propre, rien, juste gcc et le strict minimum pour le faire marcher (d'où le nom Minimalist GNU for Windows). Dans les 2 cas il faut recompiler la SFML avec ... eh ... eheh ... Cmake, qu'il faut aussi installer et faire en sorte qu'il s'intègre correctement dans l'environnement.

Ouais, je suis en école d'info. J'ai commencé à programmer au lycée sur ma calculatrice dès que j'ai posé les yeux sur son manuel, ça remonte à 6 ans maintenant. J'ai fait quelques jeux (mais pas que ça), le seul qui soit complet est un jeu de dames (sur la calculatrice sus-citée), les autres j'ai toujours eu soit la flemme de continuer, soit j'avais pas le temps à cause des études (bien qu'en réalité je glandais pas mal en prépa xD ). Il y a quelques mois je me suis lancé dans un projet assez costaud ( https://touhou-france.forumactif.com/t1916-projet-jeu-de-combat-avec-personnages-et-maps-scriptables ), mais j'ai vraiment du mal à trouver le temps de m'en occuper, j'ai pas eu de grandes vacances (juste 2 semaines pour aller voir ma famille ?) et maintenant non seulement je suis en stage, mais en plus pour ce mois d'Octobre, au Japon, j'ai l'impression qu'ils se sont surpassés pour sortir des animes plus intéressants que d'habitude. Ce que je ne veux pas louper, et j'ai pas envie de reporter non plus (j'ai déjà d'autres animes/mangas en attente, et même quelques tomes de Discworld et H2G2 que j'ai pas encore ouverts), humhum.

Krssst a écrit:En effet, ça paraît logique. Dommage de risquer de perdre les optimisations sur des variables flottantes constantes auxquelles on fait très souvent accès ; si j'ai bien compris le post de stackoverflow il faudrait activer les "whole program optimizations" (en ajoutant le link time optimization avec -flto si j'ai bien compris, mais mais je n'ai pas trop cherché).

Krssst a écrit:J'avais déjà codé un peu avant le lycée (deux ou trois horreurs en PHP) mais c'est vrai que la calculatrice motive plus, surtout quand il y a un cours d'autre chose en même temps :-) Même problème de mon côté ; démotivation (surtout quand le jeu s'avère être chiant quand on y joue entre amis - grande désillusions) et manque de temps. Là le principe du jeu est très très simple mais je m'amusais un minimum en y jouant et j'ai quand même essayé d'aller jusqu'au bout vu que ça pouvait pas être bien long (en fait tout ce qui était hors gameplay a été 90% du temps de développement) et histoire de pas être totalement bredouille si je postule pour un stage (mais bon, c'est vrai que ça doit pas rendre forcément service).

Krssst a écrit:Au niveau de ton projet de jeu de combat scriptable, je serais tenté de proposer de participer au niveau code mais niveau temps je suis un peu juste aussi (beaucoup de temps libre en début d'année, mais là début des projets + arrivée des examens = plus maintenant) ; je serai tout de même curieux de jeter un oeil s'il y a un wiki et/ou un arbre git :-)