Forum de Ti-Gen.org, le site francophone des TI

Bienvenue Invité ! Se connecter Mes sujets	Administrer
Utilisateurs actifs : Aucun membre + 1 visiteur

Avant de poster sur le forum, il y a des régles de bases à respecter pour une bonne entente et un respect de tous.
Veuillez lire la charte du forum.

:: Index » Forum Ti68K » Programmation C » FrameSkip et optimisation? (16 réponse(s))

./POST DE DEPART (post n°0) Marquer comme non lu.

geogeo

Ecrit le: Mercredi 17 mars 2004 à 13:17

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

Voilà j'ai quelques problèmes à maintenir un fps résonnable pour mon jeu, en effet quand le jeu est en dessous de 60 fps le déplacement de la raquette à tendance à être très lent, y a t'il un moyen de corriger ça en permettant une gestion de son déplacement avec une interruption sans altérer la fluidité?

De plus la gestion des objets sur le jeu (Bille, Raquette, Bonus, Missiles, monstres...) est faite grâce à l'auto int n°1 et j'ai peur que le temps d'execution de toutes ses fonctions fassent planter la calculatrice. Je demande ça car je constate un énorme problème sur VTI, le fps est divisé par 2 peut être parce que VTI émule du 10 MHz? Et les niveaux de gris on tendance à clignotter lorsqu'il y a beaucoups d'objets. Voici le code de l'interruption, n'y a t-il vraiment pas un moyen d'alléger l'interruption? http://perso.wanadoo.fr/tisofts/divers/Interrupt.h

De plus il y aura certaines partie du jeu qui devront s'occuper de gérer plus de 20 monstres sur l'écran... ce que le moteur est capable de faire mais la machine ne suit pas, en effet j'ai réalisé un test en affichant 20 monstres avec ombres, 5 billes et 5 raquettes avec un niveaux comportant plus de 15 briques spéciales et le jeu tourne seulement à 20 fps ce qui me paraît bizarre car le jeu original a été développé sur un Z80 8 MHz et affiche bien plus d'objets sans constatez de fort ralentissements.

J'ai donc pensé à ajouter un FrameSkip mais je ne sais pas vraiment comment ça s'applique au jeu, le FrameSkip ne s'applique juste qu'aux fonctions d'affichage ou carrément à la boucle principal du jeu??

Désolé de poser cette question mais j'aimerais vraiment avoir beaucoups d'infos sur ce sujet pour en apperndre plus sur le développement de jeux. Merci d'avance.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°1 Marquer comme non lu.

cassius

Ecrit le: Mercredi 17 mars 2004 à 16:54

Membre privilégié

Messages: 111

Membre n°11

Inscrit le 31 janvier 2004

oue ca m alair interressant

"la foi est la plus grande preuve de courage" dante

./Post n°2 Marquer comme non lu.

Jfg

Ecrit le: Mercredi 17 mars 2004 à 18:35

Administrateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 1260

Membre n°60

Inscrit le 23 février 2004

Ca m'ettonerait que le frame skip s'applique a la boucle principale, tu aurais par exemple des probleme de gestion de collision non ?

Kill Mario

./Post n°3 Marquer comme non lu.

geogeo

Ecrit le: Mercredi 17 mars 2004 à 18:54

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

Les collisions sont assez bien gérer, même si la Bille fait 6 pas, elles seront reconnus...

Mais je vois pas comment ajouter un FrameSkip.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°4 Marquer comme non lu.

Sasume

Ecrit le: Mercredi 17 mars 2004 à 19:41

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Je n'ai jamais su comment étaient foutu les frameskip dans les jeux, mais je pense que ça ne peut que consister omettre de dessiner tout ce que tu as à dessiner à l'écran, juste sur une frame. Ça devrait te faire gagner un peu de temps qui te permettrait de calculer les trucs dont tu as besoin.
Mais bon, c'est vraiment dommage si il y a un frameskip dans ton jeu....
Essaie plutôt d'optimiser ton code...

./Post n°5 Marquer comme non lu.

geogeo

Ecrit le: Mercredi 17 mars 2004 à 19:53

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

Je voudrais bien optimiser plus mais je ne peux pas, les TIs sont trop peu puissantes pour permettre un déroulement du jeu dans les pires conditions, ce que j'ai résumé en haut. En fait le jeu tourne à 57 fps avec 3 monstres, 4 briques spéciales, une raquette et 5 billes avec les ombres. Mais si je veux aller au delà par exemple 10 monstres, 2 raquettes, 15 billes et 15 briques spéciales avec ombres, j'arrive à 20 fps mais certains niveau demande un affichage et une gestion de plus de 20 monstres avec un boss, 1 bille et une raquette. Je ne peux pas vraiment tester mais il semble que j'arrivais dans ce cas à 10 fps ce qui est trop peu. De plus tous les objets sont géré avec une interruption donc si on loupe une boucle principal on ne verra rien car les objets ce déplacerons toujours à la même vitesse et les collisions seront toujours bien réalisées même si la marge d'erreurs augmente. Ce que j'ai peur c'est niveau fluidité...
Je vais esayer de voir si je peux pas optimiser les fonctions SHADOW et d'affichage de sprites.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°6 Marquer comme non lu.

Lionel Debroux

Ecrit le: Mercredi 17 mars 2004 à 20:59

Envoyer un message privé à Lionel Debroux

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Déjà, 57 fps est le triple du framerate maximum raisonnable sur nos TI-68k (l'écran étant trop mauvais). Pour info, Ice Hockey 68k et Duke68k tournent vers 15 fps, et ça va très bien.

> Je vais esayer de voir si je peux pas optimiser les fonctions SHADOW et d'affichage de sprites.
Les SHADOW 8 et 16, pas vraiment... Tu as déjà 2*2 boucles.
Les SHADOW 32, en revanche, peuvent être optimisées. Dérouler la boucle deux fois ne sert presque à rien en vitesse sur cette routine. Deux shiftings iraient bien, mais ça complique beaucoup le code...
Je suis en train d'optimiser la SHADOW 32 pour l'utilisation que j'en ai dans ExtGraph, avec une seule boucle. Il faudra que tu refasses les modifications pour t'adapter à ton format de plane...
Si tu veux plus de vitesse sur les fonctions de sprite, il faut 2*2 boucles (deux shiftings, boucle déroulée deux fois). Mais ça ne gagnera qu'une vingtaine de %, alors que ça double la taille de la routine...
Les SHADOW sont les plus lentes des fonctions de sprite. Elles sont plus complexes que toutes les autres.

Est-ce que ton jeu se prête à l'utilisation de fonctions de tile (sprites dessinés à des coordonnées multiples de 8 ou de 16 suivant leur taille) ? De telles fonctions sont beaucoup plus rapides que les fonctions de sprite standard pour cette utilisation.

Si ça ne va toujours pas, eh bien, il y a toujours le preshifting, qui consomme *énormément* de mémoire, ou le tilemap engine, mais il faudra réécrire des trucs (bien qu'il ne faille déjà pas refaire les sprites puisque tu as déjà des entrelacés)... Essaie aussi d'utiliser moins de sprites masqués (MASK) et plus de BLIT voire RPLC.

Lionel Debroux - membre de TICT.

./Post n°7 Marquer comme non lu.

geogeo

Ecrit le: Mercredi 17 mars 2004 à 21:31

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

En fait j'utilise intensément quand je le peux les fonctions de dessin de sprites à des coordonnées absolus donc des multiples de 8.
Le programme commence à être assez gros, je ne sais même pas ce que je vais faire lorsqu'il arrivera à 64 Ko.

Pour l'instant il fait 50 Ko ce qui n'est pas rien.
COmme tu l'auras remarqué, il y a beaucoups de fonctions d'affichage dans le jeu et ce pour avoir le maximum de vitesse mais j'arrive à un point où je doute que je dois optmiser mais grossir le programme ou inversement.

>Déjà, 57 fps est le triple du framerate maximum raisonnable sur nos TI-68k (l'écran étant trop mauvais). Pour info, Ice Hockey 68k et Duke68k tournent vers 15 fps, et ça va très bien.

Ah oui, l'écran est vraiment mauvais qu'un simple motif de sprite trop clair ou trop foncé le fait baver.
J'aimerais bien un Framerate grand minimum de 25 fps. En dessous de 20 fps le jeu n'est vraiment pas fluide et ça devient un désastre visuel car on vois la bille saccader... Mais comme je l'ai dit pour l'instant je suis à 57 fps dans les conditions normal mais je veux permettre un jeu le plus fluide dans les pires conditions? Peut être qu'ajouter un FrameSkip variable serait interessant?

Après avoir effectué de nombreux tests, les fonctions graphiques consomment mais bon reste les fonctions de collisions et gestion des objets qui consomment horriblement, pour info, l'ajout d'un monstre consomme 2 fps environ, l'ajout d'une raquette, 3 fps, l'ajout d'une bille entre 1 et 2 fps.

>Les SHADOW 8 et 16, pas vraiment... Tu as déjà 2*2 boucles.
Les SHADOW 32, en revanche, peuvent être optimisées. Dérouler la boucle deux fois ne sert presque à rien en vitesse sur cette routine. Deux shiftings iraient bien, mais ça complique beaucoup le code...
Je suis en train d'optimiser la SHADOW 32 pour l'utilisation que j'en ai dans ExtGraph, avec une seule boucle. Il faudra que tu refasses les modifications pour t'adapter à ton format de plane...
Si tu veux plus de vitesse sur les fonctions de sprite, il faut 2*2 boucles (deux shiftings, boucle déroulée deux fois). Mais ça ne gagnera qu'une vingtaine de %, alors que ça double la taille de la routine...
Les SHADOW sont les plus lentes des fonctions de sprite. Elles sont plus complexes que toutes les autres.

Oui SHADOW32 est assez lent mais surtout à cause des registres du CPU qui ce limitent à 32 bits et donc qui compliquent le codage.

Je pense que booster ses fonctions serait interessant, j'essayerais de gagner la taille que j'ai perdu autre part.

>Est-ce que ton jeu se prête à l'utilisation de fonctions de tile (sprites dessinés à des coordonnées multiples de 8 ou de 16 suivant leur taille) ? De telles fonctions sont beaucoup plus rapides que les fonctions de sprite standard pour cette utilisation.

Oui j'utilise énormément ça c'est d'ailleurs pour ça que casser une brique ne consomme vraiment rien car le décor est redessiné avec les ombres comme il faut et ce seulement avec des routines ne travaillant qu'avec des coordonnées multiples de 8. De plus pour réafficher la MAP à chaque frame j'utilise un buffer... Bref il y a un travaille d'optimisation assez important dans le jeu et je doute de pouvoir mieux dans tout ce qui est affichage.

>Si ça ne va toujours pas, eh bien, il y a toujours le preshifting, qui consomme *énormément* de mémoire, ou le tilemap engine, mais il faudra réécrire des trucs (bien qu'il ne faille déjà pas refaire les sprites puisque tu as déjà des entrelacés)... Essaie aussi d'utiliser moins de sprites masqués (MASK) et plus de BLIT voire RPLC.

Je préfère pas utiliser tilemap engine ou encore du preshifting c'est bien mieux de tout coder et de rester un maximum compatible avec Pedrom ce qui est vraiment le cas en ce moment. De plus ça consommerait trop de mémoire ce qui commence à devenir urgent dans mon cas.

Par contre s'est quoi les sprites BLIT ou RPCL? Ca apporte un gain vraiment important?

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°8 Marquer comme non lu.

Kevin Kofler

Ecrit le: Jeudi 18 mars 2004 à 01:59

Administrateur

Groupe: Staff de Ti-Gen

Messages: 4814

Membre n°40

Inscrit le 08 février 2004

Attention, je ne suis pas sûr que tu as compris ça: Un frameskip ne va par définition pas augmenter ton framerate. Ce que ça va faire, c'est faire en sorte que le jeu ne ralentisse pas quand le framerate descend.

Membre de l'équipe de TIGCC: http://tigcc.ticalc.org
Mainteneur du portage Linux/Unix de TIGCC: http://tigcc.ticalc.org/linux/
Membre de l'équipe de CalcForge: http://www.calcforge.org:70/

Participez à la reprise de Ti-Gen!

./Post n°9 Marquer comme non lu.

geogeo

Ecrit le: Jeudi 18 mars 2004 à 07:29

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

Ouai bien sûr.

Je vais voir ce que je peux faire sans Frameskip.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°10 Marquer comme non lu.

Sasume

Ecrit le: Jeudi 18 mars 2004 à 14:07

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

> Je préfère pas utiliser tilemap engine ou encore du preshifting c'est bien mieux de tout coder et de rester un maximum compatible avec Pedrom ce qui est vraiment le cas en ce moment
Quel rapport avec PedroM ?

Tu utilises quoi actuellement pour afficher ton arrière-plan ?

./Post n°11 Marquer comme non lu.

Lionel Debroux

Ecrit le: Jeudi 18 mars 2004 à 18:05

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> Par contre s'est quoi les sprites BLIT ou RPCL? Ca apporte un gain vraiment important?
BLIT: voir la doc d'ExtGraph.
RPLC: c'est BLIT avec un blitmask hard-coded de 0. Je ne les ai pas encore toutes écrites.

Lionel Debroux - membre de TICT.

./Post n°12 Marquer comme non lu.

geogeo

Ecrit le: Jeudi 18 mars 2004 à 19:05

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

>BLIT: voir la doc d'ExtGraph.
RPLC: c'est BLIT avec un blitmask hard-coded de 0. Je ne les ai pas encore toutes écrites.

Ok je vais m'informer.

Sasume> Oups désolé il n'y avais aucun rapport avec PedroM, je voulais parler de compatibilité avec mon format de sprites...

Pour afficher mon arrière plan, j'utilise un sprite de 32x32 motif que je répéte à des coordonnées divisibles par 8 et une routine s'occupant d'afficher que ll'arrière plan, pour accélérer les choses, l'arrière plan en divisé en 3 zones.

-Edité le: Jeudi 18 mars 2004 à 19:06 par geogeo-

-Edité le: Jeudi 18 mars 2004 à 19:07 par geogeo-

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°13 Marquer comme non lu.

Sasume

Ecrit le: Jeudi 18 mars 2004 à 19:11

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Si tes coordonnées sont aussi divisibles par 16, alors tu pourras afficher 4 octets à la fois, ce qui accélèrera ta routine, si elle n'affiche qu'un octet à la fois.

./Post n°14 Marquer comme non lu.

Lionel Debroux

Ecrit le: Jeudi 18 mars 2004 à 19:24

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Ah, c'est ce que j'allais suggérer.
Pour info, geogeo: j'ai écrit et testé toutes les routines de tile B/W et grayscale prenant des sprites non entrelacés pour ExtGraph. A partir de là, faire et tester les routines prenant des sprites entrelacés est assez facile (1 à 2 h)...
Je suis encore assez loin de la Beta 2 (sans update de doc - le boulot qu'Orage et toi m'avez fait est à peu près inutilisable, je n'en ai pas tenu compte quand j'ai modifié des trucs; je vous ferai un template plus explicite quand je vous demanderai de le refaire)...

Lionel Debroux - membre de TICT.

./Post n°15 Marquer comme non lu.

geogeo

Ecrit le: Jeudi 18 mars 2004 à 20:04

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

Oui j'ai pas précisé mais oui bien sûr j'affiche plusieurs octets à la fois par paquet de 2 ou de 4 suivant les routines...

>Pour info, geogeo: j'ai écrit et testé toutes les routines de tile B/W et grayscale prenant des sprites non entrelacés pour ExtGraph. A partir de là, faire et tester les routines prenant des sprites entrelacés est assez facile (1 à 2 h)...
Je suis encore assez loin de la Beta 2 (sans update de doc - le boulot qu'Orage et toi m'avez fait est à peu près inutilisable, je n'en ai pas tenu compte quand j'ai modifié des trucs; je vous ferai un template plus explicite quand je vous demanderai de le refaire)...

Ok pas de pbs mais pas en ce moment j'ai pas beaucoups de temps entre mon TPE, les cours et diverses choses personnelles.

>le boulot qu'Orage et toi m'avez fait est à peu près inutilisable

Dséolé nous avons pensé faire de notre mieux.

Webmaster du site.
Programmeur sur TI68K. Arkanoid, Nebulus, GFA-Basic.

Plus d'informations sur GFA-Basic (un langage Basic pour TI68K).
http://www.tigen.org/gfabasic

./Post n°16 Marquer comme non lu.

Lionel Debroux

Ecrit le: Vendredi 19 mars 2004 à 19:39

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> Dséolé nous avons pensé faire de notre mieux.
Evidemment, même si je pense bien avoir spécifié qu'il fallait copier les prototypes depuis la doc, pas faire ce que vous avez fait...
Ca n'est pas tellement pour râler que pour vous le signaler: si je délègue et que je ne suis pas content du résultat parce que je n'ai pas été clair ou contrôlé suffisamment, je répare les conséquences...

Lionel Debroux - membre de TICT.