Quake 2 - Page 5

Zerosquare (./120) :
Peu importent les perfs, c'est déjà impressionnant que ça tourne tout court.

Merci, c'est apprécié.

Merci pour les news ! Cela reste top comme projet !

J'avoue que je suis assez impressionné par le rendu avec éclairage et la différence sans (mais je ne me suis jamais vraiment intéressé à la 3D en tant que développeur et aux FPS en tant que joueur, donc...).
Ca coute combien en terme de "perfs" d'ajouter l'éclairage ? 10%, 20% ?

En tous cas, c'est vraiment impressionnant d'arriver à faire cracher ça à la Jag. Ca "marche" sur une vraie Jag d'ailleurs ? Et sur BigPEmu en mode performance/boost ?
(il faudrait essayer sur le core accéléré de SCPCD à un moment d'ailleurs même si je ne pense que ça suffira à rendre le tout jouable/acceptable)

odie_one (./122) :
Merci pour les news ! Cela reste top comme projet !

Merci, ca reste du proof of concept, de l'expérimentation. Je continuerai a poster quand j'aurai des news a partager.
Si un jour le fps a la bougeotte, je le ferais savoir illico presto.

Fadest (./123) :
J'avoue que je suis assez impressionné par le rendu avec éclairage et la différence sans (mais je ne me suis jamais vraiment intéressé à la 3D en tant que développeur et aux FPS en tant que joueur, donc...).
Ca coute combien en terme de "perfs" d'ajouter l'éclairage ? 10%, 20% ?

Pour la map que j'ai montré, on parle de moins de 10%. J'allumes les lumières dans une map que de temps en temps histoire de voir si ca fonctionne toujours, sinon mes "tests" se font sans lumières activées.

Fadest (./123) :
En tous cas, c'est vraiment impressionnant d'arriver à faire cracher ça à la Jag. Ca "marche" sur une vraie Jag d'ailleurs ? Et sur BigPEmu en mode performance/boost ?
(il faudrait essayer sur le core accéléré de SCPCD à un moment d'ailleurs même si je ne pense que ça suffira à rendre le tout jouable/acceptable)

Merci. Je n'ai jamais essayé de binaires sur la console. J'avais essayé une map sur BigPEmu, il y a quelques temps, ca marchait en mode normal. Il m'a fallu avant réussir a convertir mon binaire en ELF vers le COFF et résoudre les "soucis" LMA/VMA.
Je n'utilises que mon Virtual Jaguar Rx et les binaires sont en format ELF/DWARF. Toolchain: Vasm / Vlink / gcc compiler / libs "maison". Je compile le code avec d'autres compiler par moment histoire de voir leurs warnings.
Il est impossible qu'un binaire soit "jouable", le code qui s'occupe de l'input n'a pas été encore porter. Je m'en occuperai quand les performances seront (nettement) amélioré ou alors quand je repasserai dans les menus pour les rendre utilisable.

Je n'entendais pas forcément jouable dans le sens gameplay, mais plus dans le sens viable (quelques FPS par secondes).

Combien pèse une scène en ko (je suppose que ça dépend des textures) ? Et combien de secondes pour la générer ?
Parce qu'à défaut d'avoir Quake 2, on pourrait presque envisager de générer des écrans fixes et ajouter du gameplay par dessus type point'n click ou Alone in the Dark/Residant Evil).
Ou finalement, avoir les images compressées pèserait moins lourd dans la ROM que assets+moteur pour les générer ?

est-ce que tu as déjà essayé de réduire drastiquement la fenêtre de rendu, puis de la zoomer en plein écran avec l'OP? On perdrait en résolution évidemment mais ca devrait sensiblement booster les FPS

Fadest (./125) :
Combien pèse une scène en ko (je suppose que ça dépend des textures) ? Et combien de secondes pour la générer ?

C'est un point important dans Quake 2. On peut avoir une map de 300Ko mais qui utilise beaucoup de textures, comme en avoir une de 500Ko et une ou deux textures. Une des demos, de dml, pour son port sur Atari Falcon a montré une map assez grosse et une texture qui se répète, et un skydome, et c'est pas mal du tout comme effet. C'est le classique trade off Level Design / Level Art. Il a aussi tout passé le code en Fixed Point, et il a du en baver.
Je ne comprends pas trop ce que tu entends par "combien de secondes pour générer une scène?"

Fadest (./125) :
Parce qu'à défaut d'avoir Quake 2, on pourrait presque envisager de générer des écrans fixes et ajouter du gameplay par dessus type point'n click ou Alone in the Dark/Residant Evil).

Je ne sais pas, ca sort du cadre de ce que je suis en train de faire / expérimenter. Peut être utiliser la version PC, faire les captures écrans dans les angles souhaités et faire un engin dédié a ce genre de gameplay?

Fadest (./125) :
Ou finalement, avoir les images compressées pèserait moins lourd dans la ROM que assets+moteur pour les générer ?

La résolution du port est 320x240 en 8 bits. Une seule bitmap dans l'OP. A voir un % de compression envisageable. Assets et Engine seraient de toute façons plus malléable, changer la position du spawn point a la demande mais cette feature n'existe pas (ou alors je ne l'ai pas encore découvert).

J'espères que mes réponses peuvent aider mais, en ce qui me concerne, je suis en mode expérimental. Le cote "productif" ne m'intéresse pas. Je continuerai a poster ici si j'ai des news et si un jour le fps a la bougeotte et bien vous serez les premiers a le savoir.

lordkraken (./126) :
est-ce que tu as déjà essayé de réduire drastiquement la fenêtre de rendu, puis de la zoomer en plein écran avec l'OP? On perdrait en résolution évidemment mais ca devrait sensiblement booster les FPS

Tu veux dire modifier le setting viewsize utilisé par l'engin? Ce qui crée juste une petite fenêtre de rendu avec du border noir autour?

dilinger (./127) :
J'espères que mes réponses peuvent aider mais, en ce qui me concerne, je suis en mode expérimental. Le cote "productif" ne m'intéresse pas. Je continuerai a poster ici si j'ai des news et si un jour le fps a la bougeotte et bien vous serez les premiers a le savoir.

En fait, vu que je suis en période 100% improductif, je laisse le cerveau dériver sur des idées débiles sans plan précis.
Dans tous les cas, chapeau bas pour ton travail, fais ce qui te plait, quand tu as envie de le faire, c'est encore le meilleur moyen de ne pas se laisser bouffer par un projet de ce genre, surtout dans la scène Jaguar.

dilinger (./128) :

lordkraken (./126) :
est-ce que tu as déjà essayé de réduire drastiquement la fenêtre de rendu, puis de la zoomer en plein écran avec l'OP? On perdrait en résolution évidemment mais ca devrait sensiblement booster les FPS

Tu veux dire modifier le setting viewsize utilisé par l'engin? Ce qui crée juste une petite fenêtre de rendu avec du border noir autour?

pas tout a fait, tu fais le rendu de ta scene dans une texture avec une faible resolution, disons 160 * 120, que tu utilise comme data pour un bitmap object scalé à 2x, du coup full screen

Fadest (./129) :
En fait, vu que je suis en période 100% improductif, je laisse le cerveau dériver sur des idées débiles sans plan précis.
Dans tous les cas, chapeau bas pour ton travail, fais ce qui te plait, quand tu as envie de le faire, c'est encore le meilleur moyen de ne pas se laisser bouffer par un projet de ce genre, surtout dans la scène Jaguar.

Merci d'être sur ce forum et de lire mes posts.

lordkraken (./130) :
pas tout a fait, tu fais le rendu de ta scene dans une texture avec une faible resolution, disons 160 * 120, que tu utilise comme data pour un bitmap object scalé à 2x, du coup full screen

J'ai souvenir d'un thread sur une question que j'avais eu dans cette optique, mais je cherchais une résolution vidéo pas un rendu dans une texture.
topics/193775-mode-low-resolution-160x120-8-bits#post-1
Ta méthode proposée est élégante. Merci.
hormis les menus/UI, dont les spirites sont bâtis pour du 320x240, le renderer ne devrait pas avoir de problèmes au vu de mes tests d'il y a... 3 ans... Je vais chercher dans les git commits.

Attention, le scaling via l'OP a un impact négatif sur les perfs, contrairement aux astuces indiquées dans l'autre topic (bon après, si tu testes jamais sur la machine physique, tu t'en fous... )

évidemment ca a un cout, mais qui je pense sera largement contrebalancé par la fenêtre de rendu réduite

Oui ce sera toujours plus rapide que du 320x240, mais autant économiser au maximum en utilisant ce qui consomme le moins de ressources

Merci pour ces informations, je me suis rajouté un issue dans le github.
Je préfères l'émulation pour le moment, c'est plus pratique même si mon laptop date de 8 ans et commence a tousser.

Bonsoir.

Je n'ai pas beaucoup avancer sur le "port".
Je voulais partager des screens d'un pak "Last day on Stroggos" que j'ai trouvé et qui m'a aidé a tester des trucs, notamment la ligne alias d1 "map idlog.cin+strogg04" dans le autoexec.cfg. Ca lance la cinématique idlog et ensuite la map. Chose que je ne pouvais pas vraiment faire avant, aucune performance c'est sur. Le format .cin met le 68000 à genoux dans dans une mine en Alaska, comme le reste d'ailleurs.

Screenshot venant de la cinematique.


Screenshot des maps vu du spawn point

Joli

Bonjour,

Un modeste update sur le "port", je suis en mode de passer tout le bousin en fixed point.
Donnant sa chance au mode natif du fixed point du gcc; commencer en 2008, des développeurs avaient fait un travail préparatoire pour le support du "N1169 draft of the ISO/IEC DTR 18037 standard for embedded systems".
A force de poser des questions, d'voir des points de vues divergents, et de triturer le gcc, j'ai pu réactiver ce support pour le signed _Accum et un peu de _Fract, fixer des problèmes, et ajouter les fonctions insn, maths (libm) et bas niveau (libgcc) pour le 68000.
Pris isolement. les tests fonctionnent et ca augure bien en terme de performances. Pas encore de binaire Quake 2, il y a encore pleins de trucs a adapter (code et data) mais au moins je fais dans le code manuel quand j'ai plus le choix.
A priori, le bousin gcc + Quake 2 fonctionnera ensemble, et le gcc pourrait être utile pour d'autres plateformes 68000/10/20/30.
Avantage, au lieu de faire float, on utilise _Accum et le compilateur gcc fait le reste.

Tu dois du coup déterminer la bonne précision en fonction de l'usage j'imagine. Ça doit pas être facile...

Brunni (./139) :
Tu dois du coup déterminer la bonne précision en fonction de l'usage j'imagine. Ça doit pas être facile...

Pour le moment, j'utilise juste _Accum (S1Q16.15) au lieu de float; j'ai ajouté un typedef _float qui me permet de compiler soit avec float soit avec _Accum.
L'effet secondaire permet aussi de voir les types conversions qui bouffent du cycles 68000.

Ouais après le 1.16.15 c'est pas forcément idéal pour les calculs directement liés à la 3D, et ça peut être super chiant à déboguer les soucis liés à un overflow. Enfin bon courage tu as deja pu tester un peu, ça s'affiche toujours à peu près correctement ?

Brunni (./141) :
Ouais après le 1.16.15 c'est pas forcément idéal pour les calculs directement liés à la 3D, et ça peut être super chiant à déboguer les soucis liés à un overflow. Enfin bon courage tu as deja pu tester un peu, ça s'affiche toujours à peu près correctement ?

C'est exact mais passer en Q16.16 a la main, ca me rendait dingue. C'est pour ca que je suis passe en mode gcc _Accum. Ca me prend du temps aussi, mais c'est plus "fun".
Pour la saturation, il existe un _Sat pour le _Accum et _Fract mais je le supporte pas vraiment en 68000, ca existe oui et gcc le prend en compte.
Et, pas encore d'integration Quake 2, ca va prendre encore du temps pour avoir le bousin et avoir le data des maps en _Accum.
C'est plus du test gcc et libs séparer pour le moment.