1

Bonjour

J'ai codé un petit moteur qui fait de la 3D à base de sprite.

Le zip contient un exemple d'utilisation avec toutes les sources nécessaires (les fichiers c1,c2,s1 et les main.c, inputs.c, trigo.c et 3d.c).
https://www.mirari.fr/l6lb

Je compile avec NGdevkit mais ça devrait fonctionner avec les autres kits.

J'aimerai connaître vos idées d'optimisation en restant en C (je ne pratique pas l'assembleur). Je pense notamment à la gestion de la boucle principale, et aux 2 fonctions dédiées à l'affichage proprement dit:
- display_sprite dans main.c
- display dans 3d.c

En gros, frames paires on traite les données 3D:
move_cam();
transform_3d_to_2d();
sort_2d();


Cette partie là me semble assez bien optimisée.

Frames impaires, c'est l'affichage proprement dit, gérée par la fonction display(). Dans le détail, on se retrouve alors avec une liste dsorted_index d'indices correspondant à des sprites à afficher dans l'ordre parmi:
#define ball_black 0
#define ball_red 1
#define ball_white 2
...

lesquels sont définis graphiquement dans les listes def_htiles[], def_vtiles[] et def_tile_index[], ces dernières correspondant aux assets dans c1, c2.

La difficulté consiste alors à mettre à jour le plus rapidement possible la Vram, sachant que les sprites n'ont pas tous le même nombre de tiles en V et en H.

Je reste à dispo pour expliciter toute partie de code un peu obscure.

J'aimerai aussi essayer de coder l'affichage d'un plan en mode 7 simplifié. Mais je n'arrive pas à faire fonctionner les Timer Interrupt. Quelqu'un saurait-il me proposer un exemple minimaliste d'utilisation d'un Timer Interrupt ?

2

Why there is no P ROMs inside archive? Or programmer must build it by himself?
avatar

3

Yes, all *.c files are included. I ask help to improve engine performances

4

Is ngdevkit using compulsory for P ROMs building, or SDK by NeoBitz or Sebastian Mihai might to suit for it too? I using the Sebasian Mihai's SDK.
avatar

5

I don't know, you should try and give us the answer smile

Well it is is just C code, it should work with different compilers.

6

Sympa ton neotris, j'aime bcp l'ambiance love
avatarHighway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

7

totologic (./5):
I don't know, you should try and give us the answer smile

Well it is is just C code, it should work with different compilers.

For some reason my compiler complains about many syntax violations after trying to build the program.

tromb Fichier joint : VRhE
tromb Fichier joint : dYv5
avatar

8

C'est bien le resultat escompté? Avant de tout bricoler embarrassed

191007052146381755.png

Tearing à gogo en effet, afficher les sprites prend quasi toute la frame.

9

Oui tout à fait ça.

10

Bon sur le screen j'avais du log de debug en route, c'est pas lent à ce point en réalité. Mais ca reste lent.

Bricolé un peu, c'est mieux mais y'aura pas de miracles sans une vraie gestion des sprites adaptée au système. Tu peux coder comme ça sur CPS, mais sur neo c'est pas adapté.
https://www.dropbox.com/s/naxljs7kare4186/neo3D.zip?dl=0


J'ai rentré le bouzin au chausse pied dans ma lib, ça respire mieux:

Faut que je finisse et release cette maj avec scaling un de ces 4, quand j'aurais plus la flemme grin

11

HPMAN (./10) :
mais y'aura pas de miracles sans une vraie gestion des sprites adaptée au système. Tu peux coder comme ça sur CPS, mais sur neo c'est pas adapté.
Ah, par curiosité tu parles de quelles propriétés différentes entre la néo et le CPS ?
avatarHighway Runners, mon jeu de racing à la Outrun qu'il est sorti le 14 décembre 2016 ! N'hésitez pas à me soutenir :)

https://itunes.apple.com/us/app/highway-runners/id964932741

12

Ca rend bien. Avec ta lib tu es resté sur 30FPS ou as-tu réussi à monter à 60FPS ?

13

Oui ca rend pas mal.
Rien en asm par contre quand j'ai regardé le code ce week end.
J'ai pas mal de trigo dans mes démos Atari au 68000, toute la partie matrice de rotation etc... est pas mal optimisée.
Ca vaut peut-être le coup de regarder de ce côté là ... et remplacer tes calculs ... mais est ce vraiment là que se situe le speed up ?

14

La trigo je pense que c'est OK, un quart de cercle a été stocké dans un tableau.

Dans la transfo 3D->2D, les sprites inutiles (hors du frustrum) sont skippés au fur et à mesure des calculs. Au final un sprite rendu demande 7 multiplications, 1 division et une poignée d'additions/soustractions.

La division pourrait sûrement être précalculée ou approchée:
_shr = ((SCREEN_HALF_H << 10) / _d);_d est la distance sprite - caméra dans le repère caméra, donc dans [CAM_NEAR, CAM_FAR], dans l'exemple c'est réglé à [120, 1500].

Implémenter un quadtree pourrait permettre d'ajouter des sprites et faire une map plus grande.

La bounding box caméra n'est pas optimale, elle pourrait être plus petite en utlisant les cos et sin du cam_yaw,.

Sinon je suis curieux de toute autre optimisation.

15

Brunni (./11) :
HPMAN (./10) :
mais y'aura pas de miracles sans une vraie gestion des sprites adaptée au système. Tu peux coder comme ça sur CPS, mais sur neo c'est pas adapté.
Ah, par curiosité tu parles de quelles propriétés différentes entre la néo et le CPS ?

Sur CPS t'as pas loin de 200Ko de vram, directement mappée sur le cpu, avec une série de registres pour dire au gpu quelle zone utiliser pour la liste de sprites, les plans etc...
Donc tu peux bricoler ta sprite list directement en vram pendant que tu affiche les données d'une autre zone à l'écran. T'as juste à modifier un registre pendant le vblank pour swap le pointeur entre zone affichée/travail.

Eh oui la vraie rolls c'est le CPS grin


totologic (./12) :
Ca rend bien. Avec ta lib tu es resté sur 30FPS ou as-tu réussi à monter à 60FPS ?

La c'est en 60, y'a pas grand monde à l'écran .

16

Si c'est pas déjà fait:

Une pratique assez standard consiste à construire lentement une table de commandes vidéo en RAM pendant la frame, et de l’interpréter rapidos pendant le v-blank.
Ça permet de laisser l'affichage tranquille pendant le rendu. Il faut que l’interpréteur soit bien optimisé pour pouvoir faire le max d'opérations avant que ça déborde dans la frame.
Le truc cool c'est que le code du jeu lui même peut prendre son temps.

Par ex. les commandes peuvent être "set position (n,x,y)", "set map (n,pointeur)", "set zoom (n,valeur)" etc... Il suffit d'un octet pour la coder + les paramètres, donc pas besoin d'énormément de RAM.
avatarJe fais des trucs. Des fois ça marche, des fois ça marche pas.

17

Effectivement c'est déjà un peu ce qui est fait. Les fonctions 3D ne touchent pas à l'affichage, elles ne font que tripoter des données 3D/2D. A la fin il n'y a plus qu'à dérouler les tableaux 2D dans l'ordre.pour faire l'affichage.

18

This is definitely some gangster shit! Excellent work! Love it! Thanks very much for sharing! bigeyes