Quake 2 - Page 3

dilinger (./34) :
Faut dire aussi que ce forum est agréable, on peut échanger normalement ce que l'on fait sans pression. C'est un hobby.
C'est une des raisons pour laquelle, j'hésite a partager ce que j'ai fait sur Atari Age. La bas, de ce que j'ai pu voir, tu as vite fait d'être mal pris.

Le "french" paradoxe...

Je suis impatient de tester ce petit Quake 2 sur ma Skunkboard

Ce qui est marrant c'est que c'est toujours pareil avec les hobbys/passions, que ce soit le groupe de jazz, le cercle poésie, théâtre, ou l'asso locale de poterie !

Il y aura toujours ceux qui cherchent à se vider la tête du boulot et à se faire plaisir, a se challenger eux même sur des défis techniques sans avoir de pression. Et toujours ceux qui au contraire veulent plaire à une audience, faire quelque chose qui se veut "pro" avec des projets un peu commerciaux et vont bien souvent chercher à manipuler les premiers à entrer dans leurs projets...

Moi forcemment je vais davantage m'intéresser aux homebrews bien soignés auxquels je peux jouer. Et je vais moins apprécier les démos et autres projets dont l'intérêt est uniquement le défi technique, principalement car je n'ai pas la connaissance necessaire pour apprécier le travail technique qui est derrière. Donc des que je vois des programmeurs qui s'intéressent à la Jag ou autres consoles de prédilection j'ai naturellement envie de les voir plancher sur des projets concrets avec sortie physique.

Mais je réalise aussi que c'est une vision très égoïste. Mon père est dans un groupe de jazz et il se trouve nettement dans la première catégorie du dessus, content d'aller à la répétition toutes les semaines depuis plus de 20 ans pour peaufiner ses solos, mais bien saoulé de voir d'autres dans le groupe pousser pour sortir des CD, faire des 'morceaux qui plaisent' ou plus de concerts...

Donc bien sûr qu'il faut qu'il y ait les 2 dans des communautés comme ici ou AtariAge, et c'est important d'avoir un environnement ou chacun peut se sentir à l'aise et encouragé positivemment dans ses projets quels qu'ils soient.

MetalKnuckles (./62) :
Mais je réalise aussi que c'est une vision très égoïste.

Disons que c'est plutôt un centre d'intérêt différent.

Belle analyse MetalKnuckles ! Et ouais c'est bien d'avoir un peu de tout dans une communauté de passionnés.

Perso je fais plutôt parti du premier groupe, mais j'essaye lentement de passer dans le second. Et c'est dur !!! Donc je respecte énormément ceux qui arrivent à sortir un produit fini sur leur temps libre !

Bonjour.

Oui, cette expérimentation stupide continue. Quelques points pour ceux que cela intéresse.

1. Toujours en C / 68000.
2. John Carmack est brillant, tourner vers l'avenir avec son code, mais cela impacte les vieux processeurs (sic). Alors, j'ai transformer une partie du code a utiliser des shorts, ou bytes, a la place de int 32 bits qui ne faisaient pas de sens au vu des valeurs maximales possible. Il devrait y avoir encore de la marge de ce cote la.
3. Modifications dans les CVars, John Carmack est brillant mais il a base ce système sur les floats, toutes les variables CVars qu'elles soient utilisable comme bool, int ou float, sont en float. Alors, j'ai transforme le système pour les distinguer les unes des autres. Ca fait gagner du cycle mais aussi clarifie les calculs.
4. Améliorations de mes outils pour manipuler les fichiers et datas de Quake II et les adapter aux modifications apportées dans l'engin
-- BSP handler.
-- CVars handler.
-- MD2 handler.
-- SP2 handler
-- WAL handler.
-- PCX handler.
5. Ca déborde toujours en mémoire a qui mieux mieux.
6. Tentative d'utiliser LLVM (68k) et Vbcc, pour le moment la meilleure option est gcc 5.5.0

Cool ! Tu penses que c'est possible de passer le gros du jeu sur Tom ?

Brunni (./66) :
Cool ! Tu penses que c'est possible de passer le gros du jeu sur Tom ?

Non, Tom a 4ko de RAM et cela ne suffira pas. Si c'est utiliser Tom dans les 2Mo de RAM, cela ne passerait pas non plus, car je déborde en RAM. Le code actuel tient dans les 800Ko en ROM en mode Debug.
Si quelqu'un voudrait porter le jeu avec une connotation 'commerciale / Release', il faudrait coder from scratch, ou s'inspirer du code et recoder le tout. C'est une autre démarche intellectuelle.

C'est quoi le problème de déborder en RAM ? Pourquoi ça passe avec le 68k et pas Tom ? Déborder dans quel sens ? Ça devrait faire planter non ?

Brunni (./68) :
C'est quoi le problème de déborder en RAM ? Déborder dans quel sens ? Ça devrait faire planter non ?

C'est exact. La bss + heap + stack ne rentre pas dans les 2Mo. En réalité, la bss + stack se place plutôt bien dans les 2Mo, la heap pas vraiment.
Le reste du data tient en ROM.
C'est pour cela que j'utilise mon VJ-Rx avec le support 8Mo, même si je n'ai pas besoin de tout cet espace. Cela permet de faire passer l'ensemble, et permet de profiler l'occupation mémoire.

Brunni (./68) :
Pourquoi ça passe avec le 68k et pas Tom ?

Parce que le code est majoritairement en C, donc utilisation de compilateur (gcc en l'occurrence).
Pour compiler le code pour Tom, il faudrait un compilateur C qui génère du code pour lui. Ca existe mais il ne tourne que sur DOS de ce que j'ai pu comprendre et je connais pas ses limitations s'il y en a.
Utiliser Tom pour une partie de la partie rendu fait bien du sens, mais je ne vois pas comment le gros du jeu pourrait tourner sur Tom.
Le code 68K tourne en ROM, Tom demande de la RAM.

Oui ok je vois, c'est un monstre de codebase j'imagine. Merci, et bon courage pour la suite

SCPCD (./17) :
Si jamais t'as un binaire, je suis intéressé de le tester sur la JagFPGA pour voir ce que ça donne dessus

Bonjour SCPCD,
Est-ce que tu es toujours intéressé par tester un binaire sur ton FPGA?
J'ai pu faire tenir une map de test dans les 2MB, en mode Debug, des inits au premier rendu (affichage des textures ligne a ligne).
Le binaire est au format coff, tester sur VJ & VJ-Rx.

oui, ça m’intéresse
Ça donnera l'occasion de la rallumer

SCPCD (./72) :
oui, ça m’intéresse
Ça donnera l'occasion de la rallumer

Cool. Merci. Je t'ai envoyé les liens sur les binaires par message. Vu que c'est que du 68K qui tourne, ton FPGA devrait faire "tourner" le binaire.

On peut avoir quelques infos du coup ? Merci.

fredifredo (./74) :
On peut avoir quelques infos du coup ? Merci.

Aux dernières nouvelles:
1) Le build dédié au menu tournait sur le FPGA, avec du flicker. Ce qui est en lien avec le double buffering vidéo manquant (rien a voir avec le FPGA), mais ca aide a démontrer que la loop du menu tourne.
2) Le build dédié au rendering / engine, se lance sur le FPGA mais ne va pas très loin avec un warning message qui semble tourner en boucle. SCPCD a un doute sur son FPGA; connaissant le code qui tourne autour du warning message, j'ai des doutes aussi mais je penses que SCPCD connait bien mieux son FPGA pour dire si les doutes sont fondés ou non.
SCPCD m'avait aussi reporté un truc bizarre dans le fichier .coff; vu que ma toolchain est basé sur le ELF/DWARF format, je re-export l'exe .elf en .coff, possible que ma moulinette ait du plomb dans l'aile aussi.

Voici quelques nouvelles du port, avec quelques images.
Toujours du 68000 uniquement, améliorations du build system et des outils de transformation des datas; aucune amélioration sur les performances mais je voulais essayer différentes maps et d'afficher au moins un item.
J'ai une vague idée de pourquoi le binaire coff est malformer par ma moulinette binaire ELF->coff.

Affichage d'un item, un ammo_shells en l'occurrence.


Essai du player de cinématique avec le ID Logo, le player devra être remplacer de toutes façons.


Réparation du skydome.

C'est du RGB 15 bits?

Brunni (./77) :
C'est du RGB 15 bits?

8 bits et honnêtement ca "stress" suffisamment.

Ça donne bien, pour dire qu'est-ce que tu entends par stress ?

Brunni (./79) :
Ça donne bien, pour dire qu'est-ce que tu entends par stress ?

Je veux dire ca occupe déjà pas mal de mémoire même en 8 bits.

En parlant de mémoire.
L'engin utilise le concept de mémoire maximale occupée. Genre t'as une petite map, modeste, ben non, les arrays occuperont toujours le même volume de ram. Ca m'a embêter un max on va dire, mes outils adaptent les valeurs selon le besoin de la map.
Ca donne une, ou des maps si elles partagent a peu près les mêmes besoins en ram, par binaire / rom. Adieu le concept de pak file si cher au PC. De toutes façons, avec 6MB de rom faut pas rêver non plus.
Des occupations max en mémoire sont fréquent dans le code, un programmeur PC peut s'en moquer mais c'est un joyeux bordel quand tu n'as pas le luxe d'autant de ram.
Je recommandes aussi les valeurs écrite en dur, sans défines, a la mano, dans le code, que l'on découvre aux moments opportuns… Genre le skydome qui plantait ou pas, la pareil des valeurs additionnées ici et la que je ne prenait pas en compte a l'origine dans mes outils.

Ah oui je vois.

Ben c'est sûr que pour un jeu PC ça n'a pas de sens qu'il tourne sur une machine qui ne peut pas faire tourner la map la plus grande. Et puis à l'époque c'était courant d'éviter autant que possible l'allocation dynamique. Non seulement ça évite tous les problèmes liés à ça (fragmentation, bugs et impacts de performance subtils et imprévisibles…) et au final c'est passablement plus économe en pratique, du moins dans le "pire des cas". Bref facile à déboguer, à optimiser et à comprendre si tu vas au-dessus des limites. Aujourd'hui bien sûr les gains sont négligeables et les performances sont imprévisibles de toute façon, en plus les OS modernes (hors desktop) n'aiment pas les processus qui consomment beaucoup de mémoire, donc on regarde ça différemment.

Du coup y a aucune chance de jamais faire tourner ça sur Tom ? Genre faire en sorte que sa mémoire locale soit un "cache" ?

Brunni (./81) :
Du coup y a aucune chance de jamais faire tourner ça sur Tom ? Genre faire en sorte que sa mémoire locale soit un "cache" ?

Tom a 4KB de ram, je ne vois pas comment faire tenir le bousin la dedans. Ou, alors, je ne comprends pas ta question. Tu peux élaborer si tu veux.

Je connais pas du tout, mais Tom n'a vraiment pas accès à la RAM principale ? Je me doute que 2-3 ko c'est pas assez pour mettre grand-chose en matière de logique du jeu, à part des routines de rendu bien spécifiques ? Mais peut-être que ça resterait plus rapide si le code était exécuté depuis la RAM mais par Tom ?

J'ai lu quelques part que oui, on peut faire tourner Tom dans la ram principale. Je me souviens que quelqu'un avait fait un benchmark a ce sujet.
Je n'ai pas de compilateur gpu/dsp qui tourne sur Windows, ce que j'ai pu trouver tourne sous dos.
Je préfères passer mon temps sur la réduction de l'usage de la ram et d'éliminer les floats. Trouver aussi le soucis avec le binaire coff et pourquoi ca ne passe pas sur BigPEmu.

Brunni, heu, l'allocation dynamique est a proscrire, meme de nos jours!

dilinger (./84) :
J'ai lu quelques part que oui, on peut faire tourner Tom dans la ram principale. Je me souviens que quelqu'un avait fait un benchmark a ce sujet.
Je n'ai pas de compilateur gpu/dsp qui tourne sur Windows, ce que j'ai pu trouver tourne sous dos.
Je préfères passer mon temps sur la réduction de l'usage de la ram et d'éliminer les floats. Trouver aussi le soucis avec le binaire coff et pourquoi ca ne passe pas sur BigPEmu.

Oui il est possible de faire tourner le RISC de TOM en RAM mais c'est "compliqué"
Déjà il faut respecter certaines règles pour éviter de faire "sauter" le contrôleur mémoire avec des sauts alignés "incorrectement"
Mais le plus embêtant c'est qu'on perd quasi tout l'intérêt du RISC de la Jaguar car (quelle qu'en soit la raison ce n'est pas la question ici) le RISC devient alors quasiment aussi lent (sinon aussi lent voir +) que le 68000, en comptant en plus le fait qu'il bouffe alors aussi la bande passante de la RAM.

Le "quelqu'un" qui avait fait les benchs à ce sujet il me semble bien que c'est SCPCD

Merci pour ces informations pertinentes et aussi merci a SCPCD pour ses benchs.
Sans oublier le reste de mes librairies qui se rajouterait a la taille du code du risc. Je ne penses pas que les "efforts" a mettre tom en ram en vaille la peine.

En parlant de ram, voici un aperçu de l'occupation rom et ram pour une de mes maps de tests.

En rom, nous avons approximativement:
Le code occupe 800KB avec Microwindows, et 550KB sans Microwindows.
Le data occupe 1.2MB tout compris, mais 1MB sans Microwindows.

En ram, nous avons approximativement:
La bss occupe 1.2MB, il reste donc moins de 800KB pour le heap et le stack, plus une petite portion pour du data transférer dans la ram.

La bss, et le data, peuvent changer selon les besoins de la map. Il me reste aussi pas mal d'optims a mettre en place pour réduire la bss.
Microwindows est condamner a disparaitre des que le double buffering vidéo sera en place.