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 » Projets » Jeux de voiture!!! (190 réponse(s))

./REPRISE DU POST PRECEDENT (post n°152) Marquer comme non lu.

Benjy

Ecrit le: Lundi 28 juin 2004 à 12:15

Membre: Maître Ultime

Groupe: Omega staff

Messages: 1156

Membre n°91

Inscrit le 09 mars 2004

non il faut pas laisser tomber mais ce qu'il ya c'est qu'il n'y pas grand monde d'actif la

Le langage C y'a pas mieux!!!

./Post n°153 Marquer comme non lu.

geogeo

Ecrit le: Lundi 28 juin 2004 à 12:24

Fondateur

Groupe: Staff de Ti-Gen

Groupe: Orage Studio

Messages: 4257

Membre n°3

Inscrit le 29 janvier 2004

Je voudrais être plus actif sur ce projet mais je dois développer le forum et le site et ça me bouffe enormément de temps.

Sinon en faisant des recherches je pense qu'il faudrait récupérer les graphismes de V-Rally sur GB.

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°154 Marquer comme non lu.

Lionel Debroux

Ecrit le: Lundi 28 juin 2004 à 21:06

Envoyer un message privé à Lionel Debroux

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

J'ai joué un peu avec le code d'Extreme Racing. J'ai mis ExtGraph 2.00 Beta 3 (ce qui ne gagne de toute façon pas grand chose), changé la hauteur des sprites (il a un sprite 32x32 dont les 8 lignes supérieures et inférieures sont blanches...). En changeant aussi quelques paramètres (largeur de la route, distance à laquelle on voit), on garde plus de 25 FPS sur vraie 89 HW2 (compteur de frame corrigé avec un rate de 256 Hz et pas 350 Hz pour l'AI1) tout en en voyant plus que sur l'original. L'objectif de 15 FPS devrait donc être envisageable.
Il faut que je modifie le code pour utiliser directement des routines __regparm__ pour les multiplications et divisions, à la place des routines librairie __stkparm__ que GCC exige. Ca sera moins lisible mais plus efficace.

[EDIT: enlevé une bêtise...]
-Edité le Lundi 28 juin 2004 à 21:31 par Lionel Debroux-

Lionel Debroux - membre de TICT.

./Post n°155 Marquer comme non lu.

Sasume

Ecrit le: Lundi 28 juin 2004 à 21:08

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Essayez d'avoir un objectif de 20 fps plutôt, c'est quand même plus agréable.
Sinon, tu utilises quelles routines de Extgraph ? Tracé de ligne horizontale ?

./Post n°156 Marquer comme non lu.

Lionel Debroux

Ecrit le: Lundi 28 juin 2004 à 21:14

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

J'ai édité le post pendant que tu écrivais le tien.

20 FPS ne me paraît pas envisageable - surtout si on utilise du vrai doublebuffering, ce qui n'est pas le cas là (macros de doublebuffering, mais FastCopyScreen non synchronisés). N'oublie pas que pour LTC, il faut mettre le bas-côté, les arbres, une IA (les adversaires), les checkpoints quand c'est nécessaire, la gestion du carburant...
D'ExtGraph, il y a les routines de lignes horizontales, FastCopyScreen_R, GrayClearScreen2B_R, GraySprite32_MASK_R.

Lionel Debroux - membre de TICT.

./Post n°157 Marquer comme non lu.

Sasume

Ecrit le: Lundi 28 juin 2004 à 21:27

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

J'ai regardé les sources d'AUTOmatix v0.02, et à mon avis, c'est surtout le tracé des lignes horizontales qui prend du temps.
Tu utilises quelle routine d'extgraph pour les lignes horizontales ? La mienne qui écrit par pas de 32 pixels ?
Parce que j'en avais écrite une autre, qui était plus rapide pour les petites lignes, donc je peux te la passer, bien que je ne sois pas sûr que les lignes soient franchement petites dans ce moteur de jeu (par petites, j'entends entre 0 et 50 pixels de largeur).

./Post n°158 Marquer comme non lu.

Lionel Debroux

Ecrit le: Lundi 28 juin 2004 à 21:29

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> Tu utilises quelle routine d'extgraph pour les lignes horizontales ? La mienne qui écrit par pas de 32 pixels ?
Oui.

> Parce que j'en avais écrite une autre, qui était plus rapide pour les petites lignes, donc je peux te la passer, bien que je ne sois pas sûr que les lignes soient franchement petites dans ce moteur de jeu (par petites, j'entends entre 0 et 50 pixels de largeur).
Beaucoup de lignes sont bien plus grandes que ça. Mais les bordures de route (blanc) d'Extreme Racing sont très petites.

Lionel Debroux - membre de TICT.

./Post n°159 Marquer comme non lu.

Sasume

Ecrit le: Lundi 28 juin 2004 à 21:29

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Sinon, je ne comprends absolument rien à la façon dont le moteur fonctionne.
Déjà, je n'arrive pas à trouver où sont stockés les niveaux...

Quelqu'un peut-il m'éclairer ?

./Post n°160 Marquer comme non lu.

Sasume

Ecrit le: Lundi 28 juin 2004 à 21:31

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Au fait, à propos des routines de tracé de lignes horizontales d'extgraph, elles ne sont pas en nvg, il me semble. Tu les as modifiées ou bien tu appelles 1 fonction pour chaque plan ?

./Post n°161 Marquer comme non lu.

Lionel Debroux

Ecrit le: Lundi 28 juin 2004 à 21:32

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Pour Extreme Racing, les niveaux sont aléatoires et créés au début.

Lionel Debroux - membre de TICT.

./Post n°162 Marquer comme non lu.

Benjy

Ecrit le: Lundi 28 juin 2004 à 21:35

Membre: Maître Ultime

Groupe: Omega staff

Messages: 1156

Membre n°91

Inscrit le 09 mars 2004

pour LTC les niveaux seront predefinis

Le langage C y'a pas mieux!!!

./Post n°163 Marquer comme non lu.

Lionel Debroux

Ecrit le: Lundi 28 juin 2004 à 21:40

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Pour le moment, j'appelle une fonction pour chaque plan.

Le framerate change plutôt peu si on passe au mode Low Quality...

Lionel Debroux - membre de TICT.

./Post n°164 Marquer comme non lu.

Sasume

Ecrit le: Lundi 28 juin 2004 à 21:48

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

C'est super lent d'appeler une fonction par plan. Je pense qu'il faut impérativement qu'on écrive des fonctions pour les niveaux de gris.
Pour gérer les différentes couleurs, un self-modifying code me tenterait bien, mais en même temps, la fonction doit faire à peine plus de 100 octets, donc ce n'est peut-être pas la mort d'avoir 4 fois pratiquement le même code...

Faut voir si le SMC ralentit vraiment ou non. D'après mes tests (qui datent pas mal tout de même, donc je me trompe peut-être), ça ne ralentissait quasiment pas.

./Post n°165 Marquer comme non lu.

Sasume

Ecrit le: Lundi 28 juin 2004 à 22:08

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

J'ai regardé ce qui est dans la beta 2 d'extgraph, et à mon avis, ce qui est utilisé là est le meilleur compromis taille-vitesse : le début de la fonction est le même pour tous les modes, mais on a une boucle différente par mode.
Au passage, il me semble qu'on peut facilement gagner quelques octets et quelques petits cycles sur ces routines. Je verrai ça demain.

./Post n°166 Marquer comme non lu.

Sasume

Ecrit le: Lundi 28 juin 2004 à 22:17

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Bon, en fait, je n'ai pas pu m'empêcher de regarder maintenant.
Donc en fait, l'optimisation à laquelle je pensais n'est pas possible puisqu'il faut gérer le mode REPLACE et le mode NORMAL (ce serait bien si on pouvait virer le mode REPLACE qui n'a pas de sens pour une ligne horizontale, ça permettrait d'optimiser plus), mais on peut quand même gagner quelques petits cycles (8 grand maximum, je crois) sans prendre de place en plus.
Je vérifierai ça demain (pour de vrai).

./Post n°167 Marquer comme non lu.

Benjy

Ecrit le: Lundi 28 juin 2004 à 22:56

Membre: Maître Ultime

Groupe: Omega staff

Messages: 1156

Membre n°91

Inscrit le 09 mars 2004

lol super le travail pour le jeu commence reelement

ca le fait

Le langage C y'a pas mieux!!!

./Post n°168 Marquer comme non lu.

Lionel Debroux

Ecrit le: Mardi 29 juin 2004 à 09:53

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

> C'est super lent d'appeler une fonction par plan.
En effet. C'était juste pour essayer.

Dans Extreme Racing, on peut enlever le mode A_XOR, et même ne pas faire de SMC: Malcolm a fait quatre fonctions séparées pour les 4 couleurs. Cette optimisation vitesse est extrême (d'autant plus que pour lightgray et darkgray, il suffit d'inverser les arguments de plane), mais coûte en fait peu cher en place. Le moteur lui-même fait environ 7 KB, ce sont les sprites:
* backgrounds: 3*7680 octets;
* sprites préscalés: 3*4*1024 octets, qu'on peut réduire à 3*7680 + 3*4*512, car les sprites font 16 pixels de haut
qui la place.
Je ne sais d'ailleurs pas ce qui lui a pris de préscaler les sprites et d'utiliser une boucle d'attente... ScaleSprite32_OR (modifié pour écrire dans un sprite normal) + GraySprite32_MASK_R doivent faire l'affaire, en bien plus petit. Si elles ne sont pas assez rapides, ce dont je doute, il suffit d'optimiser ScaleSprite32_OR comme tu l'avais fait pour ScaleSprite16_OR (plus de deux fois plus rapide).

Lionel Debroux - membre de TICT.

./Post n°169 Marquer comme non lu.

Sasume

Ecrit le: Mardi 29 juin 2004 à 15:38

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Tiens, voilà un premier jet, plutôt optimisé en taille, mais je pense qu'en vitesse il n'est pas mal non plus.
Compare avec ce que tu utilisais avant (à savoir appel de fonction BW par plan).
On peut encore optimiser en taille (6 octets) en perdant en vitesse (10 clocks pour la couleur noire).
Et on peut encore augmenter la vitesse des tracés gris (clair ou foncé) en utilisant un registre supplémentaire (bien sûr il faut penser à le sauver/restaurer) et faire un move plutôt qu'un clr, mais il faut voir si ça augmente vraiment la vitesse...
A tester.

La fonction : http://perso.wanadoo.fr/jackiechan68k/sources/GrayFastDrawHLine2B_R.s
Bien sûr, comme à mon habitude, je n'ai pas testé, je n'ai même pas essayé de la compiler (je suis sous linux et je n'ai pas encore installé TIGCC), donc peut-être qu'il y aura des branchements trop courts - mais ça m'étonnerait).

-Edité le Mardi 29 juin 2004 à 15:40 par Sasume-

./Post n°170 Marquer comme non lu.

Sasume

Ecrit le: Mardi 29 juin 2004 à 15:43

Membre: Titan

Messages: 918

Membre n°24

Inscrit le 01 février 2004

Au fait, je pense que ce sont là mes derniers ajouts à ExtGraph.
En effet, je viens d'écrire cette fonction, et je me rends compte qu'il faudra probablement écrire la version stkparm.

J'ai voulu modifier la fonction FastDrawHLine qui est optimisable elle-aussi, mais je me suis rendu compte qu'il faudra que je modifie aussi la version stkparm.

Bref, ExtGraph est une horreur à maintenir, ça me démotive.

./Post n°171 Marquer comme non lu.

Lionel Debroux

Ecrit le: Mercredi 30 juin 2004 à 11:32

Membre: Maître Ultime

Messages: 1721

Membre n°10

Inscrit le 31 janvier 2004

Je n'ai plus beaucoup de forfait Internet, dont je ne me suis pas connecté hier soir: j'ai fait des routines moi-même. Optimisation vitesse, sans SMC.
Mais je vais quand même évidemment regarder ce que tu as fait.

Après d'autres optimisations (utilisation de __regparm__ pour les macros de division longue signée et non signée et multiplication longue), avec une largeur de route similaire à celle de LTC, une visibilité convenable, j'obtiens les framerates suivants:
* ~23 FPS quand le circuit n'est composé que de montée.
* ~46 FPS quand le circuit n'est composé que de descente.

On peut réduire un peu la taille de la fenêtre dans laquelle on dessinera: il faut bien marquer les infos de course quelque part, en-dehors du circuit. Ca ne change le framerate qu'en montée, et de façon peu significative.

Lionel Debroux - membre de TICT.