Re: [SPIN-OFF] COSMOS version Nintendo NES ?

[drfloyd]

oui, tout doit se passer dans une seule et unique fenetre (de la taille de ton choix), l'ideal etant selon moi 178*178 (11*11 cases de 16 pixels) mais la je parle pour uen def de 320*200... a voir dans ton cas avec la definition Nes....

Chaque ecran ne doit pas necessiter d'actualiser d'autres ecrans, sinon la Nes ne va pas suivre et ca va prendre des plombes. Pour cela dans chaque plan doit avoir une donnée repere issue des plans de niveau supérieur. Et tu crée ton plan en commencant par un "RANDOMIZE" avec cette valeur)

Il ne faut en aucun cas par exemple garder en mémoire tes 6 plans de zoom pour une planete (d'ailleurs c'est énorme 6 plans de zoom pour une planete ???)... attention à ne pas "perdre" le joueur.

Chaque plan se crée en temps réel à leur apparition.

[vincent2105]

Je pense choisir une fenêtre de 128x128 px parce que ca correspond à une zone de 16 tiles x 16 tiles soient 256 octets, vue que je ne travaille qu'avec des registres 8 bits, ça m'épargne pas mal de complications. 

Pour le reste, on verra bien, je me suis déjà cassé les dents un nombre incalculable de fois, je suis pas à une près :) C'est formateur.

[vincent2105]

Dans le cas le plus critique (cad changement d'écran au niveau du sol), on a au maximum 5 plans à mettre à jour, mais  l'occurence est rare.  
Pour donner une idée (en incluant des changements de direction occasionnels 1/8)
- Dans 1 changement d'écran sur 8 il faut maj 1 plan d'altitude supérieur,
- Dans 1 changement d'écran sur 64 il faut maj 2 plans d'altitude supérieur,
- Dans 1 changement d'écran sur 512 il faut maj 3 plans d'altitude supérieur,
Etc
Et chaque plan n'occupe que 256 octets contre 960 pour une nametable complète (en faisant abstraction des attributs de couleurs).
Après faut voir comment on torture chaque octet pour randomizer tout ça. C'est là qu'il va falloir être bon. Voir combien de cycles on passe sur chaque octet telle est la question...
Après je peux me gourer complétement

[Urbinou]

Dans le cas le plus critique (cad changement d'écran au niveau du sol), on a au maximum 5 plans à mettre à jour, mais  l'occurence est rare.  
Pour donner une idée (en incluant des changements de direction occasionnels 1/8)
- Dans 1 changement d'écran sur 8 il faut maj 1 plan d'altitude supérieur,
- Dans 1 changement d'écran sur 64 il faut maj 2 plans d'altitude supérieur,
- Dans 1 changement d'écran sur 512 il faut maj 3 plans d'altitude supérieur,

Pas sûr de saisir le problème (pourquoi maintenir les plans up to date constamment ?) mais... chaque mouvement induit systématiquement un changement dans tous les plans directement inférieurs.

[vincent2105]

Pour ce qui est du plan d'altitude inférieur, à mes yeux, il n'est concerné que si on s'y rend, et je repositionnerai le joueur systématiquement "au centre" de la zone 16x16 (genre en (x7, y7) ).
Sinon, c'est toujours la tile du plan d'altitude supérieur qui définit l'écran a afficher. C'est pour cette raison que je maj les plans supérieurs dès que cela est nécessaire (et uniquement dans ce cas précis, donc en moyenne tous les 8 changements d'écran vu qu'on est sur une grille 16x16). Peut être n'est il pas nécessaire de les conserver en RAM en permanence, c'est possible.
La planete est composée de tiles choisies aléatoirement (dans une certaine mesure),puis il en est de même pour les niveaux de plus faible altitude si on zoome (en fonction l'octet sur lequel on se trouve). Tout est rendu plus simple pour les routines puisque chaque plan fait 16x16 tiles soit 256 octets.



Désolé si j'expose mal la situation   ... Dans tous les cas, j'ai pas de pb particulier pour l'instant, mais ca sera peut-être le cas pour une randomisation optimale. Pour l'instant ça m'amuse

[vincent2105]

Je n'ai toujours pas assemblé la moindre ligne de code, je continue de réfléchir à l'ensemble... 

En ce qui concerne la topographie, je pense opter pour une base en ROM, 256 tiles qui renvoient à 256 nametables de 256 octets (64Ko / 512 dispos).  Grace aux 8Ko de RAM, rien ne m'empêchera de modifier des tiles de ci de là, et surtout, grâce aux 256 Ko de CHR ROM, je pourrais appliquer des skins différents (au moins un par niveau de zoom, et pourquoi pas un tileset propre à chaque type de planète, à 4Ko le tileset de 256 tiles, pourquoi s'en priver ?). 
Je ne fais pas une croix sur le procedural, mais y'aura une base en ROM, qui permettra malgré tout une bonne diversité... 
Par ailleurs, je commence à être assez séduit par l'idée de représenter les pnj et le héros par des sprites de taille 8x8. Lors des actions importantes, la fenetre de vue de dessus laisserait place à une illustration de la scene. (rencontre avec un ennemi, lieu important, etc)...

[drfloyd]

affiche les PNJ sous forme de sprites generiques monocolors tout petits, comme dans SUNDOG.

tu as trop de zooms niveau, le joueur va s'y perdre..... pour le splanetes je ne frrai que 3 niveaux de zoom perso :

vu d'ensemble de la planete
vu de tres haut (un peu comme une map de rpg)
vu de tres pres

quitte à ne pas respecter les dimensions reelles d'une planete...

[vincent2105]

Pour le nombre de niveaux de zoom, je savais que tu tiquerai  
Mais si tu regardes bien le petit croquis que j'ai fait plus haut, en ne conservant que les 3 derniers niveaux de zoom par exemple,  il n'est pas possible d'avoir une surface totale de plus de 16 Km² (4km x 4km ... si on veut une concordance des déplacements d'un plan à l'autre...)
Après je comprends que ça ne va pas dans ton sens, comme je te l'ai dit ca sera surement un spin off de ton COSMOS, y'aura peut-être d'autres points qui n'iront pas avec ta vision de la chose et qui pourtant me plairont particulièrement, donc si tu ne veux pas que ce projet y soit rattaché dis le moi sans détour, je continuerai avec un autre nom, y'a pas de problème

[TotOOntHeMooN]

Tu ne paux simplement pas "sauter" des niveaux de zoom ?
(quite à t'en servir pour faire un effet de zoom justement)

[vincent2105]

Avec ma fenêtre 128x128 px, non. Je suis sur un quadrillage 16x16 (tiles) quel que soit le niveau de zoom. Et de toute façon même avec la totalité des 256x240px dispo, ça ne serait pas possible.
Je vais essayer d'expliquer autrement ( de facon très succinte    )

Soit x5 la position x sur le plan 5.
si x5 +=16 alors x4 +=1
si x4 +=16 alors x3 +=1
donc si x5 +=256 alors x3 +=1
Chaque plan dépend du/des plan(s) d'altitude supérieur.

Mais bon, perso, ça me pose vraiment pas de problème d'avoir 6 plans... 1 skin et une palette différente pour chaque plan et le tour est joué si je peux dire.

Si vraiment on ne voulait conserver que 3 niveaux de zoom pour une planète,  en considèrant qu'une tile sur la vue au sol représente 1 mètre, avec la même idée, pour chaque plan, un quadrillage de 251x251 serait nécessaire pour une même planète de 16000 km de diamètre... même une planète de 100 km de diamètre nécessiterait un quadrillage de 46x46... Ce n'est pas possible avec une NES qui affiche 32*30 tiles.

Mais j'ai peut-être la tête dans le guidon

[vincent2105]

Je commence à y voir plus clair dans l'agencement des tilesets et nametables... Je pense tenir le bon bout, et comme vous le disiez, inutile de tenir chaque plan à jour, ça sert de réfléchir 2 minutes   .
Je vais synthétiser tout ça avant d'attaquer le code et les tilesets... y'a du pain sur la planche !

[vincent2105]

Pour pousser le délire à son paroxysme, je suis en train de voir si je peux pas inclure cours d'eau, routes, etc...
J'adore ce projet...

[drfloyd]

Eclate toi !

[vincent2105]

Sur le papier, j'ai bien dégrossi le problème, et sauf erreur, j'ai ma routine d'affichage de fenêtre 128x128 px.
Je vais pouvoir attaquer... mais dans un premier temps, ca va être mise en place des banks / configuration et tout le toutim...

[vincent2105]

Affichage de la fenêtre 128x128 ok... 
C'est moche, mais ça marche   

EDIT : 
C'est peut-être plus parlant avec les attributs de couleur

[drfloyd]

c'est un bon début on semble distinguer uen riviere, une foret, des montagnes 

[vincent2105]

Avant d'attaquer nametables et tilesets, je vais me pencher sur les déplacements, changement de plan et positions sur chaque plan.
Vu que je travaille sur une grille 16x16, je ne vais avoir besoin que d'un caractere ("0" à "F").
Donc pour les 6 plans, on aura par exemple :
X : 0492E5
Y : B7743A

Prochaine évolution graphique : le sprite 8x8 du vaisseau 

[drfloyd]

Chaud le sprite 8x8 !

[vincent2105]

Ca sera une soucoupe volante (vue au zenith)
Ca me donne déjà quelques idées de gameplay, car on peut s'autoriser à changer de direction brusquement (plus qu'avec une navette), pour les combats, ça peut être sympa.
Mais ma priorité, c'est les déplacements/position sur chaque plan, c'est parti  

[Invité]

Bon courage Vincent !!
Je suis ce projet de folie et suis curieux de voir comment tu vas agencer un jeu, sous le regard avisé de Lord British !!

[vincent2105]

Merci Vetea, ça fait plaisir

[vincent2105]

Remise en question... J'ai pas mal avancé la routine de déplacement / position sur chaque plan et j'ai testé sur NES. 
Outre un petit bug graphique, c'est surtout qu'on se sent un peu à l'étroit.
Je réfléchis à la possibilité d'utiliser une grille 24x24 plutôt que 16x16.
Premier avantage, on peut faire sauter un niveau de zoom et avoir une planète de 8000 km de diamètre malgrès tout.

[drfloyd]

8000km de diametre c'est leger, les grosses planetes telluriques peuvent monter bien plus haut.

A savoir que théoriquement uen planete tellurique comme la Terre ne pourrait pas depasser environ 25 à 30 000 km de diametre... ca semble etre un grand maximum

Bon apres il y a le splanetes gazeuse qui elles peuvent monter à des millions de km de diametre ! Mais là ca depend si tu envisages de pouvoir les survoler de près

[vincent2105]

Ok. Donc vaut mieux conserver les 6 plans alors et avec le ratio "une tile = 1 mètre" en vue au sol, on arriverait à un diametre de près de 190000 km (24^6)... Ca devrait pas poser de pb particulier de conserver les 6 plans. Un plan de plus on atteindrait 4,5M de km.
Faut voir... En tout cas je vais me pencher sur la grille 24x24 sérieusement.

[TotOOntHeMooN]

Sur les screens du Doc (320x240), les tiles sont en 16x16. Déjà qu'avec la résolution de la NES tu n'es pas aidé...
Alors, si en plus tu viens à grossir les gfx, tu as deux problèmes de tailles en retour :
- Il faudra revoir tous les tiles et non seulement leurs couleurs
- Tu afficheras vraiment rien à l'écran et ça sera peut coloré

[vincent2105]

Oui je comptais revoir tous les gfx de COSMOS (l'original). En fait, j'use du nom, mais c'est vrai que je fais un peu tout à ma sauce puisque j'ai le consentement du Doc   
Eventuellement, je pourrais repiquer les visages des personnages rencontrés et autres... Mais j'en suis encore très loin.

Edit : j'ai lu en diagonale, excuse moi... non, je ne compte pas grossir les gfx. Je compte juste agrandir la fenetre (passer de 128x128 px à 192x192 px)

[vincent2105]

P'tit test avec une fenêtre 24x24. On se sent moins à l'étroit.
Je déclenche une interruption à la dernière ligne du hud pour avoir 100% des index de tiles dispos pour la carte. Comme on le voit sur la capture, c'est pas net, mais je sais comment régler le pb (merci @brokestudio )
Ce soir, je  m'occuperai de la routine de position sur chaque plan.
Pour définir la position je n'utiliserai finalement que des lettres. Vu que la grille fait 24 cases de coté, j'ai besoin de quasiment tout l'alphabet, du coup certaines positions sur la carte auront du sens, et je trouve ça marrant  
Pour la taille de la soucoupe, pour l'instant, c'est du 8x8 (avec un contour gris en plus   ), je verrai plus tard si je passe en 16x16...
Avec une nametable dessinée à la main :

[drfloyd]

ah, sur cet exemple c'est une planete oceanique assez froide avec des glaciers ?

[vincent2105]

Ca pourrait oui, j'ai fait ça en 2 minutes, je me suis pas torturé
Mais promis je prévois de la diversité C'est un des trucs qui me botte.

[drfloyd]

c'est aussi passionnant de générer des maps le plus crédible possible avec un minimum de calculs

[vincent2105]

Quand j'en aurai fini avec mes histoires de niveaux de zoom et mes tilesests, en effet, je me pencherai sérieusement là dessus, c'est tout aussi intéressant (j'ai une piste, avec une base en ROM)...