Déplacements "arrondis" - Page 1

En ce moment, je travaille sur un jeu et j'ai des problèmes en ce qui concerne la partie déplacements.
J'ai un sprite de 16x16 pixels (un peu moins des fois), mais la zone de collision verticale est plus petite (du pixel 6 au pixel 15 il me semble) que je dois faire bouger. Je voudrais faire des déplacements "arrondis". C'est à dire que si je butte sur le bord d'un coin (c'est un peu compliqué à expliquer), le sprite doit se déplacer d'un pixel vers l'espace vide, puis pouvoir aller d'un pixel dans la direction voulue.
J'ai pas eu le temps de faire des images donc je vais représenter ça avec des 0 et des 1

le coin en haut à gauche d'un bloc par exemple:
00001111
00111111
01111111
01111111
11111111
11111111
11111111
11111111

Bon, là ça devraît suffire pour comprendre. C'est un peu plus compliqué dans la pratique puisque le coin ne doît être arrondi que si il est entouré de deux espaces vides.
Je ne sais pas exactement comment faire ça simplement alors j'aurais besoin d'aide (en espérant qu'on me comprenne...)

GoldenCrystal > C'est quoi que tu appelles windows 4.x (dans ta signature) ?

GoldenCrystal :
En ce moment, je travaille sur un jeu et j'ai des problèmes en ce qui concerne la partie déplacements. J'ai un sprite de 16x16 pixels (un peu moins des fois), mais la zone de collision verticale est plus petite (du pixel 6 au pixel 15 il me semble) que je dois faire bouger. Je voudrais faire des déplacements "arrondis". C'est à dire que si je butte sur le bord d'un coin (c'est un peu compliqué à expliquer), le sprite doit se déplacer d'un pixel vers l'espace vide, puis pouvoir aller d'un pixel dans la direction voulue.

C'est une détection de collisions pixel par pixel que tu veux? Il y a ça dans ExtGraph.

Moumou
: GoldenCrystal > C'est quoi que tu appelles windows 4.x (dans ta signature) ?

Windows 4.x, c'est 95 (4.00), 98 (4.50) ou Me (4.90), normalement.

Hum, c'est plus clair en disant win9x/me alors ...

Euh, non, je veux pas de collision de pixels car c'est bien trop lent pour mon jeu qui est déjà pas très optimisé vu qu'il est en C. Mais je vais quand même tester pour voir si ça ralentit pas trop.

SI ta routine de collision n'est pas utilisée en permanence, tu peux te permettre d'utiliser cette d'extgraph, sinon, faudra que tu utilise d'autres méthodes ...

Ben en fait, je sais pas si je peux utiliser la méthode classique (déplacements "carrés") pour les ennemis parce que j'ai pas regardé comment fonctionnait le jeu original sur ce point

Bah je peux pas te dire sinon, tu peux faire comme si la collision était celle du carré

mon jeu qui est déjà pas très optimisé vu qu'il est en C

ton jeu peu être TRES optimisé s'il est en C.
l'optimisation, c'est du programmeur qu'elle dépend...
ok, il y a une différence entre C et ASM... mais si tu optimise ton code C, il sera pas des masses plus mauvais qu'en ASM.
(enfin, en général)

on bon codeur en C generera du code meilleur qu'un codeur moyen en ASM mais jamais meilleur qu'un bon codeur en ASM

tiens, ça ressemble à quelque chose que j'ai déjà dit un bon paquet de fois
(meme si je ne le disais pas exactement comme ça )

dans mon cas, vaut mieux que je reste au C, vu la façon primitive dont je code en ASM
(sauf pr un peu d'ASM inline, éventuellement...°

suivant se que tu codera tu seras a mon avis (sur TI en tout cas, sur pc je pense qu'il vaux mieux pas y penser) tu sera obligé a des moment de faire des "section critique" 100% en asm...

./12> certes.
Les routines graphiques, par exemple... ce qui explique que j'utilise des librairies, et non pas des routines écrites par moi-même (ça vaut mieux )
cela dit, je suis capable de modifier certaines foncions de ces libs, afin de les adapter à mes besoins.

GoldenCrystal
:mon jeu qui est déjà pas très optimisé vu qu'il est en C

Certains ont l'air de confondre le C avec le TI-BASIC.

godzil
:suivant se que tu codera tu seras a mon avis (sur TI en tout cas, sur pc je pense qu'il vaux mieux pas y penser) tu sera obligé a des moment de faire des "section critique" 100% en asm...

squale92 :
./12> certes.Les routines graphiques, par exemple...

Pour Backgammon, j'utilise une routine de sprites en C et ça marche très bien.

Oui, Kevin en C ça marche.
Mais regarde, en ASM sur certaines routines on gagne 16% de vitesse sans changer un poil de l'algo. (on a peut-être eu de meilleurs résultats sur certaines routines, mais c'est celui là qui m'est revenu en tapant ce post)

Kevin Kofler :
Certains ont l'air de confondre le C avec le TI-BASIC.

Non, mais si tu voyais mon programme, tu comprendrais ce que je veut dire. En plus d'être en C, la plupart de mes fonctions ne sont pas optimisées (surtout les jolies fonction de scrolling que j'ai écrites il y a 3 ou 4 mois), alors, plus le programme deviendra complexe, plus ça sera lent

jackiechan :
Oui, Kevin en C ça marche. Mais regarde, en ASM sur certaines routines on gagne 16% de vitesse sans changer un poil de l'algo. (on a peut-être eu de meilleurs résultats sur certaines routines, mais c'est celui là qui m'est revenu en tapant ce post)

Je sais.
Je sais programmer en ASM, et je sais que ce que je sors est souvent nettement meilleur que ce que me sort GCC. Par exemple, j'ai codé un sscanf en 1,5 KO alors que les réalisations C avec les mêmes fonctionnalités prennent à peu près le double en place.
Mais la question est: est-ce que ça vaut le coup? Pour sscanf certainement (3 KO, c'est trop pour une routine à intégrer à TIGCCLIB!), mais pour une petite routine de sprites utilisée une seule fois?

Utilisée une seule fois, non ce n'est pas la peine.
Mais dans un jeu, on n'appelle pas qu'une fois la routine de sprite, mais par exemple pour afficher ne serait-ce qu'un arrière-plan sur tout l'écran d'une TI-92+, il faut appeler 16*9=144 fois la fonction.

Et il faut savoir que j'ai écrit une fonction de tracé de ligne en ASM qui était plus de 2 fois plus rapide que son équivalente en C, l'algo était le même globalement.
Donc dans ce cas, ça peut valoir le coup !

jackiechan :
Utilisée une seule fois, non ce n'est pas la peine. Mais dans un jeu, on n'appelle pas qu'une fois la routine de sprite, mais par exemple pour afficher ne serait-ce qu'un arrière-plan sur tout l'écran d'une TI-92+, il faut appeler 16*9=144 fois la fonction.

Euh...
Par "utilisée une seule fois", je voulais dire "utilisée dans un seul programme".

Pour Backgammon, j'utilise une routine de sprites en C et ça marche très bien.

ça marche, pour un jeu qui n'est pas hautement graphique.
pour K1, ça marche, en gros... mais ça rame par moment, et ça empéche de rajouter des effets graphiques... et donc, des fonctionnalités. => passage à plus puissant, en méme temps qu'à KII

Mais la question est: est-ce que ça vaut le coup? Pour sscanf certainement (3 KO, c'est trop pour une routine à intégrer à TIGCCLIB!), mais pour une petite routine de sprites utilisée une seule fois?

le fait est que, dans un jeu hautement graphique, la routine de sprites est appelée plus qu'une seule fois... une cinquantaine, voire une centaine, ou deux centaines meme (en meme temps que j'écris, je réfléchis, et je me rend compte que 50 c peu, 100 c encore peu...) de fois par cycle... à mettons 20 cycles par seconde (en espérant que j'arrive à pas trop descendre en dessous )... donc, la rapidité compte bcp !
si c pr appeler qu'une fois, je prend DrawIcon de AMS, et ça fait tout aussi bien l'affaire.

Bah même si c'est utilisé dans un seul programme ça peut être intéressant.

Par "utilisée une seule fois", je voulais dire "utilisée dans un seul programme".

ce à quoi je répondrai la meme chose que jackiechan