Baballe - Page 1

J'avais envie de programmer un baballe. C'est maintenant chose faite.

Bon, j'ai un peu revu le principe, maintenant, non seulement il ne faut pas aller sur les cases blanches (bon, vu la map du gif animé, ça n'est pas très difficile), mais en plus, les cases noires rapportent des points et les cases gris clair vous font sauter. Ça permet d'élargir un peu le gameplay que je trouvais assez pauvre.

Les touches à utiliser pendant sont les deux flèches directionnelles et la touche [ESC] pour quitter (parce que ça recommence en boucle sinon, et dans la map dispo actuellement, c'est impossible de mourir).

Le jeu n'est pas encore terminé, je compte gérer des niveaux externes, des high-scores, peut-être des modes de difficultés supplémentaires. Et il faut que je fasse au moins une quinzaine de maps (de 200 lignes chacunes au moins) pour que le jeu soit potable. Et je changerai peut-être le sprite de la "balle" pour mettre une animation.

La source est distribuée avec, vous pouvez vous amuser à modifier des paramètres et voir comment ça influe sur le moteur. Les paramètres actuels sont ceux qui me plaisent le plus. Vous pouvez modifier la hauteur de la caméra par rapport au sol et sa distance focale (c'est-à-dire, la distance caméra-écran [projetée sur l'axe Z en fait]), vous pouvez aussi modifier la longueur des cases.

Mais en fait, j'ai un petit problème : le jeux est en niveaux de gris, et pour avoir une bonne jouabilité, il est nécessaire d'avoir des niveaux de gris de bonne qualité (il faut pouvoir distinguer facilement une case blanche d'une case gris clair). Sur vti avec les routines classique, ça rend plutôt bien (comme d'hab), mais sur realTI, ce n'est pas terrible et l'écran bave en plus. Je me suis dit que j'allais utiliser le double buffering de TIGCC pour pallier à ce problème, mais j'ai vraiment l'impression que ça ne change rien... Enfin si : sur VTI les niveaux de gris sont horribles et clignotent affreusement.
Dans la source, il y a une directive de compilation #define USE_DBUF qui permet de spécifier si on souhaite utiliser le double buffering ou non. Est-ce quelqu'un qui connaît le fonctionnement du double buffering pourrait me dire si je ne fais pas n'importe quoi ? (la source n'est pas grande du tout et toutes les lignes relatives à l'utilisation du double buffering sont encadrées par un #ifdef USE_DBUF....#endif [attention, j'utilise aussi #ifndef parfois.)

Merci.

Au fait, voici le ZIP qui contient la source et l'exécutable (pas de readme, désolé) : http://perso.wanadoo.fr/jackiechan68k/download/Baballe.zip

Le clignotement sur VTI (et sur vraie HW1!) s'explique par le fait qu'il faut attendre 2 switches après GrayDBufToggleSync(); sur HW1:
if (!_GrayIsRealHW2()) GrayWaitNSwitches(2);
Cf. http://pub26.ezboard.com/ftichessteamhqfrm15.showMessage?topicID=233.topic.

Merci.
Et il n'y a pas de solution pour que l'écran bave moins ? Je croyais que l'utilisation du double buffering rendait l'image plus propre.
Sinon, si au lieu d'afficher 20 fps j'en affiche 40 (en divisant la vitesse par deux aussi, évidemment), ça améliorera la netteté ?
Si c'est le cas, j'essaierai ça, mais il faudra que j'optimise à fond pour pouvoir afficher assez de frames par secondes.

jackiechan
a écrit : Sinon, si au lieu d'afficher 20 fps j'en affiche 40 (en divisant la vitesse par deux aussi, évidemment), ça améliorera la netteté ?

Probablement pas. Tu affiches déjà 2 fois plus de fps que nécessaire.

Ça ralentit drôlement, d'attendre 2 switches...
Je ne vois aucun changement quand j'utilise le double buffering et quand je ne l'utilise pas.
Mais avec le double buffering, le fait d'avoir à attendre 2 switches ralentit pas mal le prog...
Est-ce qu'il y a un intérêt à ce que je continue à utiliser le double buffering ?

Ce que tu fais "sans double-buffering" est aussi du double-buffering, juste par une autre technique (recopie de buffers contre échange de pointeurs).

Ce que tu peux essayer, c'est d'utiliser ta recopie de buffers en attendant 1 switch (GrayWaitNSwitches(1);) avant tes 2 memcpy. GrayDBufToggleSync(); attend aussi 1 switch de toute façon. Peut-être que ça rend mieux comme ça.

Un autre truc à essayer est d'utiliser l'échange de pointeurs et de ne pas attendre les 2 switches tout de suite, mais juste quand tu essayes de recommencer à dessiner. Mets:
unsigned long w=0;
au début,
w=GrayGetSwitchCount()+2;
après GrayDBufToggleSync(); et:
while(GrayGetSwitchCount()<w);
avant l'affichage du frame.

ou alors tu utilises les gray de GX.. (methode la plus rapide je crois)

Pas du tout! Je vais copier-coller ma réponse à Thibaut du topic signalé dans le message #1, que tu n'as visiblement pas lue:

>With GraphX and other specialized libraries, the user don't have to understand the mechanism.

That's wrong. You have to understand double-buffering to use it, whether you use our routines or yours.

<< For exemple, with Graphx, he just have to write "GX_DisplayWorkBuffer" to display modifications to the screen ! It's GraphX which <handles> the synchronisation and the swap buffering, not the user >>

What's the difference between calling GX_DisplayWorkBuffer and calling GrayDBufToggleSync?

Yes, you need to wait for synchronization once more after calling GrayDBufToggleSync on HW1. (Use GrayWaitNSwitches(2); after GrayDBufToggleSync.) I think that this needs to be fixed (it should be done by the GrayDBufToggleSync macro).

Pourtant il me semble qu'il avait trouvé une solution pour eviter d'attendre la synchro (3 buffer ..) ??

Ah, tu veux parler de vitesse d'exécution, pas de simplicité d'utilisation. Bon, en effet, sa méthode est légèrement (voire négligeablement) plus rapide (l'ordre de grandeur de la différence dépend largement du programme, donc je ne peux pas donner une indication plus précise), mais consomme une grande quantité de mémoire supplémentaire (il utilise en plus des buffers plus grands que nécessaire).

oui, mais ce qui ralentit dans un jeu, c'est surtout les niveaux de gris.. je peux faire des routines aussi rapide que je veux, ca ne se vera pas a cause des nv de gris

Voici une nouvelle version de Baballe.
Les quelques nouveautés sont :
- Niveaux externes
- Gestion des scores

C'est à peu près tout...
Baballe.zip

Beta 1 :
[li]5 niveaux au total[/li]
[li]Niveaux dans l'exécutable (pas de fichier séparé)[/li]



Cette version sera la dernière à priori.

Sasume == jackiechan? Je savais pô

Depuis cet été
Ceci dit il est bien sympa le baballe

Tu devrait laisser les niveau en externe, qu'on puisse en rajouté (et faire un petit tuto pour en créer).

En fait, c'est parce que j'ai la flemme de faire un truc propre pour créer ses niveaux que j'ai fait ça.
Au début, j'étais parti dans l'optique de faire éventuellement un éditeur de niveaux, donc j'avais commencé à mettre les niveaux en externe, mais finalement ça m'ennuie de faire l'éditeur ; et de les faire à la main, c'est un peu du bidouillage, mais si tu veux, je peux t'expliquer le format des niveaux...
Remarque ça doit être décrit dans les sources je pense.

a ui, éxact, pas besoin de tuto, le format est assez simple.

Y a rien à modifier si ce n'est le fichier map.c ??

sinon, HSx et magic, ils servent à koi ??

hs=highscore (d'ailleurs, le highscore n'est sauvegardé que si le prog est désarchivé, je n'avais jamais fait attention à ça)
magic ne sert plus à rien en fait. Il devait servir, quand les niveaux étaient encore des fichiers externes, à identifier le fichier comme étant effectivement un niveau du jeu baballe, et pas autre chose.
En changeant le fait que les niveaux ne sont plus dans des fichiers externes, j'ai quand même voulu garder la possibilité de revenir en arrière, donc j'ai gardé la même structure de données. D'ailleurs, si tu fais attention tu verras qu'à côté des instructions qui concernent les niveaux, il y a parfois une instruction semblable au-dessus mais mise en commentaire. Il s'agit des instructions que j'utilisais quand les niveaux étaient externes que j'ai voulu garder pour pouvoir revenir facilement en arrière.
Voilà.

c l'avantage des fichiers externes, c trés facile de les archiver/désarchiver pour les modifiers^^

tu me diras, c aussi simple de copier le prog en ram puis d'écraser le fichier archivé avec à la fin de la partie, mais bon^^

MacIntoc
: c l'avantage des fichiers externes, c trés facile de les archiver/désarchiver pour les modifiers^^

Oui, et si tu regardes le code, tu verras que pour la fonction LoadMap, c'est ce que je faisais quand j'utilisais des fichiers externes.

pkoi tu utilises plus technique ??

Parce que les niveaux sont en interne.
J'ai peut-être mal compris ta question.

euh... c tout à fait possible que tu ne l'est pas comprise, étant donné que j'ai zappé la moitié des mots

je reprend :
Pkoi tu n'utilise plus de fichiers externe ??

lol
Comme je n'ai pas fait d'éditeur de niveaux, quand j'ai voulu releaser, je me suis dit que c'était dommage d'utiliser un fichier externe pour stocker les niveaux. Ça me permettait de gagner de la place, puisque je supprimais la fonction qui recherche les fichiers de niveaux pour baballe (qui doit faire environ 300 octets) et que je simplifiais l'utilisation puisqu'il n'y a plus qu'un fichier à envoyer à sa TI.

c vrai, d'un autre coté, vu la simplicité des niveaux, l'éditeur est par forcément indispensable (c pas comme GBS)^^

Beuh ds gbs il est pas forcément indispensable, y'avait bien un gbsXport.tpr pendant un moment

Bon, cette doc pour l'éditeur de niveaux de gbs, tu la fait quand ???

elle est presque terminée... http://perso.club-internet.fr/vertyos/Html/GMEDoc/index.htm

Il me manque du temps et surtout de la motivation.