Seuls les membres ayant 30 points peuvent parler sur le chat.

Forum Casio - Projets de programmation


Index du Forum » Projets de programmation » 1v1 3D >> FxEngine (Moteur 3D)
Milang Hors ligne Membre Points: 473 Défis: 2 Message

1v1 3D >> FxEngine (Moteur 3D)

Posté le 10/04/2019 20:45

Image destinée a être dans le futur un écran d'accueil

Bonjour à tous !
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



2: Version 2
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 !


Fichier joint


Milang Hors ligne Membre Points: 473 Défis: 2 Message

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
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

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.
Milang Hors ligne Membre Points: 473 Défis: 2 Message

Citer : Posté le 18/07/2019 14:44 | #


Bon bah finalement je vais essayer de faire au plus simple pour l'instant
Ninestars Hors ligne Membre Points: 2257 Défis: 22 Message

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 !
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 18/07/2019 21:29 | #


Ninestars a écrit :
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.
Milang Hors ligne Membre Points: 473 Défis: 2 Message

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 makefile
# 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 ?
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

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.
Milang Hors ligne Membre Points: 473 Défis: 2 Message

Citer : Posté le 28/08/2019 14:04 | #


J'ai changé le Makefile en renommant la lib en libfxengine.a
# fxengine makefile
# 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)
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

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.
Milang Hors ligne Membre Points: 473 Défis: 2 Message

Citer : Posté le 28/08/2019 14:09 | #


Non, j'ai un nouveau bug lors de fxengine]$ make :
mkdir -p build/
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

Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 28/08/2019 14:10 | #


Le Makefile est pas prévu pour compiler dans des sous-dossiers de build. Change ça :

build/%.c.o: %.c | build/
    $(target)-gcc -c $< -o $@ $(cflags)

En ça :

build/%.c.o: %.c
    @ mkdir -p $(dir $@)
    $(target)-gcc -c $< -o $@ $(cflags)
Milang Hors ligne Membre Points: 473 Défis: 2 Message

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 , ce qui me donne par exemple l'erreur suivante :
In file included from src/render/zbuffer.c:5:
/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) ?

Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

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.
Milang Hors ligne Membre Points: 473 Défis: 2 Message

Citer : Posté le 28/08/2019 15:00 | #


cc1: warning: unrecognized gcc debugging option: F
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
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

Citer : Posté le 28/08/2019 15:09 | #


Je sais pas ce que t'as fait là mais tu t'es planté quelque part. ó_ó
Milang Hors ligne Membre Points: 473 Défis: 2 Message

Citer : Posté le 28/08/2019 15:10 | #


j'avais mis -DFX9860G au lieu de -D FX9860G
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

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.
Milang Hors ligne Membre Points: 473 Défis: 2 Message

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 :
src/render/bitmap.c:2:10: fatal error: fxengine/render/bitmap.h: No such file or directory
    2 | #include <fxengine/render/bitmap.h>
      |  


Le makefile n'a pas changé, c'est toujours le même
# fxengine makefile
# 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 ?
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

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.
Milang Hors ligne Membre Points: 473 Défis: 2 Message

Citer : Posté le 29/08/2019 12:20 | #


ah...

Comment devais-je gérer les dépendances du coup ?
Lephenixnoir Hors ligne Administrateur Points: 18201 Défis: 142 Message

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.

LienAjouter une imageAjouter une vidéoAjouter un lien vers un profilAjouter du codeCiterAjouter un spoiler(texte affichable/masquable par un clic)Ajouter une barre de progressionItaliqueGrasSoulignéAfficher du texte barréCentréJustifiéPlus petitPlus grandPlus de smileys !
Cliquez pour épingler Cliquez pour détacher Cliquez pour fermer
Alignement de l'image: Redimensionnement de l'image (en pixel):
Afficher la liste des membres
Pour coloriser votre code, cliquez ici.
Sinon cliquez sur le bouton ci-dessous.
:bow: :cool: :good: :love: ^^
:omg: :fusil: :aie: :argh: :mdr:
:boulet2: :thx: :champ: :whistle: :bounce:
valider
 :)  ;)  :D  :p
 :lol:  8)  :(  :@
 0_0  :oops:  :grr:  :E
 :O  :sry:  :mmm:  :waza:
 :'(  :here:  ^^  >:)

Σ π θ ± α β γ δ Δ σ λ
Veuillez donner la réponse en chiffre
Vous devez activer le Javascript dans votre navigateur pour pouvoir valider ce formulaire.

Si vous n'avez pas volontairement désactivé cette fonctionnalité de votre navigateur, il s'agit probablement d'un bug : contactez l'équipe de Planète Casio.

Planète Casio v42 © créé par Neuronix et Muelsaco 2004 - 2020 | Il y a 29 connectés | Nous contacter | Qui sommes-nous ? | Licences et remerciements

Planète Casio est un site communautaire non affilié à Casio. Toute reproduction de Planète Casio, même partielle, est interdite.
Les programmes et autres publications présentes sur Planète Casio restent la propriété de leurs auteurs et peuvent être soumis à des licences ou copyrights.
CASIO est une marque déposée par CASIO Computer Co., Ltd