Demo de mode 7 - Page 2

Je stocke un octet par tile, donc on peut faire en sorte qu'un même octet n'ait pas la même signification à chaque frame ^^ (un peu comme les palettes rotatives du temps des cartes vidéo 256 couleurs, sauf que là c'est 256 couleurs parmi 4 couleurs au lieu de 256 couleurs parmi 32768 )

pareil, j'utilisais quelques bits dans le codage des tiles pour les animations ou autre. Mais maintenant que j'y pense pour la conso en RAM, y a peut etre moyen de mettre des données en read-only (précalculs des rotations?) dans des fichiers archivés sur la calc... faudrait que je m'y remette tiens.

oui, cf sources de formula0, c'était une des choses que j'avais envisagées... par contre ça doit être particulièrement pénible à faire de façon optimisée, parce que y a plein de cas différents pour le "recollage" (+zoom) des tiles ^^ et je ne sais pas si visuellement le résultat serait superbe

cela dit même sans pré-rotations je pense qu'il y a moyen de faire largement mieux niveau fluidité que ce qui se fait actuellement ^^

Ca serait pas mal de précalculer pour un angle donné chaque offset vers le pixel de la map a rendre. Comme le parcours de l'écran est linéaire, ca demanderait aucun calcul pour aller chercher le bon offset et le rendu serait vraiment beacoup plus rapide. Donc les données en read-only c'est les offsets, maintenant faut voir pour combien d'angles on peut précalculer tout ca sans que ca prenne une place monstrueuse en archive

Ah oui, moi je parlais de précalculer les rotation de tiles, mais sans les zooms (ce qui aurait permis de faire le rendu de plein de pixels à la fois parce qu'un zoom de facteur constant c'est facile, mais évidemment ça demande de faire attention aux bordures de tiles).

En fait en y réfléchissant ce dont tu parles c'est assez proche de ce que je fais dans la dernière version (qui n'a rien à voir avec le code source qui est sur mon site), sauf que ma méthode utilise plutôt du code déroulé pour limiter au maximum les accès mémoires, donc je ne peux pas précalculer une ligne entière sinon le code serait trop gros ^^ (ou l'approximation trop voyante, au choix) Et en fait j'utilise aussi du code auto-modifiant, donc je ne peux pas non plus me permettre d'avoir trop de code à modifier

En ce qui concerne les écrans virtuels, j'ai utilisé une technique un peu spéciale :
- un écran virtuel rempli avec des tiles 16*16 pour les tiles proches
- un écran virtuel rempli avec des tiles 8*8 pour les tiles lointaines

Ainsi, dans le moteur, les 15 dernières lignes horizontales - celles qui représentent les tiles lointaines - sont générées à partir du buffer en tile 8*8.
ça me permet de limiter la taille des buffers, surtout qu'on a pas besoin de tiles précises au bout d'un moment...Une technique inspirée du mipmapping dur PC
Bon c'est vrai on voit un peu la ligne de démarcation entre les deux zones horizontales quand on sait où elle est. Mais pour l'instant personne ne me l'a fait remarquer
Maintenant c'est trop tard

>Nerick : c'est pas mal comme idée !
Mais le problème c'est que les offsets dont tu parles sont différents pour chaque ligne horizontale de l'écran, si je ne m'abuse. ça ferait une quantité monstrueuse de données par angle !

Sinon, Pollux, le rendu avec sprite pré-rotationné, ça doit pas être très efficace pour les lignes horizontales "lointaines" , non ?

Parce que pour ces lignes les tiles sont petites ( même si ça dépend des réglages de FOV et tout )et donc ya plein de sprites à zoomer par ligne. ( enfin, c'est pas un rendu ligne par ligne, mais bon )
Maintenant c'est vrai qu'on peut envisager une technique hybride, avec 2/3 des lignes dessinées avec les sprites pré-rotationnés, le 1/3 restant en pixel par pixel. Mais je n'ose imaginer la taille prise par un tel moteur

Oui évidemment si tu n'as qu'un ou deux pixels par tile le pré-rotationné n'est plus très efficace (enfin ça restait honnête par rapport à l'ancien moteur), c'est aussi pour ça que j'ai jamais implémenté cette technique ^^

Le mipmapping, j'y avais aussi pensé, mais pour ça il faudrait que je puisse afficher des buffers de 16 ko (au lieu de 64 ko) sans trop perdre en vitesse... Tes écrans virtuels font quelle taille ?

Les deux buffers font 16K0 chacun : 64 cases pour le 16*16, 256 cases pour le 8*8
C'est vrai qu'un buffer de 64 ko ( enfin de 256 octets de côté ), c'est plus pratique, mais j'ai besoin de mémoire pour le reste ...

Bon, j'ai enfin trouvé le temps de programmer un peu !

Alors, j'ai pas énormément avancé : j'ai passé pas mal de temps à mettre au point le pseudo moteur 3D.
Maintenant, il est à peu près opérationnel, et le jeu tourne à 13-15 fps en basse résolution.

Visuellement donc, pas de gros changement par rapport au screen précédent :



Vous pouvez accéder à la nouvelle démo ici ( http://membres.lycos.fr/dcoz )

Surtout, j'ai besoin de vos remarques :
- comment ça rend sur vraie TI ( genre est ce qu'on voit les triangles blancs, par ex. ) ?
- vous préférez (AVEC les trucs 3D) ou ( SANS mais avec une meilleure résolution/ meilleur fps) ?
- ça plante toujours sur Titanium ?

Merci d'avance !

Ca marche bien sur v200.

comment ça rend sur vraie TI ( genre est ce qu'on voit les triangles blancs, par ex. ) ?

C'est fluide et on distingue bien les objets 3D sur le bord (c'est ça les triangles blancs?). Le sol sur les bords est un peu brouillé par contre.

vous préférez (AVEC les trucs 3D) ou ( SANS mais avec une meilleure résolution/ meilleur fps) ?

Bah je préfère avec, pasque sinon ça donnerait une impression de platitude quand même .

Je viens de tester et c'est vraiment bien

Je trouve le jeu très fluide et les objet en 3D donne une vrai impression d'avancer.
Est-ce que dans la résolution au dessus le jeu rame vraiment (avec les objet en 3D)?
Les triangles se voient bien mais je trouve qu'ils ont une drôle de forme qu'en on s'en approche.

Par contre, comme dans la précédente version, il y a de gros bogues dans la gestion de collision(commme dans les versions précédentes), par exemple quand on "racle" un mur, on est parfois remis quelques centimetre en arrière (voire de la distance de plusieurs voiture) et aussi quand on va tout droit en fin de ligne droite on va dans le décor et on traverse jusqu'à se retrouver de nouveau sur la piste.

Je suis quand même etonné de la fluidité

bonne chance pour la suite

Ok, merci pour les commentaires !
C'est plutôt bon niveau fluidité, apparemment

> Bah je préfère avec, pasque sinon ça donnerait une impression de platitude quand même .
> les objet en 3D donne une vrai impression d'avancer.
Je suis plutôt de cet avis aussi ... Par exemple si je fais un jeu de F1, c'est primordial de "sentir" à quelle vitesse on va. Pour un MarioKart c'est moins grave. D'ailleurs j'hésite entre ces deux types de jeux Votre avis ?

>Est-ce que dans la résolution au dessus le jeu rame vraiment (avec les objet en 3D)?
Ben je pense que sur vraie TI ça doit tourner entre 8 et 10 fps. ça devient un peu tendu, surtout qu'il faudra ajouter l'affichage de sprites, l'IA, tout ça...

> Les triangles se voient bien mais je trouve qu'ils ont une drôle de forme qu'en on s'en approche
Ouais, c'est peut être parce que je crois pas avoir réussi à trouver les mêmes paramètres de projection pour mon mode7 et mon moteur3D

>Par contre, comme dans la précédente version, il y a de gros bogues dans la gestion de collision
C'est clair ! j'ai tendance à oublier vu que je m'y suis habitué! Vais corriger ça...

>bonne chance pour la suite
Merci

Je suis plutôt de cet avis aussi ... Par exemple si je fais un jeu de F1, c'est primordial de "sentir" à quelle vitesse on va. Pour un MarioKart c'est moins grave. D'ailleurs j'hésite entre ces deux types de jeux Votre avis ?
>jeu type F1

Les 2

La résolution et l'activation du moteur 3D est codé en dur ou c'est paramétrable à la volée ?

J'ai testé avec une Ti89 Titanium ça rend très bien

> La résolution et l'activation du moteur 3D est codé en dur ou c'est paramétrable à la volée ?
Pour l'instant c'est codé en dur, mais ça peut facilement être paramétré à la volée... tout comme les paramètres de vision d'ailleurs ( FOV et hauteur de la caméra ...) Après pour des soucis de taille va falloir faire des choix

En parlant de choix, c'est décidé je suis parti pour faire un jeu de F1

Là je me suis lancé dans l'affichage des sprites et j'ai pas mal galéré !
J'ai pas trouvé de sprites "tout fait" qui me convenaient, donc j'ai pris une F1 dans 3D Studio, je l'ai rotationné un peu et j'ai pris des screenshots ...

Enfin, maintenant c'est fait, et la routine d'affichage est à peu près terminée. La voici en action :



Les sprites des différentes tailles sont précalculés, donc la voiture adverse donne un peu l'impression de "grossir" par à coup, mais bon ..

Maintenant il faut que je fasse une IA potable
( et que je rajoute des ombres en dessous des voitures aussi !)

c'est vraiment super joli
li te reste beaucoup de marge pour l'IA ?

oué ça rend sympa
Et les ombres ce serai une bonne idée, parceque là tel quel ça donne l'air que la f1 plane légèrement au dessus du sol, en tout cas c'est l'effet que ça me fait,
enfin bref ajouter un repère visuel ça ne sera que mieux !

c'est un détail, mais il faudra plusieurs couleurs de voitures.

>li te reste beaucoup de marge pour l'IA ?
alors là je dois utiliser environ 100 Ko de Ram, donc niveau RAM ça devrait aller. Niveau de la taille du programme, faudra que je mette pleins de trucs en fichiers externes ( paske rien qu'avec la petite démo je suis déjà à 32 ko ), mais là encore rien d'impossible.

Après je sais pas si je réussirais à faire une IA moins bête que celle de GT, où le parcours des voitures etait pré calculé => enemis chiants... Faire un comportement "temps-réel", avoir une gestion des dépassements, des collisions entre voitures,etc... je pense que tout ça demandera pas mal de temps de calcul, du moins si j'arrive à coder tous ces trucs !!!
Mais bon, ça s'annonce super intéressant donc je suis motivé

>Et les ombres ce serai une bonne idée, parceque là tel quel ça donne l'air que la f1 plane légèrement au dessus du sol, en tout >cas c'est l'effet que ça me fait,enfin bref ajouter un repère visuel ça ne sera que mieux !
Complètement d'accord. D'ailleurs faudrait aussi que je fasse des images qd on tourne son véhicule, pour qu'on est pas l'impression de "pivoter" sur place.... Enfin, là j'en ai ma claque des sprites, je veux me fritter un peu avec de l'algo, avec de l'IA !

>c'est un détail, mais il faudra plusieurs couleurs de voitures.
Argh, cf remarque ci dessus , pour l'instant je compte juste inverser les composantes gris clair / gris foncé des sprites pour faire deux couleurs. Après je pense qu'on peut faire difficilement plus que deux couleurs de voitures, vu qu'on doit pas voir grand chose sur une vraie TI, j'imagine ....

en tout cas, je suis bien épaté par le résultat, je vais peut-être même ressortir ma TI
pour l'IA, tu dois pouvoir faire une IA ç peu près intéressante même si elle est très simple (genre essayer de contrer ton doublement, ralentir avant les virages et c'est à peu près tout ^^)