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