Ce topic regroupe l'ensemble des évolutions du projet de jeu 1v1 3D.
Brève présentation du jeu :
1v1 3D est un projet de jeu de tir à la première personne (fps) en multijoueur sur graph 75/85/95 en utilisant le cable 3pin...
Vous êtes en l'an 2119, et l'homme vit maintenant sous terre. La guerre fait rage entre les différents clans qui essayent de s'accaparer la terre entière... Vous spawnez dans un tunnel désaffecté et vous avez pour mission d'éliminer tout intrus. Cependant, la répartition des territoires et loin d'être claire, et votre adversaire vous traquera, jusqu'à ce que l'un d'entre vous tue l'autre...
Avant de commencer la partie il vous faudra choisir l'une des 3 armes disponibles :
Le pistolet simple (fréquence de tir moyenne, dégâts moyens, et croix pour viser)
Le fusil d'assaut (fréquence élevée, faibles dégâts par balle, et croix pour viser)
Le pistolet laser (rechargement long, mais dégâts puissants, pas de croix et présence d'un viseur avec zoom et masque)
Avancement du projet :
Ce moteur 3d, du nom de FxEngine, est en cours de développement. Je suis actuellement en train de le réécrire sous GNU linux. Cela prend du temps car j'essaie de le rendre réutilisable dans d'autres jeux.
Progrès publiés :
1: version du CASIO fx9860 SDK
Un premier jet très moyen en de performances
Alpha 1
J'ai un peu travaillé sur le sujet, notamment sur comment déformer les textures et j'arrive mainenant à des resultats comme ça :
Donc le rendu est ok, la taille de l'image rendue est de 124x85 mais toutes les variables sont des
double et donc le rendu est très lent, à en juger par le le nombre de FPS affiché en bas (bon, on calc c'est un chouia plus rapide, parce que ici je fais tourner le logiciel avec wine mais 6-7 FPS pour une pyramide pas super proche, ça ne fait pas rêver).
Il faudra donc que je transforme le système de codage des coordonnées en
int et optimiser la fonction de rendu des textures.
Je compte réécrire tout de zéro afin de pouvoir ajouter le clipping et la suppression des faces cachées.
Vous pouvez d'ailleurs noter la présence en bas d'une partie du futur affichage ingame !
Au point où j'en suis, j'utilise les libs suivantes :
MonochromeLib de pierrotll
LibText de lephenixnoir
Alors que la version précédente a été réalisée avec le SDK de CASIO, j'ai décidé de poursuivre le projet avec les outils libres :
-> GNU Linux (bah oui j'ai dit outil libre)
-> le cross compilateur
GCC pour les architectures sh3eb-elf (le programme est quand même compatible SH4-A, donc avec les calculatrices les plus récentes)
->
le fxsdk et
gint, deux outils puissants faits par
Lephenixnoir
Bien évidemment, cela n'empêche pas le programme d'être mis sur la calculatrice depuis windows, la manipulatiuon se fait comme avec un add-in normal.
Bon c'est pas tout, mais revenons à la bete
Si vous avez regardé la version précédente vous allez certainement être surpris !
J'ai réécrit mon programme de zéro, et appliqué les optimisations suivantes :
Optimisation 1 : J'ai réécrit mon programme, en utilisant à 99,99% des entiers.
Optimisation 2 : J'ai ajouté la notion de coté visible d'une face.
Optimisation 3 : J'ai changé la méthode de conversion des coordonnées, j'utilise maintenant les matrices de rotation.
Optimisation 4 : Un grosse optimisation au niveau de l'affichage des triangles, notamment une suppression du cas par cas pour une boucle plus légère.
Ces quatre optimisations, associées à l'utilisation du puissant compilateur gcc, et de gint (par Lephenixnoir) qui remplace les syscalls peu optimisés de CASIO, permettent d'obtenir le rendu de triangle, à charge égale, d'une vitesse environ 10 fois supérieure (oui, 10 fois, vous ne rêvez pas !). De plus, j'ai complété la fonction de déformation des textures, appliquant maintenant la perspective de façon plus affinée sur celles-ci.
Cependant, la technique de déformation n'est pas encore complètement au point et donc certaines vues sont un petit peu erronées, c'est notamment ce que j'essaierai de corriger pour la prochaine version.
Vous pouvez allez voir l'avancement sur
le dépot gitea du projet.
Le moteur FxEngine est également accessible, mais reste pour l'instant incomplet. A partir du moment où elles auront atteint un minimum de stabilité je publierai en tant que programme. N'hésitez pas à dire ce que vous en pensez !
Image destinée a être dans le futur un écran d'accueil
Citer : Posté le 18/07/2019 14:40 | # |
Fichier joint
ah ok !
Je n'avais pas du tout pensé au temps d'accès mémoire, je pensais juste en terme de calculs
don oui, faudra plutot que je revienne aux tableaux traditionnels comme je le faisais dans la version d'avant
Projet de jeu multijoueur : 1V1 3D
Une lib de debug simple : la liblog
Citer : Posté le 18/07/2019 14:41 | #
Y'a aussi des histoires de cache qui rentrent en compte mais je ne sais pas à quel point ça influence les perfs sur SH4.
Citer : Posté le 18/07/2019 14:44 | #
Bon bah finalement je vais essayer de faire au plus simple pour l'instant
Projet de jeu multijoueur : 1V1 3D
Une lib de debug simple : la liblog
Citer : Posté le 18/07/2019 21:26 | #
Enfin tout ça est négligeable vis-à-vis des algorithmes pour faire de la 3D...
En tout cas c'est plus simple pour ajouter dynamiquement des objets à la suite dans ton tableau c'est sur
Enfin, es-tu certain d'être dans le cas où tu ne connais pas avant la compilation les triangles à afficher ?
Je me dis que si ce sont des triangles, il doit s'agir de ceux qui composent ta carte, donc tu es censé les rentrer à la main avant la compilation.
Auquel cas, un tableau classique est bien plus pratique à utiliser !
Citer : Posté le 18/07/2019 21:29 | #
Enfin tout ça est négligeable vis-à-vis des algorithmes pour faire de la 3D...
Peut-être mais autant que ce soit efficace ! D'ailleurs je verrais bien pour le cache moi... ça compte peut-être plus que ça en a l'air.
Citer : Posté le 18/07/2019 21:31 | #
Je ne suis pas exactement dans ce cas là, car je compte coder les maps dans des fichiers -> le mieux c'est de pouvoir les créer dynamiquement en ne chargeant que la map concernée. pour l'instant, comme je réécris tout de zéro, je vais juste faire les tests de performance d'abord avec des objets statiques.
Mais c'est une de mes idées à exploiter dans le futur, avec le DMA Controller...
Ajouté le 28/08/2019 à 11:41 :
J'ai un problème de makefile (peut être que je n'y connais pas grand chose aussi
J'ai créé, en m'appuyant sur le makefile de libprof (merci @lephe), un makefile permettant de compiler fxengine en tant que lib.
voici le Makefile, même si je pense que ce n'est pas lui qui pose problème :
# fxengine needs gint (@Lephenixnoir)
target ?= sh3eb-elf
cflags := -m3 -mb -ffreestanding -nostdlib -fstrict-volatile-bitfields -Wall \
-Wextra -Os -I .
lib := fxengine.a
header := include/
prefix := $(shell $(target)-gcc -print-search-dirs | grep install \
| sed 's/install: //')
ifeq "$(prefix)" ""
$(error "Can't find install directory")
endif
src := $(wildcard *.c)
obj := $(src:%=build/%.o)
all: $(lib)
$(lib): $(obj)
$(target)-ar rcs $@ $^
build/%.c.o: %.c | build/
$(target)-gcc -c $< -o $@ $(cflags)
clear:
@ rm -rf build
@ rm -f $(lib)
%/:
mkdir -p $@
install:
cp $(lib) $(prefix)
cp -r $(header) $(prefix)/include/fxengines
Le problème se situe au niveau du fxsdk, car je ne sais pas modifier le makefile de telle sorte qu'il linke la lib
Du boup, j'ai des undefined reference to à chaque fonction que j'utilise...
Comment dois-je linker la lib ?
Projet de jeu multijoueur : 1V1 3D
Une lib de debug simple : la liblog
Citer : Posté le 28/08/2019 13:05 | #
Ta lib doit s'appeler libX.a et tu linkes avec -lX dans ton add-in. Par exemple libfxengine.a et -lfxengine.
Attention si ta lib utilise gint tu dois avoir -lgint-fx après -lfxengine. Ça marche pour toutes les dépendances.
Citer : Posté le 28/08/2019 14:04 | #
J'ai changé le Makefile en renommant la lib en libfxengine.a
# fxengine needs gint (@Lephenixnoir)
target ?= sh3eb-elf
cflags := -m3 -mb -ffreestanding -nostdlib -fstrict-volatile-bitfields -Wall \
-Wextra -Os -I .
lib := libfxengine.a
header := include/
prefix := $(shell $(target)-gcc -print-search-dirs | grep install \
| sed 's/install: //')
ifeq "$(prefix)" ""
$(error "Can't find install directory")
endif
src := $(wildcard *.c)
obj := $(src:%=build/%.o)
all: $(lib)
$(lib): $(obj)
$(target)-ar rcs $@ $^
build/%.c.o: %.c | build/
$(target)-gcc -c $< -o $@ $(cflags)
clear:
@ rm -rf build
@ rm -f $(lib)
%/:
mkdir -p $@
install:
cp $(lib) $(prefix)
cp -r $(header) $(prefix)/include/fxengine
et j'ai changé la ligne lf-fx := $(LDFLAGS) -Tfx9860g.ld -lgint-fx -lgcc -Wl,-Map=build-fx/map en lf-fx := $(LDFLAGS) -Tfx9860g.ld -lfxengine -lgint-fx -lgcc -Wl,-Map=build-fx/map
Cependant j'ai toujours la même erreur
Du coup, je me pose la question suivante, j'ai l'intuition que le problème vient de la ligne src := $(wildcard *.c)
Il y avait eu un problème au niveau du fxsdk à ce niveau, alors je me demande si je peux remplacer par src := $(shell find src -name '*.c') (c'est le code du fxsdk, mais je crois me souvenir qu'il y avait des changements supplémentaires)
Projet de jeu multijoueur : 1V1 3D
Une lib de debug simple : la liblog
Citer : Posté le 28/08/2019 14:09 | #
Ça peut être là. Ça se verrait trivialement dans un log de compilation de la lib ou avec un coup de sh3eb-elf-ar -t libfxengine.a, si la lib' est vide.
Citer : Posté le 28/08/2019 14:09 | #
Non, j'ai un nouveau bug lors de fxengine]$ make
sh3eb-elf-gcc -c src/event/keyboard.c -o build/src/event/keyboard.c.o -m3 -mb -ffreestanding -nostdlib -fstrict-volatile-bitfields -Wall -Wextra -Os -I .
Assembler messages:
Fatal error: can't create build/src/event/keyboard.c.o: Aucun fichier ou dossier de ce type
make: *** [Makefile:30: build/src/event/keyboard.c.o] Error 1
rm build/make: unlink: build/ : est un dossier
alors que je n'avais pas ce problème avant
Ajouté le 28/08/2019 à 14:09 :
je disais non à mon post
Projet de jeu multijoueur : 1V1 3D
Une lib de debug simple : la liblog
Citer : Posté le 28/08/2019 14:10 | #
Le Makefile est pas prévu pour compiler dans des sous-dossiers de build. Change ça :
$(target)-gcc -c $< -o $@ $(cflags)
En ça :
@ mkdir -p $(dir $@)
$(target)-gcc -c $< -o $@ $(cflags)
Citer : Posté le 28/08/2019 14:16 | #
tiens, maintenant quand je fais make il me dit
Makefile:31: *** séparateur manquant. Arrêt.
Ajouté le 28/08/2019 à 14:17 :
non, juste un problème d'indentation
Ajouté le 28/08/2019 à 14:36 :
C'est bon, il détecte les fichiers sources (et les erreurs
notamment au niveau de target, où je ne sais pas comment automatiser le choix de la plateforme
/usr/lib/gcc/sh3eb-elf/9.1.0/include/gint/display.h:52:13: error: unknown type name 'color_t'
52 | void dclear(color_t color);
|
ce qui est assez gênant...
comment dois-je faire si je ne souhaite compiler que pour une seule architecture (en l'occurence, fx) ?
Projet de jeu multijoueur : 1V1 3D
Une lib de debug simple : la liblog
Citer : Posté le 28/08/2019 14:49 | #
Si tu ne veux compiler que pour une architecture, tu dois définir la macro FX9860G ou la macro FXCG50 (avec -D sur la ligne de commande). gint est prévu pour qu'au moins une de ces macros soit définie à tout instant.
Pour libprof, comme le code est identique pour les deux, j'ai commencé à autoriser la compilation de code sans cible spécifique. C'est très expérimental et comme tu peux le voir toutes les définitions qui ne sont pas identiques sur toutes les plateformes sont inaccessibles.
Dans ton cas, ajoute -DFX9860G à tes options de compilation.
Citer : Posté le 28/08/2019 15:00 | #
cc1: warning: unrecognized gcc debugging option: X
cc1: warning: unrecognized gcc debugging option: 9
cc1: warning: unrecognized gcc debugging option: 8
cc1: warning: unrecognized gcc debugging option: 6
cc1: warning: unrecognized gcc debugging option: 0
cc1: warning: unrecognized gcc debugging option: G
l'option D est déjà prise
Projet de jeu multijoueur : 1V1 3D
Une lib de debug simple : la liblog
Citer : Posté le 28/08/2019 15:09 | #
Je sais pas ce que t'as fait là mais tu t'es planté quelque part. ó_ó
Citer : Posté le 28/08/2019 15:10 | #
j'avais mis -DFX9860G au lieu de -D FX9860G
Projet de jeu multijoueur : 1V1 3D
Une lib de debug simple : la liblog
Citer : Posté le 28/08/2019 15:12 | #
Je ne vois pas quelle version du compilateur/préprocesseur ne supporte pas cette syntaxe-là, dont je me sers tout le temps... bizarre.
Citer : Posté le 28/08/2019 15:12 | #
gcc 9.1.0
Ajouté le 28/08/2019 à 15:13 :
cflags := -m3 -mb -DFX9860G -ffreestanding -nostdlib -fstrict-volatile-bitfields -Wall \
-Wextra -Os -I . ne marche pas, par contre
cflags := -m3 -mb -D FX9860G -ffreestanding -nostdlib -fstrict-volatile-bitfields -Wall \
-Wextra -Os -I . si.
Ajouté le 29/08/2019 à 11:52 :
J'ai <encore> un problème au niveau du makefile...
J'ai ajouté un header, mais à la compilation, il ne le trouve pas :
2 | #include <fxengine/render/bitmap.h>
|
Le makefile n'a pas changé, c'est toujours le même
# fxengine needs gint (@Lephenixnoir)
target ?= sh3eb-elf
cflags := -m3 -mb -D FX9860G -ffreestanding -nostdlib -fstrict-volatile-bitfields -Wall \
-Wextra -Os -I .
lib := libfxengine.a
header := include/
prefix := $(shell $(target)-gcc -print-search-dirs | grep install \
| sed 's/install: //')
ifeq "$(prefix)" ""
$(error "Can't find install directory")
endif
src := $(shell find src -name '*.c')
obj := $(src:%=build/%.o)
all: $(lib)
$(lib): $(obj)
$(target)-ar rcs $@ $^
build/%.c.o: %.c
@ mkdir -p $(dir $@)
$(target)-gcc -c $< -o $@ $(cflags)
clear:
@ rm -rf build
@ rm -f $(lib)
%/:
mkdir -p $@
install:
sh3eb-elf-ar -t $(lib)
cp $(lib) $(prefix)
cp -r $(header) $(prefix)/include/fxengine
Comment dois-je faire pour qu'il prenne en compte le header ?
Projet de jeu multijoueur : 1V1 3D
Une lib de debug simple : la liblog
Citer : Posté le 29/08/2019 12:04 | #
Ton cflags contient -I . donc gcc consulte le dossier courant (celui du Makefile) quand tu cherches les headers. D'après ton dépôt le fichier est (je devine) plutôt dans include/render/bitmap.h.
Déjà tu devrais changer le -I . en -I include. Ensuite tu dois soit écrire #include <render/bitmap.h> soit placer tous les contenus de include dans un sous-dossier nommé fxengine.
Le Makefile de la libprof, qui ne contient qu'un fichier source et un en-tête, n'est pas fait pour des gros projets. Il n'y a pas de gestion des dépendances (!) ce qui fait que ton code va finir par casser à cause d'une décorrélation entre différents fichiers sources car les en-têtes ne sont pas suivis.
C'était un peu risqué de partir avec ça si tu ne maîtrises pas le détail de processus de compilation.
Citer : Posté le 29/08/2019 12:20 | #
ah...
Comment devais-je gérer les dépendances du coup ?
Projet de jeu multijoueur : 1V1 3D
Une lib de debug simple : la liblog
Citer : Posté le 29/08/2019 14:27 | #
Bah, c'est un peu tordu. Il faut utiliser des options de GCC pour que le préprocesseur génère la liste des dépendances et ensuite stocker ça dans des fichiers .d à inclure dans le Makefile. Si tu veux les détails, il y a une description par un des mainteneurs de make ici : Advanced auto-dependency generation (make.mad-scientist.net)
Si tu n'est pas trop gourouteries de Makefile, je te conseille de plutôt partir de celui du fxSDK et de récupérer uniquement :
• La règle d'archivage au lieu de l'édition des liens du programme final
• La règle d'installation
Pour ça, il suffit de connaître un peu make.